© Dmitry Kalinovsky, 123RF

DRBD ist zwar ein zuverlässiges Werkzeug für die Replikation von Daten, doch gefeit vor Problemen ist es nicht. Das Linux-Magazin zeigt, wo und wie der Admin nachschaut, falls mal etwas klemmt.

Beschäftigte man sich in den vergangenen Jahren mit Replikation, standen die skalierbaren Lösungen schnell im Mittelpunkt – Ceph, Gluster-FS und wie sie alle heißen. In vielen Setups werkelt jedoch nach wie vor DRBD. Die von der Wiener Firma Linbit erfundene Replikationslösung ist zwar nicht ganz so skalierbar wie Ceph & Co., erledigt aber seit über zehn Jahren in produktiven Setups zuverlässig ihre Arbeit und hat eine große Fangemeinde. Wer heute im Rahmen eines kleineren Setups eine Replikation braucht und nicht zu den klassischen NAS-Systemen greifen möchte, der findet in DRBD einen zuverlässigen Partner.

Allerdings: Auch DRBD ist nicht fehlerfrei. Wie jede Software kommt DRBD aus Menschenhand und greift gelegentlich daneben. Gerade bei DRBD 8 werden diese Fälle zwar weniger – schließlich hat diese DRBD-Version bereits ein paar Jährchen auf dem Buckel und ist entsprechend ausgereift. Doch selbst so gut abgehangene Software macht im Alltag gelegentlich Schwierigkeiten.

Die gute Nachricht für Admins: Die meisten Fehlerszenarien bei DRBD sind gut beschrieben und bekannt. Geht also mal etwas schief, lässt sich die Wurzel des Übels in der Regel sehr schnell identifizieren und das Problem lösen.

Dieser Artikel listet die gängigen Fehlerszenarien in DRBD auf und beschreibt, wie der Admin einem Problem auf die Schliche kommt und wie er die Diagnose absichert. Dabei geht es genauso um die Software, die üblicherweise im Gespann mit DRBD zum Einsatz kommt – denn längst nicht in allen Fällen ist DRBD ganz alleine Schuld an den Problemen.

DRBD 8 und DRBD 9

Bevor sich dieser Artikel ins Getümmel der Fehlermeldungen und Probleme stürzt, ist ein kurzer Ausflug in die DRBD-Theorie notwendig. Denn am Markt existieren in Form von DRBD 8 und DRBD 9 zwei Versionen, die sich stark voneinander unterscheiden. Und so gern die Firma Linbit den Übergang zu DRBD 9 erzwingen möchte – die ältere Variante der Lösung erfreut sich bis heute großer Beliebtheit.

Doch wo liegen die Unterschiede? Für die Frage nach den passenden Debugging-Ansätzen ist die Antwort von großer Bedeutung, denn DRBD 9 ist nicht nur viel potenter als DRBD 8, sondern in der Konsequenz auch viel komplexer.

DRBD 8 folgt einem simplen Mantra: Zwei Systeme bilden einen Cluster und nutzen DRBD, um Daten zwischen den in ihnen verbauten Festplatten zu replizieren. Die Replikationslösung klinkt sich dafür in die Blockgeräte-Schicht des Kernels und liegt zwischen physischem Speichergerät und dem Frontend zur Nutzerseite, mit dem der Anwender unmittelbar in Kontakt kommt. Eingehende Pakete kopiert DRBD einfach zum DRBD-Modul auf dem anderen Clusterknoten (Abbildung 1), das sich um das Schreiben der Daten auf die dortige Festplatte kümmert.

Abbildung 1: DRBD hebt sich von Ceph & Co. dadurch ab, dass es eine recht simple Architektur darstellt, die wenig fehleranfällig ist. Quelle: LINBIT

Damit das wie gewünscht funktioniert, verschafft DRBD sich auch Zugriff auf den Netzwerkteil des Linux-Kernels auf beiden Systemen. Vor einigen Jahren haben die Entwickler von Linbit diesen Teil sogar radikal umgebaut und in eine Art Schnittstelle verwandelt, die je nach Bedarf verschiedene, nachladbare Protokolle sprechen kann (Abbildung 2).

Abbildung 2: Aktuelle DRBD-Versionen trennen im Kernel zwischen Replikation und Netzwerktransport – deshalb gibt es zwei Module.

In DRBD 9 ist vieles ähnlich wie in DRBD 8 – und doch ganz anders: In DRBD 9 haben die Entwickler endlich das Versprechen erfüllt, DRBD zur geordneten Replikation über mehr als zwei Knoten zu nutzen. Drei Knoten waren zwar auch in DRBD 8 schon möglich, aber nur mit einem schlimmen Hack: Dass sich Geräte innerhalb der Blockgeräte-Schicht des Linux-Kernels quasi beliebig stapeln lassen, machten die Entwickler sich nämlich zunutze und stapelten eine DRBD-Ressource auf eine andere.

Der Performance der Lösung war das allerdings nicht zugänglich, und sonderlich wohlgelitten war diese Lösung bei Linbit im Grunde auch nie. In DRBD 9 ist sie Geschichte: Für ein Laufwerk – oder im DRBD-Sprech – eine Ressource, lassen sich in DRBD 9 mehrere Peers definieren, die an der Replikation teilnehmen.

Komplexes Userland

Entsprechend bietet DRBD 9 eine Möglichkeit, den Speicher fast nahtlos in die Breite zu skalieren: Indem der Admin neue Knoten mit neuen Festplatten in die Verbindung aufnimmt, vergrößert er die Netto-Speicherkapazität. Aus dieser lassen sich dann auf jenen Systemen, auf denen noch Platz vorhanden ist, DRBD-Laufwerke gezielt anlegen.

Es wäre aber sehr unkomfortabel, darüber händisch Buch zu führen, weshalb die Entwickler ihren Nutzern Werkzeuge an die Hand geben, die diese Aufgabe erledigen. Anfangs war »drbdmanage« das Tool der Wahl, das im Linux-Magazin seinerzeit auch einen Auftritt in einer Vorstellung von DRBD 9 hatte [1].

Drbdmanage haben die Entwickler inzwischen aber schon wieder zugunsten einer anderen Lösung in den Ruhestand geschickt – Linstor ist nun das empfohlene Werkzeug, um DRBD 9 zu verwalten (Abbildung 3). Allein: Linstor ist wie sein Vorgänger auch ein komplexes Gebilde auf Basis einer Server-Client-Architektur, sodass es zur in DRBD 9 ohnehin schon erhöhten Komplexität weiter beiträgt (Abbildung 4).

Abbildung 3: Linstor heißt das neue Management-Werkzeug von Linbit, das komplett in Go geschrieben ist, seinem Vorgänger … Quelle: LINBIT

Abbildung 4: … »drbdmanage« in seiner Architektur aber stark ähnelt. Quelle: LINBIT

Beschäftigt man sich mit dem Thema DRBD-Debugging, ist es deshalb unbedingt wichtig, sich zunächst der DRBD-Version zu vergewissern, mit der man es zu tun hat. Denn davon abhängig kann ein bestimmtes DRBD-Verhalten auf multiple Probleme hindeuten – eine Analyse des Gesamtzusammenhangs ist daher unabdingbar.

Die gute Nachricht allerdings ist: Solange der Admin es tatsächlich mit jenem Teil von DRBD zu tun hat, der im Linux-Kernel verankert ist, unterscheiden sich die Versionen von DRBD gar nicht so dramatisch voneinander – lediglich der Weg, über den der Admin an Infos kommt, hat sich in der jüngeren Vergangenheit entscheidend geändert.

Herausfinden, was ist

In welche Probleme laufen Admins bei DRBD üblicherweise? Das klassische Szenario ist, dass die Replikation zwischen zwei Knoten nicht mehr wie gewünscht funktioniert. Um dieses Problem zu diagnostizieren, muss der Admin jedoch wissen, wo er nachschauen muss – es empfiehlt sich daher dringend, die richtigen Pfade im Kopf zu haben.

Grundsätzlich gilt: DRBD 8 gibt auf einem System über »/proc/drbd« detailliert Auskunft über alle im System vorhandenen Ressourcen und deren jeweiligen Zustand. Woran erkennt der Admin hier aber, dass etwas nicht passt?

Pro aktiver Ressource sind in »/proc/drbd« zwei Zeilen zu finden. Die erste Zeile enthält an erster Stelle die Nummer der DRBD-Ressource. Steht hier »0«, heißt die zugehörende Ressource »/dev/drbd0«. Danach folgt hinter dem Schlüsselwort »cs« der Connection State, der bei DRBD 8 üblicherweise » Connected« oder »WFConnection« ist. Hinter »ro« kommt außerdem die Rolle (Role), die die DRBD-Ressource auf dem jeweiligen System hat, das heißt wahlweise Primary oder Secondary. Hinter »ds« verbirgt sich dann schließlich der »Disk State«, der Auskunft über den Zustand der Daten auf dem Datenträger gibt.

Der Normalzustand einer DRBD-Ressource beim Connection State ist »Connected« auf beiden Cluster-Seiten, bei der Rolle »Primary« beziehungsweise »Secondary« sowie »UpToDate« beim »Disk State«. Ist jener Zustand gegeben, funktioniert die DRBD-Ressource, wie sie soll. Gibt es hier aber Abweichungen, lohnt sich ein genauerer Blick.

Stand-alone ist böse

Taucht beim Connection State etwa »Stand-Alone« auf, ist größte Vorsicht geboten, denn in diesen Modus wechselt DRBD 8 nur, wenn es vom Partner im Cluster widersprüchliche Informationen über den Zustand der Festplatte dort geliefert bekommt. Es geht dann automatisch in den Stand-alone-Modus über, was aber nicht immer hilft Schaden abzuwenden. Im blödesten Fall präsentiert sich DRBD auf beiden Knoten im Stand-alone-Modus mit einem Disk-Status von »UpToDate« und der Rolle »Primary« – das ist dann ein waschechter Split-Brain, den der Admin anhand der DRBD-Dokumentation [2] lösen muss.

Wähnt sich hingegen nur ein Knoten in der »Primary«-Rolle, ist die Situation oft nicht so schlimm. Hier ist das Problem dann meist, dass aufgrund von Fehlern der Netzwerkverbindung die beiden DRBD-Ressourcen einander nicht mehr sehen. Die Ursache ist in der Regel aber kein Problem in DRBD, sondern eher eines in der Netzwerkkonfiguration oder sogar der Netzwerkhardware.

Vieles ist anders bei DRBD 9

Bei DRBD 9 stellt sich die Situation anders dar, denn hier gibt es das aus DRBD 8 bekannte »/proc/drbd« zwar noch, die Entwickler raten aber von der Nutzung ausdrücklich ab. Es ist gar als »deprecated« markiert und wird in einer künftigen DRBD-Version vermutlich verschwinden. Stattdessen soll der Admin nun auf »drbdadm status Ressource« setzen.

Das gibt eine weit weniger technische Sicht auf die Dinge ab, verrät dem Admin die wichtigsten mit einer Ressource verbundenen Details aber ebenso – die Interpretation der Ergebnisse unterscheidet sich von jener bei DRBD 8 insofern nicht.

Wer auch die aus »/proc/drbd« bekannten Zahlen will, hängt dem Aufruf ein »–verbose« und wahlweise auch ein »–statistics« an, dann ähnelt die Ausgabe von »drbdadm status« dem Inhalt von »/proc/drbd« – wenn auch nicht die Syntax.

Wer sich für DRBD 8.4 Skripte fürs eigene Monitoring gebastelt hat, die »/proc/drbd« auslesen und parsen, kann diese jedoch mit hoher Wahrscheinlichkeit bald wegwerfen. In Sachen Monitoring haben die DRBD-Entwickler sich ohnehin etwas Neues in Version 9 überlegt.

Zusätzlich zu »drbdadm status« bietet Linstor auch eine Möglichkeit, die mit DRBD im Zusammenhang stehenden Ereignisse als Monitoring-Stream auf der Kommandozeile oder an andere Programme kontinuierlich auszugeben. Das ist gerade dann praktisch, wenn man Linstor an Monitoring-Werkzeuge wie Sensu ankoppeln will – denn die Events, die zu Problemen führen, liefert »drbdadm« selbstständig und das Monitoring-System muss “nur” noch darauf reagieren.

Pacemaker spuckt in die Suppe

Wer DRBD in einem klassischen Cluster mit zwei Knoten nutzt, tut das nicht selten in Kombination mit Pacemaker. Dem haftet bekanntlich nicht gerade der Ruf an, besonders anwenderfreundlich zu sein. Daher haben die meisten Admins Pacemaker gar nicht auf der Rechnung, wenn sie sich DRBD-Problemen stellen müssen. Was sich schnell rächt: Nicht selten ergehen sich Admins in ohnehin schon stressigen Situationen – etwa während einer Downtime – im Debugging von DRBD, ohne Pacemaker auch nur eines Blickes zu würdigen.

Gerade bei älteren DRBD-Versionen ist das aber fatal. Wer DRBD wie beschrieben in Systemen mit zwei Knoten nutzt, kommt um einen Clustermanager gar nicht herum. Denn vor der Einführung des »Auto-Promote«-Feature war es unmöglich, DRBD ohne Clustermanager überhaupt in den »Primary«-Modus zu schalten. Genau der ist jedoch die Voraussetzung dafür, dass eine DRBD-Ressource sich auf einem Host nutzen lässt. Das Dateisystem auf einer DRBD-Ressource lässt sich gar nicht in das lokale System einhängen, wenn der »Secondary«-Modus gegeben ist.

In klassischen Zwei-Knoten-Clustern mit DRBD 8.4 ist Pacemaker deshalb in der Regel ebenfalls anzutreffen. Dabei kann es seitens des Admin gelegentlich durchaus gewollt sein, Pacemaker ins Handwerk zu pfuschen – etwa wenn ein Update ansteht. Nicht zuletzt greift Pacemaker manchmal daneben, wenn es seinen eigentlichen Job machen soll, etwa einen Fail-over nach dem Ausfall eines Systems. Regelmäßig entpuppen sich vermeintliche DRBD-Probleme deshalb als Pacemaker-Probleme. Wie geht der Admin aber mit ihnen um?

Den Ressourcen-Zustand überprüfen

Das A und O im Umgang mit Pacemaker ist es, den Zustand der Ressourcen im Cluster herauszufinden. Das geschieht wahlweise per »crm_mon -1 -rf« oder per »pcs status«, je nachdem, welches der beiden Werkzeuge verfügbar ist. Sind die DRBD-Ressourcen im Primary- und Secondary-Modus geführt und entspricht das den Status-Meldungen von DRBD (siehe oben), gibt es keinen Grund zur Sorge. Wenn aber eine DRBD-Ressource in Pacemaker etwa als »Failed« markiert ist, dann steht Arbeit an.

Zunächst sollte der Admin mittels »crm resource cleanup ID« oder »pcs resource cleanup ID« die Ressource in Pacemaker bereinigen. Wichtig: Der Cleanup-Befehl ist auf die Master-Slave-Ressource anzuwenden, die bei der Nutzung von DRBD in Pacemaker stets vorhanden ist.

Geht sie danach sofort wieder in einen Fehlerzustand über, beseitigt der Admin idealerweise das zugrunde liegende Problem. Dazu schaltet er den Cluster zunächst in den Wartungsmodus, was er per »crm configure property maintenance-mode=true« oder »pcs property set maintenance-mode=true« erreicht. Anschließend inspiziert er die von Pacemaker geführten Logdateien »/var/log/daemon« oder »/var/log/syslog« auf Fehler. Bevorzugt sucht er per »grep« die Zeichenkette »ERROR«.

Während der Cluster im Maintenance-Modus ist, lässt Pacemaker die Finger von allen Ressourcen. Am Ende sollte der Admin aber daran denken, diesen Modus auch wieder abzuschalten, denn sonst droht beim nächsten Problem eine unliebsame Überraschung in Form eines tatenlosen Clustermanagers.

Leben ohne Schmerz: DRBD 9

Setzt der Admin auf DRBD 9, ist die Wahrscheinlichkeit, dass er DRBD mit dem verhassten Pacemaker-Clustermanager verarzten muss, ausgesprochen gering. Denn für DRBD 9 haben die Entwickler sich die bereits erwähnte Auto-Promotion ausgedacht – heißt ganz konkret: Versucht auf einem Host ein Prozess auf eine DRBD-Ressource zuzugreifen, schaltet diese automatisch vom »Secondary«- in den »Primary«-Modus um, falls sie nicht auf einem anderen Host im Cluster bereits im »Primary«-Modus ist.

Zwischen DRBD und Pacemaker muss insofern gar keine logische Verbindung mehr existieren – in Pacemaker verwaltet der Admin nur jene Ressourcen, die auf DRBD zugreifen, aber eben nicht DRBD selbst. Baut der Admin sein Setup wie beschrieben, eliminiert er eine potenzielle Fehlerquelle von Anfang an.

Frei nach dem Motto “Wie gewonnen, so zerronnen” ergeben sich dafür in DRBD 9 neue potenzielle Störer. So setzt die neue Verwaltungssoftware Linstor wie zuvor »drbdmanage« auf ein Server-Client-Prinzip. Die Komponenten sind alle in Go verfasst, ihre Installation und Inbetriebnahme gelingen also leicht.

Doch im laufenden Betrieb besteht trotzdem die Möglichkeit von Problemen. Liefert ein an Linstor abgeschickter Befehl auf der Kommandozeile lediglich einen Fehler zurück, bedient der Admin sich aber der klassischen Debugging-Mechanismen: Er schaut in die Logdateien der entsprechenden Dienste, in denen sich fast immer eine aussagekräftige Beschreibung verbirgt.

Die Firewall im Visier

Ein in der Praxis häufig auftretendes Problem sind Firewall-Regeln, die sich verselbstständigen oder durch Updates neu erstellt werden. DRBD nutzt für die Verbindung zwischen zwei Hosts im Regelfall TCP/IP: Auf beiden Hosts macht also das DRBD-Kernelmodul dann einen TCP/IP-Port auf, mit welchem sich das Gegenüber verbinden kann. Welcher Port zum Einsatz kommt, bestimmt in DRBD 8.4 die Konfigurationsdatei einer Ressource. Linstor kümmert sich für DRBD 9 selbstständig darum, den passenden Netzwerkport auszuwählen.

Richtet der Admin ein DRBD-Setup einmal ein, schaltet er dabei meist auch die Firewall frei. Leider gibt es unter Linux ja kein distributionsunabhängiges Werkzeug – auf Ubuntu schlägt man sich mit »ufw« herum, auf Red Hat kommt »firewalld« zum Einsatz und Suse und Debian haben wieder andere Prinzipien. So kommt es oft vor, dass die DRBD-Verbindung zwischen zwei Hosts plötzlich nicht mehr funktioniert, weil im Hintergrund das Firewall-Management streikt. Besonders häufig ist der Effekt bei Updates, bei denen neue Firewall-Regeln den Weg auf den Host finden.

Die Debugging-Strategie ist klar: Mit »tcpdump« kann der Admin etwa prüfen, ob überhaupt DRBD-spezifische Pakete von der Gegenseite den Host erreichen. Wenn das der Fall ist, besteht der nächste Test darin, im IPtables-Regelwerk den Eintrag zu identifizieren, der die Verbindung verhindert. Denkbar ist auch, auf beiden Systemen per CLI eine Ausnahmeregel für den DRBD-Port zu hinterlegen und zu testen, ob die Verbindung dann wieder klappt. Ist das der Fall, kann man die Firewall-Regeln verewigen.

Wer auf RHEL 8 unterwegs ist, hat mit IPtables übrigens nichts mehr zu tun – hier kommt stattdessen NFtables zum Einsatz, das aber ebenfalls die Firewalld-Schnittstelle nutzt.

Platte kaputt: Was tun?

Hardware geht kaputt, wohl jeder Admin wird aus Erfahrung bestätigen, dass Festplatten zu jenen Bauteilen gehören, die eher regelmäßig den Heldentod sterben. DRBD bietet dem Admin zwei Möglichkeiten, mit dem Problem umzugehen: Wahlweise kann es Fehler vom Blockgerät einer Ressource an die übergeordnete Anwendung – in aller Regel das Dateisystem – weitergeben, oder es kann die Ressource im Fall des Falles deaktivieren und für defekt erklären.

Welche Strategie hier besser ist, hängt auch von den Programmen ab, die auf die Daten des Dateisystems zugreifen. Grundsätzlich gilt aber, dass ein kaputtes Dateisystem ein Problem ist – und wenn die Applikation zu doof für den Umgang damit ist, kommt es blödestenfalls zu einer Unterbrechung des Service.

DRBD hat für dieses Szenario allerdings einen eingebauten Schutzmechanismus, und der Admin tut gut daran, ihn zu verwenden: Konfiguriert er DRBD nämlich so, dass DRBD den Datenträger in Ruhe lässt, wenn dieser Fehlermeldungen wirft, ist zumindest die Gefahr eines Dienstausfalls gebannt.

DRBD geht dann nämlich auf dem Knoten, auf dem die DRBD-Ressource die »Primary«-Rolle hält, in den Diskless-Modus über. Konkret: Eingehende Schreib- und sogar Lese-Anfragen wickelt zwar die DRBD-Ressource auf dem »Primary«- Knoten ab, als Speichergerät im Hintergrund nutzt sie aber den Datenträger im »Secondary«-Knoten.

Aus Sicht der Applikation ändert sich damit gar nichts, wenn man von der Performance absieht: Weil alle Daten durchs Netzwerk gehen, erhöht sich natürlich die Latenz beim Zugriff auf die DRBD-Ressource. Die Bandbreite hingegen ist selten ein Thema, denn die ist ja zumindest bei vollsynchroner Replikation bereits begrenzt durch die tatsächliche Kapazität der Verbindung zwischen den beiden Systemen.

Apropos langsam …

Zu den wirklich lästigen Problemen gehören jene, die quasi aus dem Nichts auftreten und lediglich die Performance von DRBD betreffen, nicht aber zum kompletten Ausfall der Funktionalität führen. Gerade ältere Setups mit DRBD folgen meist dem klassischen Rat, die DRBD-Verbindung über einen eigenen Link ohne Switch-Zwischenstopp zu realisieren (Cross-Link). Schwindet die auf den DRBD-Ressourcen zu erreichende Performance ohne Änderungen am System (etwa ein Kernelupdate), kommt als Ursache praktisch nur die Hardware in Betracht und es empfiehlt sich, nach Möglichkeit mit anderer Hardware zu experimentieren.

Performance-Probleme auf DRBD-Ressourcen sind in der Regel jedenfalls auf externe Faktoren zurückzuführen; die Ursachen liegen selten in DRBD selbst – denn so komplex wie Ceph & Co. ist DRBD nicht, als Komponente innerhalb der Blockgeräte-Schicht des Linux-Kernels ist es praktisch Performance-neutral.

Den Kanal voll

Wobei es von dieser Regel – natürlich – eine Ausnahme gibt. Und die hat der Admin bestenfalls gerade dann im Hinterkopf, wenn er DRBD für Replikation über die Grenzen eines Standorts hinweg verwendet. Offsite-Replikation mit DRBD nutzt meist das DRBD-Protokoll A, das asynchrone Replikation vorsieht. Ein lokaler Client bekommt das Okay für den Schreibvorgang dabei in dem Augenblick, in dem das lokale DRBD-Modul die Daten in den Netzwerkstack des lokalen Systems abgegeben hat.

Gerade bei langsamen Verbindungen wird das zum Problem. DRBD nutzt keine eigenen internen Puffer für Netzwerkverbindungen, sondern verlässt sich an dieser Stelle komplett auf den Linux-Kernel. Der lässt sich zwar in vielerlei Hinsicht tunen, um größere Buffer bereitzustellen – doch irgendwann ist einfach kein weiterer Platz mehr vorhanden.

Füllt sich auf einem System also der lokale Netzwerkspeicher schneller als die Daten über das Netzwerk zum Clusterpartner geschrieben werden können, ist das Maß irgendwann voll. DRBD wird dann zwar nicht langsamer, aber die DRBD-Ressource hin zum Offsite-Clusterpartner geht in den »WFConnection«-Status über, trennt also kurzzeitig die Verbindung.

Meist kommt die Verbindung danach aber wieder zustande, und zusätzlich zum ohnehin anfallenden Datenstrom müsste DRBD jetzt theoretisch auch noch die Blöcke resynchronisieren, die im Activity Log vermerkt sind. So entsteht fast zwangsläufig ein Flapping State, mit der Konsequenz, dass die Offsite-Replikation nicht mehr funktioniert. Säuft das Rechenzentrum während einer solchen Situation ab, sind auf der DRBD-Ressource im Ausfallstandort nur alte Daten verfügbar (Abbildung 5).

Abbildung 5: Offsite-Replikation ist ein oft genutztes Feature, das aber zusätzliche Komponenten bedingt.

Effektiv lösen lässt sich das Problem nur mit Hilfe einer Art Proxy zwischen den beiden Standorten, der als riesiger Cache funktioniert. Will der Admin ein solches Konstrukt nicht selbst zusammenzimmern, kann er auf ein Produkt von Linbit namens DRBD Proxy zurückgreifen, das entsprechende Aufgaben erfüllt – allerdings ist das Produkt weder Open Source noch kostenlos verfügbar.

Fazit

DRBD merkt man die vielen Jahre an, die die Lösung bereits auf dem Buckel hat. Zugleich kommt ihr die überschaubare Komplexität zugute, die DRBD von Alternativen wie Ceph angenehm abhebt. DRBD-Debugging geht stets mit der Frage los: In welchem Zustand befinden sich die einzelnen Ressourcen? Sind alle benötigten Module geladen? Hat DRBD in dieser Konfiguration schon einmal funktioniert? Falls ja, ist die Wahrscheinlichkeit hoch, dass das Problem nicht in DRBD selbst liegt.

Bemerkenswert sind außerdem die Unterschiede, die sich zwischen DRBD 8 und 9 ergeben, gerade im Hinblick auf die genutzten Komponenten. Während bei DRBD 8 noch oft Pacemaker den Brei verdirbt, liegt der Fokus bei DRBD 9 auf den nativen Werkzeugen, die zu DRBD gehören.