Elegante Verlagerung

von Martin Loschwitz

Das Distributed Replicated Block Device gehört zu den ältesten Werkzeugen für die Replikation von Speicherlaufwerken per Netzwerk unter Linux. War DRBD 8 im Wesentlichen noch auf die Replikation zwischen zwei Servern beschränkt, bietet DRBD 9 die Funktion zwischen nahezu beliebig vielen Knoten und Laufwerken. In Form von LINSTOR legt der Hersteller Linbit zudem ein versatiles Managementwerkzeug vor, das sich sogar in Windows integriert. In unserem Test lieferte das Duo eine leistungsstarke und flexible Storage-Replikation.

Hochverfügbarkeit ist im Rechenzentrum ein Standardkonzept und längst existieren zahllose Mittel und Wege, um umfassendes HA auf Anwendungsebene zu erreichen. Auch vor Speicher macht das Prinzip nicht halt: NAS- und SAN-Storage bieten lokale oder standortübergreifende Replikation ebenso wie entsprechende Anwendungen. Gerade in den letzten Jahren hat Software-defined Storage (SDS) an Beliebtheit gewonnen und Object Stores wie Ceph tragen dazu erheblich bei.

Ein alter Hase in diesem Geschäft ist auch das Distributed Replicated Block Device (DRBD) des Wiener Unternehmens LINBIT. DRBD ist seit 2010 sogar offiziell Teil des Linux-Kernels und hat sich einen festen Namen in der HA-Szene gemacht. Die im Kernel enthaltene Version 8 von DRBD allerdings ist auf die Replikation zwischen zwei Laufwerken in zwei Servern begrenzt.

Die Nachfolgeversion 9 räumt mit dieser Einschränkung auf und erlaubt Replikation für beliebig viele Laufwerke zwischen beinahe beliebig vielen Systemen. Unter der Haube setzt DRBD 9 dabei auf eine Mischung aus Werkzeugen des Block Device Layers des Linux-Kernels wie LVM und eigener Technik. Damit das Konstrukt verwaltbar bleibt, liefert der Hersteller zudem LINSTOR mit. Dieses Managementwerkzeug für DRBD 9 greift beim Einrichten von Volumes unter die Arme und erlaubt dem Admin, die Übersicht zu behalten. Über LIN-STOR ist zudem die Anbindung an Dienste wie Kubernetes geregelt und auch iSCSI- oder NVMe-over-Fabric-Targets sind leicht aufzusetzen.

Weil von DRBD mittlerweile eine Version für Windows vorliegt und LINSTOR in Java verfasst und damit grundsätzlich auf Linux und Windows lauffähig ist, lassen sich laut Hersteller sogar Windows-Systeme mit DRBD versorgen und mit Linux-Maschinen querverbinden – also eine Art Replikation über die Grenzen von Betriebssystemen hinweg. Grund genug, genauer hinzusehen und das Produkt auch in den Vergleich mit Werkzeugen wie Ceph zu schicken.

HA mit geringer Latenz schnell aufgesetzt

Wer sich mit DRBD befasst, will vor allem Datenreplikation auf Systemebene. Der auf diese Weise entstehende Speicher kommt üblicherweise auf Systemen im Rahmen eines HA-Setups zum Einsatz, also etwa als Ressource, die ein Clustermanager verwaltet. In der Vergangenheit fiel diese Aufgabe regelmäßig dem Linux-HA-Stack mit Pacemaker zu, mittlerweile stellt LINBIT aber auch einen eigenen, auf DRBD zugeschnittenen Clustermanager namens "DRBD Reactor" als Teil von LINSTOR zur Verfügung. So oder so, die zu bewältigenden Aufgaben sind dieselben: Damit eine DRBD-Ressource auf einem System im Schreibzugriff zum Einsatz kommen kann, muss sie im "Primary"-Modus sein. Daran hat sich zwischen DRBD 8 und 9 nichts grundlegend geändert.

Die LINSTOR-Installation im Gespann mit DRBD 9 geht ausgesprochen leicht von der Hand. Wir hatten dabei die Wahl zwischen einem Community-Repository des Herstellers, auf das der Zugriff ohne Kosten möglich ist. Alternativ gibt es eine kommerziell unterstützte Version in einem eigenen Verzeichnis. Grundsätzlich unterscheiden sich die beiden Varianten nicht voneinander, die kommerzielle Version ist im Regelfall aber etwas aktueller. LINSTOR besteht aus mehreren Komponenten und basiert im Prinzip auf einer Server-Agenten-Architektur. DRBD und LINSTOR sind grundsätzlich zwei separate Komponenten, kommen aber üblicherweise zusammen zum Einsatz. Der Administrator installiert also sowohl die für DRBD 9 nötigen Kernel-Module als auch die LINSTOR-Komponenten auf seinen Systemen.

Technisch unterscheidet DRBD sich bis heute in einem zentralen Punkt von vielen vergleichbaren Tools wie etwa Ceph. Denn DRBD klinkt sich im Linux-Kernel unmittelbar in den Block Device Layer ein und tritt dort als eine Art virtueller Datenträger auf. Für Anwendungen sieht es mithin aus wie jedes andere Speicherlaufwerk. Hinter den Kulissen leitet DRBD Daten, die es empfangen hat, einerseits auf den lokalen Datenträger im Hintergrund weiter, kopiert sie andererseits aber auch in den Netzwerkstack und verschickt sie an den Cluster-Partner für eine DRBD-Ressource. Hier kommen also keine komplexen Algorithmen zum Einsatz, die das Berechnen von Hash-Werten oder ähnliche Kalkulationen notwendig machen.

DRBD funktioniert im Innern also fundamental anders als beispielsweise RADOS in Ceph, das fortwährend CRUSH-Berechnungen zu bewältigen hat (wobei CRUSH ein ausgesprochen langsamer Algorithmus ist). Das macht sich deutlich bemerkbar, denn anders als bei Ceph, wo die CRUSH-Replikation erhebliche Latenz im Speicherpfad verursacht, erzeugt DRBD selbst bei synchroner Replikation nur wenig Latenz. Anders als die meisten Objektspeicher beherrscht DRBD zudem asynchrone Replikation (Protokoll A), sodass auch standortübergreifende Replikation deutlich einfacher zu realisieren ist als bei den meisten Objektspeichern.

Unbegrenzte Replikation

Nachdem im Test DRBD und LINSTOR auf allen beteiligten Systemen zur Verfügung standen, konnten wir HA-Laufwerke mit Replikation konfigurieren. Die entsprechende Funktionsweise ist dabei bemerkenswert: Grundsätzlich stellt der Administrator LINSTOR auf jedem beteiligten System physische Laufwerke, also SSDs oder Festplatten, zur Verfügung. Diese packt LINSTOR in eine Volume Group von LVM. Legt der Administrator dann eine gespiegelte Ressource an, erstellt LINSTOR in der Volume Group ein Logical Volume (LV) und richtet für dieses die Replikation ein. Der Redundanzlevel ließ sich dabei nach Belieben festlegen, es wäre also auch möglich, drei- fache Replikation für dieselbe Ressource zu definieren und den gesamten Datensatz einer DRBD-Ressource so auf drei Systemen zu halten.

Anders als bei Objektspeichern wie Ceph empfiehlt es sich bei DRBD entsprechend, ein RAID als Unterbau zu verwenden, um Problemen durch Ausfälle lokaler Speicherlaufwerke entgegenzutreten – auch wenn das die Nettokapazität weiter reduziert. Auf diese Weise erreicht DRBD "nahtlose Skalierbarkeit". Damit ist es möglich, einen laufenden DRBD9-Cluster um beliebig viele Systeme mit zusätzlichen Festplatten zu erweitern und zusätzliche Volumes repliziert so lange anzulegen, wie auf mindestens zwei Systemen des Clusters noch genügend lokaler Platz vorhanden ist.

Aus diesem Prinzip ergibt sich allerdings auch die Logik für die Existenz von LIN-STOR überhaupt. Denn weil das vorgegebene System zwangsläufig erstellte Ressourcen wie einen Flickenteppich über alle Knoten der Installation verteilt, wäre das Management von Volumes ohne eine zentrale Instanz sehr mühsam. In Form von LINSTOR stillt LINBIT insofern den Bedarf, den es durch die Architektur von DRBD 9 selbst geschaffen hat.

In Summe leistet DRBD 9 sich in Sachen Installation und Setup jedenfalls keine groben Schnitzer. Wer das Produkt noch von DRBD 8 her kennt, muss sich an manchen Stellen zwar umgewöhnen. Denn dank LINSTOR ist das Herumhantieren auf der Shell mit Werkzeugen wie "drbdadm" ebenso passé wie das Auslesen von "/proc/drbd", um einen detaillierten Überblick über die lokalen Ressourcen zu erhalten. Hat sich der IT-Verantwortliche dies eingeprägt, lässt DRBD 9 sich hinsichtlich seiner basalen Funktionen leicht und zuverlässig nutzen. Gerade vor dem Hintergrund, dass die Werkzeuge für die Verwaltung von DRBD 9 nicht viele Ressourcen auf den laufenden Systemen benötigen, erleichtert dies die Verwaltung. Im direkten Vergleich mit anderen Ansätzen wie Ceph oder GlusterFS punktet DRBD zudem durch seine einfache Architektur.

Speicher einfach über NVMe-oF, NFS und iSCSI anbinden

Der schönste Speicher ist freilich nichts wert, wenn ihn die Zielanwendungen nicht nutzen können. Im RZ geschieht der Konsum von Storage-Devices dabei im Regelfall entweder als Block-Device beispielsweise für virtuelle Instanzen oder in Form eines geteilten Dateisystems, etwa auf Samba- oder NFS-Basis. Anders als die Konkurrenz bietet DRBD kein natives Dateisystem an, das liegt aber auch nicht in seinem Fokus.

In LINSTOR denkt LINBIT aber trotzdem an die Admins und implementiert mehrere Funktionen, um sinnvoll Zugriff auf DRBD-Geräte aus der Ferne zu ermöglichen. Die Funktionen richten sich erkennbar an jene Administratoren, die DRBD nicht hyperkonvergent nutzen möchten, sondern etwa in Form eines zentralen Speichers für Virtualisierungshosts. Damit kommt DRBD auch als Alternative für skalierbare Speicher wie Ceph in VMware-Umgebungen infrage.

LINSTOR bietet dabei mehrere Optionen: Mittels weniger Befehle auf der Kommandozeile richteten wir im Test wahlweise ein iSCSI-Target, ein Target für NVMe-over-Fabric oder einen NFS-Server ein. Je nach genutzter Technologie kann es notwendig sein, komplementär zu den Komponenten des DRBD-Stacks Werkzeuge wie "targetcli" für iSCSI oder "nvmeofcli" für NVMe zu installieren. Auch hier spielt der DRBD Reactor eine wichtige Rolle: Er werkelt als Teil von LINSTOR im Hintergrund und sorgt beispielsweise dafür, dass die DRBD-Ressourcen auf den Systemen im Zustand "Primär" laufen, auf denen der schreibende Zugriff auf sie erfolgen soll.

Das funktioniert in Summe ausgesprochen gut. Ein einmal per LINSTOR angelegtes iSCSI-Laufwerk konnten wir ebenso gut an VMware anbinden wie eines auf Basis von NVMe-oF. Leichtere Komforteinschränkungen gab es hier lediglich im direkten Vergleich mit einem nativ in die Virtualisierung integrierten Speicher wie VMwares vSAN. Denn anders als bei dieser kommt dem Administrator die Aufgabe zu, die in der Virtualisierung zu nutzenden Speicherlaufwerke händisch anzulegen und dann an VMware oder eine andere Umgebung anzuschließen. Ceph beispielsweise hat exakt dasselbe Problem, ebenso übrigens wie die meisten SAN- oder NAS-Produkte.

Anders als sowohl vSAN als auch ein typisches Gerät von Dell-EMC oder NetApp kommt DRBD hingegen mit einem erträglichen Preisschild daher. Weniger Komfort bedeutet also ein weniger tiefes Loch in der eigenen Tasche. Vor dem Hintergrund, dass das Setup von DRBD 9 mittels LINSTOR gut zu bewältigen ist, ist das ein fairer Deal. Das gilt umso mehr, da die Dokumentation zu DRBD in Form des "DRBD User Guides" seit vielen Jahren als ein gutes Beispiel dafür galt, wie solche Anleitungen aussehen sollten. Wer also mit LINSTOR oder DRBD in Probleme läuft, findet hier detaillierte Anweisungen dazu, diese in den Griff zu bekommen.

Umfassende Kubernetes-Unterstützung

Nicht unerwähnt bleiben darf zudem die Integration in externe Dienste wie Kubernetes oder OpenStack. Auch bei diesen will LINBIT freilich mitspielen, denn gerade Kubernetes gilt noch immer als absoluter Hype. Dabei brauchen auch Kubernetes-Setups persistenten, replizierten Speicher. LINBIT hat hier in den vergangenen Monaten mit DRBD 9.2 noch einmal erheblich nachgelegt. Bereits zuvor konnte LINSTOR eine Anbindung an Kubernetes so konfigurieren, dass dort, wo Container laufen, der persistente Speicher auch tatsächlich zur Verfügung steht. Dazu bietet der Hersteller einen eigenen Storage-Provisioner für Kubernetes an, der in der Lage ist, auf der Kubernetes-Ebene sowohl Persistent Volumes (PVC) als auch Persistent Volume Claims (PVCs) dynamisch anzulegen.

Neu hinzugekommen ist in DRBD 9.2 noch die Möglichkeit, die DRBD-Komponente für Kubernetes in eigene Namespaces in spezifische K8s-Namespaces auszurollen, um eine bessere Trennung zu erreichen. Wer stattdessen eher auf OpenStack setzt, bekommt auch hier ein Plug-in für den OpenStack-Dienst Cinder, das im Hintergrund mit LINSTOR kommuniziert und auf Zuruf Volumes einrichtet. Die Anbindung an externe Dienste in DRBD 9 präsentiert sich mithin in hervorragendem Zustand.

Komfortables GUI erlaubt Abschied vom CLI

Anders als in früheren DRBD-Versionen nutzten wir die DRBD-Kommandozeilenwerkzeuge selbst beim Einsatz von DRBD 9 und LINSTOR nur selten. Diese Aufgabe übernimmt LINSTOR über zwei Schnittstellen. Einerseits die Kommandozeile und andererseits ein noch recht neues GUI. Das Thema grafischer Frontends ist für die Wiener dabei kein neues, in Form der "DRBD Management Console" hantierte die Firma schon in den 2010er-Jahren mit einer in Java verfassten Oberfläche, die im Hintergrund DRBD und Pacemaker einrichten konnte. Mit dieser hat das LINSTOR-GUI allerdings nicht viel gemein. Denn wie es sich für ein Produkt auf der Höhe der Zeit geziemt, bietet LINSTOR selbst eine ReST-API, über die etwa die CLI-Werkzeuge mit dem Dienst kommunizieren und die auch im LINSTOR-GUI zum Einsatz kommt.

Trotz seines relativ geringen Alters ist das LINSTOR-GUI umfassend und funktional. Es erlaubte uns das Anlegen von DRBD-Ressourcen ebenso wie das Bearbeiten einzelner Parameter der DRBD-Konfiguration. Obendrein lieferte es eine Übersicht über die wichtigsten Metrikdaten, die mit einer DRBD-Installation zusammenhängen, etwa der aktuellen Belegung der verschiedenen Ressourcen oder der Laufwerke in den einzelnen Knoten. Und auch die Knoten selbst konfigurierten wir per GUI.

Performance des Systems gut steuerbar

Eine zentrale Frage bei Speicher ist stets jene nach der Performance. Das betrifft sowohl die Bandbreite als auch die Latenz. Nutzen alle zu einer LINSTOR gehörenden Plattform flotte Controller mit lokalem Cache oder gar Flash-Laufwerke, ist die insgesamt in DRBD zu erreichende Bandbreite entweder die der lokalen RAID-Laufwerke oder jene des Netzes, abhängig davon, welches weniger Bandbreite bietet. Geschwindigkeiten im GBit/s-Bereich sind jedenfalls mit moderner Hardware leicht zu erreichen.

Etwas anders liegen die Dinge in Sachen Latenz, denn hier spielt vor allem die Zeit eine Rolle, die bei synchroner Replikation ein Paket von System A zu System B benötigt. Nach unten hin ist die Latenz also mindestens so hoch wie der Netzwerk-Roundtrip. DRBD 9 spielt hier jedoch seine relativ simple Architektur in die Karten. Gerade weil nur stupide Pakete von A nach B kopiert werden, entsteht darüber hinaus kaum Latenz im Storage-Pfad. Für Setups wie Datenbanken, die geringstmögliche Latenzen brauchen, eignet DRBD 9 sich folglich besonders.

Leider lässt sich die Latenz nicht annähernd so gut tunen wie die Bandbreite. Eine zentrale Rolle spielen deshalb auch die genutzten Netzwerkkomponenten. Ethernet beispielsweise kommt mit einer relativ hohen impliziten Latenz daher. Für Setups, in denen tatsächlich Bestwerte nötig sind, empfehlen sich andere Technologien wie Infiniband, das DRBD 9 unterstützt. Weitere Optimierungen verspricht der Einsatz fortschrittlicher Technologien wie RDMA, idealerweise im Gespann mit flotten Transport-Layern wie eben Infiniband. Das geht dann zwar relativ schnell ins Geld, wer sich ein solches Konstrukt baut, verweist gerade in Sachen Latenz Alternativen wie Ceph jedoch auf die Plätze.

Darüber hinaus ließ sich DRBD insgesamt mittels einiger Sysctl-Parameter unter Linux besser tunen als etwa Ceph. Vergrößerten wir beispielsweise die TCP/IP-Buffer des Netzwerk-Stacks des Linux-Kernels, führte dies bereits zu merklichen Verbesserungen. Ebenfalls half es, für den Traffic von DRBD-Verbindungen eigene Netzwerk-Links zu nutzen und für diese eine MTU von 9000 zu aktivieren (Jumbo Frames). Auch an dieser Stelle sei nochmals auf den DRBD User Guide verwiesen, der viele alltagstaugliche Tuning-Maßnahmen verständlich aufbereitet darlegt.

Auch Windows repliziert tadellos

Eine Besonderheit von DRBD und LINSTOR ist, dass die Software auch für Win-dows zur Verfügung steht. Damit ist das Gespann eines der wenigen Angebote überhaupt, das die Replikation über die Grenzen eines Betriebssystems hinweg unterstützt. Technisch ist WinDRBD dabei durchaus interessant und nutzt denselben Code wie DRBD für Linux. Für die Installation in Windows kommt der Treiber allerdings mit einer Emulationsschicht daher, die Systemaufrufe von Linux auf Windows übersetzt und vice versa. Unterschiede im Protokoll gibt es entsprechend nicht, Administratoren sollten aber darauf achten, die gleichen Versionen von DRBD und WinDRBD auf allen betroffenen Systemen zu verwenden.

Wie beschrieben steht zudem auch LINSTOR für Windows zur Verfügung. Damit war es uns möglich, DRBD-Ressourcen zwischen Windows-Systemen und Linux-Systemen sogar per LINSTOR-GUI einzurichten, ohne uns um die Eigenheiten der beiden Betriebssysteme größere Gedanken zu machen. Das ist in dieser Form einzigartig. Zudem schafft LINBIT auf diese Weise eine Alternative zu anderen kommerziellen Replikationsprodukten für Windows, wie sie in proprietärer HA-Software oft enthalten sind – und dies auf Grundlage quelloffener Software.

Fazit

LINBIT legt in Form von DRBD 9 und LINSTOR ein überzeugendes Replikationswerkzeug insbesondere für Umgebungen vor, die hohen Performanceanforderungen unterliegen. Zwar können auch die Wiener von LINBIT die Physik nicht überlisten und bei synchroner Replikation erhält ein Schreibvorgang in DRBD zumindest die Latenz des Netzwerk-Roundtrips als "Performancestrafe" obendrauf. DRBD selbst jedoch erzeugt im Gegensatz zu vielen anderen verteilten Speicherprodukten kaum eigene zusätzliche Latenz. Kombinieren Administratoren DRBD mit einem RAID auf Basis von NVMe-Flash-Laufwerken oder zumindest RAID-Laufwerken mit Cache auf Grundlage von Flash-Speicher, sind deutlich bessere Performancewerte als etwa bei Ceph machbar.

Dass der Hersteller mit LINSTOR ein eigenes Managementwerkzeug zur Verfügung stellt, ist folgerichtig und für den Wert des Produkts erheblich. Denn ohne LIN-STOR wäre es sehr mühsam, Buch über die angelegten Ressourcen und ihre Verwendung im Cluster zu führen. Dank LINSTOR ist DRBD 9 jedoch vielseitig und kann Setups mit iSCSI oder NVMe-over-Fabric weitgehend automatisch anlegen und über den Umweg des DRBD Reactor auch Metrikdaten für Prometheus zur Verfügung stellen. So wird aus einem eigentlich recht simplen Speicher ein Vielseitigkeitsmeister. Wer verteilte Replikation benötigt, sollte DRBD 9 und LINSTOR als Kandidat auf der Evaluationsliste haben und ruhig mit der für die Community kostenfrei erhältlichen Version experimentieren. Das geht auch in VMs problemlos, auch deshalb, weil DRBD keine hohen Anforderungen an CPU und RAM stellt.

Produkt	Verteilte, replizierte Block-Storage-Software samt Managementumgebung.
Hersteller	LINBIT https://www.linbit.com
Preis	Die Community-Edition ist kostenlos, die kommerzielle Variante mit Support ist ab rund 600 Euro pro Cluster-Knoten zu haben.
Systemvoraussetzungen	Zwei Server mit Netzwerkverbindung und mindestens einem (logischen) Speicherlaufwerk, das DRBD nutzen kann. 32 MByte RAM pro angebotenem TByte RAM pro System sowie vier CPU-Kerne (für DRBD und Systemdienste).
Technische Daten	https://www.it-administrator.de/downloads/datenblaetter/

HA und Replikation	7
Erweiterte Speicheranbindung	8
Verwaltung per GUI	7
Performance	8
Windows-Integration	9
Die Details unserer Testmethodik finden Sie unter https://www.it-administrator.de/testmethodik/