DRBD 9 ist deutlich komplexer als seine Vorgänger. Nun hat dessen Entwickler Linbit mit LINSTOR ein neues Verwaltungswerkzeug eingeführt.
Zweifellos ist das Design aktueller Storage-Systeme eines der deutlichsten Anzeichen dafür, dass sich die Zeiten geändert haben. Noch vor zehn Jahren hängte man sich etwa für einen Webserver-Cluster ein kühlschrankgroßes Gerät ins Rack, bis unter den Deckel vollgestopft mit Festplatten. In den Setups der vergangenen Jahre sucht man solche Monolithen hingegen oft vergeblich: Heute greift der Administrator eher zur Hardware von der Stange und kombiniert sie mit einer Storage-Software. Diese verwandelt die Hardware dann etwa in einen Objektspeicher.
Neben der Robustheit und der impliziten HA-Funktion (High Availability) haben solche Setups obendrein den unschlagbaren Vorteil, dass sie nahtlos in die Breite wachsen können. Der Shootingstar der Cloud-Szene ist zweifelsohne Ceph: Der mittlerweile zu Red Hat gehörende Objektspeicher hat im Fahrwasser der Cloud allerorten große Beliebtheit erreicht.
Für die Entwickler von Linbit in Wien muss dieser Umstand fast schon wie Hohn wirken. Denn die Idee, teure SAN-Geräte durch Commodity-Hardware zu ersetzen und sie mit Software zu kombinieren, die die SAN-Funktionen übernimmt, hatte man dort bereits Anfang der 2000er-Jahre. Über Jahre hinweg hatte sich das von den Wienern entwickelte DRBD einen Namen gerade im HA-Umfeld gemacht.
Nachdem die Entwickler 2015 mit DRBD9 eine komplett modernisierte Version freigeben konnten, haben sie 2018 mit LINSTOR ein vollständig neu geschriebenes Verwaltungswerkzeug für DRBD9 vorgestellt.
Schöpfung mit Hindernissen
Die Innenansicht: Wie hier am Beispiel eines Zwei-Knoten-Clusters gezeigt, funktioniert DRBD bis heute – auch wenn es mittlerweile mehr als zwei Knoten pro Ressource unterstützt (Abb. 1).
Dank der Blockgeräte-Infrastruktur des Linux-Kernels konnte DRBD bereits vor der Einführung von SDS (Software-defined Storage) Daten von einer Platte eines Systems auf eine Platte eines anderen Systems spiegeln (Abbildung1). Alles, was es dafür brauchte, war ein laufendes Linux-System mit Standardkernel sowie die entsprechenden Festplatten. Installationen auf DRBD-Basis waren regelmäßig wesentlich preiswerter als der klassische SAN-Storage.
Dass DRBD nur innerhalb des Speicherplatzes erweiterbar war, den einer der beiden Clusterpartner höchstens aufnehmen konnte, spielte keine große Rolle. Denn konventionelle Setups werden bekanntlich einmal geplant und dann gebaut wie veranschlagt – ohne große Erweiterungsmöglichkeiten.
Zu Beginn des Cloud-Hypes hätte man bei Linbit allerdings gut daran getan, die Zeichen der Zeit zu erkennen und DRBD skalierbarer zu gestalten. Pläne dafür existierten seit Jahren. Schon 2010 stellte man ein neues DRBD-Design vor, das mehr als zwei Knoten erlaubte. In Form von echtem Code schlugen sich die Ankündigungen aus Wien allerdings selten nieder. Zwischenzeitlich galt DRBD9 gar als Vaporware – Software, die, obwohl großspurig angekündigt, wohl nie das Licht der Welt erblicken würde. Als DRBD9 es dann doch endlich tat, werkelten bei großen Setups Ceph & Co. bereits seit Längerem vor sich hin [1].
Mittlerweile ist DRBD9 entsprechend gereift, sodass Administratoren es wagen können, der Software ihre Daten anzuvertrauen, die weit entfernt ist von einem schlechten Ersatz für Ceph oder die anderen Storage-Systeme aus dem Cloud-Dunstkreis. Tatsächlich bietet DRBD9 Funktionen, die bei Ceph & Co. fehlen und sich dort prinzipbedingt nicht ohne Weiteres nachrüsten lassen (siehe Kasten „Die Stärken von DRBD“).
