Einführung in DRBD

Ping Pong

Datenbestände von Hand zu synchronisieren ist ein mühsames Geschäft. Einfacher und zuverlässiger geht das mit DRBD, das Partitionen auf Block-Device-Ebene repliziert.
Im Zentrum stehen dieses Mal Tools, mit denen sich Administratoren das Leben einfacher machen, indem sie Aufgaben automatisieren und skripten: ... (mehr)

Um Daten zwischen zwei Servern zu synchronisieren, bietet sich zunächst Rsync an, denn es ist zuverlässig, schnell und nicht schwer zu konfigurieren. Aber Rsync arbeitet asynchron, und wenn man nicht immer wieder in kurzen Abständen synchronisiert, ist der Datenbestand zwischen den beiden Maschinen nach kurzer Zeit nicht mehr up to date.

DRBD [1] kann diese Lücke schließen. Die Abkürzung steht für "Distributed Replicated Block Device". DRBD erzeugt auf den beiden Servern ein spezielles Block-Device, das auf einer normalen physischen Partition, einem RAID oder einem logischen Volume liegen kann. Dieses Blockdevice formatiert der Admin mit einem normalen Dateisystem und mountet es auf einem der beiden Server. Daten, die dorthin geschrieben werden, landen automatisch auf dem Zwillings-Blockdevice auf dem zweiten Server ("RAID-1 übers Netz"). Ist Server Nummer Eins wegen einer Wartung oder eines Ausfalls unpässlich, kann der zweite Server die Partition mounten und die Daten nutzen. Sobald Nummer Eins den Ring wieder betritt, werden die in der Zwischenzeit veränderten Daten wieder abgeglichen.

Mit der aktuellen DRBD-Version können Sie auch Setups realisieren, in denen beiden Knoten gleichzeitig das DRBD-Device mounten und nutzen dürfen, man spricht hier von einer Active/Active- oder Master/Master-Konfiguration. Dafür ist allerdings ein Dateisystem vonnöten, das Schreibkonflikte erkennen und verhindern kann, beispielsweise Oracles OCFS2 (siehe [2]). Ext3/4, ReiserFS, XFS und Kollegen sind in einer solchen Konfiguration nicht brauchbar. Das folgenden Kochrezept konzentriert sich auf eine klassische Active/Passive-Konfiguration, in der nur eine der beiden Seiten gemountet sein darf. Die ganze Konfiguration passiert auf der Kommandozeile, allerdings gibt es mittlerweile auch eine grafische Oberfläche zur DRBD-Konfiguration (Abbildung 1).

Abbildung 1: Eine GUI erlaubt die Konfiguration von DRBD, befindet sich aber noch in stetiger Entwicklung.

Die beiden Server heißen »host1« und »host2« . Sie haben jeweils eine Partition namens »/dev/sdb1« – wie erwähnt, ist es für den DRBD-Einsatz unerheblich, ob es sich dabei um ein LVM-Volume oder irgendeine Art von Hardware handelt – die 5 GByte groß ist. Nach der Installation der DRBD-Pakete kann es losgehen. Je nach Distribution können alle benötigten Komponenten in einem Paket oder in zweien, Module oder Source und DRBD-Utilities, vorliegen. In letzterem Fall installieren Sie beide Pakete.

Konfiguration

Die Konfigurationsdatei »drbd.conf« besteht aus mindestens drei Abschnitten. Die beiden ersten heißen »global« und »common« und sehen beispielsweise so aus:

global {
usage-count yes;
}
common {
syncer rate 100M;
}

Natürlich lässt sich hier noch wesentlich mehr konfigurieren, aber das ist für den Einstieg nicht notwendig. »Usage-count yes« bedeutet, dass Sie an der Zählung der weltweiten DRBD-Installationen teilnehmen. Wenn Sie DRBD zum ersten Mal in Betrieb nehmen, erhalten Sie eine Meldung wie diese:

Thank you for participating in the ↩
global usage survey
The server's response is:
you are the 12277th user to install this ↩
version

Die Option »syncer rate 100M« definiert die Geschwindigkeit, mit der die beiden Server ihre DRBD-Dateisysteme synchronisieren. Achtung: Die Einheit ist Byte pro Sekunde, nicht Bit pro Sekunde – der Wert 100 enspricht also etwas weniger als einem GBit/s.

Der dritte Abschnitt in der »drbd.conf« ist die Ressourcenkonfiguration. Ein Verbund aus zwei DRBD-Devices, die miteinander synchronisiert werden, ist eine Ressource. Für das Beispiel sieht der dritte Abschnitt so aus wie in Listing 1.

Listing 1

DRBD-Ressource

resource meinFS {
net {
cram-hmac-alg sha1;
shared-secret "geheim";
}
on host1 {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.7.1:7789;
}
on host2 {
device /dev/drbd0;
disk /dev/sdb1;
address 192.168.7.2:7789;
}

Der Name der Ressource, hier »meinFS« , darf frei gewählt werden. Das »shared-secret« verhindert unter anderem, dass sich mehrere Ressourcen auf dem gleichen Server ins Gehege kommen. Verwenden Sie also für jede Ressource ein anderes Secret. Nach dem Schlüsselwort »on Servername« beginnt die Server-spezifische Konfiguration. Den Anfang macht der Servername in der Form, wie er in der »/etc/hosts« steht. Hinter »device« folgt der Name des Blockdevices, der bei allen künftigen Dateioperationen (zum Beispiel Formatieren) genutzt wird, hier »/dev/drbd0« . Der »disk« -Name ist nur für DRBD selbst wichtig – es muss ja wissen, auf welcher "realen" Partition es arbeiten soll – aber für den Admin künftig tabu. Zuletzt konfiguriert »address« die IP-Adresse des Knotens.

Hinweis: Auf Ubuntu-Systemen ist die Konfiguration in mehrere Dateien aufgeteilt, die unter »/etc/drbd.d/« liegen. Die Abschnitte »global« und »common« sind in der Datei »global_common.conf« untergebracht. Die Konfiguration jeder Ressource kommt in eine eigene Datei, deren Name auf ».res« enden muss. Für das obige Beispiel würde sich der Name »meinFS.res« anbieten.

Die Konfigurationsdatei muss auf beiden Servern absolut identisch sein. Außerdem darf auf den (logischen) Partitionen, die für DRBD genutzt werden sollen, noch kein Dateisystem angelegt sein. Jetzt können Sie mit

service drbd start

den DRBD-Daemon starten. Der Befehl

cat /proc/drbd

verrät, in welchem Status sich die DRBD-Ressource befindet. Die Ausgabe wird etwa so aussehen wie in Listing 2.

Listing 2

DRBD-Start

root@host1:~# cat /proc/drbd
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: d29f21dbaf94e319a62bcbef67a613aa01fe5a1c build by root@host1, 2010-10-04 18:22:41
0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:2211150

Am Schlüsselwort »inconsistent« ist erkennbar, dass die beiden Seiten noch nicht synchron sind. Die Synchronisierung beginnt erst, wenn eine der beiden Seiten zum Primary-Status befördert wird:

drbdadm -- --overwrite-data-of-peer ↩
primary meinFS

Der Zusatz »--overwrite-data-of-peer« ist nur beim ersten Mal notwendig. Der Datenbestand der beiden Knoten (der momentan nur aus Müll besteht, da immer noch kein Dateisystem angelegt wurde) wird nun synchronisiert. Das kann je nach Größe der Partition und Geschwindigkeit der Datenverbindung zwischen den beiden Knoten ein Weilchen dauern, aber man kann DRBD mit

watch "cat /proc/drbd"

dabei über die Schulter schauen. Während des Synchronisierens sieht die Ausgabe etwa so aus wie Listing 3.

Listing 3

Synchronisierung

version: 8.3.7 (api:88/proto:86-91)
GIT-hash: d29f21dbaf94e319a62bcbef67a613aa01fe5a1c build by root@host1, 2010-10-04 18:22:41
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r----
ns:812731 nr:0 dw:0 dr:868385 al:0 bm:58 lo:1 pe:19 ua:256 ap:0 ep:1 wo:b oo
s:3522193
[==>.................] sync'ed: 18.2% (3317/4764)M
finish: 0:07:01 speed: 9,181 (19,623) K/sec

Da Host 1 zum Master (Primary) erklärt wurde, ist sein Datenbestand automatisch im Status »UpToDate« , Host 2 bleibt bis zum Abschluss des Vorgangs auf »Inconsistent« und wechselt danach ebenfalls auf »UpToDate« . Nach dieser Generalprobe versehen Sie die Primary-Partition endlich mit einem Filesystem, hier Ext3:

mkfs.ext3 /dev/drbd0

Mounten und "manuelles Failover"

Das formatierte DRBD-Device können Sie danach wie jedes normale Filesystem mounten und danach mit Daten füllen:

mount /dev/drbd0 /mnt

Falls Sie nun Host 1 einmal abschalten müssen und den Datenbestand auf Host 2 mounten wollen, genügen wenige Befehle. Auf Host 1:

umount /mnt
drbdadm -- secondary meinFS

Auf Host 2 sehen die Befehle so aus:

drbdadmin - primary meinFS
mount /dev/drbd0 /mnt

Diese Aufgabe kann, wenn das System hochverfügbar ausgelegt werden soll, auch einem Cluster Resource Manager wie Pacemaker übertragen werden. Beim Ausfall oder der geplanten Wartung eines Servers zieht die DRBD-Ressource dann automatisch um.

Infos

  1. DRBD: http://www.drbd.org
  2. Udo Seidel, Cluster-Dateisystem OCFS2 einfach gemacht, ADMIN 03/2010, S. 44

Der Autor

Charly Kühnast administriert Unix-Systeme im Rechenzentrum Niederrhein in Kamp-Lintfort. Zu seinen Aufgaben gehören die Sicherheit und Verfügbarkeit der Firewalls und der DMZ. Im heißen Teil seiner Freizeit frnt er dem Kochen, im feuchten Teil der Süßwasseraquaristik und im östlichen lernt er Japanisch.

comments powered by Disqus
Mehr zum Thema

DRBD-Replikation

Hochverfügbarkeit ist in modernen IT-Setups ein Muss. Ein kritischer Faktor ist dabei das redundante Speichern von Daten. Um dieses Problem kümmert sich LINBITs freies DRBD, das zum vollständigen Ersatz für ein SAN werden kann. Dieser Beitrag beschreibt die brandneue Version 8.4.

Artikel der Woche

Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2018