Storage & Protokolle
NVMe-over-Fabrics
NVMe-over-Fabrics (NVMe-oF) trägt das NVMe-Befehlsmodell über ein Netzwerk, wahlweise über TCP, RDMA oder Fibre Channel, und überwindet so die PCIe-Grenze.
- NVMe über das Netzwerk
- TCP, RDMA, Fibre Channel
- Geringe Latenz, hohe Parallelität
- Multipath über ANA
- Nachfolger/Ergänzung zu iSCSI
NVMe-over-Fabrics nimmt das schlanke, parallele Befehlsmodell von NVMe und trägt es über ein Netzwerk statt über den lokalen PCIe-Bus. Ein Server spricht dadurch zentralen Flash-Speicher an, als steckte er im eigenen Gehäuse, mit deutlich geringerem Protokoll-Overhead als bei älteren Netzwerk-Block-Protokollen.
Dieser Artikel erklärt die drei Transporte TCP, RDMA und Fibre Channel und ihre Voraussetzungen, die Begriffe Subsystem, Controller und Namespace im Netz, die Adressierung über den NQN, die Erkennung von Zielen, das Multipathing über ANA sowie die Sicherheitsmechanismen TLS und In-Band-Authentifizierung.
1. NVMe ohne PCIe-Grenze
Lokales NVMe ist an den PCIe-Bus gebunden, also an den einzelnen Server. NVMe-oF ersetzt die PCIe-spezifischen Mechanismen durch Netzwerk-Nachrichten und behält das übrige Befehlsmodell bei: dieselben Warteschlangen, dieselben Namespaces. So lässt sich Flash zentral bereitstellen und gemeinsam nutzen, ohne den Geschwindigkeitsvorteil von NVMe aufzugeben. Seit NVMe 2.0 sind die Fabric-Befehle Teil der Basis-Spezifikation, die Transporte stehen als eigene Dokumente daneben.
2. Drei Transporte mit unterschiedlichen Ansprüchen
Der Transport bestimmt Aufwand und Latenz:
| Transport | Eigenschaft |
|---|---|
| NVMe/TCP | läuft auf Standard-Ethernet ohne Spezial-NIC; einfachste Einführung, etwas höhere Latenz |
| NVMe/RDMA (RoCEv2, iWARP) | sehr geringe Latenz, braucht RDMA-NICs und ein verlustarmes Netz |
| NVMe/FC (FC-NVMe) | nutzt vorhandene Fibre-Channel-Fabric; SCSI und NVMe parallel über dieselbe Hardware |
RDMA verlangt ein verlustarmes Netz
RoCEv2 hat keine eigene Übertragungswiederholung und setzt deshalb ein verlustarmes Ethernet voraus: Priority Flow Control (PFC) und ECN müssen konfiguriert sein, Jumbo Frames sind üblich. Ohne diese Vorarbeit bricht die Leistung ein. NVMe/TCP stellt diese Anforderungen nicht.
3. Subsystem, Controller, Namespace und der NQN
Auf der Zielseite bündelt ein Subsystem einen oder mehrere Controller samt ihren Namespaces. Identifiziert wird alles über den NQN (NVMe Qualified Name), der sowohl das Ziel-Subsystem als auch den Host benennt, vergleichbar mit dem IQN bei iSCSI oder dem WWN bei Fibre Channel. Über den Host-NQN steuert das Ziel, welcher Host sich überhaupt verbinden darf.
4. Ziele finden und verbinden
Bevor I/O fließt, fragt der Host einen Discovery Controller nach den verfügbaren Subsystemen und ihren Netzwerkadressen. In größeren Umgebungen automatisiert ein zentraler Discovery-Dienst diese Suche und meldet Änderungen aktiv. Unter Linux erledigen nvme discover und nvme connect aus dem Paket nvme-cli den Aufbau.
Ziel suchen und verbinden (NVMe/TCP, Linux)
# Discovery-Controller abfragen
nvme discover -t tcp -a 10.0.20.10 -s 8009
# Subsystem verbinden (Port 4420 für I/O)
nvme connect -t tcp -a 10.0.20.10 -s 4420 -n nqn.2014-08.org.nvmexpress:uuid:...
nvme list-subsys # verbundene Subsysteme und Pfade anzeigen5. Hochverfügbarkeit über ANA
Für mehrere Pfade zum selben Namespace nutzt NVMe-oF ANA (Asymmetric Namespace Access), das Gegenstück zum ALUA der SCSI-Welt. Das Ziel kennzeichnet jeden Pfad als optimal, nur erreichbar oder nicht verfügbar, und der Host wählt den besten. Der Linux-Kernel bringt dieses Multipathing nativ mit (Richtlinien wie NUMA, Round-Robin oder Queue-Depth), ohne dass eine separate Multipath-Software nötig ist.
6. Sicherheit: Isolation, Authentifizierung, Verschlüsselung
Ein eigenes Storage-VLAN trennt den Verkehr, verschlüsselt ihn aber nicht. NVMe-oF bietet dafür zwei Mechanismen: DH-HMAC-CHAP als In-Band-Authentifizierung zwischen Host und Controller (mit Diffie-Hellman gegen Replay-Angriffe und HMAC statt schwachem MD5) und, für NVMe/TCP, TLS 1.3 zur Verschlüsselung der Verbindung. Die Verfügbarkeit von DH-HMAC-CHAP hängt vom Transport und der Implementierung ab; in offenen Linux-Stacks ist sie vor allem für NVMe/TCP gegeben. Für NVMe/RDMA sieht die Spezifikation keine eigene Transportverschlüsselung vor; dort kommen Netz-Maßnahmen wie MACsec oder IPsec in Betracht.
Segmentierung ist Eindämmung, keine Vertraulichkeit. Wer Block-Daten im Netz schützen muss, aktiviert bei NVMe/TCP TLS und in jedem Fall die In-Band-Authentifizierung.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| NVMe-Leistung über das Netz, geringer Overhead | RDMA-Transport erfordert Hardware und verlustarmes Netz |
| NVMe/TCP ohne Spezialhardware, einfach einzuführen | NVMe/TCP latenzempfindlicher in schlechten Netzen |
| Drei Transporte für verschiedene Anforderungen | Ökosystem (Tools, Hypervisor) jünger als bei iSCSI |
| Natives Multipath über ANA im Linux-Kernel | RDMA ohne eigene Transportverschlüsselung in der Spec |
| In-Band-Authentifizierung und TLS (NVMe/TCP) | saubere Netzplanung Voraussetzung für die Leistung |
Häufige Fragen zu NVMe-over-Fabrics
NVMe/TCP läuft über gewöhnliches Ethernet ohne spezielle Netzwerkkarten und ist am einfachsten einzuführen, hat aber etwas höhere Latenz. NVMe/RDMA (über RoCEv2 oder iWARP) erreicht geringere Latenz, setzt dafür RDMA-fähige NICs und ein verlustarmes Netz mit Priority Flow Control und ECN voraus. Die Wahl hängt davon ab, wie viel Latenz zählt und wie viel Netzaufwand vertretbar ist.
Es ist der modernere Ansatz und ergänzt oder ersetzt iSCSI zunehmend, weil das schlanke NVMe-Befehlsmodell weniger Overhead hat und mehr Parallelität bietet. iSCSI bleibt wegen seines reifen Ökosystems und der einfachen Ethernet-Anbindung weiterhin verbreitet. Oft ist NVMe/TCP der naheliegende nächste Schritt, weil es auf derselben Ethernet-Infrastruktur läuft.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
NVMe-over-Fabrics im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.