Basisfunktionalität

DRBD nutzt für die Kommunikation mit einem Blockgerät die Blockspeicher-geräteverwaltung des Linux-Kernels („Block Device Layer“), sodass ein DRBD-Laufwerk („Resource“) selbst auf einem Linux-System ebenfalls ein Blockgerät darstellt. Auf Applikationsebene funktioniert der Zugriff auf DRBD-Ressourcen mithin genauso wie jener auf Festplatten oder SSDs; ebenso benötigt eine DRBD-Ressource ein Dateisystem oder eine vergleichbare Vorrichtung, um den koordinierten Lese- und Schreibzugriff zu ermöglichen. DRBD ist mithin agnostisch im Hinblick auf die Software, die es benutzt.

Von der Applikationsseite her eingehende Lese- und Schreibanfragen leitet eine DRBD-Ressource einerseits unmittelbar an das mit ihr verbundene Blockgerät blockweise („Backing Device“) weiter. Andererseits übergibt die DRBD-Ressource dieselben Daten auch an die Netzwerkverwaltung („Network stack“) des Linux-Kernels auf dem System, von wo aus dieser sie an den bzw. die jeweils anderen Knoten sendet. Dieser Mechanismus garantiert die Synchronisation der Daten in DRBD.

Zwar beherrscht DRBD verschiedene Netzwerktransportmedien für die Datenübertragung; die Standardkonfiguration sieht jedoch die Verwendung einer vorhandenen Ethernet-Verbindung mittels TCP/IP-Protokoll vor. Wahlweise lassen sich zwei DRBD-Systeme auch direkt – also ohne zwischenliegende Netzwerk-Switches – verbinden („Cross Link“), falls geeignete Netzwerkkarten in den Systemen verbaut sind.

DRBD beherrscht die automatische Resynchronisation der Backing Devices einer DRBD-Ressource, falls die Netzwerkverbindung dieser Ressource zwischenzeitlich getrennt war. Sobald die Netzwerkverbindung wiederhergestellt ist, prüft DRBD automatisch den Zustand der Ressource auf den Hosts und leitet gegebenenfalls eine Resynchronisation ein. Diese gilt als erfolgreich abgeschlossen, sobald der sich auf den Backing-Devices der DRBD-Ressource befindliche Datensatz auf allen beteiligten Servern identisch ist.

Eine Sonderform der Resynchronisation ist das erstmalige Anlegen einer DRBD-Ressource: Hierbei unterscheidet sich der Inhalt der Backing Devices zwar vielleicht auf der Ebene der Blockgeräte; dies ist jedoch belanglos, weil bei der Nutzung von DRBD die Daten auf den Backing Devices ohnehin sukzessive überschrieben werden. DRBD bietet deshalb die Möglichkeit, mittels spezieller Befehle die Synchronisation der Backing Devices beim erstmaligen Anlegen der Ressource zu überspringen.

Funktionalität bis DRBD 8.4

Bis einschließlich DRBD 8.4 bot DRBD lediglich die Möglichkeit, denselben Datensatz von einem System auf ein anderes System zu spiegeln. Üblich war insofern der Einsatz in Hochverfügbarkeitsclustern mit zwei Knoten, wobei der schreibende Zugriff etwa durch Applikationen im Normalfall nur auf einem System geschieht.

In einem Cluster bestehend aus zwei Knoten hält eine DRBD-Ressource auf einem System in aller Regel die Rolle („role“) Primary und auf dem anderen System die Rolle Secondary. Lese- wie Schreibzugriff sind bei DRBD immer ausschließlich auf jenem Knoten möglich, auf dem die jeweilige DRBD-Ressource die Primary-Rolle besitzt. Die DRBD-Ressource im Secondary-Modus empfängt lediglich Updates für den Datensatz des jeweiligen Laufwerks, die die Ressource auf dem Primary-Modus an sie sendet.

Eine bis einschließlich DRBD 8.4 häufig genutzte Funktion zur Umgehung der Limitation auf zwei Knoten war das sogenannte „Device Stacking“. DRBD bot dabei die Möglichkeit, mehrere DRBD-Ressourcen auf einem Host innerhalb der Blockgeräteverwaltung des Linux-Kernels so zu kombinieren, dass sie Veränderungen in festgelegter Reihenfolge aneinander vererben. Vorrangiges Ziel dieser Maßnahme war es, die redundante, lokale Replikation einerseits und gleichzeitig die Replikation hin zu einem anderen Standort andererseits zu ermöglichen. Gestapelte Ressourcen waren im Hinblick auf die erreichbare Performance jedoch ihren „normalen“ Pendants unterlegen.

Mit dem Funktionsumfang von DRBD 8.4 ist DRBD aktuell offizieller Bestandteil des Linux-Kernels.

Funktionalität ab DRBD 9.0

Beginnend mit DRBD 9 haben dessen Maintainer die Funktionalität der Software erheblich erweitert. Weggefallen ist insbesondere jene Einschränkung, wonach eine DRBD-Ressource mit der Primary-Rolle ihre Daten lediglich auf eine weitere DRBD-Ressource mit der Secondary-Rolle kopieren kann. Aktuelle DRBD-Versionen von DRBD 9 bieten stattdessen die Möglichkeit, Daten von einer Primary-Ressource auf bis zu 31 Secondary-Ressourcen gleichzeitig zu kopieren.

Funktionalität als Software Defined Storage (SDS)

Indirekt lässt sich DRBD seit DRBD 9 durch die Einführung der Management-Software drbdmanage als eine Lösung für Software Defined Storage nutzen: DRBD-Ressourcen lassen sich dabei aus Umgebungen wie OpenStack heraus dynamisch auf den Servern eines DRBD-Clusters anlegen, die gerade noch freie Ressourcen – also verfügbaren Speicherplatz – bieten. Die Funktionen von DRBD 9 ermöglichen indirekt also den Betrieb als Speicher, der in die Breite skalieren kann („Scale Out“).

Durch die Einführung der Replikation hin zu mehreren Zielen hat das aus DRBD 8.4 bekannte Stapeln von Ressourcen („Device Stacking“) in DRBD 9 seine Bedeutung de facto eingebüßt.

Rollen einer DRBD-Ressource

DRBD unterscheidet bei einer Ressource grundsätzlich zwischen den Rollen Primary und Secondary.

• Primary: Die Ressource ermöglicht den lesenden wie schreibenden Zugriff
• Secondary: Die Ressource empfängt lediglich Updates von einer Primary-Ressource und ist lokal weder lesend noch schreibend verwendbar

Die Rolle einer DRBD-Ressource ist grundsätzlich unabhängig vom aktuellen Status der Ressource im Hinblick auf ihre Netzwerkverbindung. Für die eigene Netzwerkverbindung kennt eine Ressource in DRBD drei Zustände:

• Connected: Es besteht eine aktive Verbindung hin zum anderen Clusterknoten für die jeweilige Ressource
• StandAlone: Es besteht keine aktive Verbindung hin zum anderen Clusterknoten für die jeweilige Ressource und die Ressource versucht auch nicht aktiv, eine solche Verbindung herzustellen
• Connecting (bis DRBD 8.4: WFConnection): Es besteht keine aktive Verbindung hin zum anderen Clusterknoten für die jeweilige Ressource; diese versucht jedoch aktiv, eine solche Verbindung herzustellen

In Summe ergeben sich für eine DRBD-Ressource auf einem Host mithin die folgenden möglichen Zustände:

Replikationsmodi

DRBD unterstützt verschiedene Replikationsmodi, die in DRBD als „Protokolle“ bezeichnet werden. Maßgeblich unterscheiden sich die verfügbaren Protokolle im Hinblick auf dem Zeitpunkt, zu dem die DRBD-Ressource im Primary-Modus einer auf sie schreibend zugreifenden Applikation signalisiert, dass der Schreibvorgang erfolgreich abgeschlossen ist.

Die Standardkonfiguration für ein Laufwerk sorgt für vollsynchrone Replikation (Protokoll C); hierbei bestätigt in einem Setup mit zwei Knoten die DRBD-Ressource der schreibend auf sie zugreifenden Applikation erst, dass ein Schreibvorgang erfolgreich abgeschlossen ist, sobald dieselbe DRBD-Ressource auf beiden Cluster-Knoten die Veränderung erfolgreich auf ihr lokales Blockgerät geschrieben hat. In DRBD 9 ist die Anzahl der Knoten, auf denen ein Schreibvorgang erfolgreich beendet sein muss, bevor er im Sinne des Protokolls C als erfolgreich gilt, durch den Admin konfigurierbar. Dieser Replikationsmodus bietet als einziger der von DRBD unterstützten Modi Transaktionssicherheit. Er ist deshalb auch der in den meisten Setups anzutreffende Modus.

Als Protokoll B bezeichnet DRBD seine Implementation semi-synchroner Replikation: Hierbei müssen die Pakete lediglich die Netzwerkkarte des gegenüberliegenden Cluster-Knotens erreicht haben, damit die Primary-Ressource der Applikation die erfolgreiche Beendigung des Schreibvorgangs signalisiert. Der Modus ist nicht transaktionssicher, weil etwa im Falle eines Stromausfalls beim Knoten mit der Ressource im Secondary-Modus die Daten dort möglicherweise noch nicht auf die Platte geschrieben waren. In der Praxis kommt dem Protokoll B lediglich untergeordnete Bedeutung zu.

Das Protokoll A beschreibt in DRBD das Prinzip der asynchronen Replikation: Die DRBD-Ressource im Primary-Modus signalisiert der lokalen Applikation den erfolgreichen Abschluss eines Schreibvorgangs, sobald die Daten das der DRBD zugrundeliegende Blockgerät auf demselben Knoten erreicht haben. Das Protokoll A kommt üblicherweise nicht für die lokale Replikation zwischen zwei Knoten zum Einsatz; es eignet sich stattdessen besonders für die Replikation zwischen verschiedenen geographischen Standorten, falls die über das Netzwerk zu erreichende Latenz dort unzufriedenstellend ist.

Dual-Primary-Ressourcen

DRBD bis einschließlich Version 8.4 bietet grundsätzlich die Möglichkeit, zueinander gehörende DRBD-Ressourcen auf unterschiedlichen Hosts parallel in der Primary-Rolle zu betreiben. Der zuverlässige Betrieb einer DRBD-Ressource in der Primary-Rolle auf mehreren Systemen stellt jedoch fast immer erheblich höhere Anforderungen an das Setup als der klassische Betrieb nach Primary-Secondary-Schema; er bedingt etwa die Nutzung eines Sperrmechanismus, um konkurrierende Schreibvorgänge zu unterbinden, wofür unter Linux üblicherweise der Distributed Lock Manager (DLM) zum Einsatz kommt. Für DRBD 8.4 raten die DRBD-Entwickler bereits für die Mehrzahl der Fälle von entsprechenden Setups ab; der einzige legitime Einsatzzweck ist demnach der kurzzeitige parallele Betrieb im Dual-Primary-Modus zum Zwecke der Live-Migration virtueller Maschinen.

DRBD 9 unterstützte den Betrieb einer Ressource im Dual-Primary-Modus zwar grundsätzlich, die Entwickler der Software messen diesem Einsatzszenario jedoch mit Ausnahme der erwähnten Live-Migration virtueller Maschinen keine praktische Relevanz mehr bei. Eine Weiterentwicklung der Funktion ist seitens des Anbieters augenblicklich nicht vorgesehen.

Layout des Backing Devices

Für seine ordnungsgemäße Funktionalität benötigt DRBD sogenannte Metadaten auf den Backing Devices einer Ressource. Beim Anlegen einer Ressource in DRBD 8.4 oder vorherigen Versionen erstellt der Admin die Metadaten mittels drbdadm selbst auf allen beteiligten Systemen; in DRBD 9 besteht bei der Nutzung von drbdmanage alternativ die Möglichkeit, dieses die Metadaten automatisch anlegen zu lassen.

Der Bereich mit den Metadaten befindet sich üblicherweise am Anfang oder am Ende des Backing Devices; alternativ lassen sich die Metadaten auch auf einem externen Blockgerät ablegen. Dieses Setup kommt vorrangig zum Einsatz, um die Replikation von Blockgeräten mittels DRBD im Nachhinein zu ermöglichen. Das Auslagern der Metadaten neu anzulegender DRBD-Ressourcen ist hingegen unüblich und kommt nur in besonderen Szenarien zur Anwendung.

Der Metadatenbereich hat eine variable Größe, die im Wesentlichen von der Größe des Backing Devices insgesamt abhängt. Im betrieblichen Alltag kann das zu Problemen führen, wenn eine Ressource interne Metadaten nutzt und durch den Admin vergrößert werden soll. In solchen Fällen ist es notwendig, die Metadaten der DRBD-Ressource zunächst an das Ende des Backing Devices zu verschieben, nachdem die neue Größe des Backing Devices bestimmt ist.

Zu den in den Metadaten zu findenden Informationen gehören insbesondere das DRBD Activity Log sowie Informationen über Rollenänderungen der jeweiligen DRBD-Ressource in der Vergangenheit.

Activity Log

Im betrieblichen Alltag eines Hochverfügbarkeitsclusters ist der Abbruch der Netzwerkverbindung zwischen den verschiedenen Clusterknoten ein gängiges Fehlerszenario. Der Ausfall eines Clusterknotens etwa, mit dem der Ausfall der Netzwerkverbindung zwangsweise einhergeht, ist gar das klassische Einsatzszenario für einen Hochverfügbarkeitscluster überhaupt. Aus Sicht von DRBD wie aus Sicht jeder netzwerkbasierten Replikationslösung stellt der Abbruch der Kommunikationsverbindung hin zum Clusterpartner jedoch ein handfestes Problem dar.

Das trifft insbesondere dann zu, wenn der nunmehr ausgefallene Clusterknoten zuvor DRBD-Ressourcen in der Primary-Rolle betrieben hat. Trotz vollsynchroner Replikation per Protokoll C ist es nicht zu verhindern, dass auf jenem Clusterknoten Änderungen des Datensatzes des Backing Devices der DRBD-Ressourcen unmittelbar vom Ausfall des Knotens stattfinden, die nicht mehr erfolgreich zum Clusterpartner synchronisiert werden können. Im ungünstigsten Fall befinden sich auf dem Backing Device der Ressource des dann ausgefallenen Knotens also aktuellere Daten als auf dem Backing Device der Ressource des verbliebenen Systems.

Kommt ein Cluster-Manager wie Pacemaker zum Einsatz, aktiviert dieser unmittelbar nach dem Ausfall eines Knotens im Normalfall alle Ressourcen auf dem verbliebenen Knoten für die dortige Nutzung; DRBD-Ressourcen schaltet er dort dann in die Primary-Rolle um. Weil zumindest im Protokoll C etwaige Transaktionen auf dem vorherigen Primary-Knoten nicht als erfolgreich abgeschlossen galten, handelt es sich ausdrücklich nicht um eine Split-Brain-Situation. Sobald der zwischenzeitlich ausgefallene Clusterknoten dem Cluster wieder beitritt, muss der verbliebene Clusterknoten jedoch für die Löschung der dann nicht mehr korrekten Daten auf den Backing Devices der DRBD-Ressourcen auf dem zwischenzeitlich ausgefallenen System sorgen.

Hierfür existierenden verschiedene Ansätze: Einerseits könnte der Knoten mit den DRBD-Ressourcen in der Primary-Rolle den gesamten Inhalt des Backing Devices vom primären auf den sekundären Knoten synchronisieren. Gerade bei großen DRBD-Ressourcen würde dies jedoch einige Zeit in Anspruch nehmen, während der die Performance der DRBD-Ressourcen nicht optimal wäre. DRBD nutzt deshalb stattdessen eine Technik namens „Activity Log“: Im Activity Log, das in den Metadaten einer DRBD-Ressource liegt, verzeichnet DRBD, welche Extents des Backing Devices zuletzt verändert worden sind. Die Anzahl der im Activity Log verzeichneten Extents lässt sich per Konfigurationsdatei an lokale Gegebenheiten anpassen. Sobald die Netzwerkverbindung wieder zustande gekommen ist, synchronisiert der Knoten mit den DRBD-Ressourcen in der Primary-Rolle lediglich jene Extents, die im Activity Log der Ressource auf dem anderen Knoten verzeichnet sind. DRBD umgeht auf diese Weise die vollständige Resynchronisation der Backing Devices.

Unterschiedliche Netzwerktransporte

Waren in DRBD 8.4 noch sowohl die Replikationslogik als auch die Logik für den Transport der zu replizierenden Daten Teil des gemeinsamen DRBD-Kernelmoduls drbd.ko, so haben die Entwickler die Netzwerklogik der Lösung in DRBD 9 erheblich modifiziert. Das eigentliche Kernelmodul für DRBD kümmert sich seither ausschließlich um die Replikation von Daten und übergibt diese über eine interne, generische Schnittstelle an ein ebenfalls in den Kernel zu landendes Modul für den Netzwerktransport der DRBD-Daten. Das neue Design ermöglicht die Nutzung verschiedener Netzwerktransportschichten; neben Ethernet unterstützt DRBD 9 etwa auch Replikation via InfiniBand. Die Unterstützung für zusätzliche Transportmedien ist seitens des Herstellers geplant und befindet sich in Vorbereitung.

Performance

Anders als verteilte Speicherlösungen wie Ceph oder GlusterFS nimmt DRBD selbst keine Reorganisation der Daten vor. Als Teil des Block Device Layers des Linux-Kernels leitet es eingehende Schreib- und Leseanfragen lediglich an das jeweilige Backing Device einerseits und an den Netzwerkstack des lokalen Systems andererseits weiter. Weil das Verschieben von Daten innerhalb des Block Device Layers des Linux-Kernels praktisch in Echtzeit geschieht, entspricht der zu erreichende Durchsatz auf einer DRBD-Ressource in etwa jenem des darunter liegenden, physischen Blockgerätes. Entsprechend lässt sich dieser Durchsatz erhöhen, indem DRBD RAID-Verbünde mit vielen Spindeln nutzt, deren Bandbreite entsprechende RAID-Controller bündeln.

Hinsichtlich der zu erwartenden Latenz bei Schreibzugriffen auf DRBD-Ressourcen wirkt sich die durch DRBD gewährleistete Replikation hingegen negativ aus. Die DRBD-Ressource in der Primary-Rolle kann den erfolgreichen Abschluss einer Schreiboperation an die schreibende Applikation erst vermelden, nachdem die Bestätigung vom Clusterpartner über das erfolgreiche Schreiben der Daten auf dem dortigen Blockgerät eingelangt ist. Dadurch entsteht eine Gesamtlatenz bestehend aus der Latenz der beiden Datenträger sowie der doppelten Netzwerklatenz zwischen den Systemen. Durch den Einsatz alternativer Netzwerklösungen wie InfiniBand, deren implizite Latenz deutlich geringer als jene von Ethernet ist, lässt sich dieser Parameter jedoch optimieren.

In Summe liegt die Latenz von Schreibzugriffen auf DRBD-Ressourcen selbst bei der Nutzung von Ethernet deutlich unter jener von verteilten Storage-Lösungen. Jene bieten im Gegenzug meist deutlich höhere Bandbreiten, weil sie die Bandbreite vieler Knoten durch das Aufteilen der zu schreibenden Daten in binäre Objekte miteinander kombinieren.

DRBD 8.4 und früher

Bis einschließlich DRBD 8.4 standen Administratoren vier Werkzeuge zur Verfügung, um DRBD-Ressourcen zu verwalten:

• /proc/drbd
• drbd-overview
• drbdsetup
• drbdadm

Die Datei drbd innerhalb von procfs enthält grundsätzliche Details über die lokal vorhandenen DRBD-Ressourcen. In ihr verzeichnet der DRBD-Kerneltreiber alle aktiven Ressourcen sowie deren Rollen auf dem lokalen System und ggf. auf dem Clusterpartner.

Das Werkzeug drbd-overview liest /proc/drbd aus und korreliert die dort gefundenen Daten mit den Inhalten der Konfigurationsdateien von DRBD; schließlich zeigt es eine entsprechend aufbereitete Übersicht aller Ressourcen an. drbd-overview ist allerdings obsolet und sollte nicht länger zum Einsatz kommen.

drbdsetup ist das Low-Level-Werkzeug zum Management von DRBD-Ressourcen. Der Admin nutzt es selten direkt; das Werkzeug drbdadm ruft drbdsetup im Hintergrund jedoch mit den richtigen Parametern auf. drbdsetup ist außerdem der empfohlene Weg, Informationen über die DRBD-Ressourcen aus /proc/drbd zu beziehen.

drbdadm ist in DRBD 8.4 das Hauptwerkzeug für Admins um DRBD-Ressourcen anzulegen, zu verwalten und zu löschen.

DRBD 9

Aufgrund der in DRBD 9 im Vergleich mit DRBD 8 stark gestiegenen Komplexität der grundsätzlich möglichen Setups hat der Hersteller LINBIT zusammen mit DRBD 9 auch ein neues Management-Werkzeug namens drbdmanage vorgestellt. drbdmanage basiert auf einer Server-Client-Architektur und ermöglicht das cluster-weite Anlegen, Verwalten und Löschen von DRBD-Ressourcen. Die erste Version von drbdmanage basiert auf der Skriptsprache Python; aktuell arbeitet LINBIT jedoch an einer neuen Version von drbdmanage, die auf Java basieren soll.

Ebenfalls haben die DRBD-Entwickler im Rahmen der Einführung von DRBD 9 die Entwicklung von DRBD und den dazugehörigen Verwaltungswerkzeugen getrennt, so dass sie nun unterschiedlichen Releasezyklen folgen.

Für Kontroversen sorgte LINBIT Ende 2016, als es die Lizenz von drbdmanage von der freien GPL v3 hin zu einer kommerziellen Lizenz änderte, die mit den Anforderungen der Definition freier Software des GNU-Projektes nicht in Einklang zu bringen war. LINBIT revidierte die Entscheidung wenig später jedoch, so dass für drbdmanage nun wieder die Bestimmungen der GNU GPL v3 gelten.

LINBIT ersetzte drbdmanage im Juli 2018 durch Linstor, um den neuen Anforderungen im Storage-Management gerecht zu werden.

Verteilte Speicherlösungen

Anders als DRBD handelt es sich bei Lösungen wie Ceph oder GlusterFS um massiv verteilte Speichersysteme. Diese zeichnen sich dadurch aus, dass sie anhand eines Algorithmus – etwa eines Hash-Algorithmus – Daten auf Basis bestimmter Kriterien auf eine beliebige Anzahl physischer Speichergeräte verteilen. Replikation ist dabei üblicherweise impliziter Teil der Lösung.

Cluster-Dateisysteme

Cluster-Dateisysteme wie OCFS2 oder GFS2 ermöglichen es, innerhalb eines Clusters auf denselben Datensatz von mehreren Klienten aus konkurrierend schreibend wie lesend zuzugreifen. DRBD ist mithin keine Alternative zu Clusterdateisystemen, kann im Dual-Primary-Modus jedoch die Basis für solche Ansätze bilden.