mini|Übersicht des DRBD-Konzepts
DRBD (Distributed Replicated Block Device) ist eine freie Netzwerkspeicher-Software für Linux. Als Kernel-Modul zusammen mit einer Management-Applikation im Userspace und einem Skript dient es dazu, ein Blockgerät auf einem produktiven (primary) Server in Echtzeit auf andere (secondary) Server zu spiegeln. Dieses Verfahren wird verwendet, um Hochverfügbarkeit (HA) im Linux-Umfeld zu realisieren und somit eine gute Verfügbarkeit verschiedener Dienste zu erreichen. Alternativen hierzu sind verteilte Dateisysteme wie z. B. GlusterFS.
Funktionsweise Die primäre Aufgabe der Software DRBD besteht darin, im Sinne von Hochverfügbarkeit das Vorhandensein ein und desselben Datensatzes auf mehr als einem Blockgerät – etwa einer Festplatte oder einer SSD – sicherzustellen. Die jeweiligen Blockgeräte befinden sich üblicherweise in unterschiedlichen Servern, um Redundanz im Falle des Ausfalls eines Servers zu garantieren. DRBD verfügt über mehrere Funktionen, um die mit Datenreplikation zumeist einhergehenden Probleme zu umgehen oder ihre Effekte abzumildern; es beherrscht etwa neben der vollsynchronen Replikation auch die semi-synchrone sowie die asynchrone Replikation. Ebenso unterstützt es mehrere Netzwerktransportmedien. Das Activity Log stellt sicher, dass nicht der komplette Inhalt eines Blockgerätes zwischen den Knoten eines Hochverfügbarkeitsclusters erneut synchronisiert werden muss, falls die Netzwerkverbindung zwischen den beiden Systemen abbricht.
Basisfunktionalität DRBD nutzt für die Kommunikation mit einem Blockgerät die Blockspeichergerä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: +RolleVerbindung aktivWarte auf VerbindungVerbindung getrenntPrimaryPrimary / ConnectedPrimary / Connecting oder WFConnectionPrimary / StandAloneSecondarySecondary / ConnectedSecondary / Connecting oder WFConnectionSecondary / StandAlone
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