Blogpost Teil 1: Block-, File- und Object - Storagesysteme & Protokolle in der Entwicklung

Starnberg, 06. Nov. 2020 - Längerfristig eher Konvergenz oder Ablösung von bestehenden Speichertechnologien und Protokollen? Eine technologische Standortbestimmung...

Um was es hier geht: Der vorliegende Blogpost versucht aufzeigen, welche in der Praxis relevanten Speicherprotokolle und damit verbundenen Storage-Technologien sich über die Zeit im Markt etabliert haben und skizziert, wo ihre Ausprägungen in aktuellen Produkten gerade beginnen, sich im Sinne einer möglichen Konvergenz oder gar Ablösung bestehender Technologien zu verschieben. Konkret: inwieweit stellen Block- und File Storage, SAN, NAS, Objektspeicher oder global clustered Filesysteme weiterhin die Basis, kommt es irgendwann zu einem radikalen Bruch beim Transport-Layer oder existieren einfach immer mehr Technologieoptionen parallel, mit denen wir uns dann zu beschäftigen haben? Ziel des Beitrags ist es, aktuelle Trends etwas besser einzuordnen, auch um mögliche Implikationen für die eigene IT-Umgebung abschätzen zu können.

A) Block Level Storage (auch Block Storage) ist ein klassisches Speicherprotokoll und wird fast immer in Speichernetzwerken (typisch FC-SAN) oder Cloud-basierten Speicherumgebungen (typisch iSCSI) verwendet. Ohne Block Storage läuft im Rechenzentren noch gar nichts. Zur Funktionsweise: zu speichernde Daten werden in Blöcke aufgeteilt und mit einer spezifischen Kennung versehen. Das Speichernetzwerk platziert die Datenblöcke dort, wo es für die Anwendung geeignet ist. Wenn ein Benutzer seine Daten von einem Blockspeichersystem anfordert, setzt das Speichersystem die Datenblöcke wieder zusammen und präsentiert diese der Anwendung.

Blöcke können so konfiguriert werden, dass der Vorgang mit verschiedenen Betriebssystemen wie z.B. Linux und Windows funktioniert. Auch kann ein Block für NFS und einer z.B. für SMB formatiert werden. Die Blockspeicherung entkoppelt damit die Daten von der Benutzerumgebung, indem eine Abstraktionsebene eingefügt wird. Weil die Daten bei diesem Verfahren über mehrere Umgebungen flexibel verteilt werden können, existieren mehrere Datenzugriffs-Pfade; dies erlaubt es Benutzern, sie schneller abzurufen. Dieses Verfahren ist natürlich aufwendiger als ein relativ einfach zu konfigurierendes NAS-System.

  • Direkt angeschlossener Speicher (DAS = Direct Attached Storage) verfügt über Vorteile, dem je nach Anwendungsprofil auch Einschränkungen gegenüberstehen. Die Vorteile betreffen je nach Implementierung über Blocklevel-Zugriff reduzierte Latenzzeiten, unkomplizierter Betrieb sowie relativ niedrige Kosten (TCO) auf Grund eines relativ geringen Verwaltungsaufwandes. Nachteile betreffen neben der begrenzten Skalierung von Kapazität & Leistung vor allem die eingeschränkte Applikationsverfügbarkeit. Soll diese erhöht werden, muss ein zweiter Host angeschlossen werden. Die Datenverfügbarkeit auf JBOD- bzw. Array-Ebene lässt sich durch RAID (Software oder Hardware) verbessern. Als gängige Protokolle finden sich im DAS-Umfeld neben SCSI meist SATA und SAS. Bei DAS kontrolliert immer der Server den Zugriff auf den Speicher. Server-based Storage ist ein wachsender Trend, der im Zusammenhang mit NVMe Flash, Big Data Apps, NoSQL Datenbanken, Im-Memory-Computing, KI-Anwendungen oder auch Software Defined Storage zu beobachten ist.

  • Das Speichernetzwerk (SAN = Storage Area Network) ist im Gegensatz zu DAS ein spezialisiertes Hochgeschwindigkeits-Netzwerk, welches den Zugriff auf die angeschlossenen Speichergeräte (JBODs, Arrays) und deren Daten über Block Level Storage ermöglicht. SAN-Implementierungen bestehen aus Servern-/Hosts, intelligenten Switches und Speicherelementen, die über spezialisierte Protokolle wie Fibre Channel oder SCSI miteinander verbunden sind. SANs können zur Erhöhung der Business Continuity für kritische Anwendungsumgebungen mehrere Standorte umfassen. Ein SAN präsentiert den angeschlossenen Serversystemen mit Hilfe von Virtualisierung den Speicher so, als wäre dieser lokal angeschlossen. Ein SAN-Array stellt dazu einen konsolidierten Storage-Ressourcen-Pool bereits, typischerweise auf Basis virtueller LUNs, die in Cluster-Umgebungen von mehreren Hosts gemeinsam als shared storage genutzt werden. SANs basieren meist noch auf dem Fibre-Channel-Protokoll (FCP). Aber auch Fibre Channel over Ethernet (FCoE) und die Konvergenz von Speicher- und IP-Protokollen über eine Verbindung sind Optionen. Es ist bei SANs möglich, Gateways zu verwenden, um bei Bedarf die Anwendungsdaten auch zwischen verschiedenen Speichernetzwerk-Technologien verschieben zu können.

Ein beliebtes Blockspeicher-Protokoll im SAN ist iSCSI

Hier wird das SCSI-Speicherprotokoll über eine Ethernet Netzwerkverbindung mit TCP ausgeführt. Meist wird im on-premise oder private Cloud Umfeld iSCSI für sog. sekundäre Blockspeicher-Anwendungen benutzt, die nicht hoch geschäftskritisch sind. Wirklich kritische Applikationen benutzen in der Regel weiterhin robuste und latenzarme, vom Applikationsnetz konsequent getrennte SANs auf Basis Fibre Channel, oder bereits NVMe für besonders leistungsintensive I/O-Workload-Profile. Hohe Datenintegriät, latenzarme Übertragungsleistung und Funktionen wie Buffer Flow Control ermöglichen es FC, kritische Unternehmens-SLAs zu definieren und QoS-Levels konsistent zu erfüllen.

Das Protokoll eignet sich auch als NVMe-Transport-Layer, da es sowohl SCSI- als auch den NVMe-Datenverkehr gleichzeitig auf einer Fabric unterstützt. Bestehende Gen5 (16G) und Gen6 (32G) FC SANs können FC-NVMe über bestehende SAN-Fabrics mit nur geringen Änderungen betreiben, da laut FCIA alle Spezifikationen von NVMe erfüllt werden.

  • Anders ist die Situation bei den Hyperscale-Rechenzentren großer Cloud Services Provider, die alleine aus Kostengründen (Standardisierung, Kapazitäten etc.) derzeit (noch) auf iSCSI Block Storage und Ethernet-Protokolle mit 25G, 50G oder 100G setzen, wenngleich auch hier NVMe für mehr Leistung und neue Serviceangebote für bestimmte Anwendungen attraktiver wird. Im Zusammenhang mit Software-definierten Infrastrukturen bleibt Ethernet aus Standardisierungs- und Kostengründen in der Breite aller Installationen auf absehbare Zeit wohl die erste Wahl. Im hochspezialisierten HPC-Umfeld hingegen wird on-premise häufig InfiniBand (IB) verwendet, das zwar deutlich leistungsfähiger in Bezug auf Latenzzeiten und skalierbaren Durchsatz ist, aber auch mehr kostet (CAPEX). Zudem ist der Support von Hypervisor- und Betriebssystemen sowie Treiber-/Firmware eingeschränkt (OPEX). iSCSI als Block Level Storage läuft zwar am häufigsten über Ethernet mit TCP, kann aber auch über InfiniBand eingesetzt werden.

  • iSCSI wird auf Standard-Netzwerkkarten oder speziellen Host-Bus-Adaptern ausgeführt, um entweder mit RDMA (unter Verwendung von iSER) oder iSCSI-Offloads und/oder eine TCP-Offload-Engine zu nutzen. Durch den Einsatz von Netzwerkadaptern für I/O-Performance-Zwecke mit iSCSI-Hardware-Offload und/oder TCP-Offload-Engine beschleunigt,  wurde die Workload-Unterstützung von iSCSI erweitert. Im ersteren Fall lagert der Host-Bus-Adapter alle iSCSI-Initiatorfunktion von der Host-CPU aus. Im zweiten Fall lagert der Adapter die TCP-Verarbeitung vom Server-Kernel und der CPU aus. Der wichtigste Vorteil von iSCSI in der Praxis ist, dass es von allen gängigen Betriebssystemen bzw. Hypervisor-Implementierungen und Storagesystemen unterstützt wird. Dies trifft derzeit noch nicht für NVMeoF zu.

B) Wie FC und iSCSI verwendet auch das noch relativ junge NVMeoF-Protokoll Block Level Storage

NVMe und NVMe-oF sind als I/O-Protokolle bei Overhead deutlich schlanker als SCSI bzw. iSCSI und damit auch schneller. Wird deutlich mehr Leistung in Form von geringsten Latenzen beim I/O benötigt, ist Non-Volatile Memory Express NVMe das optimierte Protokoll für die Serververbindung mit nativen PCIe-Flashstorage über Direct Attached Storage (DAS). NVMe over Fabrics (NVMeoF) als skalierbare Netzwerk-Variante ermöglicht es, Daten mittels NVMe-oF über ein Speichernetz auf Basis Ethernet (RoCE; iWARP), Fibre Channel oder InfiniBand zwischen Hosts und Flashstorage zu übertragen.

Derzeit gilt: Wie bei iSER können NVMe-oF Ethernet-RDMA-Endknoten derzeit nur mit anderen NVMe-oF-Ethernet-Endknoten zusammenarbeiten, die denselben Ethernet-RDMA-Transport unterstützen. NVMe-oF-Endknoten sind nicht in der Lage, mit iSCSI- oder iSER-Endknoten zusammenzuarbeiten.

  • NVMe(oF) eliminiert SCSI als Protokoll und verfügt damit geringere Latenzen als iSCSI. Während Festplatten- und SSD-Arrays oft noch das gängige SCSI-Protokoll verwenden, ist ohne SCSI-Overhead die Leistung drastisch verbessert. Beispiel: Command Queuing bei SCSI unterstützt nur EINE Warteschlange für I/O-Befehle, während NVMe bis zu 64.000 erlaubt. Jede Warteschlange ihrerseits kann bis zu 64.000 Befehle gleichzeitig bedienen. Zusätzlich vereinfacht NVMe die Befehle auf der Grundlage von 13 spezifischen NVMe-Command-Sets, die auf die besonderen Anforderungen von NVM-Devices hin entwickelt wurden. Die Latenzzeiten für NVMe lagen bereits bei Einführung der Technologie rund 200 Mikrosekunden unter denen von 12-GBit SAS; zudem konnte durch den effizienteren Befehlssatz die CPU-Belastung um >50 Prozent gegenüber SCSI reduziert werden. Ähnlich verhält es sich bei sequenziellen Reads und Writes: Durch die hohe Bandbreite lassen sich in der Regel bei sequenziellen Lese- und Schreibvorgängen sechs- bis achtmal höhere I/O-Performancewerte im Vergleich zu SATA-SSDs erzielen.

  • NVMe-oF Block Storage kann über Ethernet-/TCP, Fibre Channel, Ethernet RDMA oder InfiniBand-Fabrics implemetiert werden. Als RDMA-Option wird die höchste Leistung bereitgestellt, aber alle Versionen von NVMe-oF sind bereits schneller als iSCSI. Ein Grund, weshalb die Anbieter von Flashstorage beginnen, verstärkt auf NVMe-oF umzustellen. Man wird letztlich sehen, welche Technologie-Optionen sich über die Zeit auf breiter Front durchsetzen. In weiterer Arbeit befindliche NVMeoF / RDMA Varianten sind iWARP, IB, NVMeTCP sowie RoCEv2 („Rocky“).


Im nächsten Blogpost ( Dez. 20) werde ich darauf eingehen, inwieweit Block-Level Storage auf Basis FC, iSCSI und NVMe-oF über die nächsten Jahre noch eine stabile Zukunft haben werden...