NVMe-over-Fabrics 1.1: NVMe für das Rechenzentrum

Das NVMexpress-Konsortium arbeitet aktiv an verschiedenen Spezifikationen im Rahmen von NVMe. Neben den Specs für NVMe selbst kommen von dem Industrie-Konsortium auch Standards zum Management-Interface für NVMe-Devices (NVMe-MI), sowie zur Nutzung von NVMe in Speichernetzen, auch bekannt als NVMe-oF. Zu letzterem wurde Ende 2019 die neue Version 1.1 veröffentlicht.

NVMe als Spezifikation lässt sich zurück verfolgen bis ins Jahr 2007, als Intel auf ihrem Intel Developer-Forum ihre ersten Ideen zu einer Spezifikation für NVMHCI vorstellte. Seit 2011 gibt es die Spezifikation NVMe 1.0. Anfangs ging es insbesondere darum, PCI Express (PCIe) um Kommandos zu erweitern für den Zugriff auf Flash-Storage. Später kamen dann Spezifikationen zu NVMe-MI (Management Interface) und NVMe-oF (over Fabrics) dazu, die insbesondere von Kunden aus dem Enterprise-Segment nachgefragt wurden. Alle drei Bereiche werden vom Industrie-Konsortium NVMexpress gepflegt und Stück um Stück erweitert.

Zuletzt auf Version 1.1 aktualisiert wurde im Herbst 2019 die Spezifikation zu NVMe-oF. Darin sind Funktionen und Mechanismen beschrieben, die gebraucht werden, um von einem oder mehreren Hosts auf ein NVMe-Subsystem im Netzwerk zuzugreifen, so wie man das von Storage-Systemen im SAN kennt. Mit dem letzten Update von NVMe-oF wurden drei wesentliche Dinge ergänzt bzw. erweitert:

• Erweiterung um einen Datentransport über TCP/IP,
• Verbesserung der Multipathing-Funktionalität,
• Verbesserungen beim automatischen Discovery von NVMe-Geräten innerhalb eines NVMe-oF-Netzwerks.

NVMe Specification-Roadmap (Quelle: NVM Express)

TCP jetzt auch für NVMe-oF

NVMe-oF erforderte bisher als Transport-Protokoll wahlweise PCIe, RDMA oder Fiber-Channel. Ersteres hat Längen-Beschränkungen, RDMA braucht spezielle Hardware, und FC setzt eine entsprechende Infrastruktur mit Glasfaser und Fiber-Channel-Switches voraus. In allen drei Fällen ist eine einfache, unkomplizierte Verwendung von NVMe-oF nicht möglich.

Die aktuelle Version NVMe-oF 1.1 trägt diesem Umstand Rechnung und spezifiziert dazu TCP als zulässige Transport-Schicht. Mit einer TCP-Offload-Engine in Hardware ist dabei ein latenzarmer Betrieb möglich, der nur unwesentlich langsamer ist, als eine native NVMe-Verbindung über PCIe. Aber auch eine reine Umsetzung als Software-Treiber liefert noch Latenzwerte deutlich jenseits denen von SAS/SATA (Mikrosekunden vs. Millisekunden).

Multipathing – alle Wege führen zum Flash

Bereits in der ersten Version der Spezifikation von NVMe-oF war Multipathing möglich. Allerdings brauchte man dazu je Pfad einen eigenen Controller, und die Controller mussten identische Hardware sein, damit die Adressierung funktioniert.

Mit NVMe 1.4 (Juni 2019) führte das NVMexpress-Konsortium den sogenannten Asymmetric Namespace Access (ANA) ein, der mit NVMe-oF 1.1 jetzt auch für Storage-Netze umgesetzt wurde. Die genaue Bezeichnung eines Hardware-Pfades hin zu einem NVMe-Drive spielt keine Rolle mehr, die Pfade werden jetzt logisch abgebildet. In der Praxis bedeutet das, dass sich für verschiedene Pfade zum selben Drive auch verschiedene Controller (und damit Treiber) benutzen lassen. Zusätzlich kann eine Pfad-Priorität festgelegt werden, um Daten beispielsweise bevorzugt über den schnelleren Pfad zu transportieren. Nur im Fehlerfall wird automatisch ein alternativer aber langsamerer Pfad benutzt. Solche Optionen kennt man auch aus Storage-Arrays im SAN-Umfeld, wo es ebenfalls eine Unterscheidung zwischen preferred path und alternate path gibt.

Auto-Discovery, Domains und Divisions, gezielte Fehlerbehandlung

Zum besseren und übersichtlichen Management ist es ratsam und sinnvoll, große Storage-Töpfe in einzelne voneinander unabhängige Bereiche zu unterteilen. Was im Bereich von Disk-Subsystemen längst zum guten Ton gehört, ist mit NVMe-oF jetzt auch für zentrale Flash-Systeme möglich. Ein NVMe-Subsystem lässt sich in verschiedene Domains einteilen. Damit lässt sich insbesondere die Verfügbarkeit eines großen Subsystems verbessern, weil einzelne Bereiche des Subsystems (Domains) getrennt voneinander gestoppt, gestartet und administriert werden können.

Wird ein Host gebootet und dabei der NVMe-oF-Treiber geladen, erfolgte bisher ein einmaliger Scan des angeschlossenen NVMe-oF-Netzwerks nach zur Verfügung stehenden LUNs. Mit NVMe-oF 1.1 kann dieser Vorgang jetzt jederzeit zur Laufzeit neu angestoßen werden. Es ist also jetzt möglich, dynamisch neue NVMe-LUNs hinzuzufügen oder zu entfernen, ohne jedes Mal das Host-System zu rebooten.

Gelegentlich kann es bei NVMe-oF vorkommen, dass sich einzelne I/O-Queues fehlerhaft verhalten, oder so abstürzen, dass sie keine Daten mehr transportieren. Bisher war es dann notwendig, die Zuordnung der betroffenen LUN zum Host-Controller per Reboot neu zu initialisieren. Mit NVMe-oF gibt es jetzt auch Mechanismen, einzelne, fehlerhafte I/O-Queues zu löschen, ohne dabei die Verbindung von Host-Controller zur LUN dazu zu resetten. Auch dieses Feature verbessert die Zuverlässigkeit und macht NVMe-oF ein weiteres Stück Enterprise-tauglich.

NVMe-oF 1.1: NVMexpress-Konsortium arbeitet an neuen Feature-Sets

Das NVMexpress-Konsortium arbeitet intensiv weiter an neuen Funktionen und verbessert bestehende Funktionen, immer den generischen Anwendungsfall »Enterprise IT« im Hinterkopf«, sagt John Kim, Director Storage Marketing bei Mellanox. »Man hört dabei auch aufmerksam auf Probleme, Herausforderungen und Wünsche der Anwender.« Dass im Konsortium zahlreiche Unternehmen aus allen Bereichen des NVMe-Stacks aktiv mitarbeiten, soll auch weiterhin zu einem ausgewogenen Feature-Set von NVMe-oF beitragen. Und wer Spaß daran hat, trockene technische Spezifikationen zu lesen: das NVMexpress-Konsortium bietet alle bisher veröffentlichten Versionen zum Download an.

.