WISSEN > ENTERPRISE STORAGE > LOHNT STORAGE KONSOLIDIERUNG
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Wann lohnt sich Storage Konsolidierung
und wann nicht?
Das sollten Sie mitnehmen:
- Der Lifecycle liefert den Anlass, nicht die Begründung.
Ein anstehender Refresh eröffnet die Architekturprüfung, entscheidet sie aber nicht.
- Kapazität wird erst im gemeinsamen Pool zur Reserve.
Verteilte Restkapazitäten mehrerer Systeme helfen dem System nicht, das an seine Grenze stößt.
- Performance ist auf Workload-Ebene zu beurteilen.
Konsolidierte Anwendungen teilen sich Ressourcen, weshalb I/O-Profile und Lastspitzen zählen, nicht Durchschnitts-IOPS.
- Nicht jeder Workload gehört auf dieselbe Plattform.
Applikationsbindung, Verfügbarkeit und administrative Isolation rechtfertigen bewusste Trennung.
- Das Ziel ist nicht die kleinste Systemzahl.
Entscheidend ist, welche Silos technisch notwendig und welche historisch entstanden sind.
Wann lohnt sich Storage Konsolidierung?
Inhaltsverzeichnis
- Konsolidierung führt Workloads zusammen – Virtualisierung ist etwas anderes
- Der Lifecycle liefert den Anlass, nicht die Begründung
- Kapazität wird erst im gemeinsamen Pool zur Reserve
- Geteilte Ressourcen schaffen Spielraum und Konkurrenz zugleich
- Weniger Systeme bedeuten nicht automatisch weniger Betrieb
- Der Preis pro Terabyte ist die falsche Vergleichsgröße
- Energie und Fläche sprechen für Konsolidierung – der PUE nicht unbedingt
- Konsolidierung verschiebt die Failure Domain
- Vereinheitlichter Schutz vergrößert den Blast Radius
- Die Anwendung ist der härteste Einwand
- Unsere Projekterfahrung: rund zehn Storage-Systeme auf dem Prüfstand
- Wann Konsolidierung lohnt und wann Trennung die bessere Architektur ist
- Vom System zur Workload: ein Entscheidungsmodell
- Fazit
- Quellen
Storage-Infrastrukturen entstehen selten auf der grünen Wiese. Neue Anwendungen kommen hinzu, Kapazitäten werden erweitert, Hersteller wechseln, einzelne Systeme erreichen das Ende ihres Lifecycles. Über Jahre können so mehrere Storage-Plattformen nebeneinander bestehen, obwohl sie heute teilweise sehr ähnliche Aufgaben erfüllen. Spätestens beim nächsten Hardware-Refresh stellt sich deshalb die Frage, ob die vorhandenen Systeme einzeln ersetzt werden sollen oder ob sich ihre Workloads auf weniger Plattformen zusammenführen lassen.
Die Anzahl der Systeme allein beantwortet diese Frage nicht. Zehn Storage-Systeme können technisch notwendig sein; sie können ebenso das Ergebnis historischer Entscheidungen sein, deren ursprüngliche Gründe längst nicht mehr bestehen. Storage-Konsolidierung lohnt sich deshalb nicht grundsätzlich dann, wenn viele Systeme vorhanden sind. Sie wird interessant, wenn technisch nicht mehr notwendige Silos beseitigt werden können, ohne Anforderungen der Anwendungen an Performance, Verfügbarkeit, Protokolle oder Isolation zu verletzen.
Konsolidierung führt Workloads zusammen – Virtualisierung ist etwas anderes
Unter Storage-Konsolidierung verstehen wir die Zusammenführung von Daten und Workloads mehrerer bislang unabhängiger Storage-Systeme auf eine kleinere Zahl gemeinsam genutzter Plattformen. Das ist von Storage-Virtualisierung zu unterscheiden, auch wenn beide Begriffe in Projektdiskussionen regelmäßig vermischt werden.
Die SNIA definiert Virtualisierung als das Abstrahieren, Verbergen oder Isolieren der Funktion eines Systems oder Service. Die Aggregation mehrerer Ressourcen zu einer gemeinsam nutzbaren Einheit ist dabei ausdrücklich nur eines von mehreren Anwendungsbeispielen, neben dem Verbergen von Komplexität und dem anwendungs- und netzunabhängigen Management. Storage-Virtualisierung ist entsprechend schlicht die Anwendung dieses Prinzips auf Storage Services oder Devices. Virtualisierung kann damit ein technisches Mittel zur Konsolidierung sein, ist aber weder mit ihr gleichzusetzen noch für sie zwingend erforderlich.
Nach einer Konsolidierung erhalten die Anwendungen weiterhin ihre jeweiligen Volumes, LUNs, File Systems oder Shares. Auf der darunterliegenden Infrastruktur teilen sie sich jedoch Controller beziehungsweise Nodes, Ports, Cache, Medien und je nach Auslegung auch gemeinsame Storage Pools. Genau in dieser geteilten Schicht liegen sowohl die Vorteile als auch die Risiken.
<!-- DIAGRAMM 1: Schichtenmodell einer konsolidierten Umgebung — Hosts / SAN bzw. Ethernet / gemeinsame Storage-Plattform / Storage Pools / physische Medien. Ersetzt die ASCII-Kette der Vorfassung. -->
Der Lifecycle liefert den Anlass, nicht die Begründung
Ein anstehendes End-of-Life oder ein regulärer Hardware-Refresh ist ein sinnvoller Zeitpunkt, die Storage-Architektur grundsätzlich zu überprüfen. Es wäre jedoch ein Fehler, daraus unmittelbar abzuleiten, dass mehrere alte Systeme durch ein einzelnes neues zu ersetzen sind. Der Lifecycle ist der Auslöser der Architekturentscheidung, nicht ihre Begründung.
Vor der Entscheidung sollte geklärt sein, welche Workloads auf den bestehenden Systemen liegen, warum sie ursprünglich getrennt wurden und ob diese Gründe heute noch bestehen. Hinzu kommen die Fragen, welche Ressourcen die Workloads tatsächlich benötigen, welche FailureDomains und Verfügbarkeitsanforderungen erhalten bleiben müssen, welche Storage-Funktionen und Protokolle die Anwendungen voraussetzen und was sich durch einen gemeinsamen Ressourcenpool verändert. Erst danach lässt sich beurteilen, welche Silos technisch erforderlich und welche lediglich historisch entstanden sind.
Kapazität wird erst im gemeinsamen Pool zur Reserve
Ein grundlegendes Problem gewachsener Storage-Landschaften ist nicht zwingend zu wenig Rohkapazität, sondern deren Verteilung. Angenommen, vier Systeme besitzen jeweils noch freie Kapazität:
System
Nutzbare Kapazität
Belegt
Frei
Storage A
100 TB
90 TB
10 TB
Storage B
100 TB
55 TB
45 TB
Storage C
100 TB
70 TB
30 TB
Storage D
100 TB
40 TB
60 TB
In Summe wären noch 145 TB verfügbar. Benötigt eine Anwendung auf Storage A weitere 30 TB, helfen die freien Kapazitäten der übrigen drei Systeme jedoch nicht. Ohne Datenmigration, Virtualisierung oder einen vergleichbaren Mechanismus bleiben die Reserven voneinander getrennt, und die Erweiterung von Storage A wird notwendig, obwohl die Umgebung als Ganzes reichlich Platz hätte.
Ein größerer gemeinsamer Pool verändert diese Situation, weil zuvor gebundene Kapazität dorthin fließen kann, wo sie gebraucht wird. Der Konsolidierungsvorteil entsteht damit nicht dadurch, dass weniger Storage-Systeme existieren, sondern dadurch, dass zuvor getrennte Ressourcen gemeinsam nutzbar werden.
Diese Betrachtung hat eine Einschränkung, die in Kapazitätsplanungen regelmäßig untergeht: Freie Terabyte sind nicht automatisch geeignete Terabyte. Performance, Medienklasse, Datenservices, Resiliency und Failure Domain müssen ebenfalls zum jeweiligen Workload passen. Eine Kapazitätsreserve auf einem Capacity-Tier hilft einer latenzkritischen Datenbank nicht.
Geteilte Ressourcen schaffen Spielraum und Konkurrenz zugleich
Bei der Performance ist die Betrachtung komplexer als bei der Kapazität. Eine aktuelle Plattform kann gegenüber mehreren älteren Systemen erheblich leistungsfähiger sein, doch daraus folgt nicht, dass Konsolidierung als solche die Storage-Performance erhöht. Technisch geschieht zunächst etwas anderes: Mehrere bislang getrennte I/O-Workloads greifen auf einen gemeinsamen Ressourcenverbund zu.
Je nach Architektur teilen sie sich dabei Frontend-Ports, Netzwerk- oder SAN-Verbindungen, Controller beziehungsweise Storage Nodes, CPU und Memory, Cache, Backend-Verbindungen sowie die Speichermedien selbst. Das ist zunächst ein Vorteil, weil Ressourcen nicht mehr exklusiv für einen einzelnen Workload vorgehalten werden müssen und Lastspitzen einzelner Anwendungen aus einem größeren Vorrat bedient werden können. Gleichzeitig entsteht das Risiko gegenseitiger Beeinflussung: Ein Workload mit unvorhersehbarem oder schlicht sehr aggressivem I/O-Verhalten kann Ressourcen belegen, die eine kritische Anwendung im selben Moment benötigt.
Wir behandeln diesen Punkt in Konsolidierungsprojekten als eigenständige Planungsaufgabe und nicht als Betriebsdetail, das sich nach der Migration klären lässt. Je stärker konsolidiert wird, desto wichtiger werden Workload-Analyse, Ressourcensteuerung und, wo die Plattform es zulässt, QoS-Mechanismen oder technische Isolation. Für einzelne kritische Workloads kann die konsequente Antwort auch lauten, sie gar nicht erst in den gemeinsamen Pool zu nehmen.
Für die Dimensionierung reicht es entsprechend nicht, die durchschnittlichen IOPS der bestehenden Systeme zu addieren. Relevant sind Blockgrößen, das Verhältnis von Lese- zu Schreibzugriffen, der Anteil sequentieller und zufälliger Zugriffe, Durchsatz, Latenzanforderungen, Parallelität und vor allem das zeitliche Muster der Lastspitzen. Zwei Workloads mit identischen durchschnittlichen IOPS können ein Storage-System vollkommen unterschiedlich belasten – und zwei Workloads, deren Spitzen zeitlich zusammenfallen, verhalten sich in einer konsolidierten Umgebung anders als in getrennten Systemen.
Weniger Systeme bedeuten nicht automatisch weniger Betrieb
Der betriebliche Effekt einer Konsolidierung wird häufig auf eine geringere Zahl administrativer Oberflächen reduziert. Das greift zu kurz, weil jede zusätzliche Storage-Plattform Abhängigkeiten erzeugt, die weit über die Management-GUI hinausreichen: Monitoring-Anbindung, Firmware-Stände, Multipathing, Treiber, Supportverträge, Ersatzteilhaltung, Dokumentation, Backup-Integration, Replikationsbeziehungen, Automatisierung und nicht zuletzt vorgehaltenes Know-how. Bei unterschiedlichen Herstellern oder Produktgenerationen kommen abweichende Betriebsmodelle und Werkzeugketten hinzu.
Storage Resource Management umfasst nach der SNIA-Definition das Management physischer und logischer Storage-Ressourcen einschließlich Storage Elements, Storage Devices, Appliances, virtueller Devices, Disk-Volumesund File-Ressourcen. Die Definition beschreibt damit den Umfang dessen, was verwaltet werden muss – sie sagt nichts darüber aus, ob dieser Aufwand durch Konsolidierung sinkt.
Denn das ist keineswegs gesichert. Eine größere Plattform mit mehreren Mandanten, Performance-Klassen, Replikationsbeziehungen, heterogenen Workloads und umfangreichen Data Services kann betrieblich anspruchsvoller sein als ein einzelnes kleines Array. Was sinkt, ist die Zahl separat zu pflegender Infrastrukturdomänen; was steigen kann, ist die Komplexität innerhalb der verbleibenden. Entscheidend ist deshalb nicht die Anzahl der Systeme, sondern der gesamte Betriebsaufwand über beide Effekte hinweg.
Der Preis pro Terabyte ist die falsche Vergleichsgröße
Wer eine Konsolidierungsentscheidung ausschließlich am Anschaffungspreis neuer Storage-Kapazität ausrichtet, vergleicht die falsche Größe. Verglichen werden sollte die Infrastruktur über ihren betrachteten Lifecycle, also Hardware und Software, Wartung und Support, Netzwerk- und SAN-Anbindung, Rackspace, Energie, Betriebsaufwand, Migrationsaufwand und die vorzuhaltende Reservekapazität.
Gerade der letzte Punkt wird selten quantifiziert. Wenn fünf Systeme jeweils eigene Wachstumsreserven benötigen, kann die Summe dieser Reserven deutlich größer sein als die Reserve eines gemeinsamen Pools, weil Wachstumsspitzen einzelner Workloads sich in einem Pool gegenseitig abfedern. Ob und in welchem Umfang dieser Effekt eintritt, hängt allerdings von den Workloads, ihren Wachstumsprofilen und der konkreten Architektur ab; bei stark gleichgerichtetem Wachstum fällt er gering aus.
Eine belastbare Wirtschaftlichkeitsrechnung vergleicht deshalb mindestens zwei Szenarien: die einzelne Erneuerung der bestehenden Silos gegen die Zusammenführung der Workloads auf weniger Plattformen. Die relevante Kennzahl ist dabei nicht der niedrigste Preis pro Terabyte, sondern der Aufwand für diejenige Architektur, die die technischen Anforderungen über den geplanten Zeitraum tatsächlich erfüllt.
Energie und Fläche sprechen für Konsolidierung – der PUE nicht unbedingt
Konsolidierung wirkt unmittelbar physisch. Weniger Systeme bedeuten weniger Controller, weniger Enclosures, weniger Höheneinheiten, weniger SAN-Ports und weniger Netzteile. Der größte Teil dieses Effekts stammt allerdings aus dem gleichzeitigen Technologiewechsel: Der Übergang von älteren Systemen mit rotierenden Medien auf aktuelle Flash-Plattformen senkt die Leistungsaufnahme je nutzbarem Terabyte erheblich, unabhängig davon, ob dabei konsolidiert wird.
Der eigenständige Konsolidierungseffekt liegt woanders, nämlich in der Grundlast. Jedes Storage-System hat eine lastunabhängige Leistungsaufnahme aus Controllern, Lüftern, Netzteilen und der Idle-Aufnahme der Medien. Zehn mäßig ausgelastete Systeme tragen diese Grundlast zehnfach. Wer Workloads zusammenführt, eliminiert Grundlastanteile, die durch keine Effizienzmaßnahme am Einzelsystem zu beseitigen wären. Für belastbare Vergleiche sollten dabei nicht Nennleistungen aus Datenblättern herangezogen werden, sondern gemessene Werte; die SNIA Emerald Power Efficiency Measurement Specification definiert hierfür eine herstellerunabhängige Messmethodik einschließlich Idle- und Active-Zuständen.
Für Rechenzentren in Deutschland kommt eine regulatorische Ebene hinzu, und hier zeigt sich ein Konstruktionsproblem der maßgeblichen Kennzahl. § 11 EnEfG bindet die Anforderungen an die Energieverbrauchseffektivität, also an den PUE als Verhältnis von Gesamtstromverbrauch zum Verbrauch der IT-Systeme. Rechenzentren, die vor dem 1. Juli 2026 den Betrieb aufgenommen haben, müssen ab dem 1. Juli 2027 einen PUE von höchstens 1,5 und ab dem 1. Juli 2030 von höchstens 1,3 im Jahresdurchschnitt dauerhaft erreichen; für ab dem 1. Juli 2026 in Betrieb genommene Rechenzentren gilt ein Wert von höchstens 1,2. Die Pflichten greifen ab einer nicht-redundanten Nennanschlussleistung von 300 kW.
Eine Konsolidierung senkt nun genau den Nenner dieser Kennzahl. Bleiben Kühlung, unterbrechungsfreie Stromversorgung und Gebäudetechnik unverändert dimensioniert – was in Bestandsrechenzentren der Regelfall ist –, dann steigt der PUE, obwohl der absolute Stromverbrauch sinkt. Die Kennzahl bewertet eine energetisch richtige Maßnahme schlechter. Umgekehrt lässt sich der PUE verbessern, ohne eine einzige Kilowattstunde einzusparen, indem die IT-Last wächst. Wer in einem EnEfG-pflichtigen Rechenzentrum konsolidiert, sollte die PUE-Wirkung deshalb vorab rechnen – nicht weil der PUE die sachlich richtige Kennzahl wäre, sondern weil er die regulierte ist. Praktisch bedeutet das, die Kühlleistung im selben Zug an die reduzierte Last anzupassen, da Kälteanlagen im Teillastbetrieb deutlich ineffizienter arbeiten.
Zu berücksichtigen ist, dass diese Vorgaben derzeit in Bewegung sind. Das Bundeskabinett hat am 24. Juni 2026 eine Novelle des EnEfG beschlossen, die für Bestandsrechenzentren gelockerte PUE-Grenzwerte sowie eine höhere Eingangsschwelle vorsieht; das parlamentarische Verfahren war zum Redaktionsschluss nicht abgeschlossen. Bis zur Verkündung gilt das bestehende Recht.
Unabhängig von der Regulierung ist der freiwerdende Rackspace ein realer Wert, insbesondere dort, wo die Anschlussleistung oder die Kühlkapazität eines Standorts die eigentliche Wachstumsgrenze bildet und nicht die verfügbare Stellfläche.
Konsolidierung verschiebt die Failure Domain
Ein besonders wichtiger Punkt wird in Konsolidierungsprojekten leicht übersehen. Werden mehrere unabhängige Storage-Systeme durch eine Plattform ersetzt, verändert sich die Fehlerdomäne. Vorher liegen unterschiedliche Anwendungen auf physisch getrennten Systemen, und der Ausfall eines Systems betrifft genau die dort liegenden Workloads. Danach teilen sich mehrere Anwendungen eine gemeinsame Plattform, und ein Ausfall kann sie gleichzeitig treffen.
Das bedeutet nicht automatisch eine geringere Verfügbarkeit, denn moderne Enterprise-Storage-Systeme besitzen intern umfangreiche Redundanzmechanismen und erreichen Verfügbarkeitswerte, die eine Landschaft aus zehn älteren Einzelsystemen nicht erreicht. Die relevante Architekturfrage lautet vielmehr, welche Komponenten nach der Konsolidierung gemeinsam genutzt werden und welche Ausfälle dadurch mehrere Workloads gleichzeitig betreffen können.
Zu analysieren sind dabei Controller beziehungsweise Nodes, Storage Pools, Frontend-Ports, SAN-Fabrics oder Ethernet-Netze, Backend-Medien, Stromversorgung, Replikationsziele sowie Management- und administrative Domänen. Eine Plattform kann innerhalb dieser Ebenen wiederum eigene Failure Domains schaffen, etwa durch getrennte Pools oder getrennte Port-Gruppen – aber nur, wenn diese Trennung bewusst geplant wird. Physische Konsolidierung und logische Isolation sind zwei unterschiedliche Architekturentscheidungen, und die zweite folgt nicht aus der ersten.
<!-- DIAGRAMM 2: Verschiebung der Failure Domain — links drei Anwendungen auf drei getrennten Systemen, rechts drei Anwendungen auf einer gemeinsamen Plattform mit intern abgegrenzten Domänen. Ersetzt die ASCII-Grafik der Vorfassung. -->
Vereinheitlichter Schutz vergrößert den Blast Radius
Für Cyber Resilience gilt eine verwandte, aber nicht identische Überlegung, denn die maßgebliche Achse ist hier nicht die technische Fehlerdomäne, sondern die administrative Vertrauensdomäne. Eine gemeinsame Storage-Plattform kann Data-Protection-Funktionen zentral bereitstellen und damit Snapshot-, Replikations- und Immutability-Konzepte vereinheitlichen, sofern die Plattform die erforderlichen Mechanismen unterstützt. Das ist ein realer Gewinn, weil uneinheitliche Schutzkonzepte über mehrere Systeme hinweg erfahrungsgemäß die Stellen sind, an denen im Ernstfall Lücken auftreten.
Gleichzeitig darf Konsolidierung nicht dazu führen, dass zuvor getrennte Schutzdomänen unbemerkt zu einer einzigen administrativen Vertrauensdomäne verschmelzen. Wer sämtliche Produktions- und Schutzkopien unter dieselbe Administration stellt, hat die technische Redundanz erhöht und die Angriffsfläche gleichzeitig konzentriert. Zu klären ist deshalb, welche Administratoren Zugriff besitzen, wie administrative Rollen getrennt sind, welche Identitätssysteme verwendet werden, welche Schutzkopien innerhalb derselben Domäne liegen, welche Systeme Replikationen oder Snapshots löschen können und welche Recovery-Kopien tatsächlich unabhängig existieren. Eine technische Konsolidierung sollte daher nicht automatisch eine Konsolidierung aller Security- und Recovery-Domänen bedeuten.
Die Anwendung ist der härteste Einwand
Die größte Storage-Plattform nützt wenig, wenn eine Anwendung dort nicht sinnvoll oder nicht unterstützt betrieben werden kann. Anwendungen können bestimmte Block-, File- oder Object-Protokolle voraussetzen, zertifizierte Storage-Systeme verlangen, definierte Latenzen benötigen, auf bestimmte Snapshot- oder Cloning-Mechanismen aufsetzen, synchrone oder asynchrone Replikation erfordern, spezielle Integrationen nutzen, konsistente Application Snapshots erwarten oder definierte Failure Domains voraussetzen.
Daraus folgt eine Unterscheidung, die in Konsolidierungsplanungen früh getroffen werden muss: Technisch konsolidierbar und applikationsseitig sinnvoll konsolidierbar sind nicht dasselbe. Eine tragfähige Konsolidierungsstrategie versucht deshalb nicht, sämtliche vorhandenen Systeme abzulösen. Sie konsolidiert so weit, wie es technisch sinnvoll ist, und trennt dort, wo eine nachvollziehbare Anforderung die Trennung rechtfertigt.
Unsere Projekterfahrung: rund zehn Storage-Systeme auf dem Prüfstand
In einem von uns begleiteten Projekt bestand die Ausgangsumgebung aus rund zehn Storage-Systemen mit einem Gesamtdatenbestand von mehreren hundert Terabyte. Auslöser der Betrachtung war der Lifecycle der vorhandenen Infrastruktur.
Statt die bestehenden Systeme einzeln durch neue zu ersetzen, haben wir die Storage-Landschaft insgesamt bewertet, mit vier Kriterien im Mittelpunkt: Kosten, Betrieb, Kapazitätsauslastung und Performance. Der Lifecycle wurde damit zum Anlass für eine Architekturüberprüfung und nicht für einen reinen Hardwareaustausch.
Ein wesentliches Ergebnis war, dass nicht jeder Workload konsolidiert wurde. Einzelne Anwendungen blieben aus applikationsspezifischen Gründen außerhalb der konsolidierten Umgebung. Das ist für die Architekturentscheidung der eigentlich relevante Punkt: Das Ziel war nicht die kleinstmögliche Anzahl von Storage-Systemen, sondern eine sachlich begründete Zuordnung der Workloads.
Bei den tatsächlich migrierten Workloads haben wir keine negativen Performance-Auswirkungen beobachtet; die neue Gesamtplattform war gegenüber den abgelösten Systemen leistungsfähiger. Dieses Ergebnis taugt allerdings nicht als allgemeiner Beleg dafür, dass Konsolidierung die Performance erhöht. Im konkreten Projekt fanden Konsolidierung und Technologie-Refresh gemeinsam statt, und ohne einen kontrollierten Vergleich beider Effekte lässt sich der Performancegewinn nicht kausal der Konsolidierung zuschreiben. Wir halten diese Unterscheidung für wichtig, weil sie in Herstellerargumentationen regelmäßig verwischt wird.
Daraus ergibt sich eine über das Einzelprojekt hinaus tragfähige Vorgehensweise: Der Lifecycle schafft den Anlass zur Konsolidierungsprüfung, die Entscheidung selbst wird anhand der Workloads getroffen.
Wann Konsolidierung lohnt und wann Trennung die bessere Architektur ist
Bedingungen, unter denen sich eine Analyse lohnt
Eine Konsolidierung sollte näher untersucht werden, wenn mehrere der folgenden Bedingungen gleichzeitig vorliegen:
Ausgangssituation
Warum Konsolidierung interessant wird
Mehrere Systeme erreichen zeitnah ihren Lifecycle
Die Architektur kann statt einzelner Hardwarekomponenten neu bewertet werden
Ähnliche Workloads liegen auf getrennten Systemen
Die technische Notwendigkeit der Silos lässt sich hinterfragen
Kapazitätsreserven sind stark über mehrere Systeme verteilt
Gemeinsame Pools können Ressourcen flexibler nutzbar machen
Viele Plattformen erzeugen hohen Betriebsaufwand
Weniger Infrastrukturdomänen können die Administration vereinfachen
Unterschiedliche Plattformen erfüllen inzwischen dieselben Anforderungen
Die historische Trennung besitzt möglicherweise keinen technischen Nutzen mehr
Die neue Plattform bietet ausreichend Performance und Skalierbarkeit
Mehrere Workloads können denselben Ressourcenpool nutzen
Schutz- und Betriebsfunktionen sollen vereinheitlicht werden
Gemeinsame Data Services können Architektur und Betrieb vereinfachen
Keines dieser Kriterien ist für sich genommen ausreichend, und keines ersetzt die Workload-Analyse. Sie zeigen lediglich an, ab wann sich der Aufwand einer Konsolidierungsanalyse lohnt – und je mehr von ihnen gleichzeitig zutreffen, desto wahrscheinlicher ist, dass die vorhandene Systemzahl nicht mehr aus technischen Gründen besteht.
Gründe, die für bewusste Trennung sprechen
Umgekehrt gibt es gute Gründe, Storage nicht vollständig zu konsolidieren. Der erste ist die Applikationsbindung, wenn eine Anwendung eine bestimmte Storage-Architektur, Integration oder Herstellerfreigabe benötigt. Der zweite ist Performance-Isolation, wenn ein kritischer oder stark schwankender Workload andere Anwendungen nicht beeinflussen soll und die verfügbaren QoS-Mechanismen dafür nicht ausreichen. Der dritte sind unterschiedliche Verfügbarkeitsanforderungen, wenn Workloads getrennte Failure Domains oder abweichende Replikationskonzepte benötigen.
Hinzu kommen unterschiedliche Storage-Klassen: Ein hochperformanter Datenbank-Workload und große Mengen kalter Daten stellen fundamental verschiedene Anforderungen, und eine gemeinsame physische Plattform ist nur dann sinnvoll, wenn sie beide technisch und wirtschaftlich sauber abbildet. Schließlich kann Security- oder administrative Isolation eine Trennung erzwingen, wenn bestimmte Daten oder Recovery-Systeme bewusst nicht derselben administrativen Domäne angehören sollen. Aus dieser Summe von Gründen folgt, dass eine Architektur aus zwei oder drei spezialisierten Plattformen durchaus das bessere Konsolidierungsergebnis sein kann als eine einzige universelle.
Vom System zur Workload: ein Entscheidungsmodell
Vor einer Konsolidierung sollte jedes bestehende Storage-System inventarisiert werden – nach den darauf liegenden Workloads, der belegten und geplanten Kapazität, dem Wachstum, dem I/O-Profil, den Latenzanforderungen, den benötigten Protokollen, den Verfügbarkeits- und Data-Protection-Anforderungen, den Abhängigkeiten und dem Lifecycle-Status.
Anschließend werden nicht die Systeme gruppiert, sondern die Workloads. Eine in der Praxis brauchbare Einteilung unterscheidet vier Klassen: performance-kritische Workloads wie Datenbanken und transaktionsorientierte Anwendungen, bei denen die Latenz die bestimmende Größe ist; allgemeine Enterprise-Workloads wie Virtualisierung und Standardapplikationen ohne besondere Anforderungen; kapazitätsorientierte Workloads mit großen Datenmengen und moderateren Performance-Erwartungen; und schließlich Anwendungen mit Sonderanforderungen, also spezifischen technischen Voraussetzungen oder Support-Abhängigkeiten. Maßgeblich für die Zuordnung ist jeweils die Anforderung, die die Plattformwahl tatsächlich determiniert, nicht die Anwendungskategorie.
Erst danach wird geprüft, welche Gruppen gemeinsam auf einer Plattform betrieben werden können. Damit verschiebt sich die Fragestellung von „Wie viele Storage-Systeme können wir abschaffen?“ zu „Wie viele unterschiedliche Storage-Architekturen benötigen unsere Workloads tatsächlich?“ – und das ist die erheblich bessere Grundlage für eine Konsolidierungsentscheidung.
Fazit
Storage-Konsolidierung ist keine Hardwareentscheidung. Sie betrifft gleichzeitig Kapazitätsplanung, Performance, Betrieb, Kosten, Energiebilanz, Failure Domains, Cyber Resilience und Applikationsarchitektur – und in mehreren dieser Dimensionen wirkt sie in beide Richtungen zugleich. Der gemeinsame Ressourcenpool, der Kapazität flexibel nutzbar macht, ist derselbe Pool, in dem Workloads um Ressourcen konkurrieren. Die vereinheitlichte Data Protection, die Schutzlücken schließt, ist dieselbe, die administrative Domänen zusammenführt. Wer nur eine Richtung betrachtet, entscheidet auf halber Datenbasis.
Eine gewachsene Umgebung mit vielen Storage-Systemen ist deshalb nicht automatisch ineffizient, und eine zentrale Plattform ist nicht automatisch die bessere Architektur. Der entscheidende Schritt besteht darin, die historisch gewachsene Zuordnung von Anwendung zu vorhandenem System aufzulösen und durch eine anforderungsbasierte Kette zu ersetzen: vom Workload über seine technischen Anforderungen zur geeigneten Storage-Klasse und erst von dort zur Plattform.
Genau darin liegt der Wert einer Storage-Konsolidierung – nicht darin, möglichst viele Systeme abzuschaffen, sondern die Storage-Landschaft wieder an den tatsächlichen Anforderungen der Anwendungen auszurichten.
Quellen
Storage Networking Industry Association (SNIA): SNIA Dictionary – virtualization. https://www.snia.org/education/online-dictionary/term/virtualization (abgerufen am 26.08.2026)
Storage Networking Industry Association (SNIA): SNIA Dictionary – storage virtualization. https://www.snia.org/education/online-dictionary/term/storage-virtualization (abgerufen am 26.08.2026)
Storage Networking Industry Association (SNIA): SNIA Dictionary – storage resource management. https://www.snia.org/education/online-dictionary/term/storage-resource-management (abgerufen am 26.08.2026)
Storage Networking Industry Association (SNIA): SNIA Emerald™ Power Efficiency Measurement Specification. Herstellerneutrale Mess- und Auswertungsmethodik für die Energieeffizienz von Storage-Systemen einschließlich Idle- und Active-Zuständen. https://www.snia.org/tech_activities/standards/curr_standards/emerald
Bundesrepublik Deutschland: Gesetz zur Steigerung der Energieeffizienz in Deutschland (Energieeffizienzgesetz – EnEfG) vom 18. November 2023, § 11 – Klimaneutrale Rechenzentren. https://www.gesetze-im-internet.de/enefg/__11.html (abgerufen am 26.08.2026)
Bundesregierung: Kabinettsbeschluss vom 24. Juni 2026 zum Entwurf eines Gesetzes zur Beschleunigung der Umsetzung der Energieeffizienzrichtlinie (EnEfG-Novelle). Parlamentarisches Verfahren zum Redaktionsschluss nicht abgeschlossen. [Primärfundstelle BT-Drucksache nachzutragen]
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
