NVMe over Fabrics: Was ist NVMe-oF und wie funktioniert es?
Wenn ein IT-Verantwortlicher bei uns anruft und berichtet, dass ein frisch angeschaffter All-Flash-Array zwar enorme Kapazität liefert, die Datenbankperformance aber trotzdem hinter den Erwartungen…
Wenn ein IT-Verantwortlicher bei uns anruft und berichtet, dass ein frisch angeschaffter All-Flash-Array zwar enorme Kapazität liefert, die Datenbankperformance aber trotzdem hinter den Erwartungen zurückbleibt, dann lohnt sich der Blick auf das Speicherprotokoll. In vielen dieser Fälle sitzt das Problem nicht in den SSDs selbst, sondern in der Art, wie sie über das Netzwerk angesprochen werden. Genau an dieser Stelle setzt NVMe over Fabrics an.
Die ursprüngliche NVMe-Spezifikation wurde 2011 veröffentlicht, um Flash-Speicher direkt über den PCIe-Bus anzubinden – also dort, wo keine Netzwerkstrecke mehr zwischen Anfrage und Medium liegt. Ab 2016 wurde dieses Protokoll mit der NVMe-oF-Spezifikation auf Netzwerk-Fabrics erweitert. Seither lässt sich die niedrige Latenz und die massive Parallelität von NVMe auch über Ethernet, Fibre Channel oder RDMA nutzen, ohne den Umweg über SCSI gehen zu müssen.
Das SAN-Bottleneck: Warum klassische Protokolle bei Flash an ihre Grenzen stoßen
Damit der Vorteil von NVMe-oF greifbar wird, hilft ein kurzer Blick auf die Vorgänger. iSCSI und Fibre Channel über SCSI transportieren SCSI-Befehle, die aus einer Zeit stammen, in der rotierende Festplatten das Maß der Dinge waren. Diese Protokolle sind für sequenzielle Lasten optimiert, nicht für Tausende paralleler Zugriffe auf Flash-Speicher.
Das bedeutet für die Praxis konkret: SCSI-basierte Protokolle verarbeiten Anfragen typischerweise über eine einzelne I/O-Warteschlange mit maximal 256 gleichzeitigen Befehlen. Wenn heute eine Virtualisierung mit dutzenden VMs läuft, eine Datenbank Random Reads im 4K-Format absetzt und gleichzeitig ein Backup-Fenster offen ist, dann stoßen solche Warteschlangen sehr schnell an ihre Grenzen. Die SSDs selbst wären noch lange nicht ausgelastet – sie warten nur auf den nächsten SCSI-Befehl.
NVMe-oF im Kern: Vom PCIe-Bus ins Netzwerk
NVMe wurde ursprünglich für lokal angebundene PCIe-SSDs entwickelt und ist von Grund auf parallelisiert. Die Idee hinter NVMe over Fabrics ist einfach: Man nimmt den NVMe-Befehlssatz und bettet ihn in ein Netzwerk-Transportprotokoll ein, sodass entfernt liegender Speicher fast wie lokal angebundener Speicher reagiert. Das NVMe-Protokoll wird also nicht ersetzt, sondern über das Netzwerk erweitert.
NVMe-oF ist im Kern keine neue Hardware, sondern eine radikale Öffnung des NVMe-Befehlssatzes über das Netzwerk – mit bis zu 65.535 I/O-Warteschlangen statt einer einzigen.
Diese Architektur erklärt auch, warum NVMe-oF in modernen Rechenzentren so schnell Verbreitung gefunden hat: Die Speicher-Arrays selbst bleiben oft unverändert, nur das Protokoll auf der SAN-Strecke wird ausgetauscht.
Parallelisierung als eigentlicher Durchbruch
Der markanteste Unterschied zwischen NVMe und SCSI ist die Anzahl der I/O-Warteschlangen. Wo SCSI eine einzige Queue mit 256 Befehlen erlaubt, bietet NVMe bis zu 65.535 Queues mit jeweils bis zu 65.535 Befehlen. Theoretisch sind das mehr als vier Milliarden parallele Operationen – in der Praxis reicht schon ein Bruchteil davon, um Engpässe spürbar aufzulösen.
Was das für den Alltag eines Administrators bedeutet: Eine einzelne VM kann einen dedizierten Queue-Pool nutzen, eine andere VM bekommt einen separaten Pool, und Latenzspitzen einer Anwendung wirken sich nicht mehr direkt auf alle anderen aus. Bei virtualisierten Umgebungen, Datenbanken und KI-Workloads ist genau diese Isolation der entscheidende Hebel, weil zufällige 4K-Lasten nun tatsächlich parallel verarbeitet werden, statt sich gegenseitig zu blockieren.
Die drei Transportwege im Vergleich: RDMA, Fibre Channel und TCP
NVMe-oF definiert drei wesentliche Transportkategorien. Sie unterscheiden sich deutlich in Latenz, Hardware-Anforderungen und Investitionskosten – die folgende Übersicht fasst die wichtigsten Unterschiede für die Einordnung zusammen.
| Merkmal | NVMe/RDMA (RoCE v2, iWARP, InfiniBand) | NVMe/FC (FC-NVMe) | NVMe/TCP |
|---|---|---|---|
| Typische Latenz | unter 100 µs | ca. 80–150 µs | ca. 100–200 µs |
| Erforderliche Hardware | RDMA-fähige NICs (RNICs), oft RoCE-v2-Switches | FC-Switches ab Gen 6 | Standard-Ethernet, ab 25 GbE empfohlen |
| CPU-Last auf Hosts | sehr gering (DMA) | gering | höher (TCP-Checksummen, Segmentierung) |
| Investitionsaufwand | hoch | mittel bis hoch | niedrig |
| Eignung für Bestandsnetze | nur mit spezieller Hardware | bei vorhandenem FC-Fabric | sehr gut |
RDMA-basierte Varianten liefern die absolut niedrigste Latenz, weil sie Daten per Direct Memory Access ohne CPU-Umweg transportieren. Fibre Channel mit FC-NVMe bettet die NVMe-Befehle in FC-Frames ein und kann auf vielen vorhandenen Gen-6-FC-Switches ohne Hardware-Austausch genutzt werden. NVMe/TCP wiederum läuft auf gewöhnlichem Ethernet und wurde im November 2018 als Transportmechanismus ratifiziert.
NVMe/TCP in der Praxis: Warum der Standard-Ethernet-Weg für viele passt
In unserem Support-Alltag sehen wir, dass NVMe/TCP für viele mittelständische Umgebungen der pragmatischste Einstieg in die NVMe-oF-Welt ist – gerade dann, wenn noch kein dediziertes SAN-Fabric existiert oder das Budget für RNICs nicht freigegeben ist.
Für viele Administratoren ist NVMe/TCP der pragmatischste Einstieg: Es läuft auf vorhandener 25-GbE-Infrastruktur, ohne dass RDMA-NICs oder neue Switches angeschafft werden müssen.
Die Latenz liegt typischerweise zwischen 100 und 200 Mikrosekunden – damit ist NVMe/TCP zwar etwas träger als RDMA, aber im Vergleich zu klassischem iSCSI messen Kunden in der Praxis eine um 25 % bis 50 % reduzierte Latenz, vor allem bei kleinen Blockgrößen wie 4K Random I/O. Dazu kommt ein weiterer Vorteil: NVMe/TCP wurde 2019 nativ in den Linux-Kernel 5.0 integriert, sodass keine proprietären Treiber mehr erforderlich sind.
Wie das technisch zustande kommt, lässt sich am Schreibvorgang gut erklären. Kleine Schreiboperationen bis 8 KB werden direkt im CapsuleCmd-PDU inline übertragen, sodass ein einziger Round-Trip genügt. Größere Schreibvorgänge durchlaufen zusätzlich eine R2T-Phase. Diese Konstruktion reduziert Protokoll-Overhead genau dort, wo ihn virtualisierte Workloads am meisten spüren.
Hardware-Anforderungen und CPU-Last: Was Administratoren wirklich beachten müssen
Bevor man NVMe-oF produktiv ausrollt, gehören drei Aspekte ehrlich auf den Tisch. Erstens: NVMe/TCP benötigt zwar keine RDMA-Hardware, die TCP-Verarbeitung – Checksummen, Segmentierung und Reassembly – lastet aber die Host-CPUs spürbar stärker aus als ein SCSI-Stack. Bei vielen tausend IOPS pro Host sollte man daher die CPU-Kerne mit einkalkulieren, die für Speicher-IO reserviert sind.
Zweitens: Für NVMe/TCP sind 25-GbE- oder schnellere Netzwerke empfehlenswert. Zwar läuft das Protokoll auch auf 10 GbE, der verfügbare Durchsatz wird aber schnell zum Engpass, sobald mehrere Hosts gleichzeitig schreiben. Drittens: Wer FC-NVMe nutzt, sollte prüfen, ob die vorhandenen Switches mindestens Gen 6 unterstützen – ältere Modelle können das Protokoll meist nicht ohne Austausch verarbeiten.
Best Practices für den Alltag: So vermeiden Sie klassische Fallstricke
Wer NVMe-oF einführt, sollte die Migration als Gelegenheit nutzen, einige erprobte Routinen mitzuziehen. Aus unserer Erfahrung im Support haben sich folgende Punkte bewährt:
- Netzwerksegmentierung sauber aufsetzen: NVMe/TCP gehört in ein eigenes VLAN oder eine eigene Fabric, getrennt vom allgemeinen Client-Traffic. QoS-Markierungen helfen, Burst-Lasten abzufedern.
- MTU konsistent setzen: Jumbo Frames (typischerweise 9000 Byte) reduzieren die Anzahl der Pakete pro I/O. Eine einheitliche MTU im gesamten Pfad ist Pflicht, sonst fragmentiert der TCP-Stack und die Latenz steigt.
- CPU-Pinning für Storage-Worker einplanen: Reservieren Sie auf jedem Host dedizierte CPU-Kerne für die NVMe-Verarbeitung, damit Storage-IO nicht mit Anwendungs-Threads um Taktzyklen konkurriert.
- Multipathing von Anfang an: Auch bei NVMe-oF gibt es mehrere Pfade zum Target. Setzen Sie Multipath-I/O frühzeitig auf, damit Failover und Lastverteilung ohne Bastelei funktionieren.
- Monitoring auf Latenz und Queue-Tiefe ausrichten: Klassische SAN-Metriken wie reiner Throughput reichen nicht. Achten Sie auf durchschnittliche Latenz, Spitzenlatenz und die Auslastung der I/O-Queues – das sind die Frühwarnindikatoren.
- iSCSI nicht sofort abschalten: In heterogenen Umgebungen existieren SCSI-basierte Ziele oft noch jahrelang weiter. Planen Sie NVMe-oF als zusätzliche Schicht ein, nicht als harten Schnitt.
Das bedeutet für die Praxis: Eine NVMe-oF-Einführung gelingt am ruhigsten, wenn man mit einem einzelnen, gut vermessenen Workload startet, parallel zum bestehenden iSCSI, und die Erfahrungen aus dem Pilotbetrieb in das Regelwerk für die breite Migration übernimmt. Genau so lässt sich vermeiden, dass aus einem Protokollwechsel ein Produktivtag voller Überraschungen wird.
Fazit: Warum sich der Blick auf das Protokoll lohnt
NVMe over Fabrics ist kein Modebegriff, sondern die Antwort auf eine sehr konkrete Frage: Wie betreibe ich Flash-Speicher im Netzwerk, ohne dass SCSI-Bremsen die Performance auffressen? Wer die Architektur versteht – NVMe-Befehlssatz plus parallelisierte Queues plus ein passendes Transportprotokoll – kann gezielt entscheiden, ob RDMA, Fibre Channel oder NVMe/TCP zur eigenen Umgebung passt. In unserem Alltag sehen wir, dass die größten Sprünge nicht durch mehr Hardware entstehen, sondern durch das Protokoll, das endlich so schnell ist wie die SSDs dahinter.