© Ladyligeia / 123RF.com

Zentrale Speicher versprechen hohe Redundanz sowie eine einfache Wartung und Verwaltung. Sie an den Rest des Setups anzubinden, kann allerdings eine Herausforderung darstellen. Viele setzen da auf Ethernet, wofür es bisher nur das eher schwachbrüstige iSCSI gab. NVMe-oF will den Oldie nun in Rente schicken.

Im Rechenzentrum gelten viele Dinge implizit oder explizit als gesetzt, zum Beispiel ein zentraler Speicher in Form eines NAS oder SAN. Egal, wo man hinschaut: Fast immer findet sich irgendwo ein Gerät von Huawei, NetApp, Dell-EMC, IBM, HP oder einem anderen Hersteller, dessen einzige Aufgabe darin besteht, andere Systeme mit persistentem Speicher zu versorgen.

Aus Sicht des Admins ist es sinnvoll, zentrale Aufgaben wie Redundanz und Backup mit einer einzigen Datenquelle abzudecken, einem Single Point of Administration. Die Alternative wäre lokaler Wildwuchs mit komplizierten Backup- und Redundanzmechanismen. Hin und wieder hat zwar auch so etwas eine Daseinsberechtigung – etwa in Cloud-Setups, in denen virtuelle Maschinen extrem flotten Speicher benötigen. Aber da setzt der Cloud-Anbieter voraus, dass die Anwendung des Kunden sich selbst um die Redundanz der Daten und deren regelmäßige Sicherung kümmert. Für fast alle anderen Szenarien gilt zentraler Speicher als der Königsweg der Systemadministration.

Wie jede Technologie ist dabei auch zentraler Speicher Launen der Zeit unterworfen. Gefühlt ewig galt das Fibre-Channel-Protokoll als Goldstandard, und jeder Virtualisierungsserver im Setup brauchte einen eigenen Host-Bus-Adapter (HBA), um ihn mit dem FC-Netz zu verbinden. Die Hersteller zentraler Speicher dürften sich über die Jahre allein am Vertrieb passender Fibre-Channel-Hardware (Abbildung 1) eine goldene Nase verdient haben – und da ist die Tatsache noch gar nicht ins Spiel gebracht, dass Storage-Appliances nicht gerade zimperlich beim Griff ins Portemonnaie des Kunden sind.

Abbildung 1: Fibre-Channel-Hardware wie dieser Switch von Qlogic waren im RZ lange Standard. Heute weicht FC immer häufiger Ethernet, doch das etablierte iSCSI-Protokoll ist lahm und altbacken. Quelle: Wikipedia / Melee

Mittlerweile gilt Fibre Channel aber als nicht mehr zeitgemäß. Zwar stand auch dafür die Zeit keineswegs still, und FC-HBAs mit 128 Gbit/s Bandbreite sind durchaus verfügbar. Unternehmen scheuen heute aber den Mehraufwand, den ihnen der Betrieb einer separaten Netzwerkarchitektur nur für den zentralen Speicher aufzwingt. Ethernet soll es stattdessen richten. Kein Wunder, wurde die Netzwerktechnik doch in den vergangenen 15 Jahren konsequent auf mehr Bandbreite getrimmt: Längst haben Nvidia & Co. 400-Gbit/s-Switches (Abbildung 2) im Angebot und forschen an 800 Gbit/s und mehr.

Abbildung 2: Ethernet-Switches wie der SN4700 bieten 400-Gbit/s-Ports und übertreffen selbst die aktuellsten Fibre-Channel-Switches bei Weitem. Quelle: Nvidia

Dass die Verbesserung der Ethernet-Latenz dabei etwas unter die Räder kam – Latenz ist im Storage-Kontext eine zentrale Größe –, nehmen die meisten Kunden zähneknirschend in Kauf. Im Gegenzug kommen sie mit einer zentral gewarteten, ubiquitären Netzwerkinstallation aus, die sich zudem ganz hervorragend skalieren lässt.

Langsam und altbacken

Wenn Systeme per Ethernet auf ihren Speicher zugreifen sollen, brauchen sie dafür ein Protokoll, das den IP-Stack nutzt. Weil TCP/IP praktisch so verbreitet ist wie Ethernet selbst, entstand schon vor Jahrzehnten das – denkbar simple – iSCSI-Protokoll. Es nutzt SCSI-Befehle, verpackt diese aber in TCP/IP-Pakete und ermöglicht so den Zugriff über IP-Adresse und Port-Nummer.

Sonderlich beliebt war iSCSI bei Admins jedoch nie, und das hat sich bis heute nicht geändert. Dem Protokoll hängt zum einen der Ruf an, relativ empfindlich im Hinblick auf die genutzte Netzwerkinfrastruktur und den genutzten Speicher zu sein. Wer schon einmal VMware ESXi mit dem iSCSI-Target eines RADOS-Clusters verbinden wollte, kann ein Lied davon singen: Der iSCSI-Initiator von VMware ist ein proprietäres Produkt des Herstellers, das besonders empfindlich reagiert, wenn der Speicher zum Beispiel mit der anliegenden Last nicht zurechtkommt. Das erzwingt Retransmits, die im schlechtesten Fall das gesamte Backing Device einer Instanz offline gehen lassen, und damit die Instanz selbst. Auch auf ein instabiles Netz reagiert iSCSI äußerst empfindlich.

Zum anderen gilt iSCSI in Sachen Performance nicht gerade als der Weisheit letzter Schluss. So steht die Lösung in dem Ruf, gehörig zur Latenz beizutragen. Dass Ethernet per se schon mit einer deutlich höheren Latenz arbeitet als etwa Fibre Channel, hilft nicht. Dass das verwendete Protokoll die Sache noch deutlich schlimmer macht, hilft noch weniger. Wer iSCSI dann noch mit einem implizit eher langsamen Speicher wie RADOS kombiniert – hier sorgt der CRUSH-Algorithmus für hohe interne Latenzen – läuft Gefahr, für Single Small Writes so hohe Latenzen zu haben, dass die Installation weitgehend unbenutzbar wird.

Schlimmer noch: Es gibt nicht allzu viel, das man in solch einem Setup tunen kann. Das iSCSI-Target ist ein fixer Teil von RADOS und lässt sich nicht einfach austauschen. Die RADOS-Latenz kann man ebenfalls kaum verbessern. Kurzum: iSCSI gilt den meisten Admins heute als ebenso altbacken wie langsam und kommt regelmäßig eher aus Not denn aus Begeisterung zum Zug.

NVMe als Alternative

Den Herstellern großer Speicher ist das durchaus bewusst. NetApp beispielsweise hat mittlerweile praktisch sein gesamtes Fibre-Channel-Portfolio eingestampft und bietet ausschließlich Speicher an, die Ethernet verwenden. Andere Hersteller halten es ähnlich. Sie alle behelfen sich bisher als Zwischenlösung mit iSCSI. Hinter den Kulissen tüfteln mehrere Hersteller im Rahmen der Storage Networking Industry Association (SNIA) zusammen schon seit einigen Jahren an einer Alternative zum ungeliebten iSCSI-Protokoll, und die hat es in sich.

Dabei ist die ihr zugrunde liegende Idee relativ simpel und der Idee hinter iSCSI sehr ähnlich: In Form von NVMe steht schließlich ein neues Protokoll für den Zugriff auf Speicherlaufwerke zur Verfügung, das modern, gut konzipiert und flott ist. Baut man es so um, dass es nicht mehr unmittelbar den PCI-Bus für die Kommunikation mit dem Speicher nutzt, sondern stattdessen einen Netzwerk-Stack (Fabric), wäre ein leistungsfähiger iSCSI-Ersatz gefunden. Ähnlich begann iSCSI einst auch selbst. Von NVMe aber verspricht man sich deutlich bessere Performance und höhere Zuverlässigkeit. Die Hersteller nennen ihr neues Projekt NVMe-over-Fabrics oder kurz NVMe-oF.

Flotter Speicher

Um die Hintergründe von NVMe-oF etwas genauer zu verstehen, hilft ein Blick auf die Entwicklung von NVMe. Der seit Jahren etablierte Standard dürfte den meisten Systemadministratoren bestens bekannt sein.

NVMe unterscheidet sich vom noch viel weiter verbreiteten SATA vorrangig durch die Tatsache, dass es die Protokollkonvertierung zwischen dem PCI-Bus im System und dem Laufwerk überflüssig macht. Jedes Speichergerät muss mit den anderen Systemkomponenten irgendwie kommunizieren können. Dazu kommt praktisch immer PCI zum Einsatz. Das Problem: SATA ist ein eigenes Protokoll, und um SATA-Laufwerke per PCI anzubinden, braucht man einen Wandler, der SATA- in PCI-Befehle übersetzt. Das verursacht Latenz und begrenzt die erreichbare Leistung zudem auf die Performance des PCI-SATA-Wandlers.

NVMe kommt ohne den Umweg über einen Storage-Controller aus. NVMe-Geräte sprechen unmittelbar PCI und dadurch auch direkt mit der CPU und den anderen Geräten im System. Das sorgt dafür, dass primär die verfügbare Bandbreite des PCI-Busses die Performance limitiert und die Latenz vorrangig in den Controllern von PCI-Bus und Speichergerät entsteht. Obendrein hat man in den vergangenen Jahren NVMe heftig getunt. Heute gelten NVMe-Geräte als die mit Abstand flottesten Speicher. In Kombination mit schnellen Flash-Chips erreichen sie beeindruckende Bandbreiten und beeindruckend geringe Latenzen. So lag es aus Sicht von Intel, IBM, NetApp und Konsorten nahe, das Protokoll als Grundlage für einen iSCSI-Ersatz zu nutzen.

Wie NVMe-oF funktioniert

Allzu große Euphorie ist an dieser Stelle allerdings nicht angebracht. Einen erheblichen Teil seiner Performance zieht NVMe ja gerade daraus, dass es direkt mit CPU und RAM interagiert und keine Vermittlerschnittstellen benötigt. Verfrachtet man NVMe aber aus seinem angestammten Kontext in ein Netzwerk, sieht die Sache schon wieder ganz anders aus: Dann müssen die in IP verpackten NVMe-Pakete wie alle anderen Pakete den gesamten Netzwerk-Stack des Betriebssystems des sendenden Knotens durchlaufen, dann das physische Netz und schließlich den Kernel beim Empfänger. Es gibt also etliche Stellen, an denen NVMe im Netz zwangsweise mehr Latenz einsammelt als in seinem klassischen Habitat.

Das macht deutlich, dass es den Herstellern gar nicht primär darum gegangen ist, die NVMe-Geschwindigkeit pur durchs Netz zu bringen. Stattdessen verfolgt man mit NVMe-over-Fabrics vor allem das Ziel, das in die Jahre gekommene iSCSI-Protokoll durch ein moderneres, sichereres, besser zu konfigurierendes Protokoll mit mehr Möglichkeiten zu ersetzen. Längst machen die großen Hersteller damit Ernst.

Für RADOS, den Objektspeicher in Ceph, existiert beispielsweise wie beschrieben ein iSCSI-Target. Es gehört über den Umweg Red Hat heute zu IBM, und schon vor anderthalb Jahren hat RH eben dieses Target für “feature-frozen” erklärt. Der Anbieter entwickelt also nichts Neues mehr, die Korrektur von Bugs dürfte sich auf schwere Fehler oder solche mit Sicherheitsbezug beschränken. Stattdessen werkelt man fleißig am NVMe-oF-Target für RADOS – darauf gehen wir später noch ein.

Ob es Admins recht ist oder nicht: Red Hat Ceph Storage 6 enthält das iSCSI-Target bereits nicht mehr. Andere Anbieter dürften es mit ihren iSCSI-Implementierungen ähnlich halten. Gut möglich also, dass iSCSI in ein paar Jahren weitgehend aus den Rechenzentren der Welt verschwunden sein wird.

Begrifflichkeiten

Durchaus interessant ist die Tatsache, dass NVMe-oF bisher unbemerkt an vielen Administratoren vorbeiging. Stößt man am lokalen Admin-Stammtisch eine Diskussion zum Thema an, blickt man oft nur in fragende Gesichter. Dabei vermarkten Hersteller die Funktion bereits seit 2019, und wie üblich ist NVMe-oF nicht annähernd so neu, wie es sich anfühlt.

Hinzu kommt, dass das Konzept bereits eine Reise hinter sich hat. Als die Großen der Storage-Branche konzentriert über iSCSI-Alternativen nachzudenken begannen, herrschte unter ihnen keineswegs Einigkeit. Manche Entwickler plädierten dafür, NVMe auf Grundlage des Fibre-Channel-Protokolls zu implementieren. Der Ansatz firmiert heute unter der Bezeichnung NVMe-oFC, also NVMe-over-Fibre-Channel. Das allerdings lehnten andere Hersteller strikt ab – jene nämlich, die entweder nie ein eigenes FC-Portfolio besaßen oder sich dieses Portfolios mittlerweile entledigt hatten, weil FC bei Admins nicht mehr sonderlich beliebt ist.

Mehr Fans fand schnell die Idee, NVMe auf den TCP/IP-Stack von Ethernet zu verpflanzen. Der impliziten Nachteile der Lösung wie die deutlich höhere Latenz als bei Fibre Channel waren ihren Erfindern durchaus bewusst. Gerade weil Ethernet aber so weitverbreitet ist, waren sie bereit, diese Nachteile in Kauf zu nehmen. Auch diese Lösung trägt eine eigene Bezeichnung, nämlich NVMe-over-TCP. Weil NVMe-oFC praktisch nie über den Versuchsstatus hinauskam, ist NVMe-oF heute praktisch synonym zu NVMe-oTCP.

Das macht es gerade Einsteigern in die Materie nicht unbedingt leichter. Nicht wenige Admins denken bei NVMe-oF instinktiv an geteilte Busse und RDMA, um direkten Zugriff auf Geräte über das Netzwerk zu ermöglichen. Das allerdings setzt sowohl eine spezielle Netzwerkkonfiguration als auch geeignete Hardware voraus. All diese Faktoren bleiben bei NVMe-oTCP aber außen vor. Nicht mal NVMe-Laufwerke sind nötig: Es lassen sich auch SATA- oder SAS-Festplatten per NVMe-oTCP ins lokale Netz exponieren.

Dass das nicht sehr schnell und der praktische Nutzen einer solchen Lösung folglich arg eingeschränkt ist, liegt auf der Hand. Das Beispiel verdeutlicht aber: NVMe-oTCP kann als Ersatz praktisch überall dort zum Einsatz kommen, wo bisher iSCSI werkelt – und gerade das war den Erfindern von NVMe-oF ja ein zentrales Anliegen. Voraussetzung ist lediglich ein entsprechendes Target. Ausgerechnet die sonst so vielseitige Linux-Community hat an dieser Stelle jedoch eher noch Nachholbedarf. Zwei Beispiele sollen das verdeutlichen.

Beispiel 1: RADOS

Da ist zunächst die bereits erwähnte NVMe-oF-Lösung für den Objektspeicher RADOS, den Kernbestandteil der Speicherlösung Ceph. Die Ceph-Entwickler sind mittlerweile darauf bedacht, Umwege etwa durch den Block Device Layer des Linux-Kernels so gut wie möglich zu umgehen. Stattdessen spielt sich der größte Teil des Zugriffs auf einen RADOS-Cluster im Userland ab.

Dafür bietet RADOS vielfältige Integrationen auf der Programmierebene: Die Bibliothek Librados ermöglicht den direkten Zugriff auf RADOS-Objekte, die Librbd (für RADOS Block Device) greift auf RBD-Abbilder in RADOS so zu, als handele es sich um lokale Speicherlaufwerke. Da wundert sich niemand, dass das primäre Ansinnen von IBM darin besteht, eine NVMe-oF-Lösung für RADOS so zu implementieren, dass sie im Hintergrund die Librbd nutzt und die Daten zwischen Client und RADOS hin- und herreicht. Das macht allerdings das NVMe-oF-Target, das die RADOS-Entwickler bereits bereitgestellt haben, für alle anderen Lösungen als RADOS unbrauchbar.

Erschwerend kommt hinzu, dass es um die Qualität der aktuellen Version 1.0 von NVME-oF für Ceph bislang eher schlecht bestellt ist. IBM weist die Funktion explizit als Tech-Preview aus, verbittet sich also sämtliche Anfragen nach Support dafür. Wer aber zumindest einmal einen verstohlenen Blick auf die Implementierung werfen und sie möglicherweise mit einem laufenden iSCSI-Setup vergleichen möchte, findet in der Red-Hat-Dokumentation derzeit dafür nicht annähernd alle nötigen Informationen. Die aktuelle Dokumentation des NVMe-oF-Targets für Ceph ist schlicht völlig unzureichend; etwaige nötige Befehle muss man sich stattdessen bei Google zusammensuchen.

Dabei unterscheidet das Setup sich gar nicht groß von iSCSI: Zunächst bringt man mittels Cephadm, also der Ceph-internen Orchestrierungslösung, eine Instanz des NVMe-oF-Targets an den Start. Der gibt man per CLI-Befehl das RBD-Abbild in RADOS mit auf den Weg, das es per NVME-oF zu exponieren gilt. Tatsächlich handelt es sich dabei um insgesamt fünf Befehle, nicht nur um zwei, doch arrivierte Admins stellt das wohl kaum vor unüberwindbare Hürden. Die nötigen Kommandos allerdings zu finden, sie also aus den wenigen Suchergebnissen für “RADOS NVMeoF” bei Google herauszudestillieren, stellt im Augenblick noch eine Herausforderung dar.

Obendrein muss interessierten Admins klar sein, dass sich ein ausgerolltes NVMe-oF-Target in seiner Tech-Preview-Version 1.0 praktisch nicht produktiv nutzen lässt. Es fehlt zum Beispiel der komplette HA-Modus, über den sich das in NVMe-oF (wie in iSCSI) vorgesehene Multipathing implementieren lässt. Dabei stehen Clients mehrere Netzwerkpfade zum selben Speichergerät offen, etwa weil zwei Server es parallel ins Netz exponieren. Der HA-Modus ist durchaus vorgesehen und wurde in den Entwicklungsversionen der 1.1.x-Serie auch schon implementiert. Allerdings setzt das eine brandneue Version der Monitoring-Server in RADOS voraus, die aktuell noch gar nicht als stabile Ceph-Version vorliegt. Der nötige Patch hatte es Anfang Juli 2024 noch nicht einmal in das Git-Verzeichnis von Ceph geschafft. Stattdessen tobte unter dem entsprechenden Merge Request eine seit Monaten andauernde Diskussion. Wann und wie der HA-Modus für NVMe-oF in Ceph also verfügbar sein wird, steht momentan noch komplett in den Sternen.

Selbst wenn die nötigen Funktionen in Ceph in absehbarer Zeit wohl bereitstehen, müssen Admins sich auf eine relativ steinige Konfiguration einstellen. Wie mittlerweile praktisch alle zu Ceph gehörenden Komponenten kommt auch das NVMe-oF-Target ausschließlich in Container-Form daher. Dasselbe gilt für das zugehörige Kommandozeilenwerkzeug Nvmeof-cli. Hier hantiert man also wieder mit diversen Exec-Kommandos für Podman oder Docker, um die Konfiguration überhaupt zu hinterlegen. Da bleibt nur zu hoffen, dass sich bis dahin die Dokumentation der Gesamtlösung in einem Zustand befindet, der diesen Namen rechtfertigt.

Beispiel 2: DRBD

Etwas besser macht man es bei Linbit in Wien. Klar: Die hauseigene Replikationslösung DRBD ist unter der Haube viel weniger komplex als Ceph. DRBD liegt im Block Device Layer des Linux-Kernels und schaufelt Pakete zwischen Datenträger und Netzwerk hin und her. Der offensichtliche Andockpunkt für ein NVMe-oF-Target ist insofern der Block Device Layer selbst.

Linbit hat entsprechende Lösungen sowohl für die Nutzung mit dem hausinternen Speichermanager Linstor als auch mit klassischen Mitteln wie Pacemaker implementiert. Dabei nutzt man das durchaus verfügbare NVMe-oF-Target für Linux und exponiert darüber die gewünschten Laufwerke – alternativ zu iSCSI (Abbildung 3). Der Anbieter stellt sogar ein eigenes Werkzeug [1] zur Verfügung, um aus drei generischen Servern flott einen Linstor-Cluster mit exponiertem NVMe-oF-Target zu bauen. Dabei ist Hochverfügbarkeit für das Target selbst impliziter Teil der Lösung. Auch an andere Virtualisierer lässt dieses Konstrukt sich bereits anflanschen, beispielsweise an Proxmox (Abbildung 4).

Abbildung 3: Linstor unterstützt sowohl – wie hier zu sehen – iSCSI als auch NVMe-oF. Mittels des Tools lassen sich auf derselben Hardware also hervorragend Vergleiche anstellen.

Abbildung 4: Proxmox bietet bereits Unterstützung für NVMe-oF, zumindest lassen sich entfernte Storage-Laufwerke lokal einbinden und nutzen.

Performance-Fragen

Die Linbit-Lösung erscheint insofern interessant, als sich mittels Linstor nicht nur NVMe-oF mit wenigen Handgriffen ausrollen lässt, sondern auch dessen Quasi-Vorgänger iSCSI. Linstor bietet also implizit die Möglichkeit, die beiden Protokolle auf derselben Hardware in unmittelbaren Vergleich zu setzen. Das ermöglicht Aussagen zu den Verbesserungen, die NVMe-oF tatsächlich bietet. Entgegen kommt dem Administrator hier zudem die wie beschrieben denkbar einfache Architektur von DRBD, die ein Verfälschen der Messwerte durch die Storage-Software selbst ausschließt.

Ein streng protokollierter Vergleich nach Standardregeln war bis Redaktionsschluss nicht möglich. Die im schnellen Test ermittelten Werte lassen insofern kein finales Urteil zur Frage zu, ob NVMe-oF seinen Vorgängern wirklich haushoch überlegen ist. Die gesammelten Daten legen das aber zumindest nahe: Auf derselben Hardware lieferte NVMe-oF im Gespann mit DRBD rund 20 Prozent mehr Durchsatz bei einer fast halbierten Latenz. Anders formuliert: Eine frisch angelegte iSCSI-LUN schaffte bei einer IO-Tiefe von 32 und vier gleichzeitig laufenden Jobs gute 36 000 IOPS bei 4k Request-Größe – mit NVMe-oF waren es über 68 000 IOPS. Darin ist die Latenz, die durch die Replikation des DRBD-Protokolls C entsteht, bereits enthalten.

Gelingt es den Entwicklern von NVMe-oF-Targets für Linux und den Herstellern entsprechender Geräte, vergleichbare Verbesserungen bei NVMe-oF gegenüber iSCSI zu erzielen, dürften dessen Tage sogar noch flotter gezählt sein als allein durch die Ablösung des veralteten Protokolls. Wir empfehlen jedoch jedem Admin, der eine iSCSI-Alternative sucht, dringend ausgiebigere Tests.

Mehr Bumms mit Spezialhardware

Obendrein steht die Zeit in Sachen Performance bei NVMe-oF keineswegs still. Nvidia etwa bietet auf seinen ConnectX-Netzwerkkarten (Abbildung 5) beim Verwenden des OFED-Treibers des Anbieters selbst NVMe-oF-Offloading an. Dann kümmert sich die Netzwerkkarte um NVMe-oF-Pakete und kann dabei auch auf Technologien wie das bereits erwähnte RDMA zurückgreifen. Das könnte es sogar ermöglichen, die Latenz von NVMe-oF auf ein mit Fibre Channel durchaus vergleichbares Niveau zu drücken – potenziell ein Meilenstein in Sachen Performance-Tuning für Remote Storage unter Linux.

Abbildung 5: Sogenannte SmartNICs wie die ConnectX-6 von Nvidia verarbeiten Protokolle wie NVMe-oF selbst (“Offloading”) und erreichen dadurch erhebliche Performance-Gewinne. Quelle: Nvidia

Noch sollten Administratoren allerdings keine allzu hohen Freudensprünge vollführen. Das für diese Art des Betriebs nötige Setup von SPDK und DPDK ist kompliziert, aktuell noch nicht sonderlich gut dokumentiert und auch längst nicht von jeder Linux-Distribution unterstützt. Noch werden Installationen dieser Art entweder sorgsam händisch geschnitzt oder bleiben in ihrem Einsatz auf das Labor und Testumgebungen beschränkt. Angesichts der erheblichen Verbesserungen, die sich durch NVMe-oF gegenüber iSCSI erreichen lassen, dürfte das aber kaum so bleiben. Hinzu kommt, dass der Trend, Netzwerkaufgaben an leistungsstarke Netzwerk-Chips auszulagern, keineswegs neu ist. Hier wird insofern noch einiges an Entwicklung folgen.

Fazit

Faktisch ist NVMe-oF viel mehr als nur die Wachablösung für iSCSI. Mit der Materie vertraute Hersteller haben sich viele Gedanken darüber gemacht, wie man ein Speicherprotokoll für den Zugriff aus der Ferne sinnvoll entwirft und implementiert, ohne die Fehler von iSCSI zu wiederholen. Das Resultat ist ein Standard mit irreführendem Namen, weil es sich bei praktisch allen heutigen NVMe-oF-Setups eigentlich um NVMe-oTCP-Implementationen handelt.

In Sachen Performance macht NVMe-over-Fabrics Lust auf viel mehr und agiert in vergleichbaren Situationen fast doppelt so flott wie der antiquierte Vorgänger. Längst haben die Hersteller begonnen, Ressourcen von iSCSI abzuziehen und in die Entwicklung von NVMe-over-Fabric-Lösungen zu investieren. Das ist gut so, denn stellt sich NVMe-oF als so haushoch überlegen heraus, wie es im Moment den Anschein hat, gibt es keinen guten Grund mehr, am antiquierten iSCSI festzuhalten.

Es bleibt zu hoffen, dass NVMe-oF auch auf Seiten der Linux-Hersteller und Distributoren etwas mehr Akzeptanz erfährt und die Integration in Red Hat, Ubuntu und Suse Linux Enterprise Server sich verbessert. Dann wird es nicht mehr lange dauern, bis kein Hahn mehr nach iSCSI kräht. (jcb)