Storage-Netzwerke
NVMe/TCP
NVMe/TCP trägt NVMe-over-Fabrics über gewöhnliche TCP/IP-Netze, der einfachste NVMe-oF-Transport, da weder spezielle Netzkarten noch verlustarmes Netz nötig sind.
- NVMe über Standard-Ethernet
- Kein Spezial-NIC, kein DCB
- TLS 1.3 möglich
- Multipath über ANA
- Einfachster NVMe-oF-Transport
NVMe/TCP ist einer der Transporte von NVMe-over-Fabrics (Grundlagen siehe dort) und derjenige mit den geringsten Voraussetzungen: Er bettet die NVMe-Kommandos und -Daten in normale TCP-Verbindungen ein und läuft damit über jedes IP-Netz, ohne RDMA-fähige Karten und ohne verlustarmes Ethernet.
Dieser Artikel erklärt, wie NVMe in TCP-Segmente verpackt wird, warum kein Spezialnetz nötig ist, die Ports und das Zusammenspiel von Queue und TCP-Verbindung, das Auffinden der Ziele, das Multipathing über ANA, die Absicherung mit TLS und Authentifizierung sowie die Performance-Einordnung gegenüber RDMA.
1. NVMe in TCP verpackt
NVMe/TCP überträgt die NVMe-Strukturen in Form von Protokoll-Dateneinheiten (PDUs) über TCP: Befehle, Antworten und Daten in beide Richtungen. Der robuste TCP-Stack übernimmt dabei Flusskontrolle und das erneute Senden verlorener Pakete. Genau deshalb braucht NVMe/TCP, anders als RDMA-Transporte, kein verlustarmes Netz: Paketverluste fängt TCP ab. Optionale Prüfsummen (CRC32C) auf Header und Daten erkennen stille Übertragungsfehler.
2. Kein Spezialnetz, kein Spezial-NIC
Der entscheidende Vorteil: Jede Standard-Netzwerkkarte ab 10 Gigabit genügt, und an den Switches ist keine DCB- oder PFC-Konfiguration nötig. Das macht NVMe/TCP zum mit Abstand einfachsten Einstieg in NVMe-over-Fabrics und zum naheliegenden Nachfolger von iSCSI, das auf derselben Ethernet-Infrastruktur läuft. Der Preis ist etwas mehr CPU-Last durch die TCP-Verarbeitung und eine höhere Latenz als bei RDMA.
3. Ports, Queues und Verbindungen
NVMe/TCP nutzt zwei IANA-Ports: 4420 für die Daten-Ein-/Ausgabe und 8009 für den Discovery-Dienst. Jedes NVMe-Queue-Paar wird auf eine eigene TCP-Verbindung abgebildet. Das erlaubt echte Parallelität über viele CPU-Kerne, jede Queue mit eigener Verbindung und eigener Flusskontrolle.
Ziel finden und verbinden (Linux, nvme-cli)
nvme discover -t tcp -a 10.0.20.10 -s 8009
nvme connect -t tcp -a 10.0.20.10 -s 4420 -n nqn.2014-08.org.nvmexpress:uuid:...
nvme list-subsys # Pfade und Subsysteme prüfen4. Ziele finden und Pfade bündeln
Hosts fragen einen Discovery Controller nach den erreichbaren Subsystemen; in größeren Umgebungen automatisiert ein zentraler Dienst oder mDNS diese Suche. Für mehrere Pfade zum selben Namespace nutzt NVMe/TCP ANA (Asymmetric Namespace Access), das der Kernel nativ auswertet, mit Richtlinien wie NUMA-nah, Round-Robin oder nach Warteschlangentiefe. Eine separate Multipath-Software ist nicht nötig.
5. Sicherheit: TLS und Authentifizierung
In einem abgeschotteten Storage-VLAN wird NVMe/TCP oft unverschlüsselt betrieben. Wo der Verkehr geteilte oder weniger vertrauenswürdige Wege nimmt, schreibt die Spezifikation TLS 1.3 vor (Pflicht-Cipher TLS_AES_128_GCM_SHA256, über Pre-Shared Keys), unter Linux seit Kernel 6.7 als In-Kernel-TLS (mit dem Userspace-Daemon tlshd für den Handshake). Zusätzlich gibt es die In-Band-Authentifizierung DH-HMAC-CHAP, die Host und Controller gegenseitig prüft. NVMe/TCP ist im Linux-Kernel seit Version 5.0 enthalten.
Segmentierung trennt, sie verschlüsselt nicht. Verlässt NVMe/TCP das geschützte Storage-Segment, gehört TLS 1.3 aktiviert, kein bloßes VLAN.
6. Performance und MTU
Die TCP-Verarbeitung kostet Host-CPU und fügt gegenüber RDMA Latenz hinzu; moderne NICs mit Offload (Segmentierung, Prüfsummen) mildern das. Jumbo Frames (MTU 9000) reduzieren die Zahl der zu verarbeitenden Frames und damit die CPU-Last, müssen aber auf dem gesamten Pfad konsistent gesetzt sein. Über WAN-Strecken ist NVMe/TCP nur bei stabiler, niedriger Latenz sinnvoll, weil NVMe empfindlich auf Schwankungen reagiert.
7. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Läuft auf Standard-Ethernet, kein DCB/PFC nötig | höhere Latenz als RDMA-Transporte |
| Einfachster NVMe-oF-Einstieg, Nachfolger von iSCSI | mehr Host-CPU durch TCP-Verarbeitung |
| TLS 1.3 und In-Band-Authentifizierung verfügbar | empfindlich gegen Paketverlust/Jitter in schlechten Netzen |
| Natives ANA-Multipath im Linux-Kernel (ab 5.0) | TLS erhöht die CPU-Last zusätzlich |
| Jumbo Frames senken die CPU-Last spürbar | über WAN nur bei stabiler, niedriger Latenz |
Häufige Fragen zu NVMe/TCP
Weil der TCP-Stack verlorene Pakete erneut sendet und die Flusskontrolle übernimmt. RDMA-Transporte wie RoCEv2 haben keine effiziente eigene Verlustbehandlung und brauchen deshalb ein verlustarmes Ethernet mit Priority Flow Control. NVMe/TCP läuft dagegen auf gewöhnlichem Ethernet, erkauft sich das aber mit etwas höherer Latenz und CPU-Last.
In vielen Fällen ja. Beide laufen über Standard-Ethernet, aber NVMe/TCP nutzt das schlanke, hochparallele NVMe-Befehlsmodell mit weniger Overhead. Wer iSCSI auf vorhandener Infrastruktur betreibt, kann NVMe/TCP oft als nächsten Schritt einführen, ohne das Netz umzubauen.
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/TCP 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.