build 6ddc7a35 | content blog-content@417154f · 338 posts | profiles 32 · corpus 315 | ● 0 skipped | format run

$ soultec get service/data-management -o yaml$ soultec get service/data-management -o json$ soultec get service/data-management -o toml$ soultec get service/data-management -o xml$ python3 data-management.pyPS> ./data-management.ps1$ go run data-management.go$ node data-management.js

apiVersion: soultec.ch/v1kind: Servicemetadata: name: data-management locale: en labels: group: infrastructure capability/data-management: 2.87 capability/storage: 2.36 capability/architecture: 2.51 vendor/hpe: 1.99 vendor/ibm: 3.70 annotations: source: src/content/services/en/data-management.md route: /en/services/data-management/ schema: /nerd/schema/services.json markdown: /en/services/data-management.mdspec: title: Data Management group: infrastructure audience: [enterprise, provider] order: 2 tags: [data-management, storage, architecture] vendors: [hpe, ibm] summary: >- Software-defined storage against data growth. The real gain is that the next data migration does not happen. photoNeed: >- Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration stub: false draft: false sections: - heading:

The problem

body: | Data grows, and classic block storage often lacks the functionality for that kind of growth. At some point the problem stops being capacity and becomes the next migration onto the next system. - heading:

The approach

body: | Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM Spectrum Scale, because they have different strengths and the choice should follow the requirements rather than the other way round. What these products have in common is why they solve the problem: they run on standard x86 servers, scale out as clusters rather than up, replicate synchronously or asynchronously across sites, and speak the protocols that are actually needed, meaning S3, NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does not need a migration. Before that choice there is a requirements engineering workshop. Not as a formality: without clarity on the access patterns, availability requirements and retention periods that actually apply, every product decision is guesswork. - heading:

What it actually buys

body: | **No more migrations.** Once the data is on an SDS platform, the platform owns the lifecycle. Changing the hardware underneath becomes an operation rather than a project. **Availability to match.** Synchronous or asynchronous mirroring into a co-location or into the public cloud, depending on what is needed. **Growth is designed in.** Extending onto further clusters is part of the model rather than the exception.status: corpus: 315 solutions: - {ref: solutions/hpe/hpe-storage/alletra-storage-mp-b10000, score: 0.77} - {ref: solutions/hpe/hpe-storage/alletra-storage-mp-x10000, score: 0.77} - {ref: solutions/hpe/hpe-storage/greenlake-for-file-storage, score: 0.77} - {ref: solutions/hpe/hpe-data-management, score: 0.77} alsoLike: - {ref: solutions/hpe/hpe-storage, score: 0.77} - {ref: services/storage, score: 0.77} - {ref: solutions/hpe, score: 0.59} experts: - {ref: experts/norbert-hamm, score: 0.51} - {ref: experts/michael-steg, score: 0.44} - {ref: experts/christian-schnyder, score: 0.42} search: /en/search.json
{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "data-management", "locale": "en", "labels": { "group": "infrastructure", "capability/data-management": 2.87, "capability/storage": 2.36, "capability/architecture": 2.51, "vendor/hpe": 1.99, "vendor/ibm": 3.7 }, "annotations": { "source": "src/content/services/en/data-management.md", "route": "/en/services/data-management/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/data-management.md" } }, "spec": { "title": "Data Management", "group": "infrastructure", "audience": [ "enterprise", "provider" ], "order": 2, "tags": [ "data-management", "storage", "architecture" ], "vendors": [ "hpe", "ibm" ], "summary": "Software-defined storage against data growth. The real gain is that the next data migration does not happen.", "photoNeed": "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", "stub": false, "draft": false, "sections": [ { "heading": "

The problem

",
"body": "Data grows, and classic block storage often lacks the functionality for that kind of\ngrowth. At some point the problem stops being capacity and becomes the next migration onto\nthe next system." }, { "heading": "

The approach

",
"body": "Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM Spectrum\nScale, because they have different strengths and the choice should follow the requirements\nrather than the other way round.\n\nWhat these products have in common is why they solve the problem: they run on standard\nx86 servers, scale out as clusters rather than up, replicate synchronously or\nasynchronously across sites, and speak the protocols that are actually needed, meaning S3,\nNFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does not\nneed a migration.\n\nBefore that choice there is a requirements engineering workshop. Not as a formality:\nwithout clarity on the access patterns, availability requirements and retention periods\nthat actually apply, every product decision is guesswork." }, { "heading": "

What it actually buys

",
"body": "**No more migrations.** Once the data is on an SDS platform, the platform owns the\nlifecycle. Changing the hardware underneath becomes an operation rather than a project.\n\n**Availability to match.** Synchronous or asynchronous mirroring into a co-location or into\nthe public cloud, depending on what is needed.\n\n**Growth is designed in.** Extending onto further clusters is part of the model rather than\nthe exception." } ] }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/hpe/hpe-storage/alletra-storage-mp-b10000", "score": "0.77" }, { "ref": "solutions/hpe/hpe-storage/alletra-storage-mp-x10000", "score": "0.77" }, { "ref": "solutions/hpe/hpe-storage/greenlake-for-file-storage", "score": "0.77" }, { "ref": "solutions/hpe/hpe-data-management", "score": "0.77" } ], "alsoLike": [ { "ref": "solutions/hpe/hpe-storage", "score": "0.77" }, { "ref": "services/storage", "score": "0.77" }, { "ref": "solutions/hpe", "score": "0.59" } ], "experts": [ { "ref": "experts/norbert-hamm", "score": "0.51" }, { "ref": "experts/michael-steg", "score": "0.44" }, { "ref": "experts/christian-schnyder", "score": "0.42" } ], "search": "/en/search.json" }}
apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "data-management"locale = "en"[metadata.labels]group = "infrastructure""capability/data-management" = 2.87"capability/storage" = 2.36"capability/architecture" = 2.51"vendor/hpe" = 1.99"vendor/ibm" = 3.7[metadata.annotations]source = "src/content/services/en/data-management.md"route = "/en/services/data-management/"schema = "/nerd/schema/services.json"markdown = "/en/services/data-management.md"[spec]title = "Data Management"group = "infrastructure"audience = ["enterprise", "provider"]order = 2tags = ["data-management", "storage", "architecture"]vendors = ["hpe", "ibm"]summary = "Software-defined storage against data growth. The real gain is that the next data migration does not happen."photoNeed = "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration"stub = falsedraft = false[[spec.sections]]heading = "

The problem

"
body = '''Data grows, and classic block storage often lacks the functionality for that kind ofgrowth. At some point the problem stops being capacity and becomes the next migration ontothe next system.'''[[spec.sections]]heading = "

The approach

"
body = '''Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM SpectrumScale, because they have different strengths and the choice should follow the requirementsrather than the other way round.What these products have in common is why they solve the problem: they run on standardx86 servers, scale out as clusters rather than up, replicate synchronously orasynchronously across sites, and speak the protocols that are actually needed, meaning S3,NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does notneed a migration.Before that choice there is a requirements engineering workshop. Not as a formality:without clarity on the access patterns, availability requirements and retention periodsthat actually apply, every product decision is guesswork.'''[[spec.sections]]heading = "

What it actually buys

"
body = '''**No more migrations.** Once the data is on an SDS platform, the platform owns thelifecycle. Changing the hardware underneath becomes an operation rather than a project.**Availability to match.** Synchronous or asynchronous mirroring into a co-location or intothe public cloud, depending on what is needed.**Growth is designed in.** Extending onto further clusters is part of the model rather thanthe exception.'''[status]corpus = 315search = "/en/search.json"[[status.solutions]]ref = "solutions/hpe/hpe-storage/alletra-storage-mp-b10000"score = "0.77"[[status.solutions]]ref = "solutions/hpe/hpe-storage/alletra-storage-mp-x10000"score = "0.77"[[status.solutions]]ref = "solutions/hpe/hpe-storage/greenlake-for-file-storage"score = "0.77"[[status.solutions]]ref = "solutions/hpe/hpe-data-management"score = "0.77"[[status.alsoLike]]ref = "solutions/hpe/hpe-storage"score = "0.77"[[status.alsoLike]]ref = "services/storage"score = "0.77"[[status.alsoLike]]ref = "solutions/hpe"score = "0.59"[[status.experts]]ref = "experts/norbert-hamm"score = "0.51"[[status.experts]]ref = "experts/michael-steg"score = "0.44"[[status.experts]]ref = "experts/christian-schnyder"score = "0.42"
<?xml version="1.0" encoding="UTF-8"?><manifest kind="Service"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>data-management</name> <locale>en</locale> <labels> <group>infrastructure</group> <entry key="capability/data-management">2.87</entry> <entry key="capability/storage">2.36</entry> <entry key="capability/architecture">2.51</entry> <entry key="vendor/hpe">1.99</entry> <entry key="vendor/ibm">3.7</entry> </labels> <annotations> <source>src/content/services/en/data-management.md</source> <route>/en/services/data-management/</route> <schema>/nerd/schema/services.json</schema> <markdown>/en/services/data-management.md</markdown> </annotations> </metadata> <spec> <title>Data Management</title> <group>infrastructure</group> <audience> <item>enterprise</item> <item>provider</item> </audience> <order>2</order> <tags> <item>data-management</item> <item>storage</item> <item>architecture</item> </tags> <vendors> <item>hpe</item> <item>ibm</item> </vendors> <summary>Software-defined storage against data growth. The real gain is that the next data migration does not happen.</summary> <photoNeed>Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration</photoNeed> <stub>false</stub> <draft>false</draft> <sections> <section> <heading>

The problem

</heading>
<body>Data grows, and classic block storage often lacks the functionality for that kind ofgrowth. At some point the problem stops being capacity and becomes the next migration ontothe next system. </body> </section> <section> <heading>

The approach

</heading>
<body>Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM SpectrumScale, because they have different strengths and the choice should follow the requirementsrather than the other way round.What these products have in common is why they solve the problem: they run on standardx86 servers, scale out as clusters rather than up, replicate synchronously orasynchronously across sites, and speak the protocols that are actually needed, meaning S3,NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does notneed a migration.Before that choice there is a requirements engineering workshop. Not as a formality:without clarity on the access patterns, availability requirements and retention periodsthat actually apply, every product decision is guesswork. </body> </section> <section> <heading>

What it actually buys

</heading>
<body>**No more migrations.** Once the data is on an SDS platform, the platform owns thelifecycle. Changing the hardware underneath becomes an operation rather than a project.**Availability to match.** Synchronous or asynchronous mirroring into a co-location or intothe public cloud, depending on what is needed.**Growth is designed in.** Extending onto further clusters is part of the model rather thanthe exception. </body> </section> </sections> </spec> <status> <corpus>315</corpus> <solutions> <item> <ref>solutions/hpe/hpe-storage/alletra-storage-mp-b10000</ref> <score>0.77</score> </item> <item> <ref>solutions/hpe/hpe-storage/alletra-storage-mp-x10000</ref> <score>0.77</score> </item> <item> <ref>solutions/hpe/hpe-storage/greenlake-for-file-storage</ref> <score>0.77</score> </item> <item> <ref>solutions/hpe/hpe-data-management</ref> <score>0.77</score> </item> </solutions> <alsoLike> <item> <ref>solutions/hpe/hpe-storage</ref> <score>0.77</score> </item> <item> <ref>services/storage</ref> <score>0.77</score> </item> <item> <ref>solutions/hpe</ref> <score>0.59</score> </item> </alsoLike> <experts> <item> <ref>experts/norbert-hamm</ref> <score>0.51</score> </item> <item> <ref>experts/michael-steg</ref> <score>0.44</score> </item> <item> <ref>experts/christian-schnyder</ref> <score>0.42</score> </item> </experts> <search>/en/search.json</search> </status></manifest>
# Code generated by the soultec.ch build. DO NOT EDIT.import jsonPAGE = { "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "data-management", "locale": "en", "labels": { "group": "infrastructure", "capability/data-management": 2.87, "capability/storage": 2.36, "capability/architecture": 2.51, "vendor/hpe": 1.99, "vendor/ibm": 3.7, }, "annotations": { "source": "src/content/services/en/data-management.md", "route": "/en/services/data-management/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/data-management.md", }, }, "spec": { "title": "Data Management", "group": "infrastructure", "audience": ["enterprise", "provider"], "order": 2, "tags": ["data-management", "storage", "architecture"], "vendors": ["hpe", "ibm"], "summary": "Software-defined storage against data growth. The real gain is that the next data migration does not happen.", "photoNeed": "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", "stub": False, "draft": False, "sections": [ { "heading": "

The problem

",
"body": ( "Data grows, and classic block storage often lacks the functionality for that kind of\n" "growth. At some point the problem stops being capacity and becomes the next migration onto\n" "the next system." ), }, { "heading": "

The approach

",
"body": ( "Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM Spectrum\n" "Scale, because they have different strengths and the choice should follow the requirements\n" "rather than the other way round.\n" "\n" "What these products have in common is why they solve the problem: they run on standard\n" "x86 servers, scale out as clusters rather than up, replicate synchronously or\n" "asynchronously across sites, and speak the protocols that are actually needed, meaning S3,\n" "NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does not\n" "need a migration.\n" "\n" "Before that choice there is a requirements engineering workshop. Not as a formality:\n" "without clarity on the access patterns, availability requirements and retention periods\n" "that actually apply, every product decision is guesswork." ), }, { "heading": "

What it actually buys

",
"body": ( "**No more migrations.** Once the data is on an SDS platform, the platform owns the\n" "lifecycle. Changing the hardware underneath becomes an operation rather than a project.\n" "\n" "**Availability to match.** Synchronous or asynchronous mirroring into a co-location or into\n" "the public cloud, depending on what is needed.\n" "\n" "**Growth is designed in.** Extending onto further clusters is part of the model rather than\n" "the exception." ), }, ], }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/hpe/hpe-storage/alletra-storage-mp-b10000", "score": "0.77", }, { "ref": "solutions/hpe/hpe-storage/alletra-storage-mp-x10000", "score": "0.77", }, { "ref": "solutions/hpe/hpe-storage/greenlake-for-file-storage", "score": "0.77", }, { "ref": "solutions/hpe/hpe-data-management", "score": "0.77", }, ], "alsoLike": [ { "ref": "solutions/hpe/hpe-storage", "score": "0.77", }, { "ref": "services/storage", "score": "0.77", }, { "ref": "solutions/hpe", "score": "0.59", }, ], "experts": [ { "ref": "experts/norbert-hamm", "score": "0.51", }, { "ref": "experts/michael-steg", "score": "0.44", }, { "ref": "experts/christian-schnyder", "score": "0.42", }, ], "search": "/en/search.json", },}if __name__ == "__main__": print(json.dumps(PAGE, indent=2, ensure_ascii=False))
# Code generated by the soultec.ch build. DO NOT EDIT.$Page = [ordered]@{ apiVersion = 'soultec.ch/v1' kind = 'Service' metadata = [ordered]@{ name = 'data-management' locale = 'en' labels = [ordered]@{ group = 'infrastructure' 'capability/data-management' = 2.87 'capability/storage' = 2.36 'capability/architecture' = 2.51 'vendor/hpe' = 1.99 'vendor/ibm' = 3.7 } annotations = [ordered]@{ source = 'src/content/services/en/data-management.md' route = '/en/services/data-management/' schema = '/nerd/schema/services.json' markdown = '/en/services/data-management.md' } } spec = [ordered]@{ title = 'Data Management' group = 'infrastructure' audience = @('enterprise', 'provider') order = 2 tags = @('data-management', 'storage', 'architecture') vendors = @('hpe', 'ibm') summary = 'Software-defined storage against data growth. The real gain is that the next data migration does not happen.' photoNeed = 'Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration' stub = $false draft = $false sections = @( [ordered]@{ heading = '

The problem

'
body = @'Data grows, and classic block storage often lacks the functionality for that kind ofgrowth. At some point the problem stops being capacity and becomes the next migration ontothe next system.'@ } [ordered]@{ heading = '

The approach

'
body = @'Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM SpectrumScale, because they have different strengths and the choice should follow the requirementsrather than the other way round.What these products have in common is why they solve the problem: they run on standardx86 servers, scale out as clusters rather than up, replicate synchronously orasynchronously across sites, and speak the protocols that are actually needed, meaning S3,NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does notneed a migration.Before that choice there is a requirements engineering workshop. Not as a formality:without clarity on the access patterns, availability requirements and retention periodsthat actually apply, every product decision is guesswork.'@ } [ordered]@{ heading = '

What it actually buys

'
body = @'**No more migrations.** Once the data is on an SDS platform, the platform owns thelifecycle. Changing the hardware underneath becomes an operation rather than a project.**Availability to match.** Synchronous or asynchronous mirroring into a co-location or intothe public cloud, depending on what is needed.**Growth is designed in.** Extending onto further clusters is part of the model rather thanthe exception.'@ } ) } status = [ordered]@{ corpus = 315 solutions = @( [ordered]@{ ref = 'solutions/hpe/hpe-storage/alletra-storage-mp-b10000' score = '0.77' } [ordered]@{ ref = 'solutions/hpe/hpe-storage/alletra-storage-mp-x10000' score = '0.77' } [ordered]@{ ref = 'solutions/hpe/hpe-storage/greenlake-for-file-storage' score = '0.77' } [ordered]@{ ref = 'solutions/hpe/hpe-data-management' score = '0.77' } ) alsoLike = @( [ordered]@{ ref = 'solutions/hpe/hpe-storage' score = '0.77' } [ordered]@{ ref = 'services/storage' score = '0.77' } [ordered]@{ ref = 'solutions/hpe' score = '0.59' } ) experts = @( [ordered]@{ ref = 'experts/norbert-hamm' score = '0.51' } [ordered]@{ ref = 'experts/michael-steg' score = '0.44' } [ordered]@{ ref = 'experts/christian-schnyder' score = '0.42' } ) search = '/en/search.json' }}$Page | ConvertTo-Json -Depth 32
// Code generated by the soultec.ch build. DO NOT EDIT.package mainimport ( "encoding/json" "os")var page = map[string]any{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": map[string]any{ "name": "data-management", "locale": "en", "labels": map[string]any{ "group": "infrastructure", "capability/data-management": 2.87, "capability/storage": 2.36, "capability/architecture": 2.51, "vendor/hpe": 1.99, "vendor/ibm": 3.7, }, "annotations": map[string]any{ "source": "src/content/services/en/data-management.md", "route": "/en/services/data-management/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/data-management.md", }, }, "spec": map[string]any{ "title": "Data Management", "group": "infrastructure", "audience": []any{"enterprise", "provider"}, "order": 2, "tags": []any{"data-management", "storage", "architecture"}, "vendors": []any{"hpe", "ibm"}, "summary": "Software-defined storage against data growth. The real gain is that the next data migration does not happen.", "photoNeed": "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", "stub": false, "draft": false, "sections": []any{ map[string]any{ "heading": "

The problem

",
"body": "Data grows, and classic block storage often lacks the functionality for that kind of\n" + "growth. At some point the problem stops being capacity and becomes the next migration onto\n" + "the next system.", }, map[string]any{ "heading": "

The approach

",
"body": "Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM Spectrum\n" + "Scale, because they have different strengths and the choice should follow the requirements\n" + "rather than the other way round.\n" + "\n" + "What these products have in common is why they solve the problem: they run on standard\n" + "x86 servers, scale out as clusters rather than up, replicate synchronously or\n" + "asynchronously across sites, and speak the protocols that are actually needed, meaning S3,\n" + "NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does not\n" + "need a migration.\n" + "\n" + "Before that choice there is a requirements engineering workshop. Not as a formality:\n" + "without clarity on the access patterns, availability requirements and retention periods\n" + "that actually apply, every product decision is guesswork.", }, map[string]any{ "heading": "

What it actually buys

",
"body": "**No more migrations.** Once the data is on an SDS platform, the platform owns the\n" + "lifecycle. Changing the hardware underneath becomes an operation rather than a project.\n" + "\n" + "**Availability to match.** Synchronous or asynchronous mirroring into a co-location or into\n" + "the public cloud, depending on what is needed.\n" + "\n" + "**Growth is designed in.** Extending onto further clusters is part of the model rather than\n" + "the exception.", }, }, }, "status": map[string]any{ "corpus": 315, "solutions": []any{ map[string]any{ "ref": "solutions/hpe/hpe-storage/alletra-storage-mp-b10000", "score": "0.77", }, map[string]any{ "ref": "solutions/hpe/hpe-storage/alletra-storage-mp-x10000", "score": "0.77", }, map[string]any{ "ref": "solutions/hpe/hpe-storage/greenlake-for-file-storage", "score": "0.77", }, map[string]any{ "ref": "solutions/hpe/hpe-data-management", "score": "0.77", }, }, "alsoLike": []any{ map[string]any{ "ref": "solutions/hpe/hpe-storage", "score": "0.77", }, map[string]any{ "ref": "services/storage", "score": "0.77", }, map[string]any{ "ref": "solutions/hpe", "score": "0.59", }, }, "experts": []any{ map[string]any{ "ref": "experts/norbert-hamm", "score": "0.51", }, map[string]any{ "ref": "experts/michael-steg", "score": "0.44", }, map[string]any{ "ref": "experts/christian-schnyder", "score": "0.42", }, }, "search": "/en/search.json", },}func main() { enc := json.NewEncoder(os.Stdout) enc.SetEscapeHTML(false) enc.SetIndent("", " ") if err := enc.Encode(page); err != nil { os.Exit(1) }}
// Code generated by the soultec.ch build. DO NOT EDIT.const page = { apiVersion: "soultec.ch/v1", kind: "Service", metadata: { name: "data-management", locale: "en", labels: { group: "infrastructure", "capability/data-management": 2.87, "capability/storage": 2.36, "capability/architecture": 2.51, "vendor/hpe": 1.99, "vendor/ibm": 3.7, }, annotations: { source: "src/content/services/en/data-management.md", route: "/en/services/data-management/", schema: "/nerd/schema/services.json", markdown: "/en/services/data-management.md", }, }, spec: { title: "Data Management", group: "infrastructure", audience: ["enterprise", "provider"], order: 2, tags: ["data-management", "storage", "architecture"], vendors: ["hpe", "ibm"], summary: "Software-defined storage against data growth. The real gain is that the next data migration does not happen.", photoNeed: "Infrastructure work in progress at a customer site or in our lab: hands on hardware, a rack door open, a screen mid-configuration", stub: false, draft: false, sections: [ { heading: "

The problem

",
body: "Data grows, and classic block storage often lacks the functionality for that kind of\n" + "growth. At some point the problem stops being capacity and becomes the next migration onto\n" + "the next system.", }, { heading: "

The approach

",
body: "Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM Spectrum\n" + "Scale, because they have different strengths and the choice should follow the requirements\n" + "rather than the other way round.\n" + "\n" + "What these products have in common is why they solve the problem: they run on standard\n" + "x86 servers, scale out as clusters rather than up, replicate synchronously or\n" + "asynchronously across sites, and speak the protocols that are actually needed, meaning S3,\n" + "NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does not\n" + "need a migration.\n" + "\n" + "Before that choice there is a requirements engineering workshop. Not as a formality:\n" + "without clarity on the access patterns, availability requirements and retention periods\n" + "that actually apply, every product decision is guesswork.", }, { heading: "

What it actually buys

",
body: "**No more migrations.** Once the data is on an SDS platform, the platform owns the\n" + "lifecycle. Changing the hardware underneath becomes an operation rather than a project.\n" + "\n" + "**Availability to match.** Synchronous or asynchronous mirroring into a co-location or into\n" + "the public cloud, depending on what is needed.\n" + "\n" + "**Growth is designed in.** Extending onto further clusters is part of the model rather than\n" + "the exception.", }, ], }, status: { corpus: 315, solutions: [ { ref: "solutions/hpe/hpe-storage/alletra-storage-mp-b10000", score: "0.77", }, { ref: "solutions/hpe/hpe-storage/alletra-storage-mp-x10000", score: "0.77", }, { ref: "solutions/hpe/hpe-storage/greenlake-for-file-storage", score: "0.77", }, { ref: "solutions/hpe/hpe-data-management", score: "0.77", }, ], alsoLike: [ { ref: "solutions/hpe/hpe-storage", score: "0.77", }, { ref: "services/storage", score: "0.77", }, { ref: "solutions/hpe", score: "0.59", }, ], experts: [ { ref: "experts/norbert-hamm", score: "0.51", }, { ref: "experts/michael-steg", score: "0.44", }, { ref: "experts/christian-schnyder", score: "0.42", }, ], search: "/en/search.json", },};console.log(JSON.stringify(page, null, 2));

# 79 lines · YAML · validated at build# 108 lines · JSON · validated at build# 115 lines · TOML · validated at build# 135 lines · XML · validated at build# 131 lines · Python · read back at build, equals the JSON record# 128 lines · PowerShell · read back at build, equals the JSON record# 137 lines · Go · read back at build, equals the JSON record# 122 lines · JavaScript · read back at build, equals the JSON record · served at /en/services/data-management.md

Service · infrastructure

Data Management

Software-defined storage against data growth. The real gain is that the next data migration does not happen.

04Solutions
03Capabilities
02Vendors
315Corpus

The problem

Data grows, and classic block storage often lacks the functionality for that kind of growth. At some point the problem stops being capacity and becomes the next migration onto the next system.

The approach

Software-defined storage. We work with Qumulo, Scality RING, Cohesity and IBM Spectrum Scale, because they have different strengths and the choice should follow the requirements rather than the other way round.

What these products have in common is why they solve the problem: they run on standard x86 servers, scale out as clusters rather than up, replicate synchronously or asynchronously across sites, and speak the protocols that are actually needed, meaning S3, NFS, CIFS and HDFS. Add to that built-in automation and a hardware lifecycle that does not need a migration.

Before that choice there is a requirements engineering workshop. Not as a formality: without clarity on the access patterns, availability requirements and retention periods that actually apply, every product decision is guesswork.

What it actually buys

No more migrations. Once the data is on an SDS platform, the platform owns the lifecycle. Changing the hardware underneath becomes an operation rather than a project.

Availability to match. Synchronous or asynchronous mirroring into a co-location or into the public cloud, depending on what is needed.

Growth is designed in. Extending onto further clusters is part of the model rather than the exception.

Experts for this

Maybe you? Take a look at our open roles.

You might also like