DRBD
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 einen anderen (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.
| DRBD | |
|---|---|
 | |
| Basisdaten | |
| Maintainer | Philipp Reisner, Lars Ellenberg |
| Entwickler | LINBIT HA-Solutions GmbH, Wien und LINBIT USA LLC, Oregon |
| Aktuelle Version | 9.1.2[1] (10. Mai 2021) |
| Betriebssystem | GNU/Linux |
| Programmiersprache | C |
| Lizenz | GPL (Freie Software) |
| drbd.linbit.com/ | |
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 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 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 beiden 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[2].
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:
| Rolle | Verbindung aktiv | Warte auf Verbindung | Verbindung getrennt |
|---|---|---|---|
| Primary | Primary / Connected | Primary / Connecting oder WFConnection | Primary / StandAlone |
| Secondary | Secondary / Connected | Secondary / Connecting oder WFConnection | Secondary / 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 unzufrieden stellend 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[3]; 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.
Verwandte Lösungen
DRBD selbst bietet lediglich rudimentäre Funktionen für die knotenübergreifende Funktionalität in Hochverfügbarkeitsclustern. Seit DRBD 9 besteht etwa die Möglichkeit, eine Ressource durch DRBD automatisch in die Primary-Rolle umschalten zu lassen, falls auf diese lokal schreibend zugegriffen werden soll.
Für komplexe Installationen genügt diese Funktionalität jedoch nicht. So reicht es auf Systemen in der Regel etwa nicht, eine Ressource in die Primary-Rolle zu schalten; ergänzend dazu muss meist auch ein auf der DRBD-Ressource beheimatetes Dateisystem in das Dateisystem des Hosts eingehängt werden. Neben einem allfällig zu startenden Dienst wie einer Datenbank, die das eingehangene Dateisystem anschließend nutzt, brauchen klassische Hochverfügbarkeitscluster zudem besondere Dienste wie eine spezielle IP-Adresse auf Clusterebene, die zusammen mit den Diensten zwischen den Clusterknoten hin- und herschwenkt („Failover“). Nur so lässt sich HA-Funktionalität nämlich erreichen, ohne die Clients, die auf einen von einem Hochverfügbarkeitscluster angebotenen Dienst zugreifen sollen, umzukonfigurieren.
DRBD kommt im Kontext von Hochverfügbarkeitsclustern deshalb regelmäßig mit dem Cluster Resource Manager (CRM) des Linux-HA-Projektes, Pacemaker, sowie dessen Cluster Communication Manager (CCM), Corosync zum Einsatz. LINBIT bietet als DRBD-Betreuer einen „OCF Resource Agent“ an, mittels dessen sich DRBD-Ressourcen in Pacemaker integrieren und verwalten lassen.
Management-Werkzeuge
Die Werkzeuge, die auf der Kommandozeile dienen, um DRBD-Ressourcen zu verwalten, haben sich im Laufe der Versionsgeschichte von DRBD mehrfach geändert.
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/drbddrbd-overviewdrbdsetupdrbdadm
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[4], 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[5].
LINBIT ersetzte drbdmanage im Juli 2018 durch Linstor, um den neuen Anforderungen im Storage-Management gerecht zu werden.
Abgrenzung zu anderen Lösungen
Regelmäßig findet DRBD insbesondere in der Version 9 gleichzeitig mit anderen Speicherlösungen wie Ceph oder GlusterFS Erwähnung; auch OCFS2 oder GFS2 sind Begriffe, die im DRBD-Kontext regelmäßig fallen. Von all jenen Lösungen unterscheidet sich DRBD jedoch merklich.
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.
Vorteile gegenüber gemeinsam genutztem Cluster-Speicher
Konventionelle Computer-Cluster-Systeme benutzen in der Regel eine Art gemeinsamen Speicher, der für die Clusterressourcen benutzt wird. Dieser Ansatz hat jedoch eine Reihe von Nachteilen, die DRBD umgeht.
- Gemeinsam genutzte Speicher (Shared Storage) bringen typischerweise eine einzelne Fehlerstelle (Single Point of Failure) mit sich, da beide Clustersysteme vom gleichen gemeinsamen Speicher abhängig sind. Bei der Verwendung von DRBD besteht hier keine Gefahr, da die benötigten Clusterressourcen lokal repliziert werden und nicht auf einem eventuell wegfallenden gemeinsamen Speicher liegen. Allerdings kann in modernen SAN-Lösungen mit Spiegelungsfunktionen gearbeitet werden, welche diese früher unvermeidliche Fehlerstelle beseitigen.
- Gemeinsam genutzter Speicher wird in der Regel über ein SAN oder ein NAS adressiert, was einen gewissen Mehraufwand beim Lesezugriff erfordert. Bei DRBD wird dieser Aufwand signifikant reduziert, da Lesezugriffe immer lokal stattfinden.
Anwendungen
DRBD arbeitet innerhalb des Linux-Kernels auf Blockebene und ist damit für darauf aufsetzende Schichten transparent. DRBD kann somit als Grundlage verwendet werden für:
- konventionelle Dateisysteme
- gemeinsam genutzte Cluster-Dateisysteme wie z. B. GFS oder OCFS2
- ein weiteres logisches Blockgerät wie z. B. LVM
- jede Applikation, die den direkten Zugriff auf ein Blockgerät unterstützt.
DRBD-basierende Cluster werden eingesetzt, um z. B. Dateiserver, relationale Datenbanken (wie PostgreSQL oder MySQL) und Hypervisor/Server-Virtualisierung (wie OpenVZ) um synchrone Replikation und Hochverfügbarkeit zu erweitern.
Versionsgeschichte
Im Juli 2007 stellten die DRBD-Autoren die Software der Linux-Entwicklergemeinde für eine mögliche zukünftige Aufnahme von DRBD in den offiziellen Linux-Kernel zur Verfügung.[6] Nach zweieinhalb Jahren wurde DRBD in den Kernel 2.6.33[7], der am 24. Februar 2010[8] veröffentlicht wurde, aufgenommen.
Die kommerziell lizenzierte Version DRBD+ wurde in der ersten Hälfte des Dezembers 2008 mit der Open-Source-Version zusammengeführt und unter der GNU General Public License freigegeben. Seit der daraus resultierenden Version 8.3 ist es möglich, den Datenbestand auf einen dritten Knoten zu spiegeln. Die Höchstgrenze von 4 TiByte pro Gerät wurde auf 16 TiByte erhöht[9][10].
Seit 2012 gibt es keine Größenbeschränkung mehr pro DRBD-Device.[11] Die offizielle Nutzungsstatistik zählt rund 30.000 regelmäßig aktualisierte Installationen mit Device-Größen von bis zu 220 TB.[12]
Im Juli 2018 hat Linbit drbdmanage durch Linstor ersetzt.
Weblinks
- Offizielle Website (englisch)
- The High-Availability Linux Project (englisch)
- Einführung in DRBD (ADMIN-Magazin)
- Entwickler von DRBD
- Neue Features in DRBD9
- Die neue Version DRBD9
Einzelnachweise
- Release 9.1.2. 10. Mai 2021 (abgerufen am 11. Mai 2021).
- Linus Torvalds: linux: Linux kernel source tree. 5. Februar 2018, abgerufen am 5. Februar 2018.
- Dual Primary: Think Twice| DRBD High Availability, DR, Software-Defined Storage. In: LINBIT | DRBD High Availability, DR, Software-Defined Storage. Abgerufen am 5. Februar 2018 (amerikanisches Englisch).
- Roland Kammerer: [DRBD-user] drbdmanage v0.98. linbit.com, 28. Oktober 2016, abgerufen am 5. Februar 2018.
- drbdmanage: Management system for DRBD9. LINBIT, 15. Januar 2018, abgerufen am 5. Februar 2018.
- Lars Ellenberg: DRBD wants to go mainline. In: Linux-kernel-Mailingliste. 21. Juli 2007. Abgerufen am 21. Februar 2011.
- DRBD schafft es in den Linux-Kernel. golem.de. 10. Dezember 2009. Abgerufen am 21. Februar 2011.
- Linux 2.6.33 released. gmane.org. 24. Februar 2010. Abgerufen am 28. August 2012.
- Hochverfügbarkeitslösung DRBD+ wird Open Source. heise.de. 17. November 2008. Abgerufen am 21. Februar 2011.
- Ankündigung von DRBD 8.3 unter der GPL. LINBIT. Archiviert vom Original am 27. Dezember 2010. Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. Abgerufen am 21. Februar 2011.
- Maximum volume size on DRBD. Linbit. 2. April 2012. Archiviert vom Original am 27. August 2013. Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis. Abgerufen am 23. August 2013.
- Usage Page. Abgerufen am 28. August 2014.
