Data Management

apiVersion: soultec.ch/v1kind: Servicemetadata: name: data-management locale: en labels: group: infrastructure capability/data-management: 2.87 capability/storage: 2.62 capability/architecture: 2.93 vendor/hpe: 2.04 vendor/ibm: 3.54 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 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. 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: 267 solutions: - {ref: solutions/hpe/hpe-data-management, score: 0.76} - {ref: solutions/hpe/hpe-storage, score: 0.76} - {ref: solutions/hpe, score: 0.58} - {ref: solutions/hpe/hpe-server, score: 0.51} alsoLike: - {ref: services/storage, score: 0.76} - {ref: posts/raid-controller, score: 0.52} - {ref: solutions/ibm, score: 0.51} experts: - {ref: experts/oliver-erismann, score: 0.51} - {ref: experts/norbert-hamm, score: 0.43} - {ref: experts/michael-steg, score: 0.42}

{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "data-management", "locale": "en", "labels": { "group": "infrastructure", "capability/data-management": "2.87", "capability/storage": "2.62", "capability/architecture": "2.93", "vendor/hpe": "2.04", "vendor/ibm": "3.54" }, "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", "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\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": 267, "solutions": [ { "ref": "solutions/hpe/hpe-data-management", "score": "0.76" }, { "ref": "solutions/hpe/hpe-storage", "score": "0.76" }, { "ref": "solutions/hpe", "score": "0.58" }, { "ref": "solutions/hpe/hpe-server", "score": "0.51" } ], "alsoLike": [ { "ref": "services/storage", "score": "0.76" }, { "ref": "posts/raid-controller", "score": "0.52" }, { "ref": "solutions/ibm", "score": "0.51" } ], "experts": [ { "ref": "experts/oliver-erismann", "score": "0.51" }, { "ref": "experts/norbert-hamm", "score": "0.43" }, { "ref": "experts/michael-steg", "score": "0.42" } ] }}

apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "data-management"locale = "en"[metadata.labels]group = "infrastructure""capability/data-management" = "2.87""capability/storage" = "2.62""capability/architecture" = "2.93""vendor/hpe" = "2.04""vendor/ibm" = "3.54"[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"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[[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.'''[[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.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.'''[[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 = 267[[status.solutions]]ref = "solutions/hpe/hpe-data-management"score = "0.76"[[status.solutions]]ref = "solutions/hpe/hpe-storage"score = "0.76"[[status.solutions]]ref = "solutions/hpe"score = "0.58"[[status.solutions]]ref = "solutions/hpe/hpe-server"score = "0.51"[[status.alsoLike]]ref = "services/storage"score = "0.76"[[status.alsoLike]]ref = "posts/raid-controller"score = "0.52"[[status.alsoLike]]ref = "solutions/ibm"score = "0.51"[[status.experts]]ref = "experts/oliver-erismann"score = "0.51"[[status.experts]]ref = "experts/norbert-hamm"score = "0.43"[[status.experts]]ref = "experts/michael-steg"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.62</entry> <entry key="capability/architecture">2.93</entry> <entry key="vendor/hpe">2.04</entry> <entry key="vendor/ibm">3.54</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> <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> </spec> <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.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> <status> <corpus>267</corpus> <solutions> <item> <ref>solutions/hpe/hpe-data-management</ref> <score>0.76</score> </item> <item> <ref>solutions/hpe/hpe-storage</ref> <score>0.76</score> </item> <item> <ref>solutions/hpe</ref> <score>0.58</score> </item> <item> <ref>solutions/hpe/hpe-server</ref> <score>0.51</score> </item> </solutions> <alsoLike> <item> <ref>services/storage</ref> <score>0.76</score> </item> <item> <ref>posts/raid-controller</ref> <score>0.52</score> </item> <item> <ref>solutions/ibm</ref> <score>0.51</score> </item> </alsoLike> <experts> <item> <ref>experts/oliver-erismann</ref> <score>0.51</score> </item> <item> <ref>experts/norbert-hamm</ref> <score>0.43</score> </item> <item> <ref>experts/michael-steg</ref> <score>0.42</score> </item> </experts> </status></manifest>

The problem

The approach

What it actually buys

The problem

The approach

What it actually buys

The problem

The approach

What it actually buys

The problem

The approach

What it actually buys

Data Management

The problem

The approach

What it actually buys

Experts for this

Oliver Erismann

Norbert Hamm

Michael Steg

You might also like

Storage

RAID controllers

IBM