WISSEN > ENTERPRISE STORAGE > WAS IST ENTERPRISE STORAGE
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Was ist Enterprise Storage?
Anforderungen, Funktionen und Einsatzbereiche
Das sollten Sie mitnehmen:
- Anforderungen entscheiden, nicht Produkte.
Ob eine Plattform Enterprise-tauglich ist, bestimmt nicht ihre Kapazität, sondern ob sie die Anforderungen des betriebenen Workloads erfüllt.
- Performance ergibt sich aus dem Workload.
Eine IOPS-Zahl ohne Angabe von Blockgröße, Zugriffsmuster und Parallelität trägt keine Architekturentscheidung.
- Die Reihenfolge entscheidet.
Erst der Workload, daraus die Anforderungen, und erst daraus die Architektur – nicht umgekehrt.
- Verfügbarkeit ist keine Datensicherheit.
Redundanz und Replikation beherrschen Ausfälle, nicht die Verschlüsselung, Löschung oder Manipulation von Daten.
- Lifecycle und Migration sind Auswahlkriterien.
Beide entscheiden über die Betreibbarkeit einer Plattform und gehören deshalb vor die Architekturentscheidung.
Was ist Enterprise Storage?
Inhaltsverzeichnis
- Kapazität allein macht noch keinen Enterprise Storage
- Block, File und Object beschreiben unterschiedliche Zugriffsmodelle
- Nicht jeder Workload gehört auf dieselbe Plattform
- Aus dem Einsatzzweck entstehen die Anforderungen
- Performance beginnt beim Workload, nicht beim Datenblatt
- Kapazität ist nicht nur eine Frage der Terabyte
- Verfügbarkeit beginnt mit der Frage, welcher Fehler beherrscht werden soll
- Verfügbarkeit ist nicht gleich Datensicherheit
- Lifecycle kann wichtiger werden als zusätzliche Kapazität
- Migration gehört bereits in die Storage-Planung
- Erst jetzt wird die Storage-Architektur relevant
- Fazit
- Quellen
Enterprise Storage wird häufig über Größe definiert: viele Terabyte, Petabyte-Kapazitäten oder besonders leistungsfähige Systeme. Technisch greift diese Betrachtung zu kurz. Weder eine bestimmte Kapazität noch Flash-Medien, redundante Controller oder eine bestimmte Architektur machen ein Storage-System automatisch zu Enterprise Storage.
Entscheidend ist eine andere Frage: Kann die Storage-Infrastruktur die Anforderungen der darauf betriebenen Anwendungen und Geschäftsprozesse zuverlässig erfüllen? Dazu gehören je nach Einsatzgebiet Performance und Latenz ebenso wie Verfügbarkeit, Datenintegrität, Skalierbarkeit, Recovery, Cyber Resilience, Energiebedarf, Wartbarkeit und Lifecycle. Welche dieser Eigenschaften im Vordergrund steht, bestimmt der Workload.
Enterprise ist damit keine Technologiekategorie, sondern eine Eignungsaussage. Dieser Artikel folgt deshalb der Reihenfolge, in der sich diese Eignung überhaupt beurteilen lässt: vom Workload über die Anforderungen und die Dimensionierung zu Verfügbarkeit, Lifecycle und Migration – und erst am Ende zur Architekturentscheidung.
Kapazität allein macht noch keinen Enterprise Storage
Eine allgemeingültige technische Kapazitätsgrenze, ab der aus Storage Enterprise Storage wird, gibt es nicht. Ein System mit mehreren Petabyte kann vergleichsweise einfache Anforderungen erfüllen, während eine wesentlich kleinere Datenbankumgebung sehr hohe Anforderungen an Latenz, Verfügbarkeit und Datenintegrität stellt.
Sinnvoller ist eine anforderungsorientierte Betrachtung. Eine Enterprise-Storage-Plattform muss entsprechend ihrem Einsatzgebiet definierte Anforderungen erfüllen können: vorhersehbare Performance und Latenz, Verfügbarkeit und Fehlertoleranz, Datenintegrität, Kapazität und Skalierbarkeit, Snapshots, Replikation und Recovery, Schutz gegen Manipulation und Cyberangriffe, unterbrechungsarme Wartung und Upgrades, Monitoring und Automatisierung, Integration in die vorhandene IT-Infrastruktur, einen beherrschbaren Energie- und Kühlbedarf sowie einen zum geplanten Betriebszeitraum passenden Produkt- und Support-Lifecycle.
Nicht jede Anwendung benötigt dabei die höchste Ausprägung aller Eigenschaften. Genau das macht die Anforderungsanalyse zum eigentlichen Ausgangspunkt.
Block, File und Object beschreiben unterschiedliche Zugriffsmodelle
Enterprise Storage ist nicht mit Block Storage gleichzusetzen. NIST behandelt Block, File und Object in seinen Security Guidelines for Storage Infrastructure ausdrücklich als unterschiedliche Storage-Service-Typen und ordnet sie einer Taxonomie nach Zugriffsart zu.
Block Storage speichert Daten in Blöcken. Die SNIA weist darauf hin, dass deren Zusammenfassung zu Dateien typischerweise durch ein Filesystem auf dem Host erfolgt; der Zugriff erfolgt über Protokolle wie SCSI, Fibre Channel, iSCSI oder RDMA. File Storage stellt Daten dagegen als Dateien innerhalb von Verzeichnisstrukturen bereit – der Client arbeitet mit Dateien statt unmittelbar mit adressierbaren Blöcken. Object Storage verwaltet Daten als individuell adressierbare Objekte mit eigenem Identifier und zusätzlichen Metadaten; bei Amazon S3 beispielsweise identifiziert ein Object Key ein Objekt innerhalb eines Buckets eindeutig.
Diese drei Modelle führen zu unterschiedlichen Zugriffspfaden und damit zu unterschiedlichen Eigenschaften. Sie sind allerdings keine Produktzuordnung: Eine Datenbank muss nicht grundsätzlich auf einem bestimmten Storage-Typ betrieben werden. Entscheidend bleiben die Anforderungen der konkreten Anwendung und die von ihr unterstützten Zugriffsmethoden.
[BILD: Zugriffspfade von Block, File und Object im Vergleich – Client, Protokollebene, Adressierungseinheit]
Für Object Storage als eigenständige Datenplattform vertiefen wir diese Architektur im Grundlagenartikel Was ist Object Storage?.
Nicht jeder Workload gehört auf dieselbe Plattform
Dass sich mehrere Workloads technisch auf einer Storage-Plattform konsolidieren lassen, bedeutet nicht, dass dies architektonisch sinnvoll ist.
In unseren Projekten betrachten wir insbesondere Ablage, File und Archiv häufig als unterschiedliche Einsatzbereiche. Sie unterscheiden sich in Zugriffsmuster, Performanceprofil, Verfügbarkeitsbedarf, Aufbewahrungsdauer und wirtschaftlicher Bewertung teils erheblich – auch dann, wenn sie oberflächlich betrachtet alle „Dateien" enthalten.
Die Architekturfrage lautet deshalb nicht, wie sich möglichst alle Daten auf eine Plattform bringen lassen, sondern welche Workloads einander in ihren Anforderungen ähnlich genug sind, um sinnvoll gemeinsam betrieben zu werden. Erst danach lässt sich beurteilen, ob eine Konsolidierung technische und wirtschaftliche Vorteile bringt.
Welche Kriterien über den Erfolg einer Konsolidierung entscheiden, behandeln wir im Artikel Wann lohnt sich Storage-Konsolidierung?.
Aus dem Einsatzzweck entstehen die Anforderungen
Steht fest, welche Workloads auf der Plattform betrieben werden sollen, lassen sich daraus die relevanten Anforderungen ableiten – und zwar in dieser Richtung, nicht umgekehrt.
Bei der Bewertung einer Storage-Umgebung beginnen wir deshalb nicht mit einer isolierten Performancezahl. Welche Parameter zuerst untersucht werden, hängt vom Kundenszenario ab, häufig stehen jedoch zwei Fragen am Anfang: Wie viel Kapazität wird benötigt, und wofür wird diese Kapazität verwendet? Aus dem Einsatzzweck ergeben sich anschließend die Performance-, Verfügbarkeits- und Aufbewahrungsanforderungen.
Eine Datenbank, ein File-Repository, ein Backup-Ziel und ein Archiv können dieselbe Kapazität benötigen und trotzdem vollkommen unterschiedliche Anforderungen an das Storage-System stellen. Datenbanken benötigen typischerweise eine niedrige und vor allem definierte Latenz, konsistente I/O-Performance und Datenintegrität. Virtualisierungsumgebungen stellen Anforderungen an Parallelität, Latenz, Verfügbarkeit und die Integration in den Hypervisor. File Services benötigen Kapazität, leistungsfähige Metadatenoperationen, einen tragfähigen Namespace und ein belastbares Berechtigungsmodell. Bei Backup-Zielen dominieren Datenrate, Kapazität, Recovery-Geschwindigkeit und der Schutz der Sicherungsdaten selbst. Archive erfordern Kapazität, Retention, Datenintegrität und ein tragfähiges Kostenprofil. Analytics- und KI-Workloads schließlich verlangen vor allem Datenrate, Parallelität und eine effiziente Datenbereitstellung.
Diese Zuordnungen sind Anhaltspunkte, keine Regeln. Sie ersetzen nicht die Analyse der konkreten Anwendung.
Performance beginnt beim Workload, nicht beim Datenblatt
Einzelne Herstellerangaben zu IOPS oder maximalem Durchsatz sagen wenig darüber aus, wie gut ein System einen konkreten Workload verarbeitet. Die SNIA beschreibt Storage Performance als Fähigkeit eines Storage-Systems, die I/O-Anforderungen einer Anwendung oder eines Workloads zu bedienen, und weist darauf hin, dass unterschiedliche Anwendungen unterschiedliche I/O-Muster und damit unterschiedliche Engpässe erzeugen. Einen universellen Performancewert für Storage gibt es folglich nicht.
Zu den wesentlichen Größen gehören IOPS als Anzahl der I/O-Operationen pro Sekunde, die Latenz als für die Bearbeitung eines I/O benötigte Zeit und die Datenrate in MB/s oder GB/s als pro Zeiteinheit übertragene Datenmenge. Diese Werte sind nur gemeinsam mit weiteren Parametern interpretierbar, insbesondere I/O-Größe, Read-/Write-Verhältnis, Random- oder Sequential-Zugriffen sowie der Parallelität der Anforderungen.
Wie stark diese Parameter das Ergebnis bestimmen, zeigt sich an der Blockgröße. Die SNIA weist darauf hin, dass sich Benchmarkergebnisse durch die Wahl der Workload-Parameter erheblich beeinflussen lassen – eine sehr kleine Blockgröße kann auf einem leistungsfähigen System IOPS-Werte erzeugen, die im Wettbewerbsvergleich beeindrucken und für die tatsächliche Anwendung ohne Aussagekraft bleiben. Die Angabe „das System erreicht 200.000 IOPS" ist deshalb ohne Beschreibung des zugrunde liegenden Workloads für eine Architekturentscheidung kaum verwertbar.
Wenn die Performance die Anzahl der Laufwerke bestimmt
Besonders deutlich wurde dieser Zusammenhang bei klassischen HDD-basierten Storage-Systemen. Eine Festplatte stellt gleichzeitig Kapazität und I/O-Leistung bereit. Die Anzahl benötigter Laufwerke ließ sich deshalb nicht ausschließlich aus der gewünschten Nettokapazität ableiten: Bei Workloads mit hohen Random-I/O-Anforderungen bestimmte die erforderliche I/O-Leistung die Laufwerkszahl, obwohl bereits deutlich weniger Laufwerke genügend Kapazität bereitgestellt hätten.
In unseren Projekten trat diese Situation bei HDD-basierten Systemen wiederholt auf. Eine rein kapazitätsorientierte Dimensionierung hätte dort die tatsächlichen Performanceanforderungen verfehlt.
Bei schnellen Medien beobachten wir diese Form der Dimensionierung seltener. Das bedeutet jedoch nicht, dass Performance-Sizing mit Flash überflüssig würde – Engpässe verlagern sich lediglich auf andere Komponenten des I/O-Pfades. Auch All-Flash-Systeme müssen deshalb anhand des tatsächlichen Workloads bewertet werden. Die Unterschiede zwischen Flash-Medien, NVMe, SAS, Fibre Channel, NVMe-oF und den daraus resultierenden Performanceeigenschaften behandeln wir ausführlicher unter All-Flash Storage.
Kapazität ist nicht nur eine Frage der Terabyte
Bei der Kapazitätsplanung ist nicht allein der aktuelle Datenbestand relevant. Berücksichtigt werden müssen das erwartete Wachstum, notwendige Reserven, der geplante Lifecycle und – sofern eingesetzt – die Auswirkungen von Datenreduktion. Deduplizierung und Kompression verändern das Verhältnis von Brutto- zu Nettokapazität abhängig vom Datenbestand; in unseren Projekten haben sich pauschal angesetzte Reduktionsfaktoren über den Betriebszeitraum wiederholt als zu optimistisch erwiesen.
Hinzu kommen die physischen Randbedingungen im Rechenzentrum. In mehreren unserer Projekte war nicht die Stellfläche der begrenzende Faktor, sondern die verfügbare Leistung pro Rack – insbesondere bei Storage-Erweiterungen in Umgebungen, die bereits durch andere Systeme ausgelastet waren. Eine Plattform, für die im Rechenzentrum keine Anschluss- und Kühlleistung mehr bereitsteht, ist unabhängig von ihren technischen Eigenschaften nicht einsetzbar. Anschlussleistung, Kühlbedarf und Rack-Footprint gehören deshalb aus unserer Sicht in dieselbe Betrachtung wie Kapazität und Performance.
Regulatorisch adressiert das Energieeffizienzgesetz (EnEfG) diesen Bereich seit dem 18. November 2023 und verpflichtet Betreiber von Rechenzentren unter anderem auf Grenzwerte für die Energieverbrauchseffektivität (PUE). Der am 24. Juni 2026 vom Bundeskabinett beschlossene Novellierungsentwurf sieht für Bestandsrechenzentren eine Lockerung vor – statt 1,5 künftig 1,6 ab dem 1. Juli 2027 und statt 1,3 künftig 1,4 ab dem 1. Juli 2030, jeweils im Jahresdurchschnitt –, während es für Rechenzentren mit Betriebsaufnahme ab dem 1. Juli 2026 beim Wert von 1,2 bleibt. Das parlamentarische Verfahren war zum Zeitpunkt dieses Artikels nicht abgeschlossen; bis dahin gilt der bisherige Rechtsstand.
Für die Storage-Planung ist ein anderer Punkt entscheidend. Der PUE setzt den Gesamtenergiebedarf eines Rechenzentrums ins Verhältnis zum Energiebedarf der IT-Systeme und beschreibt damit die Effizienz der Infrastruktur um die IT herum – nicht die Effizienz der IT selbst und nicht ihren absoluten Verbrauch. Eine Umgebung kann ihren PUE verbessern und gleichzeitig mehr Energie verbrauchen, wenn die installierte IT-Leistung schneller wächst als die Infrastrukturverluste sinken. Wir betrachten im Storage-Sizing deshalb die absolute Leistungsaufnahme der geplanten Konfiguration und nicht allein den regulatorisch geforderten Effizienzquotienten.
Verfügbarkeit beginnt mit der Frage, welcher Fehler beherrscht werden soll
Verfügbarkeit wird im Storage-Umfeld häufig mit Redundanz gleichgesetzt. Die SNIA definiert Data Availability jedoch als den Zeitraum, in dem Daten während der vorgesehenen Betriebszeit für Anwendungen zugänglich sind. Redundanz ist ein technisches Mittel, um dieses Ziel zu erreichen – nicht das Ziel selbst.
Für die Anforderungsdefinition ist deshalb zunächst zu klären, welche Ausfallszenarien überhaupt beherrscht werden sollen und welche Auswirkungen sie jeweils hätten. Der Ausfall einer einzelnen Komponente, der Ausfall eines kompletten Systems und der Ausfall eines Standorts führen zu vollkommen unterschiedlichen Anforderungen. Daraus leiten sich die tolerierbare Unterbrechungsdauer, der zulässige Datenverlust und damit RTO und RPO ab – als Anforderungen, nicht als Werte, die aus einem Produktdatenblatt übernommen werden.
In den von uns begleiteten Enterprise-Storage-Projekten gehört die systeminterne Redundanz regelmäßig zu den Grundanforderungen; häufig wird darüber hinaus eine Site-to-Site-Spiegelung vorgesehen. Daraus folgt allerdings nicht, dass jede Enterprise-Storage-Umgebung zwingend über zwei Standorte gespiegelt werden muss. Die erforderliche Redundanz ergibt sich aus den Auswirkungen der betrachteten Ausfallszenarien, nicht aus einer allgemeinen Erwartungshaltung.
Wie unterschiedliche Storage-Architekturen Redundanz, Failure Domains und Failure Handling technisch umsetzen, behandeln wir im Artikel Enterprise-Storage-Architekturen: Scale-up, Scale-out, SDS und disaggregierte Systeme im Vergleich.
Verfügbarkeit ist nicht gleich Datensicherheit
Ein besonders wichtiger Unterschied besteht zwischen Availability und Data Protection.
Redundante Controller, Netzteile oder Laufwerke ermöglichen den Weiterbetrieb bei bestimmten Hardwareausfällen. Replikation stellt eine zusätzliche Datenkopie bereit, gegebenenfalls an einem anderen Standort; die SNIA beschreibt Data Replication entsprechend als kontinuierliche Bereitstellung einer Datenkopie zur Unterstützung von High Availability und Redundanz. Diese Mechanismen beantworten jedoch eine andere Frage als Backup oder Cyber Resilience.
Wird eine Datei durch einen legitimen, aber kompromittierten Benutzerzugriff verschlüsselt oder gelöscht, wird diese Änderung auf ein repliziertes System übertragen. Dass mehrere identische Kopien vorhanden sind, macht den ursprünglichen Datenzustand nicht wiederherstellbar.
Auch ein Snapshot ist zunächst nur ein definierter Datenzustand zu einem Zeitpunkt. NIST beschreibt Snapshots als speichereffiziente Form der Point-in-Time-Kopie, die lediglich die gegenüber diesem Zeitpunkt geänderten Datenanteile mit Bezug auf die Quelldaten vorhält – mit der Konsequenz, dass Snapshots häufig ebenfalls unbrauchbar sind, wenn die Quelldaten nicht mehr verfügbar sind. Welche Schutzwirkung ein Snapshot entfaltet, hängt daher davon ab, wie er implementiert und gegen Veränderung oder Löschung geschützt ist.
NIST behandelt in seinen Security Guidelines for Storage Infrastructure neben klassischen IT-Sicherheitsmaßnahmen ausdrücklich storage-spezifische Bereiche wie Data Protection, Isolation, Restoration Assurance und Verschlüsselung. Für den Schutz der Sicherungsdaten fordert NIST unter anderem, die Konfiguration der Datensicherung zentral zu verwalten und vom Data Consumption Plane zu trennen, sodass Server und Clients ihre eigene Schutzkonfiguration nicht verändern können. Bei unzureichender Trennung dieser Ebenen kann ein Angreifer, der die Kontrolle über einen angebundenen Host erlangt, nicht nur die produktiven Daten beschädigen, sondern auch deren Kopien und Backups.
Ein hochverfügbares Storage-System ist damit nicht automatisch ein gegen logische Zerstörung oder Cyberangriffe geschütztes Storage-System. Redundanz, Replikation, Backup, Snapshots und Immutability erfüllen unterschiedliche Aufgaben und müssen als unterschiedliche Schutzebenen betrachtet werden.
Einen übergreifenden Einstieg in die Schutzmechanismen gibt Wie lässt sich Storage vor Ransomware schützen?. Die spezifischen Mechanismen moderner Enterprise-Storage-Plattformen behandeln wir unter Cyber Resilience im Enterprise Storage.
Lifecycle kann wichtiger werden als zusätzliche Kapazität
Storage-Systeme werden nicht ausschließlich ersetzt, weil sie zu klein oder zu langsam geworden sind. In unseren Projekten ist das End of Service regelmäßig ein konkreter Auslöser für die Erneuerung einer Storage-Plattform.
Das ist bei Enterprise-Infrastrukturen besonders relevant, weil Storage-Systeme häufig über viele Jahre betrieben werden. Bei der Auswahl ist deshalb nicht nur die aktuelle technische Leistungsfähigkeit zu betrachten, sondern auch der geplante Lifecycle: der Supportzeitraum, die Software- und Firmwarepflege, die Hardwarewartung, die Erweiterungsmöglichkeiten, die Kompatibilität zu Servern, Betriebssystemen und Protokollen sowie der voraussichtliche Zeitpunkt einer späteren Migration.
Eine Plattform kann ihre aktuellen Kapazitäts- und Performanceanforderungen noch erfüllen und trotzdem aus Lifecycle-Sicht ersetzt werden müssen.
Migration gehört bereits in die Storage-Planung
Auch die Migration sollte nicht erst betrachtet werden, nachdem die neue Plattform ausgewählt wurde. In unseren Projekten ist sie bereits bei der Planung und Auswahl ein relevantes Kriterium.
Zu klären sind Ausgangs- und Zielsystem, Datenvolumen, verwendete Protokolle, mögliche Migrationsverfahren, verfügbare Downtime, ein gegebenenfalls notwendiger Parallelbetrieb, die verfügbaren Netzwerkressourcen, die Validierung der übertragenen Daten sowie das Cutover- und Rollback-Verfahren.
In Projekten mit großen und geschäftskritischen Datenbeständen hat die Migrationsfähigkeit die Architekturentscheidung mehrfach mitbestimmt. Ein technisch geeignetes Zielsystem ist nur dann praktisch einsetzbar, wenn ein vertretbarer Weg vom bestehenden zum neuen System existiert.
[Querverweis: Storage-Migration – Artikel in Vorbereitung]
Erst jetzt wird die Storage-Architektur relevant
Sind Workloads, Anforderungen, Dimensionierung, Verfügbarkeitsbedarf, Lifecycle und Migrationsweg geklärt, lässt sich entscheiden, mit welcher technischen Architektur diese Anforderungen umgesetzt werden. Vorher lässt sich die Frage nicht sinnvoll beantworten, weil die verfügbaren Architekturmodelle sich gerade darin unterscheiden, welche Anforderungen sie besonders gut und welche sie weniger gut bedienen.
Vor dieser Entscheidung sollte deshalb festgehalten sein, welche Anwendungen und Daten auf dem System betrieben werden sollen, welche Kapazität einschließlich Wachstum, Reserven und Energiebedarf erforderlich ist, welche Performanceparameter sich daraus ableiten, welche Komponenten oder Standorte ausfallen dürfen und welche Datenstände nach einem Ausfall oder einer logischen Beschädigung wiederherstellbar sein müssen, über welchen Zeitraum das System betrieben und wie es erweitert und aktualisiert werden soll – und schließlich, wie die vorhandenen Daten auf die neue Plattform gelangen.
Diese Punkte sind keine Implementierungsdetails, sondern die Eingangsgrößen der Architekturentscheidung. Wie sich die verschiedenen Architekturmodelle in Datenpfad, Skalierung, Failure Handling und Trade-offs unterscheiden, behandeln wir deshalb gesondert:
Enterprise-Storage-Architekturen: Scale-up, Scale-out, SDS und disaggregierte Systeme im Vergleich
[BILD: Reihenfolge der Storage-Entscheidung – Workload, Anforderungen, Sizing, Availability, Lifecycle, Migration, Architektur]
Fazit
Die wichtigste Frage bei Enterprise Storage lautet nicht, welches System die meisten IOPS, die größte Kapazität oder die längste Feature-Liste besitzt, sondern welche Anforderungen tatsächlich erfüllt werden müssen.
Unsere Projekterfahrung zeigt, dass die Ausgangssituation je nach Unternehmen sehr unterschiedlich ist. Manchmal bestimmt Performance die Architektur, manchmal Kapazität. In anderen Projekten stehen Verfügbarkeit, Konsolidierung, Migration, die verfügbare Anschlussleistung oder schlicht das Erreichen des End of Service eines vorhandenen Systems im Vordergrund.
Gerade deshalb sollte die Auswahl nicht bei einer Storage-Technologie beginnen. Der tragfähige Weg führt vom Einsatzzweck über die Workloads und die daraus abgeleiteten Anforderungen zur Architektur – und erst danach zum Vergleich konkreter Systeme. Damit wird Enterprise Storage nicht über eine bestimmte Technologie definiert, sondern über seine eigentliche Aufgabe: Daten für die jeweiligen Geschäftsprozesse mit den erforderlichen Eigenschaften bereitzustellen und über den geplanten Lifecycle beherrschbar zu halten.
Quellen
Storage Networking Industry Association (SNIA): SNIA Online Dictionary. Definitionen unter anderem zu Block Storage, File Storage, Data Availability und Data Replication. Abruf: 30.08.2026.
Storage Networking Industry Association (SNIA), Networking Storage Forum: Everything You Wanted to Know About Throughput, IOPs, and Latency, But Were Too Proud to Ask, Webinar vom 07.02.2024 nebst zugehörigem Q&A. Herangezogen zur Performancedefinition sowie zur Abhängigkeit von Benchmarkergebnissen von Workload-Parametern. Abruf: 30.08.2026.
National Institute of Standards and Technology (NIST): Chandramouli, R.; Pinhas, D.: Security Guidelines for Storage Infrastructure, NIST Special Publication 800-209, Oktober 2020, DOI 10.6028/NIST.SP.800-209.
National Institute of Standards and Technology (NIST): Chandramouli, R.; Hibbard, E. A.: Security Guidelines for Storage Infrastructure, NIST SP 800-209r1, Initial Public Draft, Juli 2026. Die Kommentierungsfrist lief zum Zeitpunkt dieses Artikels noch (bis 08.09.2026); Revision 1 wird daher nicht als finaler Standard behandelt.
Amazon Web Services: Amazon S3 User Guide – Amazon S3 Objects / Object Keys / Object Metadata. Herangezogen ausschließlich zur Beschreibung der konkreten S3-Implementierung von Buckets, Object Keys und Metadaten. Abruf: 30.08.2026.
Bundesrepublik Deutschland: Gesetz zur Steigerung der Energieeffizienz und zur Änderung des Energiedienstleistungsgesetzes (Energieeffizienzgesetz – EnEfG), in Kraft seit 18.11.2023.
Bundesregierung: Entwurf eines Gesetzes zur Beschleunigung der Umsetzung der Energieeffizienzrichtlinie, Kabinettsbeschluss vom 24.06.2026 (Regierungsfassung vom 20.06.2026). Die im Text genannten PUE-Grenzwerte entstammen diesem Entwurf; das parlamentarische Verfahren war zum Zeitpunkt dieses Artikels nicht abgeschlossen. Abruf: 30.08.2026.
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
