Datenprotokolle im Rechenzentrum
Pfadfinder
Veröffentlicht in Ausgabe 05/2023 - SCHWERPUNKT
Gerade beim Storage ist das Sprichwort "es prüfe, wer sich lange bindet" von großer Bedeutung – denn vielfältig sind die am Markt verfügbaren Storage-Optionen, was auch und gerade die eingesetzten Protokolle betrifft. Manche sind nur im Gespann mit bestimmten Transportmedien nutzbar, bei anderen hat der Administrator hingegen mehr Gestaltungsspielraum.
Gleichzeitig sieht er sich mit dem typischen Buzzword-Bingo der IT-Industrie konfrontiert: Begriffe wie InfiniBand, Fibre Channel (FC) oder NVMe over Fabrics (NVMe-oF) haben die meisten Admins zwar schon einmal gehört. Doch wer nicht hauptberuflich als Storage-Experte tätig ist, kann sich unter vielen dieser Begriffe nichts Genaues vorstellen.
Die Krux der Begrifflichkeiten
Bei der Beschäftigung mit Daten- und Protokollpfaden der Gegenwart muss daher zu Beginn etwas Theorieunterricht stehen. Denn weil die genannten Begriffe oft wild durcheinander genutzt werden, ergeben sich bereits bei den Grundlagen erhebliche Verständnisschwierigkeiten. Es gilt: Wer sich mit Storage befasst, hat es regelmäßig mit zwei verschiedenen Schichten des OSI-Modells zu tun.
Gerade beim Storage ist das Sprichwort "es prüfe, wer sich lange bindet" von großer Bedeutung – denn vielfältig sind die am Markt verfügbaren Storage-Optionen, was auch und gerade die eingesetzten Protokolle betrifft. Manche sind nur im Gespann mit bestimmten Transportmedien nutzbar, bei anderen hat der Administrator hingegen mehr Gestaltungsspielraum.
Gleichzeitig sieht er sich mit dem typischen Buzzword-Bingo der IT-Industrie konfrontiert: Begriffe wie InfiniBand, Fibre Channel (FC) oder NVMe over Fabrics (NVMe-oF) haben die meisten Admins zwar schon einmal gehört. Doch wer nicht hauptberuflich als Storage-Experte tätig ist, kann sich unter vielen dieser Begriffe nichts Genaues vorstellen.
Die Krux der Begrifflichkeiten
Bei der Beschäftigung mit Daten- und Protokollpfaden der Gegenwart muss daher zu Beginn etwas Theorieunterricht stehen. Denn weil die genannten Begriffe oft wild durcheinander genutzt werden, ergeben sich bereits bei den Grundlagen erhebliche Verständnisschwierigkeiten. Es gilt: Wer sich mit Storage befasst, hat es regelmäßig mit zwei verschiedenen Schichten des OSI-Modells zu tun.
Das ist zumindest dann der Fall, wenn es, wie in diesem Artikel, ausschließlich um Speicheroptionen geht, die irgendeine Form von Netzwerkverbindung nutzen. Wer seine Flash-Medien direkt im Server mit dem Mainboard verkabelt, hat einen lokalen Datenpfad und ist mit den Überlegungen fertig. Sobald es aber darum geht, Daten zwischen verschiedenen Servern auszutauschen, kommen zwangsläufig die Schichten des guten, alten OSI-Protokolls ins Spiel.
Hier ist der IT-Fachmann in Sachen Storage üblicherweise irgendwo in den Schichten eins bis vier unterwegs. Tückisch dabei: Verschiedene Zugriffsmöglichkeiten verbinden die Layer zwangsweise miteinander. Ein gutes Beispiel dafür ist Fibre Channel. Die Schnittstelle und das zugehörige FC-Protokoll (FC-P) definieren den kompletten OSI-Stack von Ebene eins bis Ebene vier durch, sind in sich also relativ geschlossen.
Bei anderen Ansätzen sind Transport und Protokoll deutlich stärker voneinander getrennt. Etliche Datenpfade setzen etwa auf die Anwendungsebene und nutzen normales Ethernet mit TCP/IP auf den OSI-Ebenen eins bis drei. Das trifft auf fast alle Protokolle zu, die im Endanwenderbereich alltäglich sind: AFP, Samba/ CIFS oder iSCSI & Co. Eine Art Spezialfall bilden modernere Protokolle, die gewisse Optionen innerhalb des OSI-Layers einräumen. Das ist oft bei Technologien der Fall, bei denen RDMA zum Einsatz kommt, also der netzwerkgestützte direkte Zugriff auf den Speicher eines Systems.
Verwirrend ist nicht zuletzt, dass es kaum feste Regeln in der Industrie gibt, ob und wie Transport und Protokoll aneinandergekoppelt werden dürfen oder nicht. Manche Hersteller implementieren proprietäre Optionen und forcieren auf der Nutzerseite damit einen Lock-In. Andere Ansätze bieten mehr Freiheiten, sind dafür aber komplexer – und nicht so perfekt auf einzelne Einsatzzwecke zugeschnitten wie die zuvor genannten proprietären Produkte. Gerade deshalb ist es aus Sicht des Administrators so wichtig, zumindest eine ungefähre Vorstellung dessen zu haben, was er sich ins Rack holt und welche Implikationen damit einhergehen.
Fibre Channel einst übermächtig
Wie so oft in der IT strahlt auch beim Thema Storage und Datenprotokolle die Vergangenheit eindrücklich in die Gegenwart – und vermutlich ebenso in die Zukunft. Die Umsetzung eines zentralen Speichers haben IT-Verantwortliche vor 20 Jahren üblicherweise mit einem SAN (Storage Area Network) und Fibre Channel gelöst. Dieser Ansatz galt als Goldstandard, und zwar aus mehreren Gründen: Einerseits war FC dem damals recht behäbigen Ethernet in Sachen Performance und Latenz weit überlegen. Und andererseits war Fibre Channel auf sämtlichen OSI-Ebenen früh definiert und dokumentiert. Wer beim Anbieter ein FC-SAN kaufte, wusste, was er bekam, und zwar sowohl im Hinblick auf den Speicher selbst als auch in Bezug auf die Anbindung des Speichers an die lokalen Clients.
Noch dazu war Fibre Channel hervorragend in Linux integriert. Mit relativ wenig Konfiguration auf Storage- wie Clientseite sorgte der Admin dafür, dass auf Letzterer ein Blockspeichergerät verfügbar wurde, das sich wie eine lokale Festplatte nutzen ließ. Dieser Betriebsmodus hat insbesondere im Kontext der frühen Virtualisierung zahlreiche Anhänger gefunden, und FC galt über viele Jahre hinweg als echte Bank im Storage-Kontext. Auch heute finden sich klassische SAN-Umgebungen vielerorts noch im aktiven Gebrauch.
Doch war in der Fibre-Channel-Welt keineswegs alles Gold, was glänzte. Ein zentraler Nachteil etwa war der Umstand, dass es bei hohen Bandbreiten auf relativ kurze Kabellängen festgelegt war. Heute steht Fibre Channel zudem dem Problem gegenüber, dass andere Protokolle ihm das Wasser abgegraben haben. Zwar hat FC in jüngerer Vergangenheit deutliche Verbesserungen durchlaufen - mittlerweile sind etwa Datenraten von bis zu 128 GBit/s möglich. Beim Vergleich dieser Werte mit anderen Transportebenen wie dem Ethernet der Gegenwart oder InfiniBand zieht Fibre Channel aber trotzdem klar den Kürzeren. Zudem wollen viele Unternehmen heute kein eigenes Netzwerk mehr für ihre Storage-Infrastruktur betreiben. Genau das erzwingt Fibre Channel aber systembedingt.
Ethernet heute überall
Gerade der letztgenannte Aspekt hat zum Abstieg von Fibre Channel ganz erheblich beigetragen und Ethernet gilt heute als ubiquitär. Die Transporttechnologie ist nicht nur in praktisch jedem Rechenzentrum zu finden; sie ist über TCP/IP perfekt in sämtliche Netzwerkarchitekturen der Gegenwart integriert, billig zu bekommen und von praktisch allen Betriebssystemen hervorragend unterstützt. Bei der Beschäftigung mit Ethernet gilt es jedoch, zwischen der Technologie im Hintergrund sowie den darauf laufenden Protokollen zu unterscheiden.
Gerade weil die Verbreitung von Ethernet so groß ist, haben etliche Anbieter in der Vergangenheit weite Teile ihrer Entwicklung auf Ethernet fokussiert. Ein gutes Beispiel dafür ist die Firma Mellanox, die zwischenzeitlich von Nvidia übernommen worden ist – glauben wir den Gerüchten, dann vorrangig ob der eigenen Ethernet-Produktpalette. Mellanox galt seinerzeit als einer der ersten Anbieter, die Ethernet-Produkte für Geschwindigkeiten von 100 GBit/s liefern konnten, und das zu erträglichen Tarifen.
Mittlerweile ist Ethernet gar bei 400 GBit/s angekommen und noch immer punktet Nvidia mit Geräten aus Mellanox-Provenienz ob ihrer Geschwindigkeit, ihrer Stabilität und des aufgerufenen Preises. Da stört es nicht, dass die Konkurrenz längst nachgezogen hat und Anbieter wie Broadcom ebenfalls Geräte mit 400-GBit/s-Durchsatz am Start haben.
Latenz als wichtiges Kriterium
Bis heute gilt Ethernet allerdings auch als eine Art hässliches Entlein unter den Transportmedien für Speicherzwecke. Das hat vor allem etwas damit zu tun, dass Ethernet traditionell eine deutlich höhere immanente Latenz hat als praktisch alle anderen Transportmedien am Markt. Gerade im Storage-Kontext ist das mehr als eine Lappalie. Denn eine virtuelle Instanz, die über Ethernet an ihren Speicher angebunden ist, leidet unter Latenz im eigenen Datenpfad am meisten.
Ein Blick auf das Anwendungsgebiet Datenbanken macht das schnell deutlich: Während eine Millisekunde Latenz bei der Verbindung ins Internet als vernachlässigbar gilt, ist dies bei einer virtuellen Instanz bereits eine merkliche Verzögerung beim Zugriff auf den Speicher. Virtuelle Maschinen, die per Ethernet angebunden sind, haben im direkten Vergleich mit lokalem Speicher keine Chance. Ceph, ein Objektspeicher, auf den wir später noch genauer eingehen, kommt unter realistischen Bedingungen bei MySQL etwa nicht über rund 4000 IOPS hinaus. Je nach Größe der Umgebung und der Menge eingehender Anfragen kann das als Flaschenhals schon reichen, um den Speicher für den jeweiligen Einsatzzweck unbenutzbar zu machen. Das gilt umso mehr, wenn Replikation im Spiel ist und die "Latenz-Strafe" bei Ethernet pro Schreibvorgang gleich mehrmals anfällt.
Zur Wahrheit gehört aber auch, dass die Hersteller von Ethernet-Produkten in der jüngeren Vergangenheit verstärkt das Problem der Latenz angegangen sind. Während insbesondere in den 2010er-Jahren bei Ethernet "mehr Bandbreite" das einzige Motto war und die Latenz mehr oder minder unbeachtet blieb, haben Firmen wie Mellanox mittlerweile auch den Latenz-Fußabdruck von Ethernet erheblich nach unten gedrückt.
Das macht sich in konkreten Zahlen bemerkbar: Im direkten Vergleich mit InfiniBand etwa benötigten Ethernet-Verbindungen vor ein paar Jahren noch das Vier- bis Fünffache der Zeit — heute liegt dieser Wert eher beim Faktor 2. Für den Transport eines Pakets von A nach B brauchen moderne Ethernet-Switches also noch ungefähr das Doppelte der Zeit von InfiniBand, was im Transportkontext ein echter Meilenstein ist. Aber aufgepasst: Um von diesen Verbesserungen zu profitieren, müssen natürlich aktuelle Ethernet-Boliden im Rack stehen. Wer mit Uralt-Hardware operiert, muss mit deutlich höherer Latenz rechnen.
Bunter Strauß an Protokollen
Dass Ethernet trotz seiner hohen immanenten Latenz nie ernsthaft in Gefahr geraten ist, im RZ durch andere Technologien verdrängt zu werden, liegt nicht zuletzt an der Protokollvielfalt, die Ethernet bis heute als Grundlage nutzt. Praktisch sämtliche Storage-Protokolle aus dem Consumer-Bereich etwa basieren auf Ethernet.
Wer im Büro einen Network Attached Storage (NAS) betreibt, findet an diesem Ethernet-Anschlüsse. Erweiterungskarten für die Geräte von QNAP oder Synology existieren und bieten ein Upgrade von 1 auf 10 GBit/s respektive 20 GBit/s mit Kanalbündelung. Sämtliche von diesen Geräten gesprochenen Protokolle fußen ebenfalls auf TCP/IP. Wer einen Windows-Share einrichtet, nutzt CIFS über Ethernet. Apples File Protocol fußt ebenfalls auf TCP/IP und auf Ethernet.
Und selbst im Umfeld der Virtualisierung hat Ethernet sich mittlerweile de facto als Standard durchgesetzt. NAS-Appliances von Anbietern wie Dell-EMC oder Huawei verwenden Protokolle wie iSCSI, um Volumes hin zum Hypervisor zu exponieren. iSCSI gilt als eine Art Konkurrenzprodukt zu Fibre Channel, erfunden überhaupt erst, um Ethernet anstelle von FC nutzen zu können.
Objektspeicher setzen auf Ethernet
Hinzu kommt, dass in den vergangenen Jahren noch eine neue Art des Speichers Teile des Markts erobert hat, gerade im Kontext skalierbarer Plattformen: Objektspeicher. Diese funktionieren nach einem simplen Prinzip. Sie teilen die zu speichernden Informationen in kleine Teile (Objekte) auf, behandeln sämtliche Informationen als binäre Datei und profitieren so davon, dass sie die Daten beliebig zerlegen können.
Solange das Zusammenfügen in der richtigen Reihenfolge geschieht, ermöglichen Objektspeicher auf diese Art und Weise das Verteilen von beliebigen Inhalten über beinahe unbegrenzte Speichergeräte in fast beliebig vielen Systemen. Auch hier wird selbstverständlich eine Schicht für den Transport benötigt, und dabei setzen alle relevanten Angebote am Markt ebenfalls auf Ethernet.
Der Objektspeicher Ceph verdeutlicht das gut. Wer drei Systeme mit Ethernet und lokalem Speicher hat, baut in kürzester Zeit daraus einen verteilten Objektspeicher. Weil Inktank als ehemaliger Entwickler von Ceph sich von Anfang an viel Mühe bei der Integration in die Anwendungslandschaft gegeben hat, lässt dieser Objektspeicher sich etwa aus Qemu heraus unmittelbar ansprechen. Weil Qemu der Standardemulator in vielen Linux-Umgebungen ist, liegt die Nutzung von Ceph hier fast schon auf der Hand, wenn es um verteilten Speicher geht.
In den ersten Jahren der Ceph-Entwicklung galt folglich fast schon so etwas wie Goldgräberstimmung bei etlichen Softwareanbietern. Mittlerweile hat sich die Euphorie etwas gelegt, was nicht zuletzt am Transportmedium Ethernet liegt. Denn nicht zu leugnen ist, dass Ceph implizit langsam ist, weil sein Algorithmus zur Verteilung von Daten sehr latenzlastig ist.
Lange Rede, kurzer Sinn: Im Rechenzentrum der Gegenwart verfügt Ethernet über eine de facto nicht zu beseitigende Dominanzstellung – ganz einfach deshalb, weile eine Vielzahl gängiger Protokolle auf Ethernet fußt. Für die meisten Protokolle muss der Administrator de facto kaum über Ethernet-Alternativen nachdenken, weil sie praktisch nicht oder nicht sinnvoll zu implementieren sind. Interessant ist das Nachdenken über Alternativen augenblicklich vor allem dort, wo hohe Durchsatzraten und geringe Latenz gefragt sind, etwa bei der Virtualisierung oder beim Betrieb hochperformanter Datenbanken.
Edle Alternative: InfiniBand
Kenner der Branche werden einwenden, dass in Form von InfiniBand und IP over InfiniBand (IPoIB) durchaus mächtige Alternativen zur Verfügung stehen. Das ist einerseits richtig, andererseits aber nicht die ganze Wahrheit. InfiniBand gilt seit Jahrzehnten als Edelalternative zu Ethernet und ist ebenfalls den Gehirnen bei Mellanox entsprungen. Ab Werk bietet die Technologie eine deutlich geringere Latenz und zumindest früher auch deutlich höhere Durchsatzraten als Ethernet.
Eigentlich, so wäre zu erwarten, Grund genug, dass InfiniBand Ethernet in der Breite als Netzwerkstack hätte verdrängen müssen. Allerdings ist Mellanox als Teil von Nvidia bis heute der einzige Anbieter entsprechender Hardware, und meistens haben Unternehmen InfiniBand nicht als Ersatz für Ethernet angeschafft, sondern eher als Ergänzung für einzelne Teilbereiche, etwa in High-Performance-Setups.
Was dabei aber meist massiv stört, ist die parallele Netzwerkwerkinfrastruktur, die zusätzlich zu Ethernet auszurollen ist. Denn als vollständiger Drop-In-Ersatz für Ethernet mit TCP/IP lässt sich auch IPoIB nicht einfach nutzen. Ceph taugt hier einmal mehr als Negativbeispiel: Zwischen der damaligen Firma Inktank und Mellanox gab es ein gemeinsames Projekt, InfiniBand als Transportpfad für Ceph nutzbar zu machen. Über einen Pilotversuch sind diese Bemühungen aber nie hinausgekommen.
So bleibt InfiniBand in dieser Übersicht nur die Rolle, die die Technologie fast schon traditionell innehat: als Edelalternative beziehungsweise -erweiterung für Ethernet nämlich, im Kontext spezifischer Anwendungsfälle wie High Performance Computing – aber nicht als grundsätzlicher Ersatz.
Blick in die Zukunft
CPU, RAM und Speicherlaufwerke sind hinsichtlich ihrer Performance in einem steten Katz- und Maus-Spiel gefangen: Innovationen bei Prozessoren und flüchtigem Speicher sorgen dafür, dass der Bus zur Datenübertragung über immer mehr Bandbreite verfügt. Die Entwicklung bei Speicherlaufwerken ist darauf ausgerichtet, diese Bandbreite im echten Leben tatsächlich nutzbar zu machen.
Die immer größere Verbreitung von Flash-basierten Laufwerken verdeutlicht dies. Regelmäßig kommen heute Speicherlaufwerke zum Einsatz, die die übrigen Ressourcen in Systemen zum Nadelöhr machen. Etliche GByte pro Sekunde sind hinsichtlich des Datendurchsatzes bei schnellen NVMe-Laufwerken heute eher die Regel als die Ausnahme. Zwar sind Transportmedien wie Ethernet sukzessive mitgewachsen und ermöglichen es, diese Bandbreiten etwa für virtuelle Instanzen zu nutzen. Dann gibt gerade bei Ethernet aber wieder die Latenz den Spielverderber.
Um Speicher auf Netzwerkbasis trotzdem sinnvoll und performant nutzbar zu machen, hat die Industrie sich RDMA ausgedacht. "Remote Direct Memory Access" basiert auf dem Prinzip, den Transportpfad als solchen zu nutzen, auf diesem allerdings ein eigenes Protokoll zu sprechen, das in den jeweiligen Systemen direkt auf das RAM zugreift. InfiniBand hat in der Vergangenheit bereits bewiesen, für diese Art des Einsatzes hervorragend geeignet zu sein. Der großen Verbreitung von Ethernet ist geschuldet, dass entsprechende Begehrlichkeiten auch hier entstanden sind.
Dasselbe gilt für NVMe: Auf diesem Protokoll basierende Speichermedien sind mit Abstand die schnellsten am Markt. Doch sieht der NVMe-Standard vor, dass ein entsprechendes Laufwerk direkt mit dem Bus im Host-System verbunden sein muss. NVMe over Fabrics (NVMe-oF) gilt augenblicklich deshalb als Game Changer in der Branche. Der Standard erweitert NVMe um eine Protokollschicht, die Daten direkt aus dem Bus über einen entsprechenden Transport-Layer in ein lokales Netz ausleiten kann.
Besonders interessant dabei: NVMe-oF ist flexibel hinsichtlich des zu nutzenden Transports. Zur Auswahl stehen aktuell sowohl Fibre Channel, das in gewisser Weise ein Revival erlebt, sowie Ethernet. Gerade weil Ethernet in den letzten Jahren an der Latenzschraube gedreht hat, sind die Performanceunterschiede zwischen den Transporten aber nicht mehr so groß. Wer NVMe-oF ausprobieren möchte, kann also auf Ethernet-Komponenten zurückgreifen. Auf den Markt bestehender Protokolle dürfte sich NVMe-oF allerdings kaum auswirken. Es ist eher zu erwarten, dass der Ansatz eine Nischenlösung für Umgebungen mit besonders hohen Anforderungen an Direct Attached Storage (DAS) bleibt.
Fazit
Die meisten Unternehmen dürften im Jahr 2023 kaum Bedarf an anderen Netzwerktechnologien als Ethernet haben. Dort, wo besonders schneller, direkt angebundener Speicher benötigt wird, ist NVMe-oF eine valide Alternative. Dann bedarf es allerdings auch aktueller Netzwerkhardware mit geringer Latenz. Fibre Channel findet sich heute vor allem noch in Bestandsumgebungen, hat aber wie InfiniBand zumindest in der Breite gegen Ethernet meist schlechte Karten, weil gerade KMU den Aufwand einer zweiten Netzwerkinfrastruktur scheuen. Ethernet hingegen deckt die Storage-Anforderungen der allermeisten Umgebungen gut ab. Klassische Zugriffsprotokolle wie CIFS oder die Nutzung von Objektspeicher wie Ceph lassen sich ohnehin nicht anders realisieren.
(ln)