© Tsung-Lin Wu, 123RF

Wer eine große und skalierbare Plattform betreibt, kennt das Problem: Schneller und gleichzeitig replizierter Speicher ist knifflig. Excelero verspricht die Kalamität im Sprint endgültig zu lösen.

Der Trend rennt weiter in Richtung Cloud. Anbieter, so liest man es bei vielen Marktforschern, werden zu Plattformbetreibern, und Kunden konsumieren digitale Dienstleistungen in genau den Dosen, die sie wünschen. Plattformanbieter kennen aber auch die Schwierigkeiten, die mit großen, skalierbaren Umgebungen einhergehen. Ein beinahe schon klassisches Problem hängt mit dem Massenspeicher zusammen. Da rappelt es regelmäßig im Karton, denn meist liefern die Anbieter nicht, was die Kunden sich wünschen oder gewohnt sind.

Skalierbarer Speicher ist wichtig

Bis vor einigen Jahren waren Lösungen für die Verwaltung großer Compute-Umgebungen noch gar nicht verfügbar – die Cloudsuites sind ein Phänomen der letzten Jahre. Erst heute haben Admins die Wahl aus mehreren Möglichkeiten, auch wenn Open Stack sich mittlerweile als eine Art Klassenprimus etabliert hat. Mindestens so wichtig wie die Möglichkeit, eine Cloud effizient zu betreiben, ist es auch, ihre Hardware beliebig erweitern zu können. Für Compute kümmert sich darum die Cloudsoftware selbst, doch wer für seine Plattform auch nahtlos skalierenden Storage haben möchte, muss sich mit diesem Thema separat befassen. Hier hat Ceph es zu einiger Verbreitung gebracht und gilt in vielen Szenarien als gesetzt (Abbildung 1).

Abbildung 1: Ceph ermöglicht massiv skalierbaren Speicher für Open Stack sowie andere Lösungen, aber schnell ist der Ansatz nicht.

Zur Erinnerung: Clouds unterscheiden zwischen zwei Arten von Speicher: auf der einen Seite Ephemeral Storage und auf der anderen persistenter Blockspeicher. Ephemeral Storage bezeichnet flüchtigen Speicher, der nur so lange existiert, wie die dazugehörige VM auch. Bei persistentem Storage ist das anders. Dieser in Form von Volumes auftretende Speicher existiert in der Cloud dauerhaft und unabhängig von spezifischen VMs.

Das macht auch die Wartung leichter: Weil sich Volumes von der VM auf einem physischen System abmelden und an einem anderen wieder anmelden lassen, ermöglichen sie etwa auch die Live-Migration von VMs.

Synchrone Replikation

Die großen Cloudanbieter sind bereits vor Jahren dazu übergegangen, für Ephemeral Speicher überhaupt keine Garantien mehr abzugeben. Wer Daten in persistenter Weise speichern möchte, kann das nur über Volumes tun. Bei der Frage, wie man das erledigt, kommt zumeist Ceph ins Spiel.

Denn die Lösung, deren ursprüngliches Ziel eigentlich ein Posix-kompatibles Dateisystem war, hat sich als äußerst zuverlässig erwiesen. Weil sie zudem mit Hardware von der Stange funktioniert, greifen viele Anbieter zunächst zu Ceph. Nur um bald zu merken, dass Ceph nicht die eierlegende Wollmilchsau ist, als die es so manches technische Dokument beschreibt. Denn zwar sind bei Ceph grundlegende Funktionen wie inhärente Redundanz ab Werk Teil des Gesamtpakets, zugleich aber kämpft die Lösung auch mit ernsthaften Nachteilen.

Da ist zunächst der Umstand, dass Ceph als Transportmedium meist Ethernet nutzt, das aber nicht auf Latenz hin optimiert ist. Da ist zudem das Problem, dass der Crush-Algorithmus in Ceph ebenfalls Latenz-lastig ist. Er ist aber kaum zu umgehen, denn Crush entscheidet, welche binären Objekte wo auf welcher Platte des Speichers landen.

Und nicht zuletzt ist die Replikation, die Ceph nutzt, synchron: Ein Client bekommt ein Acknowledgement für ein Objekt, das in den Speichercluster geschrieben wird, also erst, wenn exakt so viele Kopien des Objekts im Cluster vorhanden sind, wie die Replikationsregeln es von Ceph verlangen. Damit bekommt der Client nicht nur die Latenz zwischen sich und Ceph ab, sondern auch noch die zwischen den einzelnen Knoten in Ceph. Kurzum: Ceph kommt über ein paar Tausend IOPS nicht hinaus, und selbst die muss man sich mühsam erarbeiten.

Lokaler Speicher

Die Werte sind unattraktiv für Kunden, die schnellen Storage aus konventionellen Setups gewohnt sind. Oft genug begegnen Admins bei der Migration solcher Setups in eine Cloud dem Problem, dass sie mit der verfügbaren IO-Leistung der Cloud die nötige Performance nicht erreichen. Das hat oft zwar auch mit den Applikationen zu tun – aber dass ein Kunde unruhig wird, wenn plötzlich bloß noch ein Bruchteil der zuvor verfügbaren Leistung bereitsteht, ist klar.

Aus der Not heraus lassen sich viele Firmen zu einem Schritt bewegen, der ihnen später meist sehr leid tut: Sie nutzen “lokalen Speicher” für VMs. Gemeint ist nichts anderes als Ephemeral-Speicher, der auf schnellen SSDs oder NVMe-Geräten in den Compute-Knoten liegt. Weil dieser Speicher allerdings nicht repliziert wird, lassen sich so gestartete VMs auch nicht wegmigrieren – und schon gar nicht live. Was letztlich dazu führt, dass es unmöglich ist, die jeweiligen Compute-Knoten sinnvoll zu warten. De facto baut man sich auf diese Art und Weise einen Wartungsalptraum, aus dem es später kaum ein Entrinnen gibt.

Seit Jahren ist das Storage-Dilemma eines der größten Probleme bei allen Clouddienstleistern. Und bisher gab es keinen Ausweg – Netzwerkspeicher ist zu langsam, aber lokaler Speicher geht gar nicht. Eine Firma namens Excelero [1] schickt sich nun aber an, das Problem zu lösen: NVMesh soll lokalen Speicher replizieren und so das Wartungsproblem umgehen, gleichzeitig aber die Performance von lokalem Speicher bieten.

Blast from the Past

Wer in den Excelero-Prospekten stöbert, begegnet zunächst einem fast schon totgesagter Begriff: Das eigene Produkt beschreibt Excelero nämlich als “Scale-Out Server SAN”. In der Vergangenheit kam der Begriff SAN zwar als Quasi-Gattungsbeschreibung aller zentralen Shared-Network-Speicher oft zur Anwendung, doch mittlerweile ist er eher selten zu vernehmen.

Zudem gibt es einen großen Unterschied zwischen den typischen SAN-Lösungen der jüngeren Vergangenheit und der von Excelero angepeilten Lösung, denn diese versteht sich als Software-only-Ansatz, der ohne besondere Hardware auskommt (wobei das nur zum Teil stimmt, wie sich später herausstellen wird). Offiziell ist der Name des Produkts übrigens “Excelero NVMesh”

Ein großer Storage-Pool

Das primäre Ziel von Excelero NVMesh, das sich selbst als Software-defined-Storage-Lösung bezeichnet und so implizit in die Tradition von Ceph & Co. stellt, ist dies: Cluster-weit vorhandene schnelle Speicher auf Basis von Flash – also SSDs, NVMe, NVMf und anderer Geräte – sollen zu einem logischen Storage gebündelt werden, der eine einheitliche Schnittstelle bietet. Damit das funktioniert, müssen mehrere Komponenten zusammenspielen.

Da ist zunächst eine zentrale Schnittstelle für das Management der Lösung. Stilecht ist das eine REST-Schnittstelle, die sich per HTTP-Protokoll bedienen lässt, wobei der Anwender das selten persönlich tut. Stattdessen liefert Excelero nämlich auch eine hübsche grafische Oberfläche mit, die das Storagemanagement ermöglicht (Abbildung 2). Wer Excelero dagegen mit Open Stack paaren möchte, der findet dafür ein eigenes Cinder-Modul vor, doch zu diesem Thema später mehr.

Abbildung 2: Excelero kommt mit einem eigenen Dashboard daher, das alle relevanten Vitalwerte der Installation anzeigt.

Die Control Plane ist eine Node.js-Applikation, die sich obendrein auch mit vielen Instanzen gleichzeitig betreiben lässt – so stellt der Admin Hochverfügbarkeit und hinreichend gute Performance sicher. Entscheidet er sich für ein solches Szenario, stellt er dem NVMesh-Controller-Cluster jedoch wie üblich noch einen Load Balancer voran.

Im Kern setzt Excelero NVMesh auf RDMA (Remote Direct Memory Access), also auf den direkten Zugriff auf die NVM-Geräte über eine Netzwerkverbindung. Das bedeutet freilich auch, dass die Aussage “Software-only SAN” so zumindest irreführend ist. Denn für RDMA braucht man durchaus Netzwerkkarten, die mit dieser spezifischen Funktion daherkommen.

Ganz falsch ist die Excelero-Behauptung aber auch nicht, denn zumindest braucht der Anwender für die Lösung keine besondere Hardware eines einzelnen Herstellers. Wer etwa schnelle Mellanox-Netzwerkkarten einsetzt, bekommt die RDMA-Funktionalität ab Werk mitgeliefert – und genau das ist auch das Szenario, das der Hersteller vorschlägt.

Im Kernel rumgefummelt

Wer sich schon mal im Detail mit der Art und Weise beschäftigt hat, wie der Linux-Kernel mit Blockgeräten umgeht, der weiß: Außerhalb des Kernels gibt es keine Möglichkeit, an die Raw-Devices heranzukommen. Genau das muss Excelero prinzipbedingt jedoch tun. Da wundert es nicht, dass ein Teil der Lösung das NVMesh-Target-Modul ist – das zu etlichen Modulen gehört, die auf den Systemen mit NVM-Speicher in den Kernel zu laden sind.

Auf den Systemen haben die Kernelmodule mehrere Aufgaben. Zunächst suchen sie die Liste der lokalen Blockgeräte nach geeigneten Kandidaten für NVMesh ab und erkennen auch, ob im System geeignete, RDMA-fähige Netzwerkkarten verbaut sind. Sind diese identifiziert, klinkt sich das Modul direkt in den Block Layer des Kernels ein und beansprucht mit Blick auf das jeweilige Gerät Exklusivrechte.

NVMe, SATA, M2, SSDs …

Um zu verstehen, wie Excelero das macht, ist ein kleiner Ausflug in die Welt der non-volatilen Flashspeicher nötig. Auch die Excelero-Dokumentation mischt Begriffe wie NVMe, NVMf, SSDs und viele andere nämlich wild und ohne zu erklären, was im jeweiligen Kontext gemeint ist.

Damit der Kernel auf ein Speichergerät zugreifen kann, muss es wie bei jedem anderen Gerät auch mit diesem kommunizieren können. Weil Festplatten und die später aufkommenden SSDs allerdings Geräte sind, die in praktisch jedem Computer in der einen oder anderen Art vorkommen, hat man sich geeinigt, ein standardisiertes Protokoll für diese Geräte zu entwickeln. Der Kernel muss bei entsprechenden Geräten keine spezifischen Treiber mehr laden, sondern darf annehmen, dass ein standardisierter Befehlssatz unterstützt wird.

Der bekannteste Standard dieser Art war bis vor einigen Jahren AHCI. Das Protokoll fungiert als Übersetzer zwischen PCIe-Schnittstellen, über die entsprechende Storage-Geräte meist angebunden sind, und SATA-Geräten, wie sie bis vor einigen Jahren üblich waren. Sind PCIe-basierte Speichergeräte per ATA-Protokoll anzubinden, ist also immer eine Konvertierung der jeweiligen Befehle nötig, was Zeit kostet und die Latenz beim Zugriff auf die Speichergeräte erhöht.

Dieser Umstand ist die Grundlage für den Wunsch der Industrie, ein neues, speziell für PCIe gebautes Protokoll zu haben, das die Konvertierung überflüssig macht. Und genau diese Aufgabe kommt NVMe zu: Das Protokoll gibt entsprechenden Speichergeräten die Möglichkeit, direkt das PCIe-Protokoll zu verwenden, ohne den Umweg über das uralte ATA-Protokoll zu nehmen.

NVMe steht für “Non-Volatile Memory Express” und deutet schon in seinem Namen darauf hin, dass es vorrangig für den Einsatz in schnellen Flashumgebungen konzipiert ist, sich mithin an Geräte auf Basis von SSD richtet. NVMe definiert also ein Protokoll für den PCIe-basierten Zugriff auf Flashspeicher – dabei ist die genaue Bauform zunächst egal.

Mittlerweile ist NVMe allerdings nicht mehr ohne Konkurrenz: M-SATA sowie SATA Express sind Konkurrenzstandards, die – im Gegensatz zu NVMe – auch die physischen Eigenschaften etwa der Stecker definieren und unmittelbar PCI Express sprechen.

Wer die Excelero-Dokumentation liest, stolpert dort nicht nur über den Begriff NVMe, sondern auch über NVMf. NVMf (in Dokumenten taucht der Standard manchmal auch als NVMoF auf) steht für “NVM over Fabric”, erweitert den NVMe-Standard also um die Möglichkeit des Netzwerkzugriffs. Die primäre Idee hinter dieser Erweiterung war es offensichtlich, den Bau von SAN-Systemen zu ermöglichen – zu genau diesem Zweck macht sich Excelero die Funktion auch zunutze.

RDDA für direkten Zugriff

Der Vollständigkeit halber sei allerdings erwähnt, dass NVMe oder NVMf, das Excelero nutzen kann, nur einen Teil der Lösung ausmachen. Denn Excelero hat für NVMe und NVMf eine Erweiterung fabriziert, die der Hersteller auf den Namen Remote Direct Drive Access getauft hat. Auf die ist Excelero so stolz, dass die Firma in der offiziellen Dokumentation gleich mehrfach darauf hinweist, dass sie patentiert ist. Stellt sich also die Frage: Was tut RDDA (Abbildung 3) in Excelero?

Abbildung 3: Excelero klinkt sich in die Kommunikation ein und stellt eine Art virtuelles Netzwerkkabel her.

Die offensichtliche Antwort auf die Frage ist, dass RDDA für die NVMe-Geräte Remote-Funktionalität nachrüstet, die sie ab Werk nicht haben – längst nicht jedes NVMe-Gerät kann auch NVMf. RDDA ist Teil der Kernelmodule auf den Zielsystemen und kommuniziert dort unmittelbar mit RDMA-NICs, um die Pakete auf direktem Weg ans Ziel zu bringen. Und selbst bei Geräten, die NVMf können, lohnt sich laut Excelero die Verwendung ihres RDDA-Protokolls. Denn dies belaste die CPUs der jeweiligen Systeme deutlich weniger und sorge auf diesem Wege auch für geringere Latenzen, als es bei NVMf möglich wäre.

Das ist gerade bei Converged Setups sinnvoll, bei denen Storage und Compute auf denselben Servern laufen müssen – andere Storage-Lösungen genehmigen sich hier nicht selten einen ordentlichen Schluck aus der CPU-Pulle und legen damit das System erst mal lahm.

Wobei dazu noch angemerkt sei, dass Excelero bei NVMf-fähigen Geräten NVMf tatsächlich ebenfalls nutzt. In den RDDA-Modulen von Excelero verbirgt sich jedoch eine eigene NVMf-Umsetzung, sodass das im Kernel vorhandene NVMf-Framework gar nicht zum Zuge kommt und brachliegt.

Der Client macht es dem Server nach

Um den Traum vom lokalen Remote-Storage zu verwirklichen, genügt es allerdings nicht, wenn das Zielsystem mit dem schnellen Speicher funktioniert. Auch der Client muss RDMA können, es muss also ein direkter, RDMA-basierter Datenpfad zwischen Client und Server zustande kommen.

Vom Design-Standpunkt aus betrachtet, wundert es nicht, dass Excelero auf dem Client so ähnlich implementiert ist wie auch auf dem Storage: Der Excelero-Client-Treiber nistet sich nämlich ebenfalls im Kernel ein und erledigt seine Geschäfte im direkten Austausch mit RDMA-fähigen NICs. Diese Technik nennt der Hersteller Intelligent Client Block Driver, weil der Client den Blockdevice-Layer nutzt, um lokal ein Blockgerät darzustellen, das in Wirklichkeit aber im Hintergrund per RDMA und RDDA-Protokoll auf ein entferntes NVMe-Gerät zugreift.

Client- wie Server-Module lassen sich auf Wunsch übrigens auch auf ein und demselben System gleichzeitig laden und betreiben, sodass auch Excelero solche Converged Setups ermöglicht.

Die Management-Schicht: TOMA

Damit ist klar, wie der Zugriff auf NVMe-Geräte funktioniert und wie ein Client mit entfernten NVMe-Geräten kommuniziert. Unklar ist bisher aber noch, wie die Verwaltung eines solchen NVMe-basierten SAN erfolgt. Dafür liefert der Hersteller eine eigene Komponente namens TOMA mit, was als Abkürzung für “Topology Manager” steht. Der Topology Manager läuft grundsätzlich auf jedem Host, der ein Storage-Target ist, also über NVMe- oder NVMf-Geräte verfügt. Er ist aber keine Kernelspace-Komponente, sondern läuft im Userland.

Den Topology Manager kann man sich im Grunde als eine Art Clustermanager vorstellen, der Excelero-spezifische Funktionen anbietet. Zunächst geht der Anbieter ja explizit mit dem Versprechen in den Ring, dass Excelero implizite Replikation beherrscht, und in der Tat können Anwender beim Anlegen eines Storage Volume auch Replikation dazukonfigurieren. Das bedeutet aber nicht, dass alles wie von Geisterhand funktioniert, sobald ein Knoten ausfällt.

In diesem Fall wird der TOMA aktiv: Er überwacht permanent den Status aller Speichergeräte im Cluster, kümmert sich um die Replikation von Daten, falls ein Volume im Raid-1-Modus konfiguriert ist, und biegt auch den Datenpfad aus Client-Sicht um, wenn ein Target-Node mit NVM-Geräten temporär den Geist aufgegeben hat. Im Prinzip funktioniert der TOMA damit ähnlich wie die MONs in Ceph – in der Tat ordnet der Hersteller TOMA ähnliche Aufgaben zu.

Echtes Raid-1 bekommt der Admin bei Excelero übrigens natürlich nicht – die Replikation basiert auf dem Prinzip von Segmenten, die über Storage-Geräte im Cluster verteilt werden. Der Topology Manager stellt dann sicher, dass Clients die Daten bekommen, die sie suchen.

Der Zugriff aus Open Stack heraus

Wie eingangs bereits erwähnt, sind vom beschriebenen Problem des fehlenden lokalen Speichers vorrangig Anbieter großer Plattformen betroffen. Da stellt sich freilich die Frage, wie sich Excelero in Open Stack einbinden lässt, denn ohne brauchbare Open-Stack-Integration (oder Integration in eine andere Cloudumgebung) nützt das tollste NVMe-SAN ja nichts. Das ist aber auch den Excelero-Entwicklern offensichtlich bekannt, also hat der Hersteller für diesen Zweck schon mal was vorbereitet.

Open Stack verwaltet persistenten Speicher mit einer eigenen Komponente namens Cinder. Sie fungiert als Mittler zwischen den virtuellen Maschinen der Plattform und zentralen Blockspeichern. Den zerlegt Cinder in kleine Stückchen und verbindet jene anschließend auf diversen Wegen unmittelbar mit dem Compute-Knoten, auf dem die VM läuft. Dort taucht sie dann als lokales Blockgerät auf, das sich etwa per Hotplug-Funktion von KVM direkt einbinden lässt.

Eben diese Funktionalität macht Excelero sich zunutze: Für Cinder liefert der Anbieter gleich einen kompatiblen Treiber mit, der sich unmittelbar in den Dienst integrieren lässt. Wenn auf den Compute-Knoten also der Excelero-Client installiert ist und Open Stack auch mit TOMA reden kann, lassen sich Volumes per Cinder-API anlegen und verwalten. Wer sich für dieses Einsatzszenario im Detail interessiert, erhält beim Anbieter auf Wunsch auch entsprechende Case Studies.

Die richtige Hardware auswählen

Excelero rät dazu, die Software bevorzugt mit Mellanox-Hardware zu nutzen, das bezieht sich sowohl auf die Netzwerkkarten als auch auf passende Switches, die der Hersteller ebenfalls liefert. Es fällt allerdings auf, dass Excelero und Mellanox offensichtlich sehr eng miteinander kooperieren, denn Aussagen zu anderen Herstellern finden sich bei Excelero erst gar nicht. Admins sollten jedenfalls davon ausgehen, dass die Kombination aus Excelero sowie ConnectX-Karten von Mellanox mit Abstand die am besten erprobte Variante ist (siehe Abbildungen 4 und 5).

Abbildung 4: Aktuell beherrschen nur ConnectX-Karten von Mellanox RDMA oder Converged Ethernet.

Abbildung 5: High-Performance-Switches wie die Spectrum-Reihe von Mellanox sind ein zuverlässiges Excelero-Backend.

Ideal ist die Situation freilich trotzdem nicht, denn Excelero bewirbt seine Lösung ja gerade mit der Unabhängigkeit von einem bestimmten Hersteller. Das allerdings setzt echte Wahlmöglichkeiten voraus – es ist also durchaus wünschenswert, dass hier künftig mehr Vielfalt herrscht. Immerhin hat der Hersteller den ersten Schritt bereits getan und unterstützt neben RoCE, also RDMA over Converged Ethernet, jetzt auch klassisches TCP/IP als Transportmedium.

Fazit

Excelero hilft Admins ein lästiges Problem im RZ-Alltag zu lösen, das bei riesigen skalierbaren Plattformen regelmäßig auftaucht: Es ermöglicht quasi-lokalen Zugriff auf entfernten Netzwerkspeicher. Dafür kombiniert es die Vorteile von Protokollen wie NVMe und NVMf mit eigenen Erfindungen wie dem RDMA-Protokoll. Aus Admin-Sicht ergibt das Sinn: Es entsteht ein Produkt, das tatsächliche Probleme löst, und zwar technisch zuverlässig und gut. Die meisten Admins wären vermutlich bereits froh und glücklich gewesen, hätte man ihnen einen Speicher gegeben, der nur etwas schneller ist als Ceph.

Das reicht Excelero aber offensichtlich nicht aus. Die Idee, RDDA als ein – wenn auch proprietäres – Protokoll für Remote-Zugriff zu entwickeln, ist brillant, auch weil man gleich auf RDMA und so auf direkten Speicherzugriff setzt. Eine schnellere Lösung ist kaum denkbar.

Und der Hersteller weiß diesen technischen Vorsprung zu nutzen: Gegenüber einer klassischen zentralisierten Lösung wie Ceph erreicht Excelero ohne großen Aufwand ein Vielfaches der IOPS-Werte und wegen des NVMe-Speichers auch viel geringere Latenzen. Entsprechende Belege aus Beispielinstallationen liefern Excelero und Mellanox zusammen, auch in realen Setups unter Nicht-Laborbedingungen sind sie reproduzierbar.

Der Pferdefuß ist freilich, dass ein rein auf NVMe basierter Speicher wegen seiner TCO eine riesige Ceph-Installation aktuell kaum ersetzen kann. Dabei spielen die Lizenzkosten für Excelero noch gar nicht die große Rolle, denn die fangen für eine Lizenz für 16 Knoten je nach Größe und Umfang des Setups bereits bei wenigen Tausend Dollar an. Deutlich teurer kommt da die Hardware, denn Flash ist noch immer viel kostspieliger als billige Platten, die zudem über deutlich mehr Kapazität verfügen.

Selbst in einer sehr großen Installation dürfte einem Storage-Cluster auf Basis von Excelero aus diesen Gründen nur die Rolle des exklusiven Edel-Speichers zukommen, den Kunden nur für sehr spezielle Zwecke buchen und den der Anbieter seinerseits mit einem entsprechenden Preisschild versieht.

Dennoch ist festzuhalten: Wer eine entsprechende Plattform betreibt und vom eingangs beschriebenen Speed-Problem betroffen ist, der sollte den schnellen Excelero ruhig satteln.