WISSEN > ENTERPRISE STORAGE > ALL-FLASH ERKLÄRT
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
All-Flash Storage: Medien, NVMe und Protokolle erklärt
Wie TLC, QLC, NVMe, Fibre Channel und NVMe over Fabrics im I/O-Pfad zusammenspielen
Das sollten Sie mitnehmen: FALSCH NEU MACHEN
- WAN-Latenz lässt sich nicht wegkaufen, nur umgehen.
Edge File Services sorgen dafür, dass möglichst wenige Zugriffe den WAN-Pfad durchlaufen.
- Global verfügbar heißt nicht lokal gespeichert.
Für die Cache-Größe zählt der lokale Working Set, nicht die Gesamtkapazität.
- Caching und Locking lösen zwei verschiedene Probleme.
Das eine optimiert den Weg zu den Daten, das andere koordiniert konkurrierende Schreibzugriffe. Wer nur das erste plant, bekommt das zweite als Überraschung.
- Nicht jedes Produkt kann standortübergreifend sperren.
DFS Replication und Azure File Sync bieten kein globales Locking – das entscheidet die Auswahl früher als jede Performance-Kennzahl.
- Sizing braucht Nutzungsdaten, keine Kapazitätszahlen.
Aussagekräftig sind Dateianzahl, Änderungsverhalten und Zugriffsverhalten am Standort.

All-Flash Storage
Inhaltsverzeichnis
- Was bedeutet All-Flash überhaupt?
- NAND Flash: Wo die Daten tatsächlich gespeichert werden
- TLC: der Allrounder für Enterprise-Workloads
- QLC: wenn Flash zum Kapazitätsmedium wird
- NAND ist nicht NVMe
- Warum NVMe für All-Flash relevant wurde
- Die Host-Anbindung: Wie kommt der Server zum Storage?
- Fibre Channel: das klassische Enterprise-SAN
- iSCSI: Block Storage über TCP/IP
- NVMe over Fabrics: NVMe verlässt den Server
- NVMe/FC: bestehende Fibre-Channel-Fabric weiterverwenden
- NVMe/TCP: NVMe über das IP-Netzwerk
- NVMe/RDMA: wenn die Fabric selbst auf geringe Verarbeitungslatenz optimiert wird
- Und wo gehören SMB, NFS und S3 hin?
- Welches Protokoll eignet sich wofür?
- Das schnellste Flash hilft nicht gegen jeden Flaschenhals
- IOPS, Durchsatz und Latenz sind unterschiedliche Anforderungen
- Flash verschiebt nicht nur die Latenz, sondern auch die Energiebilanz
- TLC oder QLC? FC oder NVMe? Die Fragen gehören nicht zusammen
- Drei typische Architekturpfade
- Entscheidungshilfe für IT-Verantwortliche
- Fazit
- Quellen
All-Flash Storage wird häufig auf eine einfache Aussage reduziert: SSDs ersetzen Festplatten und machen Storage schneller. Für eine Architekturentscheidung reicht diese Betrachtung nicht aus.
Zwischen einer Anwendung und den eigentlichen Flash-Zellen liegen mehrere technische Ebenen. Das Speichermedium kann TLC- oder QLC-NAND sein. Die SSD kann über SAS oder NVMe angebunden sein. Zwischen Server und Storage-System können Fibre Channel, iSCSI, NVMe/FC oder NVMe/TCP zum Einsatz kommen. Und ein Storage-System kann zusätzlich File-Protokolle wie NFS und SMB bereitstellen.
Diese Technologien konkurrieren nicht zwangsläufig miteinander. Sie befinden sich teilweise an völlig unterschiedlichen Stellen des I/O-Pfads.
Die entscheidende Frage lautet deshalb nicht nur:
Welches All-Flash-System ist schnell genug?
Sondern:
Wie sieht der vollständige Datenpfad zwischen Anwendung und Flash aus – und welche Technologie eignet sich an welcher Stelle?
Was bedeutet All-Flash überhaupt?
Ein All-Flash Array (AFA) ist ein Storage-System, das Flash-Speicher als persistentes primäres Speichermedium verwendet. Der Begriff sagt zunächst weder aus, welcher NAND-Typ eingesetzt wird, noch wie die SSDs intern angebunden sind oder welches Protokoll die Server verwenden.
Ein typischer I/O-Pfad kann beispielsweise so aussehen:
Anwendung → Betriebssystem → SCSI → Fibre Channel → Storage-Controller → NVMe → SSD → TLC-NAND
Eine andere Architektur könnte dagegen so aussehen:
Anwendung → Betriebssystem → NVMe → NVMe/TCP → Ethernet → Storage-System → NVMe → SSD → QLC-NAND
Beide Systeme sind All-Flash-Systeme. Technisch unterscheiden sich ihre I/O-Pfade jedoch erheblich.
Für die Architekturentscheidung müssen deshalb mindestens drei Ebenen getrennt betrachtet werden:
Speichermedium: beispielsweise TLC oder QLC
interne SSD-Anbindung: beispielsweise SAS oder NVMe/PCIe
Host-Anbindung: beispielsweise FC, iSCSI, NVMe/FC oder NVMe/TCP
Erst aus ihrem Zusammenspiel entsteht die tatsächliche Storage-Architektur.
NAND Flash: Wo die Daten tatsächlich gespeichert werden
Die Basis klassischer SSDs bildet NAND Flash. NAND ist nicht gleich NAND: Ein wesentlicher Unterschied besteht darin, wie viele Bits eine einzelne Speicherzelle abbildet.
Technologie
Bits pro Zelle
Speicherdichte
Einordnung
SLC
1
niedrig
hohe Endurance, geringe Kapazitätsdichte
MLC
2
höher
frühere Enterprise-SSD-Generationen
TLC
3
hoch
verbreitet für Enterprise-Workloads
QLC
4
sehr hoch
kapazitätsorientierte Flash-Systeme
Mit jedem zusätzlichen Bit muss eine Zelle mehr unterschiedliche Ladungszustände zuverlässig unterscheiden können. Bei SLC reichen zwei Zustände für ein Bit. TLC muss acht Zustände unterscheiden, QLC bereits 16.
Die höhere Informationsdichte ermöglicht mehr nutzbare Kapazität pro NAND-Zelle. Sie hat jedoch technische Konsequenzen insbesondere für Schreibvorgänge und Endurance. SNIA führt die Endurance-Unterschiede zwischen Medientypen wie MLC, TLC und QLC auf deren unterschiedliche Program/Erase-Zyklenfähigkeit zurück und weist darauf hin, dass die tatsächlich erreichbare Endurance zusätzlich von der eingesetzten Fehlerkorrektur und vom Over-Provisioning abhängt.
Damit ist die Aussage „QLC hält weniger aus als TLC" zwar grundsätzlich als technologische Tendenz nachvollziehbar, für die Auswahl eines Enterprise-Arrays aber noch nicht ausreichend.
Entscheidend ist das Verhalten des gesamten Systems unter dem vorgesehenen Workload.
TLC: der Allrounder für Enterprise-Workloads
TLC speichert drei Bits pro Zelle und stellt damit einen Kompromiss zwischen Speicherdichte, Schreibverhalten und Endurance dar.
Das macht TLC für gemischte Enterprise-Workloads interessant, beispielsweise:
Datenbanken
Servervirtualisierung
VDI
transaktionale Anwendungen
SAP-Umgebungen
konsolidierte Server-Workloads
Dabei darf auch TLC nicht isoliert bewertet werden. Zwei SSDs mit TLC-NAND können unterschiedliche Endurance-Werte besitzen.
Eine wichtige Kenngröße ist DWPD – Drive Writes Per Day. Sie beschreibt, wie oft die spezifizierte Kapazität eines Laufwerks pro Tag innerhalb des vorgesehenen Lebenszyklus geschrieben werden darf.
Diese Angabe ist keine Herstellerkonvention, sondern ruht auf einer Normebene. JEDEC definiert in JESD218 die Anwendungsklassen für SSDs, die zugehörigen Nutzungsbedingungen und das Verfahren zur Endurance-Verifikation; die dabei verwendeten Lastprofile für Client- und Enterprise-Klassen sind in JESD219 getrennt beschrieben. Herstellerangaben zu TBW und DWPD beziehen sich auf diese Verfahren und nicht auf den Workload des Kunden.
Innerhalb der Enterprise-Klasse nennt SNIA typische Ausprägungen: rund 1 DWPD für überwiegend leseorientierte Anwendungen sowie 3 DWPD für Mixed-Use-Szenarien wie Caching, Datenbanken und schreibintensivere Lasten. Dies sind Klassenbeispiele und keine allgemeingültigen Werte für jede TLC- oder QLC-SSD.
Deshalb sollte die Entscheidung nicht lauten:
TLC = schreibintensiv.
Sondern:
Welche Schreibmenge erzeugt der konkrete Workload, welche Write Amplification entsteht und welche Endurance garantiert das konkrete Laufwerk beziehungsweise Storage-System dafür?
QLC: wenn Flash zum Kapazitätsmedium wird
QLC speichert vier Bits beziehungsweise 16 unterscheidbare Zustände pro Zelle.
Der wesentliche Vorteil ist die höhere Speicherdichte. Damit wird Flash auch für Datenbestände interessant, bei denen Kapazität eine größere Rolle spielt als eine sehr hohe dauerhafte Schreiblast.
Potenzielle Einsatzbereiche sind beispielsweise:
große File-Repositories
Content-Repositories
Analytics-Daten
Data Lakes
große überwiegend lesende Datenbestände
bestimmte Backup- und Recovery-Workloads
Allerdings wäre es technisch falsch, QLC grundsätzlich auf Read-only- oder Archiv-Workloads zu beschränken.
Wie viel Schreiblast ein QLC-basiertes Storage-System tatsächlich verarbeiten kann, hängt nicht nur vom NAND ab. Relevant sind unter anderem SSD-Controller, Over-Provisioning, GarbageCollection, Write Amplification und die Architektur des Storage-Systems.
Gerade die Write Amplification ist wichtig.
Muss der Host beispielsweise 1 TB schreiben, während intern aufgrund von Garbage Collection und Datenorganisation 2 TB in NAND geschrieben werden, beträgt der Write Amplification Factor:
WAF = NAND Writes / Host Writes = 2 TB / 1 TB = 2
Die NAND-Zellen erfahren damit die doppelte Schreibmenge dessen, was die Anwendung erzeugt hat.
SNIA definiert WAF genau als dieses Verhältnis von NAND Writes zu Host Writes und beschreibt dabei mehrere Einflussgrößen: Je zufälliger das Schreibmuster und je voller das Laufwerk, desto ungünstiger fällt der Wert aus; TRIM und ein ausreichender Anteil unbeschriebener Kapazität wirken in die entgegengesetzte Richtung. Zwischen Over-Provisioning und WAF besteht dabei ein umgekehrt proportionaler Zusammenhang.
Für die Entscheidung zwischen TLC und QLC ist deshalb die reale Schreibcharakteristik wichtiger als die einfache Klassifizierung eines Workloads als „Datenbank" oder „File Storage".
NAND ist nicht NVMe
Eine besonders wichtige begriffliche Trennung betrifft NAND und NVMe.
TLC und QLC beschreiben die Speicherung innerhalb der Flash-Zellen.
NVMe beschreibt dagegen eine Schnittstellen- und Protokollarchitektur für Non-Volatile Memory.
Eine SSD kann daher beispielsweise aus
TLC-NAND + SAS
oder
TLC-NAND + NVMe/PCIe
oder
QLC-NAND + NVMe/PCIe
bestehen.
Die Aussage „Das System verwendet NVMe statt TLC" wäre deshalb technisch falsch. Beide Begriffe beantworten unterschiedliche Fragen.
Warum NVMe für All-Flash relevant wurde
SATA und SAS haben ihre historischen Wurzeln in einer Storage-Welt, in der magnetische Festplatten eine zentrale Rolle spielten. Flash beseitigte jedoch die mechanischen Zugriffszeiten der Festplatte.
Dadurch gewinnen andere Bestandteile des I/O-Pfades relativ an Bedeutung.
NVMe wurde speziell für Non-Volatile Memory entwickelt und unterstützt eine stark parallelisierte I/O-Verarbeitung. In einer lokalen Architektur kommuniziert ein Host beispielsweise über PCIe mit einer NVMe-SSD:
CPU → PCIe → NVMe → SSD → NAND
Für Enterprise Storage reicht das jedoch noch nicht aus. Dort befinden sich die Daten normalerweise nicht ausschließlich auf lokalen SSDs eines einzelnen Servers.
Die zentrale Frage wurde daher:
Wie lässt sich die NVMe-I/O-Architektur über eine Storage Fabric hinweg verwenden?
Die Antwort darauf ist NVMe over Fabrics.
NVM Express führt NVMe heute modular. Die aktuelle Spezifikationsfamilie umfasst unter anderem die NVMe Base Specification 2.4 sowie eigenständige Transport-Spezifikationen für NVMe over PCIe, NVMe over RDMA und NVMe over TCP.
Die Host-Anbindung: Wie kommt der Server zum Storage?
Bei zentralem Enterprise Storage muss der Host das Storage-System über ein Netzwerk beziehungsweise eine Fabric erreichen.
Für Block Storage sind insbesondere vier Ansätze relevant:
Architektur
I/O-Modell
Transport
Typischer Kontext
FC/SCSI
SCSI
Fibre Channel
klassisches Enterprise-SAN
iSCSI
SCSI
TCP/IP
Ethernet/IP-basiertes SAN
NVMe/FC
NVMe
Fibre Channel
NVMe über FC-Fabric
NVMe/TCP
NVMe
TCP/IP
NVMe über Ethernet/IP
Hinzu kommen NVMe/RDMA für entsprechende RDMA-Fabrics sowie File- und Object-Protokolle wie NFS, SMB und S3 für grundsätzlich andere Zugriffskonzepte.
Fibre Channel: das klassische Enterprise-SAN
Fibre Channel ist eng mit klassischen Enterprise-SANs verbunden.
Ein typischer I/O-Pfad sieht vereinfacht so aus:
Anwendung → Filesystem/Volume Manager → SCSI → Fibre Channel → Storage-System → SSD
Der Server arbeitet dabei mit Block Storage. Das Storage-System präsentiert dem Host logische Blockgeräte beziehungsweise Logical Units.
Eine klassische FC-Architektur besteht typischerweise nicht einfach aus einer direkten Verbindung zwischen Server und Storage. Redundante Host Bus Adapter, Switch-Fabrics, Storage-Ports und Multipathing können mehrere unabhängige I/O-Pfade bereitstellen.
Damit wird allerdings auch deutlich, dass die Storage-Architektur nicht allein durch das Array bestimmt wird.
Ein leistungsfähiges All-Flash-System kann seine Eigenschaften nur innerhalb des gesamten Datenpfades entfalten. Host-Konfiguration, Fabric, Multipathing, Queueing und Storage-Controller bleiben Bestandteile dieses Pfades.
FC/SCSI ist insbesondere dort eine naheliegende Option, wo bereits eine etablierte FC-Infrastruktur und entsprechende Betriebsprozesse existieren.
iSCSI: Block Storage über TCP/IP
iSCSI verfolgt einen anderen Ansatz.
Die IETF definiert iSCSI als Transportprotokoll für SCSI über TCP. SCSI-Kommandos, Daten und Statusinformationen werden dabei innerhalb von iSCSI Protocol Data Units über TCP-Verbindungen zwischen Initiator und Target übertragen.
Der Datenpfad sieht vereinfacht so aus:
Anwendung → SCSI → iSCSI → TCP → IP → Ethernet → Storage-System
Der wesentliche Unterschied zu FC/SCSI besteht damit nicht darin, dass der Host plötzlich eine andere Art von Storage sieht. Auch hier handelt es sich um Block Storage auf Basis des SCSI-Modells.
Der Unterschied liegt im Transport.
Dadurch kann iSCSI vorhandene IP-/Ethernet-Technologien nutzen und benötigt keine Fibre-Channel-Fabric.
Das macht iSCSI insbesondere für Umgebungen interessant, in denen:
Ethernet ohnehin die strategische Netzwerkinfrastruktur darstellt,
keine FC-Infrastruktur vorhanden ist,
Block Storage benötigt wird,
die zusätzliche FC-Infrastruktur vermieden werden soll.
Daraus folgt allerdings nicht, dass iSCSI grundsätzlich langsamer oder FC grundsätzlich schneller wäre. Die tatsächliche Performance hängt von der vollständigen Implementierung und dem Workload ab.
NVMe over Fabrics: NVMe verlässt den Server
NVMe over Fabrics erweitert die NVMe-Architektur über die lokale PCIe-Verbindung hinaus.
NVM Express beschreibt NVMe-oF als Möglichkeit, NVMe-Kommandos und Daten zwischen Host und SSD beziehungsweise Storage-System über eine Netzwerk-Fabric zu übertragen. Die ursprüngliche eigenständige NVMe-oF-Spezifikation wurde ab NVMe 2.0 in die modulare NVMe-Spezifikationsfamilie überführt und wird von NVM Express heute nur noch als historische Referenz geführt.
Damit kann der Datenpfad beispielsweise lauten:
Anwendung → NVMe → Fabric → Storage-System → NVMe SSD → NAND
Statt NVMe nur zwischen CPU und lokaler SSD zu verwenden, wird die Architektur damit auf zentralen oder disaggregierten Storage erweitert.
Dafür existieren unterschiedliche Transporte. NVM Express selbst veröffentlicht dazu eigenständige Transport-Spezifikationen für PCIe, RDMA und TCP. Fibre Channel als NVMe-Fabric ist in dieser Spezifikationsfamilie nicht enthalten, in der Praxis aber als Datenpfad etabliert.
NVMe/FC: bestehende Fibre-Channel-Fabric weiterverwenden
NVMe und Fibre Channel sind keine Gegensätze.
Fibre Channel stellt die Fabric bereit; NVMe stellt das Storage-I/O-Modell bereit.
Damit kann eine FC-Infrastruktur sowohl einen klassischen
SCSI → Fibre Channel
als auch einen
NVMe → Fibre Channel
Datenpfad ermöglichen, sofern die beteiligten Komponenten und Implementierungen dies unterstützen.
Das ist insbesondere für Unternehmen interessant, die bereits in eine redundante FC-Infrastruktur investiert haben.
Die Architekturentscheidung lautet dann nicht zwingend:
Fibre Channel oder NVMe?
Sondern:
SCSI über Fibre Channel oder NVMe über Fibre Channel?
Damit kann die vorhandene Fabric grundsätzlich weiter genutzt werden, während sich das Storage-Protokoll verändert.
Die praktische Konsequenz ist eine Prüfaufgabe und keine Produktentscheidung: Ob ein NVMe-Datenpfad über eine bestehende FC-Fabric möglich ist, hängt von Host Bus Adaptern, Switch-Firmware, Multipathing-Implementierung und Storage-Frontend gleichermaßen ab. Die Fabric selbst ist dabei üblicherweise nicht der begrenzende Faktor.
NVMe/TCP: NVMe über das IP-Netzwerk
NVMe/TCP verfolgt ein ähnliches Grundprinzip wie NVMe/FC, verwendet aber TCP/IP als Transport.
Der Datenpfad lautet vereinfacht:
Anwendung → NVMe → TCP → IP → Ethernet → Storage-System
NVM Express führt NVMe over TCP als eigenständigen Transport; aktuell ist die Transport Specification Revision 1.3 Teil der NVMe-Spezifikationsfamilie.
Der architektonische Vorteil liegt auf der Hand: NVMe-basierter Remote-Storage kann über IP-Netzwerke realisiert werden.
Das macht NVMe/TCP besonders interessant für:
Ethernet-zentrierte Rechenzentren,
neue Storage-Infrastrukturen ohne bestehendes FC-SAN,
Scale-out-Architekturen,
Cloud- und Service-Provider-Umgebungen,
disaggregierte Compute-/Storage-Architekturen.
Allerdings beseitigt NVMe/TCP nicht die Physik des Netzwerks.
Ein entferntes NVMe-System hat weiterhin Netzwerk-, Switch-, Transport- und Storage-Latenzen. NVMe over Fabrics ist deshalb nicht mit lokalem NVMe/PCIe gleichzusetzen.
NVMe/RDMA: wenn die Fabric selbst auf geringe Verarbeitungslatenz optimiert wird
Eine weitere NVMe-oF-Variante verwendet RDMA – Remote Direct Memory Access.
NVM Express beschreibt RDMA als Mechanismus, mit dem Informationen zwischen dem Hauptspeicher von Computersystemen über ein Netzwerk übertragen werden können, ohne dass der normale Betriebssystempfad in gleicher Weise beteiligt ist. Die aktuelle NVMe over RDMA Transport Specification ist Revision 1.3.
Vereinfacht:
Anwendung → NVMe → RDMA → Fabric → Storage-System
Damit ist NVMe/RDMA insbesondere für Architekturen interessant, bei denen eine sehr niedrige Transportlatenz und geringer CPU-Overhead hohe Priorität besitzen.
Der technische Vorteil muss jedoch gegen die Anforderungen an Netzwerkhardware, Konfiguration und Betrieb abgewogen werden.
Für einen klassischen Enterprise-Workload ist deshalb nicht automatisch die Technologie mit dem theoretisch kürzesten I/O-Pfad die wirtschaftlich oder betrieblich sinnvollste Architektur.
Und wo gehören SMB, NFS und S3 hin?
SMB, NFS und S3 werden häufig gemeinsam mit FC, iSCSI oder NVMe genannt. Technisch erfüllen sie jedoch eine andere Funktion.
Bei FC, iSCSI und NVMe-oF erhält der Host grundsätzlich Block Storage.
Bei NFS und SMB erhält der Client einen File Service.
Bei S3 arbeitet die Anwendung mit Objekten über eine Object-Storage-API.
Das führt zu grundsätzlich unterschiedlichen Datenpfaden:
Block Storage
Application ↓ Filesystem ↓ Block I/O ↓ FC / iSCSI / NVMe-oF ↓ Storage
File Storage
Application ↓ SMB / NFS Client ↓ IP Network ↓ File Server / NAS ↓ Filesystem ↓ Storage
Object Storage
Application ↓ S3 API ↓ HTTP-basierter Zugriff ↓ Object Storage ↓ Storage Layer
Ein All-Flash-System kann durchaus File Services bereitstellen. Dadurch wird SMB aber nicht zu einem alternativen Blockprotokoll zu Fibre Channel.
Diese Unterscheidung ist für Architekturentscheidungen wesentlich.
Welches Protokoll eignet sich wofür?
Eine pauschale Rangliste ist technisch nicht sinnvoll. Die vorhandene Infrastruktur und der Workload sind mindestens ebenso wichtig wie das Protokoll selbst.
Anforderung
Technisch naheliegender Ansatz
bestehendes Enterprise-FC-SAN
FC/SCSI weiterhin prüfen
bestehendes FC-SAN, NVMe-End-to-End gewünscht
NVMe/FC prüfen
klassischer Block Storage über Ethernet
iSCSI
neue IP-basierte NVMe-Architektur
NVMe/TCP
besonders latenzorientierte Fabric
NVMe/RDMA prüfen
File Service mit Windows-Rechte- und AD-Semantik
SMB
File Service mit POSIX-Semantik
NFS
Object-/Cloud-native Anwendungen
S3
Die beiden File-Zeilen sind bewusst nicht nach Betriebssystem formuliert. SMB und NFS werden heute plattformübergreifend eingesetzt; die unterscheidende Achse ist das Rechte- und Konsistenzmodell, das die Anwendung erwartet, nicht das Betriebssystem des Clients.
„Prüfen" ist ebenfalls bewusst gewählt. Ein Protokoll sollte nicht allein aufgrund seiner theoretischen Architektur ausgewählt werden.
Das schnellste Flash hilft nicht gegen jeden Flaschenhals
Eine der wichtigsten Konsequenzen aus All-Flash besteht darin, dass sich die Bottlenecks verschieben können.
Bei einer Festplatte dominiert die Mechanik einen erheblichen Teil der Medienzugriffszeit. Flash beseitigt Seek- und Rotationszeiten. Damit können andere Komponenten des Datenpfads relativ stärker ins Gewicht fallen.
Beispielsweise:
Anwendung → Betriebssystem → Host Stack → HBA/NIC → Fabric → Storage Frontend → Controller → SSD → NAND
Die Latenz, die eine Anwendung wahrnimmt, entsteht aus dem gesamten Pfad.
Vereinfacht:
L_total = L_host + L_transport + L_storage + L_media
Die Gleichung ist ein Architekturmodell und keine Aussage, dass sämtliche Komponenten immer rein seriell oder unabhängig voneinander arbeiten. Moderne Storage-Systeme verarbeiten zahlreiche I/Os parallel, verwenden Queues, Caches und weitere Optimierungen.
Das Modell zeigt aber einen wichtigen Zusammenhang:
Wenn L_media stark sinkt, verschwinden L_host, L_transport und L_storage nicht.
Genau deshalb ist die alleinige Betrachtung der SSD-Latenz für die Bewertung eines Enterprise-All-Flash-Systems unzureichend.
IOPS, Durchsatz und Latenz sind unterschiedliche Anforderungen
Auch „Performance" muss genauer definiert werden.
Latenz beschreibt, wie lange ein I/O benötigt.
IOPS beschreiben, wie viele I/O-Operationen pro Zeiteinheit verarbeitet werden.
Durchsatz beschreibt die übertragene Datenmenge pro Zeiteinheit.
Diese Größen hängen unter anderem von Blockgröße, Parallelität und Workload ab.
Vereinfacht gilt:
Durchsatz ≈ IOPS × durchschnittliche I/O-Größe
100.000 IOPS mit 4 KiB entsprechen beispielsweise einer völlig anderen Datenrate als 100.000 IOPS mit 128 KiB.
Deshalb ist die Aussage:
„Dieses Array schafft eine Million IOPS."
für eine Architekturentscheidung ohne weitere Angaben kaum ausreichend.
Mindestens relevant sind:
Blockgröße
Read-/Write-Verhältnis
Random oder Sequential
Queue Depth
Parallelität
Cache-Zustand
Anzahl Hosts
Transport
Latenzverteilung
Datenreduktion und weitere aktive Storage-Funktionen
Der wichtigste Parameter fehlt in den meisten Datenblättern
Zu diesen Angaben kommt ein Aspekt, der Flash von Festplatten grundlegend unterscheidet: Ein Flash-Medium liefert nicht über seine gesamte Betriebsdauer dieselbe Performance.
Ein fabrikneues oder frisch initialisiertes Laufwerk verfügt über große zusammenhängende Bereiche unbeschriebener Kapazität. Garbage Collection muss zu diesem Zeitpunkt kaum arbeiten, die Write Amplification liegt nahe bei eins, und die gemessenen Werte sind entsprechend hoch. Dieser Zustand ist nicht der Betriebszustand, sondern ein Übergangszustand.
Die SNIA Solid State Storage Performance Test Specification adressiert genau diesen Punkt und macht die Unterscheidung zur Grundlage jeder Messung. Sie definiert einen Ausgangszustand über einen Purge-Vorgang, anschließend eine Preconditioning-Phase, die das Laufwerk gezielt in den Lastbereich überführt, und schließlich den Steady State als denjenigen Zustand, in dem die gemessene Performance über mehrere Testrunden hinweg konvergiert. Erst die im Steady State ermittelten Werte gelten als vergleichbar.
Die Preconditioning-Phase ist dabei zweistufig aufgebaut: Zunächst wird der Adressbereich workload-unabhängig beschrieben, um alle Blöcke zu berühren; danach folgt eine workload-abhängige Phase mit demjenigen Lastprofil, das anschließend auch gemessen wird.
Für die Bewertung eines Angebots folgt daraus eine konkrete Frage: In welchem Zustand wurde gemessen? Ein IOPS-Wert ohne Angabe zu Preconditioning und Steady State beschreibt möglicherweise einen Zustand, den das System im Produktivbetrieb nie wieder erreicht. Gerade bei QLC-basierten Systemen mit SLC-Cache oder ähnlichen Puffermechanismen kann der Unterschied zwischen Spitzenwert und Dauerlastverhalten erheblich sein.
Gerade All-Flash macht diese Differenzierung wichtiger, weil sehr hohe Parallelität möglich sein kann.
Flash verschiebt nicht nur die Latenz, sondern auch die Energiebilanz
Die Diskussion über All-Flash konzentriert sich meist auf Performance und Kapazität. Für den Betrieb eines Rechenzentrums ist jedoch eine zweite Größe mindestens ebenso relevant: Leistungsaufnahme, Kühllast und Stellfläche. Diese Größen verhalten sich beim Übergang von rotierendem Speicher zu Flash nicht linear, und sie lassen sich nicht aus dem Datenblatt eines einzelnen Laufwerks ableiten.
Der Effekt entsteht auf Systemebene, nicht auf Laufwerksebene
Eine Festplatte erzeugt eine weitgehend konstante mechanische Grundlast, unabhängig davon, ob auf sie zugegriffen wird. Eine SSD hat eine deutlich niedrigere Ruheleistungsaufnahme, deren Verbrauch stärker mit der tatsächlichen Aktivität korreliert. Der Vergleich einzelner Laufwerke greift dennoch zu kurz.
Der wesentliche Hebel liegt in der Kapazitätsdichte. Wenn eine bestimmte Nutzkapazität statt auf mehreren Einschüben mit rotierenden Medien auf wenigen hochkapazitiven SSDs abgebildet wird, entfallen nicht nur Laufwerke, sondern Gehäuse, Netzteile, Lüfter, Verkabelung und Höheneinheiten. Kühllast und Stellflächenbedarf sinken in diesem Fall stärker als die reine Summe der Laufwerksleistungsaufnahmen vermuten lässt.
Diesem Effekt steht ein gegenläufiger gegenüber. Leistungsorientierte NVMe-SSDs mit hoher Kapazität haben eine erhebliche Leistungsaufnahme pro Laufwerk, die konzentriert in wenigen Höheneinheiten anfällt. Eine geringere Gesamtleistungsaufnahme kann also mit einer höheren Leistungsdichte pro Rack einhergehen. Für die Kühlungsauslegung ist das die schwierigere Größe. Hinzu kommt, dass Datenreduktionsverfahren wie Kompression und Deduplizierung Arbeit vom Medium in die Controller verlagern; die eingesparte Kapazität wird teilweise durch zusätzliche Rechenlast erkauft.
PUE ist für diese Entscheidung die falsche Kennzahl
Die Energieverbrauchseffektivität setzt den Gesamtenergiebedarf eines Rechenzentrums ins Verhältnis zum Energiebedarf der Informationstechnik. Der Wert beschreibt damit den Overhead der Infrastruktur, nicht die Effizienz der IT selbst.
Daraus ergibt sich ein Verhalten, das bei Storage-Modernisierungen regelmäßig zu Fehlinterpretationen führt: Wer die IT-Last senkt, indem er eine große Zahl rotierender Medien durch wenige Flash-Systeme ersetzt, verkleinert den Nenner. Bleibt die Infrastruktur – Kälteanlagen, USV, Verteilung – unverändert dimensioniert, verschlechtert sich der PUE rechnerisch, obwohl der absolute Energieverbrauch des Rechenzentrums gesunken ist.
Der umgekehrte Fall ist ebenso möglich. Ein hoch ausgelastetes Rechenzentrum mit hoher IT-Last weist einen besseren PUE aus als dasselbe Rechenzentrum bei geringer Auslastung, ohne dass sich an der Effizienz irgendeiner Komponente etwas geändert hätte.
Für die Bewertung einer Storage-Architektur ist PUE deshalb ungeeignet. Die relevante Größe ist der absolute Energiebedarf pro nutzbarer Kapazität beziehungsweise pro erbrachter Leistung. SNIA stellt mit der Emerald Power Efficiency Measurement Specification ein workload-basiertes Messverfahren für genau diese Ebene bereit; die Fassung 3.0.3 wurde als ISO/IEC 24091:2019 übernommen, die aktuelle Fassung 4.0.0 erweitert die Taxonomie ausdrücklich um Solid-State-basierte Systeme.
Die regulatorische Ebene betrifft die Auslegung, nicht das Array
Das Energieeffizienzgesetz verpflichtet Betreiber von Rechenzentren in Deutschland auf konkrete PUE-Grenzwerte. Für Rechenzentren, die vor dem 1. Juli 2026 den Betrieb aufgenommen haben, gilt nach § 11 EnEfG ab dem 1. Juli 2027 ein Wert von kleiner oder gleich 1,5 und ab dem 1. Juli 2030 von kleiner oder gleich 1,3 im Jahresdurchschnitt. Rechenzentren, die ab dem 1. Juli 2026 in Betrieb gehen, müssen einen Wert von kleiner oder gleich 1,2 erreichen und zusätzlich einen Mindestanteil wiederverwendeter Energie nach DIN EN 50600-4-6 aufweisen, der sich nach dem Jahr der Inbetriebnahme staffelt.
Eine Novelle des Gesetzes ist im Verfahren. Der Kabinettsbeschluss vom 24. Juni 2026 sieht für Bestandsrechenzentren gelockerte Grenzwerte von 1,6 ab Juli 2027 und 1,4 ab Juli 2030 sowie abgeschwächte Anforderungen an die Abwärmenutzung vor; der Grenzwert für Neubauten bleibt nach diesem Entwurf bei 1,2. Bis zur Verkündung gilt das bestehende Recht unverändert.
Der entscheidende Punkt für die Storage-Architektur liegt in der Kombination beider Absätze dieses Kapitels. Weil der PUE-Grenzwert eine IT-Last im Nenner voraussetzt, kann eine Storage-Konsolidierung die Zielerreichung erschweren, obwohl sie den Energieverbrauch senkt. Wer beides gleichzeitig verantwortet, sollte die Storage-Entscheidung und die Auslegung der Infrastruktur nicht getrennt betrachten.
TLC oder QLC? FC oder NVMe? Die Fragen gehören nicht zusammen
Ein häufiger Architekturfehler besteht darin, verschiedene Ebenen miteinander zu vergleichen.
TLC versus QLC beantwortet die Frage:
Welche Eigenschaften besitzt das physische Flash-Medium?
SAS versus NVMe beantwortet:
Wie kommuniziert das Storage-System beziehungsweise der Host mit dem Laufwerk?
SCSI versus NVMe beantwortet:
Welches Storage-I/O-Modell beziehungsweise Command Set wird verwendet?
FC versus TCP/IP beziehungsweise RDMA beantwortet:
Über welche Fabric beziehungsweise welchen Transport erfolgt die Kommunikation?
SMB/NFS versus Block Storage beantwortet:
Welche Storage-Abstraktion erhält die Anwendung beziehungsweise der Client?
Erst wenn diese Ebenen getrennt betrachtet werden, lässt sich ein Storage-System technisch sinnvoll bewerten.
Drei typische Architekturpfade
Die Entwicklung lässt sich anhand dreier vereinfachter Architekturen darstellen.
Klassisches All-Flash SAN
Server → SCSI → Fibre Channel → Storage Controller → SAS → SSD → NAND
Diese Architektur kann weiterhin sinnvoll sein, insbesondere wenn eine etablierte FC-Infrastruktur vorhanden ist und der Workload keine andere Architektur erfordert.
NVMe-basiertes FC-SAN
Server → NVMe → Fibre Channel → Storage Controller → NVMe/PCIe → SSD → NAND
Hier wird NVMe sowohl innerhalb der Storage-Plattform als auch über die Fabric genutzt.
Ethernet-basierte NVMe-Architektur
Server → NVMe → TCP/IP → Ethernet → Storage-System → NVMe/PCIe → SSD → NAND
Damit lässt sich eine NVMe-basierte Storage-Architektur ohne Fibre-Channel-Fabric aufbauen.
Keine dieser Architekturen ist grundsätzlich die beste.
Die richtige Architektur hängt davon ab, welches Problem gelöst werden soll.
Entscheidungshilfe für IT-Verantwortliche
Für eine All-Flash-Entscheidung sollte deshalb nicht mit einem bestimmten Produkt begonnen werden.
Sinnvoller ist eine schrittweise Betrachtung.
1. Workload verstehen
Wie viele Daten werden gelesen und geschrieben? Sind die Zugriffe Random oder Sequential? Welche Blockgrößen treten auf? Welche Latenzen benötigt die Anwendung?
2. Kapazität und Schreibvolumen trennen
Eine Umgebung mit 500 TB Kapazität schreibt nicht automatisch 500 TB pro Tag. Für die Medienwahl ist deshalb neben der Gesamtkapazität insbesondere das tatsächliche Schreibvolumen relevant.
3. TLC und QLC anhand des Workloads bewerten
Nicht der NAND-Name allein entscheidet. Endurance, Write Amplification, Over-Provisioning und die Architektur des konkreten Storage-Systems müssen gemeinsam betrachtet werden.
4. Bestehende Fabric berücksichtigen
Eine vorhandene, redundant aufgebaute und betrieblich etablierte FC-Infrastruktur besitzt einen anderen Ausgangspunkt als ein neues Rechenzentrum ohne SAN.
NVMe/TCP kann technisch attraktiv sein, rechtfertigt aber nicht automatisch den Austausch einer funktionierenden FC-Architektur.
Umgekehrt sollte Fibre Channel nicht allein deshalb eingeführt werden, weil es traditionell für Enterprise Storage verwendet wird.
5. Performance-Anforderung präzisieren
Benötigt die Anwendung geringe Latenz, hohe IOPS, hohen sequenziellen Durchsatz oder eine Kombination daraus?
Erst danach lässt sich beurteilen, ob ein anderer Datenpfad überhaupt einen relevanten Vorteil verspricht. Bei der Bewertung von Herstellerangaben ist zusätzlich zu klären, in welchem Zustand gemessen wurde.
6. Den gesamten I/O-Pfad betrachten
Nicht nur die SSD entscheidet:
Host → Protokoll → Fabric → Storage-Frontend → Controller → SSD → NAND
Der langsamste oder ausgelastete Bestandteil des Pfads kann die nutzbare Performance begrenzen.
7. Energie-, Kühl- und Flächenbilanz einbeziehen
Leistungsaufnahme, resultierende Kühllast, Leistungsdichte pro Rack und Stellflächenbedarf gehören in dieselbe Bewertung wie Performance und Endurance – und zwar auf Systemebene, nicht auf Laufwerksebene.
Fazit
All-Flash Storage ist heute weniger eine Frage „SSD oder Festplatte?" als eine Frage der gesamten I/O-Architektur.
TLC und QLC bestimmen Eigenschaften des physischen Flash-Mediums. SAS und NVMe betreffen die Kommunikation mit SSDs. SCSI und NVMe definieren unterschiedliche Storage-I/O-Modelle. Fibre Channel, TCP/IP und RDMA stellen unterschiedliche Transportmöglichkeiten bereit. SMB, NFS und S3 liegen wiederum auf einer anderen Ebene und stellen File- beziehungsweise Object-Zugriffe bereit.
Für IT-Verantwortliche folgt daraus eine zentrale Regel:
Nicht einzelne Technologien vergleichen, sondern den vollständigen Datenpfad bewerten.
Eine QLC-NVMe-SSD kann Bestandteil eines über Fibre Channel angebundenen Storage-Systems sein. Ein TLC-basiertes Array kann über NVMe/TCP erreichbar sein. Ein All-Flash-System kann gleichzeitig FC-Block-Storage und File Services bereitstellen.
Deshalb sollte die Architekturentscheidung beim Workload beginnen und nicht beim Produktnamen:
Workload → Zugriffstyp → Performance- und Endurance-Anforderung → Protokoll/Fabric → Storage-Architektur → Medium
Erst danach lässt sich sinnvoll entscheiden, welche Kombination aus TLC oder QLC, SCSI oder NVMe sowie Fibre Channel, TCP/IP oder RDMA technisch angemessen ist. Und erst wenn Energiebedarf, Kühllast und Stellfläche in derselben Rechnung stehen, ist die Entscheidung betrieblich vollständig.
Quellen
IETF Chadalapaka, M.; Satran, J.; Meth, K.; Black, D.: Internet Small Computer System Interface (iSCSI) Protocol (Consolidated), RFC 7143, Proposed Standard, April 2014. Obsoletet RFC 3720, 3980, 4850 und 5048. https://www.rfc-editor.org/info/rfc7143
NVM Express, Inc. NVM Express Specifications. Stand 4. August 2026: NVM Express Base Specification Revision 2.4; NVM Command Set Specification Revision 1.3; NVMe over PCIe Transport Specification Revision 1.4; NVMe over RDMA Transport Specification Revision 1.3; NVMe over TCP Transport Specification Revision 1.3. https://nvmexpress.org/specifications/
NVM Express, Inc. NVMe over Fabrics Specification. Ab NVMe 2.0 in die modulare Spezifikationsfamilie überführt; wird auf der Spezifikationsseite ausschließlich als historische Referenz geführt. https://nvmexpress.org/specifications/
JEDEC Solid State Technology Association Solid-State Drive (SSD) Requirements and Endurance Test Method, JESD218C, Mai 2025 (Revision von JESD218B.03, August 2024). Definiert Anwendungsklassen, Nutzungsbedingungen, Endurance Rating und Verifikationsverfahren. https://www.jedec.org/standards-documents/focus/flash/solid-state-drives
JEDEC Solid State Technology Association Solid-State Drive (SSD) Endurance Workloads, JESD219A.01, Juli 2012. Definiert die Lastprofile für Client- und Enterprise-Klasse, die in Verbindung mit JESD218 zu verwenden sind. https://www.jedec.org/standards-documents/docs/jesd219a
Storage Networking Industry Association (SNIA) Hands, J. (SNIA Solid State Drive Special Interest Group): Endurance of NVMe, SAS, and SATA SSDs, März 2021. Technische Einordnung von SSD-Endurance, NAND-Medientypen, Over-Provisioning, DWPD und Write Amplification. https://snia.org/sites/default/files/SSSI/NVMe_SAS_SATA_Endurance_White_Paper.pdf
Storage Networking Industry Association (SNIA) Solid State Storage (SSS) Performance Test Specification (PTS), Version 2.0.2. Definiert Purge, Preconditioning, Steady State, ActiveRange und Datenmuster als Voraussetzung vergleichbarer Performance-Messungen. https://www.snia.org/tech_activities/standards/curr_standards/pts
Storage Networking Industry Association (SNIA) SNIA Emerald Power Efficiency Measurement Specification, Version 4.0.0, verabschiedet am 3. Juli 2020; die vorhergehende Fassung 3.0.3 wurde als ISO/IEC 24091:2019 übernommen. https://www.snia.org/emerald/access/specification
Bundesrepublik Deutschland Gesetz zur Steigerung der Energieeffizienz und zur Änderung des Energiedienstleistungsgesetzes (Energieeffizienzgesetz – EnEfG), in Kraft seit 18. November 2023, hier insbesondere § 11 (Klimaneutrale Rechenzentren). https://www.gesetze-im-internet.de/enefg/__11.html
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

