NVMe (Nonvolatile Memory Express) V1.3 (c) Stor IT Back 2026
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 Geräte sind PCIe Geräte, sprechen also direkt das PCIe Protokoll und benötigen keine Protokollübersetzer (zum Beispiel ein SAS HBA oder ein RAID Controller). Damit sind
sie extrem schnell und extrem gut an die CPU angebunden. Um den Zugriff noch weiter zu optimieren wurde ein sehr kleiner Befehlssatz für diese Geräte entwickelt, deutlich weniger Befehle
als bei SCSI oder SAS.
Features wie Hot Swap sind durch PCIe Funktionen realisiert worden, so dass ein Austausch oder eine Aufrüstung im laufenden Betrieb möglich ist. Auch wurde Multipathing für dieses
Protokoll definiert, so dass auch der Einsatz in redundanten Storage-Systemen möglich ist.
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 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.
Ein Teil ist die Nutzung von NVMe SSDs in Storage-Systemen, der andere Teil ist der Anschluss von Servern an diese Storage-Systeme. Wenn innerhalb des
Storage jetzt alles auf NVMe aufgebaut ist, also der Anschluss der SSDs an das Storage. Dann muss doch auch der Server mit maximaler Performance (maximaler Durchsatz und minimaler Latenzzeit)
angeschlossen werden.
Wie wird das realisiert?
Einmal sind natürlich die bekannten Protokolle wie Fibre Channel und iSCSI möglich. Aber der Vorteil von NVMe ist ja gerade die Umgehung von
SAS oder Fibre Channel für die bessere Performance. Dafür wird auf Netzwerkebene auf Techniken des Remote Direct Memory Access zurückgegriffen. Im Falle von Ethernet ist
es dann RDMA over Converged Ethernet (kurz RoCE). Bei Fibre Channel dann NVMe oder Fabrics (kurz NVMe-oF). Vom Design her wird zwischen NVMe Device und dem PCI-Express-Bus des
Servers eine Netzwerkebene eingezogen.
Aber was ist dort nun der Vorteil?
Es geht ja trotzdem über Ethernet oder Fibre Channel. Das ist richtig, aber es wird nur das PCIe Protokoll genutzt. Es muss also nicht
wie bei SAS oder Fibre Channel das Protokoll übersetzt werden. Also direkt die PCIe Daten zwischen Server und Storage übertragen.
Aber wer braucht den jetzt ein NVMe-oF oder RoCE Storage System?
Alle Anwendungen, bei denen es auf die Latenzzeit ankommt. Also Applikationen in Echtzeit, gerade in den Bereichen Finanzen, künstliche Intelligenz (KI) und maschinelles Lernen (ML).
Aber natürlich auch Datenbanken und Applikationen in anderen Bereichen.
Was ist der Unterschied zwischen SSD und NVMe?
Eine SSD beschreibt das Speichermedium (Flash statt rotierende Platte), also was speichert. NVMe beschreibt primär das Protokoll/Interface,
also wie ein System mit dem Speicher spricht, optimiert für sehr viele parallele Zugriffe und geringe Verzögerung.
Eine SSD kann z.B. als SATA-SSD oder NVMe-SSD angebunden sein, beides sind SSDs, aber mit unterschiedlicher Anbindung und Leistung.
Merksatz: SSD = Medium, NVMe = Sprache/Anbindung für schnellen Zugriff.
Warum ist NVMe im Rechenzentrum so wichtig geworden?
NVMe kann sehr viele gleichzeitige I/O-Anfragen effizient verarbeiten und reduziert typische Engpässe,
die bei älteren Protokollen häufiger auftreten. Das ist besonders wichtig für Virtualisierung, Datenbanken, Analytik und generell
Systeme mit vielen kleinen Zugriffen. In der Praxis führt das oft zu niedrigeren Latenzen (Reaktionszeiten)
und stabilerer Performance unter Last.
Für Entscheider zählt: NVMe kann pro Server mehr Workloads ermöglichen oder Response-Zeiten verbessern, was sich direkt auf Servicequalität auswirkt.
Was bedeutet Protokolle mit FC und Ethernet in diesem Kontext?
Damit ist gemeint, dass NVMe/Storage nicht nur lokal im Server sitzt, sondern übers Netzwerk bereitgestellt werden kann.
Fibre Channel (FC) ist ein etabliertes, dediziertes Storage-Netzwerk, während Ethernet das klassische Datennetz (LAN) ist,
über das man ebenfalls Storage transportieren kann. Beide können NVMe-Datenverkehr tragen, aber mit unterschiedlichen Betriebsmodellen,
Skills und oft auch Kostenstrukturen.
Wichtig: Nicht jedes Storage über Ethernet ist automatisch NVMe, das kann auch iSCSI oder NFS/SMB sein.
Was ist lokales NVMe und wann reicht das aus?
Lokales NVMe bedeutet: NVMe-SSDs stecken direkt im Server (z. B. PCIe/NVMe-Backplane) und werden ohne Storage-Netzwerk genutzt.
Das ist oft die einfachste und günstigste Art, sehr hohe Performance zu bekommen, ideal für Caching, Datenbanken pro Host,
lokale Logs oder hyperkonvergente Systeme. Der Nachteil: Daten liegen an den Server gebunden, zentrale Storage-Services
(z.B. konsolidierte Kapazität, Shared Datastores) sind aufwendiger.
Tipp: Lokal-NVMe ist top für Performance, aber prüfen Sie früh, wie Sie Hochverfügbarkeit und Wartung (Host-Ausfall) abdecken.
Was ist NVMe-oF (NVMe over Fabrics) – und was bringt es?
NVMe-oF ist ein Sammelbegriff für NVMe über ein Netzwerk, also ähnlich wie SAN, nur mit NVMe als Datenprotokoll.
Es erlaubt, NVMe-Performance und geringe Latenz auch zentral aus Storage-Systemen bereitzustellen.
Das ist attraktiv, wenn Sie Shared Storage brauchen (z. B. Virtualisierung-Cluster) und gleichzeitig sehr schnelle SSD-Backends nutzen wollen.
Praxisbeispiel: Ein All-Flash-Array mit NVMe-oF kann mehreren Hosts extrem schnelle Block-Volumes liefern, ohne dass jeder Workload lokal auf einen Server begrenzt ist.
Woran erkenne ich, ob ich wirklich NVMe-oF brauche, oder ob klassisches SAN genügt?
NVMe-oF lohnt sich typischerweise, wenn Ihre Workloads nachweislich an Latenz/IOPS hängen und klassische Protokolle der Flaschenhals sind.
Für viele Standard-VMs, Fileservices oder Backup-Ziele ist der Unterschied oft weniger entscheidend als stabile Prozesse,
Kapazität und Kosten. Entscheidend ist der Engpass: Ist es das Storage, das Netzwerk, die Hosts oder die Applikation?
Tipp: Messen Sie Latenzen End-to-End (Applikation → OS → Storage) und planen Sie nicht nur nach Maximaldurchsatz.
Wann ist Fibre Channel besonders attraktiv, auch in NVMe-Zeiten?
FC ist attraktiv, wenn Sie ein dediziertes Storage-Netz mit klarer Trennung vom LAN, sehr planbarer Performance und etablierten Betriebsprozessen wollen.
Viele Rechenzentren schätzen FC wegen der guten Fehlereingrenzung und der Storage-first-Tooling-Welt.
FC-NVMe kann helfen, die vorhandene Investition zu nutzen und gleichzeitig NVMe-Backends besser auszureizen.
Für Entscheider: FC ist oft höher in CapEx/Skills, kann aber bei kritischen Workloads Betriebssicherheit und Planbarkeit liefern.
Welche Möglichkeiten gibt es, NVMe über Ethernet zu nutzen?
Über Ethernet gibt es mehrere Varianten: NVMe/TCP (NVMe über TCP/IP), RoCE (RDMA over Converged Ethernet) und iWARP (RDMA über TCP). Alle liefern NVMe-oF, unterscheiden sich aber im Betriebs- und Tuning-Aufwand. NVMe/TCP ist oft am einfachsten zu integrieren, weil es auf normalem IP/TCP basiert. RDMA-Varianten können sehr niedrige Latenz liefern, erfordern aber meist sorgfältigeres Netzwerkdesign.
NVMe/TCP vs. RoCE, wie wähle ich pragmatisch?
NVMe/TCP ist häufig die pragmatische Wahl, wenn Sie schnell starten, vorhandene Ethernet-Strukturen nutzen und Komplexität begrenzen wollen.
RoCE ist interessant, wenn absolut minimale Latenz und maximale Effizienz gefordert sind und Sie bereit sind, Netzwerkdesign und
Betrieb entsprechend storage-grade zu gestalten. In vielen Umgebungen ist NVMe/TCP gut genug und einfacher zu troubleshoot-en.
Entscheidertipp: Rechnen Sie nicht nur Hardwarekosten, sondern auch Betriebsaufwand (Skills, Fehlersuche, Standards) in die TCO ein.
