Storage. Backup. Virtualisierung.
NVMe (Nonvolatile Memory Express) · Version 1.3 · © Stor IT Back 2026
NVMe (Non-Volatile Memory Express) ist ein für moderne nichtflüchtige Speicher entwickeltes Protokoll, das hohe Parallelität und geringe Latenzen ermöglicht. Lokale NVMe-SSDs werden typischerweise über PCI Express (PCIe) angebunden. Mit NVMe over Fabrics (NVMe-oF) lässt sich NVMe auch über Netzwerke bereitstellen, beispielsweise mit NVMe/TCP, NVMe/RDMA über RoCE oder NVMe über Fibre Channel.
Gegenüber älteren Speicherprotokollen wie SATA oder SAS kann NVMe den Protokoll-Overhead reduzieren und moderne Flash-Speicher besser auslasten. Davon profitieren insbesondere Datenbanken, Virtualisierung, Analyseplattformen, KI-/ML-Workloads und andere Anwendungen mit hohen IOPS- oder Latenzanforderungen.
Um die Geschwindigkeit von SSDs weiter zu erhöhen und die Latenz zu verringern, kommt die SAS oder
SATA Schnittstelle bei SSDs schnell an ihre Grenzen.
Eine deutliche Geschwindigkeits- und Durchsatzsteigerung ist bei diesen Protokollen nicht zu erwarten. Also nutzt man ein
vorhandenes Protokoll (bzw. eine Schnittstelle), den PCI-Express Bus. Daher auch der Name NVM Express (NVMe), Non Volatile Memory über PCI Express.
Die SSD wird also zu einer PCI-Express-Karte. Warum denn dies?
Der PCI-Express-Bus ist in jedem Server, PC und Notebook enthalten und er ist extrem schnell und direkt an der CPU. Also warum diese Schnittstelle nicht direkt nutzen, warum den
Umweg über SAS- oder SATA-Controller gehen?
Gerade für Server und Power-PCs werden diese SSDs angeboten, aber auch im Consumer-Segment nimmt diese Schnittstelle immer mehr Raum ein.
Aber was ist im Storage-Bereich? Da dort sehr viele Platten angeschlossen
werden müssen, kann dort nicht so einfach auf SAS als Bussystem verzichtet werden. Ein Umbau von SAS auf PCI Express wäre ähnlich komplex wie die Umstellung von
Fibre Channel auf SAS bei den
Festplatten vor einigen Jahren. Und es fehlt bei PCI-Express die Erweiterbarkeit auf einige hundert Schnittstellen pro System.
Im Enterprise oder Rechenzentrumsbetrieb können die NVMe-SSDs eingesetzt werden und zwar bei der Storage-Virtualisierung. Dort werden normale Server
mit PCI-Express-Bus eingesetzt. Dort können diese SSDs direkt als extrem schneller Cache verbaut werden.
Auch bei der Neuentwicklung von Storage-Systemen setzen immer mehr Hersteller auf NVMe, dort wird zwar nicht SAS komplett ersetzt,
sondern nur das Tier 0 im Storage-Tiering oder
der Flash-Cache mit den schnellen NVMe-SSDs aufgebaut. Damit wird der schnellste Speicher auch dort verwendet, wo er auch am besten genutzt wird. Also maximale Performance für
Daten, die auch die maximale Performance benötigen.
NVMe wurde speziell für moderne nichtflüchtige Speicher entwickelt.
Bei lokal angeschlossenen SSDs wird NVMe typischerweise über PCIe transportiert.
Die Architektur unterstützt viele parallele I/O-Vorgänge und reduziert gegenüber älteren Storage-Stacks unnötigen Protokoll-Overhead.
Dadurch können Flash-Speicher ihre hohe Leistung und niedrigen Zugriffszeiten besser ausspielen.
Ob NVMe-Laufwerke im laufenden Betrieb getauscht werden können, hängt von Bauform, Backplane, Plattform, Firmware und Betriebssystem ab.
Enterprise-Bauformen und Serverplattformen können Hot-Plug bzw. Hot-Swap unterstützen;
bei einer typischen M.2-SSD ist dies dagegen nicht automatisch gegeben..
Bei Servern ist der Boot von einer NVMe SSD nur über native UEFI möglich, ein Legacy BIOS Mode ist nicht verfügbar.
Die Bauform M.2, früher als Next Generation Form Factor (NGFF) bezeichnet, ist die gängigste Bauform im Server- und Desktop-Bereich. Bei dieser Bauform ist aber nicht nur NVMe definiert,
sondern auch SATA 3 und USB 3. Bei der NVMe sind bis zu 4 PCI-Express-Lanes möglich. Je nach Mainboard teilen sich zum Beispiel PCIe Slots die Leitungen mit den M.2-Steckplätzen. Dies sollte
bei der Bestückung beachtet werden.
Eine weitere Bauform ist U.2 bzw. früher SFF-8639. Dies bezeichnet die Steckverbindung und ist für SAS, SATA und PCI-Express definiert. Eine neuere Definition ist U.3. Insgesamt sind dort Controller verfügbar, die entweder SAS und SATA beherrschen, oder eben NVMe. Wichtig ist also bei der Auswahl der Komponenten, was denn an SSDs genutzt und welche Protokolle bevorzugt werden sollen.
NVMe kann nicht nur für lokal im Server installierte SSDs eingesetzt werden. Mit NVMe over Fabrics (NVMe-oF) lässt sich der NVMe-Zugriff auch über ein Netzwerk zwischen Servern und zentralen Storage-Systemen übertragen.
Dafür stehen verschiedene Transportwege zur Verfügung:
NVMe/TCP nutzt vorhandene TCP/IP- und Ethernet-Infrastrukturen.
NVMe/RDMA kann beispielsweise über RoCE besonders latenzarme Verbindungen ermöglichen.
In Fibre-Channel-Umgebungen lässt sich NVMe ebenfalls über die bestehende Fabric transportieren.
Der entscheidende Unterschied zu klassischen Storage-Stacks besteht also nicht darin, Ethernet oder Fibre Channel grundsätzlich zu umgehen. Vielmehr wird NVMe als für moderne Flash-Speicher optimiertes Protokoll über den jeweiligen Transport eingesetzt.
NVMe-oF ist besonders interessant, wenn zentraler Shared Storage mit sehr niedrigen Latenzen und hohen IOPS kombiniert werden soll. Typische Einsatzbereiche sind leistungsintensive Datenbanken, Virtualisierungs- und Container-Plattformen, Analytics sowie KI- und Machine-Learning-Workloads.
Ob sich NVMe-oF gegenüber etablierten SAN-Technologien lohnt, sollte anhand der tatsächlichen Engpässe entschieden werden. Relevant sind insbesondere Applikationslatenz, IOPS, Durchsatz, Netzwerk, CPU-Auslastung, Hochverfügbarkeit und Betriebsaufwand.
NVMe kann nicht nur lokal über PCI Express oder über Ethernet-basierte Netzwerke genutzt werden. Auch Fibre Channel (FC) kann NVMe zwischen Server und Storage-System transportieren. Diese Variante wird als NVMe over Fibre Channel, NVMe/FC oder FC-NVMe bezeichnet.
Interessant ist dabei ein Blick auf das Fibre-Channel-Schichtenmodell. Fibre Channel besteht vereinfacht aus den Ebenen FC-0 bis FC-4. Die unteren Ebenen kümmern sich um die physische Übertragung, die Signalisierung, Frames, Flusskontrolle und gemeinsame Dienste der Fabric. Auf der obersten Ebene FC-4 werden die eigentlichen Storage- beziehungsweise Upper-Layer-Protokolle auf Fibre Channel abgebildet.
Beim klassischen Fibre-Channel-SAN wird auf dieser Ebene üblicherweise FCP (Fibre Channel Protocol) eingesetzt. FCP transportiert SCSI-Kommandos über Fibre Channel. Für NVMe gibt es mit FC-NVMe ein eigenes Mapping auf derselben FC-4-Ebene.
Vereinfacht sieht das so aus:
NVMe ersetzt Fibre Channel also nicht. Vielmehr ersetzt beziehungsweise ergänzt NVMe auf der Protokollebene den klassischen SCSI-Datenpfad. Die vorhandene Fibre-Channel-Infrastruktur mit HBAs, Switches, Ports und Verkabelung bildet weiterhin das Transportnetzwerk.
Ein großer Vorteil dieses Aufbaus besteht darin, dass FCP und NVMe/FC parallel in derselben Fibre-Channel-Fabric betrieben werden können. Ein SAN kann somit weiterhin klassische SCSI-LUNs über FCP bereitstellen und gleichzeitig NVMe-Namespaces über NVMe/FC anbinden.
Dies ermöglicht eine schrittweise Migration. Bestehende Server und Anwendungen können weiterhin FCP (also SCSI über FC) verwenden, während geeignete Systeme bereits über NVMe/FC auf neue Storage-Ressourcen zugreifen. Es ist daher nicht zwingend erforderlich, eine bestehende Fibre-Channel-Infrastruktur vollständig durch eine neue Netzwerktechnologie zu ersetzen.
Voraussetzung ist allerdings, dass die beteiligten Komponenten – insbesondere Host Bus Adapter (HBA), Treiber, Betriebssystem, Fibre-Channel-Switches und Storage-System – NVMe/FC unterstützen.
NVMe kann mit NVMe over Fabrics (NVMe-oF) auch über ein Netzwerk zwischen Servern und zentralen Storage-Systemen übertragen werden. Für Ethernet-basierte Netzwerke sind dabei insbesondere zwei Varianten relevant: NVMe/TCP und NVMe/RDMA.
Beide Verfahren verwenden auf der Storage-Ebene das gleiche NVMe-Protokoll. Der wesentliche Unterschied liegt im darunterliegenden Netzwerktransport. Während NVMe/TCP auf dem etablierten TCP/IP-Stack aufsetzt, nutzt NVMe/RDMA einen für direkten Speicherzugriff optimierten RDMA-Transport.
Damit verwenden NVMe/TCP und NVMe/RDMA beide Ethernet als Netzwerk, unterscheiden sich aber deutlich darin, wie die Daten zwischen Host und Storage-System transportiert werden.
Bei NVMe/TCP werden NVMe-Kommandos und die zugehörigen Daten über TCP/IP übertragen. NVMe/TCP definiert dazu, wie NVMe-Queues, NVMe-oF-Kommandos und Daten auf TCP-Verbindungen abgebildet werden.
Der große Vorteil von NVMe/TCP ist, dass die Technologie auf einer normalen IP-Infrastruktur aufsetzt. Vorhandene Ethernet-Switches, Routing-Strukturen und Standard-Netzwerktechniken können grundsätzlich weiterverwendet werden. Spezielle RDMA-fähige Netzwerkkarten sind für die grundsätzliche Funktion nicht erforderlich.
Damit ist NVMe/TCP insbesondere für Unternehmen interessant, die vorhandene Ethernet-Infrastrukturen nutzen und die zusätzliche Komplexität eines RDMA-Netzwerks vermeiden möchten.
TCP übernimmt dabei bekannte Aufgaben wie zuverlässige Übertragung, Reihenfolge der Datenpakete, Flusskontrolle und die Behandlung verlorener Pakete. Dadurch lässt sich NVMe/TCP auch über geroutete IP-Netze und komplexere Netzwerkstrukturen einsetzen.
Der Preis für diese Flexibilität ist zusätzlicher Verarbeitungsaufwand im TCP/IP-Stack. Je nach Implementierung kann dadurch die CPU stärker belastet werden und die Latenz etwas höher ausfallen als bei einem optimierten RDMA-Datenpfad. Moderne Netzwerkkarten können jedoch zahlreiche TCP-Funktionen in Hardware beschleunigen.
Eine zweite Möglichkeit ist NVMe over RDMA. RDMA steht für Remote Direct Memory Access und ermöglicht die Übertragung von Daten zwischen den Arbeitsspeichern zweier Systeme mit deutlich weniger Beteiligung von CPU, Betriebssystem und klassischem Netzwerk-Stack.
Der entscheidende Unterschied zu NVMe/TCP besteht darin, dass die eigentlichen Nutzdaten bei RDMA sehr effizient direkt zwischen dafür vorgesehenen Speicherbereichen auf Host und Storage-System übertragen werden können.
Der klassische Datenpfad durch mehrere Software- und Betriebssystemschichten wird dadurch reduziert. Das kann die CPU entlasten und besonders niedrige sowie vorhersehbare Latenzen ermöglichen.
Für NVMe/RDMA können unterschiedliche RDMA-Technologien verwendet werden. Im Ethernet-Umfeld sind insbesondere RoCE und iWARP relevant.
RoCE steht für Remote Direct Memory Access over Converged Ethernet. Dabei wird RDMA über Ethernet transportiert.
Heute wird insbesondere RoCEv2 eingesetzt. RoCEv2 verwendet IP und UDP, sodass der RDMA-Verkehr auch über Layer-3-Netzwerke geführt werden kann.
RoCE kann einen sehr effizienten Datenpfad und niedrige Latenzen ermöglichen. Dafür müssen Server, Netzwerkkarten und Storage-Systeme RDMA beziehungsweise RoCE unterstützen.
Außerdem ist das Netzwerkdesign wichtiger als bei einer klassischen TCP-Verbindung. Überlastung, Paketverluste, Queueing und die Konfiguration der Ethernet-Switches können die Performance eines RoCE-Netzes wesentlich beeinflussen. In leistungsorientierten Umgebungen kommen deshalb häufig zusätzliche Mechanismen zur Verkehrssteuerung und Überlastkontrolle zum Einsatz.
Eine weitere RDMA-Technologie ist iWARP. Auch iWARP ermöglicht Remote Direct Memory Access, verwendet darunter jedoch TCP/IP.
Dadurch entsteht eine zunächst etwas überraschende Situation: Sowohl NVMe/TCP als auch NVMe/iWARP verwenden TCP, trotzdem handelt es sich um unterschiedliche Technologien.
Bei NVMe/TCP wird NVMe direkt auf den TCP-Transport abgebildet. Bei iWARP liegt dagegen eine RDMA-Schicht zwischen NVMe und TCP. Der Host und das Storage-System verwenden also weiterhin die RDMA-Semantik mit direktem Datentransfer zwischen Speicherbereichen.
NVMe/TCP und NVMe/RDMA ermöglichen beide den Zugriff auf NVMe-Storage über ein Netzwerk. Der wichtigste Unterschied liegt im Transport: NVMe/TCP nutzt den etablierten TCP/IP-Stack, während NVMe/RDMA einen optimierten RDMA-Datenpfad verwendet. Die folgende Tabelle zeigt die wichtigsten Unterschiede.
| Merkmal | NVMe/TCP | NVMe/RDMA über RoCE |
|---|---|---|
| Storage-Protokoll | NVMe | NVMe |
| NVMe over Fabrics | Ja | Ja |
| Netzwerk | Ethernet / IP | Ethernet / IP |
| Transport | TCP | RDMA |
| Unterliegender Transport | TCP / IP | RoCEv2 über UDP / IP |
| RDMA-fähige Netzwerkkarte erforderlich | Nein | Ja |
| Routing möglich | Ja | Ja, insbesondere mit RoCEv2 |
| CPU-Aufwand | Tendenziell höher | Tendenziell geringer |
| Latenz | Sehr niedrig | Potenziell noch niedriger |
| Netzwerkkomplexität | Vergleichsweise gering | Höher |
| Vorhandene IP-Infrastruktur nutzbar | Sehr gut | Grundsätzlich ja, Netzwerk muss jedoch RDMA-tauglich sein |
| Typischer Vorteil | Einfache Integration und Nutzung bestehender Infrastruktur | Hohe Effizienz, niedrige Latenz und geringer CPU-Overhead |
| Typischer Einsatz | Enterprise Storage, Virtualisierung, Datenbanken, Shared Storage | Besonders latenzkritische und I/O-intensive Workloads |
NVMe (Non-Volatile Memory Express) ist ein Protokoll für nichtflüchtige Speicher, insbesondere für SSDs. Bei lokal eingebauten NVMe-SSDs erfolgt die Anbindung typischerweise über PCI Express (PCIe). NVMe wurde für hohe Parallelität, viele gleichzeitige I/O-Operationen und geringe Latenzen entwickelt. Dadurch können moderne Flash-Speicher ihre Leistungsfähigkeit besser ausspielen als mit älteren Storage-Protokollen.
Eine SSD beschreibt das Speichermedium beziehungsweise die Speichertechnologie, während NVMe das Protokoll für den Zugriff auf den Speicher beschreibt. Eine SSD kann beispielsweise über SATA, SAS oder NVMe angebunden sein. Eine NVMe-SSD ist somit eine SSD, die das NVMe-Protokoll verwendet. Merksatz: SSD beschreibt den Speicher, NVMe die Art der Kommunikation mit diesem Speicher.
M.2 und NVMe bezeichnen unterschiedliche Dinge. M.2 ist eine kompakte Bauform beziehungsweise ein Steckkartenstandard, während NVMe ein Speicherprotokoll ist. Eine M.2-SSD kann je nach Laufwerk und Steckplatz beispielsweise SATA oder PCIe mit NVMe verwenden. Umgekehrt gibt es NVMe-SSDs auch in anderen Bauformen, beispielsweise U.2, U.3, als PCIe-Steckkarte oder in Enterprise-Formfaktoren wie EDSFF.
SATA und SAS stammen aus einer Zeit, in der magnetische Festplatten den Storage-Markt dominierten. NVMe wurde dagegen speziell für moderne nichtflüchtige Speicher entwickelt und wird bei lokalen SSDs typischerweise über PCIe transportiert. NVMe ermöglicht eine hohe Parallelität und kann dadurch geringere Latenzen und deutlich höhere I/O-Leistungen erreichen. SAS bleibt insbesondere im Enterprise-Umfeld relevant, beispielsweise wegen bewährter Storage-Infrastrukturen, Dual-Port-Funktionen und bestehender Server- und Storage-Systeme.
NVMe kann sehr viele gleichzeitige I/O-Anfragen effizient verarbeiten und ermöglicht niedrige Speicherlatenzen. Davon profitieren insbesondere Datenbanken, Virtualisierung, Analytics, KI- und Machine-Learning-Anwendungen sowie andere Workloads mit vielen kleinen oder parallelen Zugriffen. NVMe kann dabei helfen, Storage-Engpässe zu reduzieren und vorhandene Flash-Speicher besser auszulasten. Entscheidend bleibt jedoch immer die Betrachtung des gesamten Datenpfads von der Anwendung bis zum Speichersystem.
Bei lokalem NVMe befinden sich die NVMe-SSDs direkt im Server und werden ohne ein externes Storage-Netzwerk genutzt. Das ermöglicht einen kurzen Datenpfad und sehr hohe I/O-Leistung bei geringer Latenz. Typische Einsatzbereiche sind lokale Datenbanken, Caching, Logs, temporäre Daten und hyperkonvergente Systeme. Bei der Planung müssen jedoch auch Hochverfügbarkeit, Datensicherung, Wartung und der Ausfall eines Hosts berücksichtigt werden.
NVMe over Fabrics, kurz NVMe-oF, ermöglicht die Nutzung von NVMe über ein Netzwerk zwischen Servern und Storage-Systemen. Dadurch können NVMe-basierte Speicher zentral als Shared Storage bereitgestellt werden, ohne dass sich die SSDs direkt im jeweiligen Server befinden müssen. NVMe-oF ist dabei der Oberbegriff für verschiedene Netzwerktransporte und nicht mit einer einzelnen Technologie wie Fibre Channel oder RoCE gleichzusetzen.
Für NVMe over Fabrics stehen verschiedene Transportmöglichkeiten zur Verfügung. NVMe/TCP nutzt TCP/IP und kann über Standard-Ethernet-Netzwerke betrieben werden. NVMe über RDMA kann beispielsweise RoCE (RDMA over Converged Ethernet) verwenden. In Fibre-Channel-Umgebungen kann NVMe über Fibre Channel als NVMe/FC transportiert werden. Welche Variante sinnvoll ist, hängt von Anforderungen an Latenz, Performance, vorhandene Infrastruktur und Betriebsaufwand ab.
NVMe/TCP transportiert NVMe-Kommandos und Daten über TCP/IP. Dadurch kann NVMe over Fabrics über bestehende IP- und Ethernet-Infrastrukturen umgesetzt werden, ohne dass zwingend ein RDMA-fähiges Netzwerk erforderlich ist. NVMe/TCP ist deshalb für viele Unternehmen eine pragmatische Möglichkeit, zentralen NVMe-Storage in vorhandene Ethernet-Umgebungen zu integrieren.
RoCE steht für RDMA over Converged Ethernet und ermöglicht RDMA-Kommunikation über Ethernet. Im Zusammenhang mit NVMe kann RoCE als Transport für NVMe over Fabrics eingesetzt werden. RDMA reduziert den Aufwand für die Datenübertragung zwischen Hosts und Storage-Systemen und kann sehr niedrige Latenzen ermöglichen. RoCE erfordert jedoch in der Regel ein sorgfältig geplantes Netzwerk sowie passende Konfigurationen für Datenverkehr, Überlastkontrolle und Betrieb.
NVMe/TCP basiert auf TCP/IP und lässt sich deshalb häufig einfacher in vorhandene Ethernet-Netzwerke integrieren. RoCE nutzt dagegen RDMA und kann bei entsprechend ausgelegter Infrastruktur besonders niedrige Latenzen und eine hohe Effizienz ermöglichen. Dafür steigen in vielen Umgebungen die Anforderungen an Netzwerkdesign, Konfiguration und Know-how. Welche Variante besser geeignet ist, sollte anhand der tatsächlichen Workloads, Latenzanforderungen und Betriebskosten entschieden werden.
Ja. NVMe kann in Fibre-Channel-Umgebungen als NVMe/FC beziehungsweise FC-NVMe transportiert werden. Dadurch können Unternehmen vorhandene Fibre-Channel-Infrastrukturen für NVMe-basierte Storage-Systeme nutzen. Fibre Channel bleibt besonders dort interessant, wo ein dediziertes Storage-Netzwerk, hohe Verfügbarkeit, planbare Performance und etablierte SAN-Betriebsprozesse wichtig sind.
NVMe-oF ist besonders interessant, wenn Anwendungen nachweislich durch Storage-Latenz oder I/O-Leistung begrenzt werden und gleichzeitig zentraler Shared Storage benötigt wird. Für viele Standard-VMs, Fileservices, Backup-Ziele und weniger latenzkritische Anwendungen kann ein klassisches SAN weiterhin vollkommen ausreichend sein. Vor einer Umstellung sollten deshalb Latenz, IOPS, Durchsatz, CPU-Auslastung und Netzwerkbelastung über den gesamten Datenpfad gemessen werden. Die technisch schnellste Lösung ist nicht automatisch die wirtschaftlich sinnvollste.
