Starnberg, 11. Febr. 2020 - Mit dem Aufkommen von schnellen Flash-Speichern und SCM gewinnt das Thema ‚Latenz’ im I/O-Stack aus Applikationssicht an Bedeutung...
Um was es hier geht: iSCSI oder NVMeoF (over Fabrics) oder beides, dass ist hier die Frage... Einleitend bleibt festzuhalten, dass SCSI wie viele andere Protokolle inzwischen schon viele Jahre auf dem Rücken hat. Ursprünglich nur für die lokale Speicherung verwendet (Direct-Attached, DAS), hat sich das beliebte Massenspeicherprotokoll über die ständig steigende Anzahl an professionellen DataCenter-Umgebungen, Clouds und Festplatten in der Breite etabliert. Nachdem Mitte der neunziger Jahre mit dem Fibre Channel SAN Industriestandard der Durchbruch für Shared-Storage und Disaster Recovery auf Speichersubsystem-Ebene eingeleitet wurde, ist rund fünf Jahre später iSCSI als populärer Standard auf dem Markt gekommen. Speziell die Variante mit Software iSCSI-Initiators ermöglicht es, iSCSI auf jedem (Windows-)Server laufen zu lassen, ohne dass spezielle HBAs nötig werden; eine sehr beliebte Variante für weniger kritische Anwendungsumgebungen, allerdings in Leistung und Verfügbarkeit beschränkt.
iSCSI über Ethernet
Wirklich geschäftskritische - hier noch vielfach on-premise - RZ-Anwendungen, die gleichzeitig neben robustem Betrieb Hochverfügbarkeit und skalierbare Performance benötigen, setzten und setzen vielfach heute noch auf FC-SANs, also auf ein robustes, latenzarmes und dezidiertes Hochleistungsnetzwerk. Mit dem Aufkommen von Cloud-Providern und 25G- und 100G-Ethernet begann / beginnt sich das zu ändern. Ethernet-Geschwindigkeiten wie 50G und 100G sowie z.B. QoS-Funktionen auf Switch-Ebene halfen, die planbare Leistung und Zuverlässigkeit von iSCSI zu erhöhen. Heute ist innerhalb von Hosting / Cloud - Umgebungen iSCSI mit Ethernet jedenfalls Standard.
NAND Flash und SCM passen nicht gut zu iSCSI
Mit dem Aufkommen von Flash SSDs entstand auf der I/O-Seite ein Problem. NAND-Drives sind deutlich schneller als bislang verwendete 15K HDDs und SATA / SAS / SCSI mutiert zunehmend zu einem Engpass (I/O-Bottleneck). Auch rücken Anwendungen im Bereich von Datenbanken wie NoSQL, Big Data Analytics oder weiterhin Virtualisierung die Latenzzeiten für (shared-) Storage in den Vordergrund. NMVe als skalierbares (z.B. queue depth) latenzarmes Protokoll ist die resultierende technische Konsequenz und Lösung. Dazu wurde die komplexe SCSI-Protokollschicht - mitverantwortlich für Latenzen - mit dem neuen Standard eliminiert; NVMoF als Fabric-basierte und skalierbare Erweiterung ermöglicht Hochleistungs-shared „SANs“ auf Basis Flash und SCM.
NVMe-oF ist dabei durchaus flexibel, was die Netzwerkseite angeht und kann über TCP oder RDMA via Ethernet, InfiniBand aber natürlich auch Fibre Channel betrieben werden (Investitionsschutz). Hochleistungs-Flash-Arrays und derzeit wegen Kompatibilitätsgründen Linux-Apps profitieren direkt von der NVMe-oF Leistung. Es ist zu erwarten, dass in den nächsten Jahren der Durchbruch auf breiter Ebene erfolgen wird (end-to-end Support). Insbesondere wenn es für Windows-Server bzw. virtuelle Systemumgebungen wie VMware & Co. einen breiteren Support auf Initiator-Seite gibt. Bis dahin wird sich iSCSI allerdings auf Grund der Unterstützung aller wichtigen Hypervisor und Betriebssysteme wohl weiter gut am Markt behaupten.
Beschränkungen von iSCSI
iSCSI wird Betreiberseitig - mal abgesehen von den möglichen RDMA-Varianten (über Ethernet) - heute aus Performancegründen gerne mit Hilfe von externen Netzwerkadapter-Karten (TOE = iSCSI TCP-Offload-Engine) beschleunigt. Dies erfordert aber einen zusätzlichen Aufwand, bietet potentielle Fehlerquellen und erhöht die Komplexität und damit Kosten. Das aus meiner Sicht jedoch entscheidende Thema betrifft den Punkt, dass iSCSI wie auch NVMeoF „nur“ Block-Storage unterstützt. Das rasche Wachstum im Bereich von unstrukturierten Daten führt jedoch gerade wie wir sehen dazu, das parallele, scale-out Filesysteme auf Grund der gemeinsame Nutzung von Daten durch mehrere Anwendungen / Benutzer (NFS, SMB) in Kombination mit Objektspeicherung (S3) eine Art Renaissance erleben.
Software Defined (scale-out) Block-Storage als Katalysator?
Langfristig (> 5 Jahre) ist es wahrscheinlich, dass der Markt für iSCSI-Blockspeicher mit Ethernet unter Druck kommen wird, weil NVMeoF als Hochleistungsprotokoll auf iSCSI zielt. Bis dahin allerdings dürfte das beliebte Speicherprotokoll für Block-Storage über Ethernet in dem großen Markt der Cloud (Hyperscaler) Anbieter schon allein aus Kosten- und Kompatibilitätsgründen für Massendaten / gängige Apps (nicht besonders latenzkritisch) kaum an Attraktivität einbüßen.
Fazit: Das Aufkommen von NVMe-oF wird iSCSI für den Hochleistungs-Blockspeicherzugriff auf Flash und SCM (Storage Class Memory wie von Samsung, Micron, Intel) verdrängen. Gleichzeitig stellt das Wachstum von hochparallelen Scale-out-Filesystemen- und Object Storage sowohl iSCSI als auch FC-SANs vor Probleme. Allerdings kann die gerade zu beobachtende breitere Akzeptanz von SDS = Software Defined (scale-out Blockstorage) Lösungen sowohl für iSCSI als auch für FC-SANs natürlich auch noch einen Boost bringen, „abgerundet“ durch NVMe für High-End-Applikationsanforderungen.
Abb. 1: 800G Ethernet... Auszug von Keynote: The Evolution of Cloud-scale Storage from iSCSI to RoCE to NVMexpress over Ethernet to NVMexpress over TCP/IP (Quelle: Andy Bechtolsheim, Arista Networks, January 22, 2020, SNIA Annual Members Symposium and 2020 Persistent Memory Summit, US).
Querverweise zum Thema / Quellen:
-
Blogpost NDeuschle> Objekt- und File-Storagelösungen für den Unternehmenseinsatz
-
Bloglink NDeuschle > Blogpost zu NVMeoF und FC SANs (part2)
-
Blogpost NDeuschle > Storage-Systeme und Künstliche Intelligenz - Neuland oder Business as Usual?
-
Link > https://nvmexpress.org/
-
Link > https://www.snia.org/