handen 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 Tau-
send 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 konventionel-
len Setups gewohnt sind. Oft genug be-
gegnen 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 er-
reichen. 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 Fir-
men 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-Ge-
rä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 Cloud-
dienstleistern. Und bisher gab es keinen
Ausweg – Netzwerkspeicher ist zu lang-
sam, 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 lo-
kalem 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 Vergangen-
heit kam der Be-
griff SAN zwar als
Quasi-Gattungsbe-
schreibung aller
zentralen Shared-
Network-Speicher
oft zur Anwen-
dung, doch mitt-
lerweile ist er eher
selten zu verneh-
men.
Zudem gibt es ei-
nen großen Unter-
schied zwischen
den typischen
SAN-Lösungen der
jüngeren Vergan-
genheit und der
von Excelero angepeilten Lösung, denn
diese versteht sich als Software-only-An-
satz, der ohne besondere Hardware aus-
kommt (wobei das nur zum Teil stimmt,
wie sich später herausstellen wird). Offi-
ziell 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-Sto-
rage-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 Schnitt-
stelle bietet. Damit das funktioniert,
müssen mehrere Komponenten zusam-
menspielen.
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.
Die Control Plane ist eine Node.js-Appli-
kation, die sich obendrein auch mit vie-
len Instanzen gleichzeitig betreiben lässt- so stellt der Admin Hochverfügbarkeit
und hinreichend gute Performance si-
cher. Entscheidet er sich für ein solches
Szenario, stellt er dem NVMesh-Control-
ler-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 Netzwerkverbin-
dung. Das bedeutet freilich auch, dass
die Aussage „Software-only SAN“ so zu-
mindest irreführend ist. Denn für RDMA
braucht man durchaus Netzwerkkarten,
die mit dieser spezifischen Funktion da-
herkommen.
Ganz falsch ist die Excelero-Behauptung
aber auch nicht, denn zumindest braucht
der Anwender für die Lösung keine be-
sondere Hardware eines einzelnen Her-
stellers. Wer etwa schnelle Mellanox-
Netzwerkkarten einsetzt, bekommt die
RDMA-Funktionalität ab Werk mitgelie-
fert – und genau das ist auch das Szena-
rio, 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 Exce-
lero prinzipbedingt jedoch tun. Da wun-
dert es nicht, dass ein Teil der Lösung
das NVMesh-Target-Modul ist – das zu75http://www.linux-magazin.deSysadminExceleroAbbildung 1: Ceph ermöglicht massiv skalierbaren Speicher für Open Stack sowie
andere Lösungen, aber schnell ist der Ansatz nicht.© IBM