Hochverfügbarkeit – Shared Storage mit DRBD

Ausfälle von IT-Systemen können in Unternehmen gravierende Folgen nach sich ziehen, sogar bis zum Existensverlust führen. Die IT-Systeme sind oftmals das teuerste Gut, der Kern des Geschäftsmodells oder zwingend zur Erbringung der eigentlichen Kernkompentenz erforderlich.

Um sich vor Ausfällen zu schützen gibt es vielfältige Möglichkeiten, von Fehlertolerenz über Redundanz bis hin zu Clustersystemen sind Lösungen auf dem Markt erhältlich. All diese Möglichkeiten kann man unter dem Oberbegriff Hochverfügbarkeit zusammen fassen. Für den eigenen Anwendungsfall ist es daher unerläßlich die konkreten Anforderungen an Ausfallsicherheit und Verfügbarkeit genau zu spezifizieren. Wir helfen Ihnen natürlich gern dabei!

In früheren Zeiten war Hochverfügbarkeit nur durch teure und proprietäre Speziallösungen zu erreichen. Mittlerweile sind aber auch preiswerte Lösungen erhältlich, zum Teil bereits in Linux Distributionen bzw. im Linux Kernel integriert. Sie verwenden unterschiedliche Technologien, bieten dementsprechend Verfügbarkeit auf unterschiedlichem Niveau und unterscheiden sich natürlich auch hinsichtlich der Kosten.

Eine zentrale Komponente in verschiedenen Hochverfügbarkeitszenarien ist die Datenablage, der Speicher. Seit Kernel Version 2.6.33 ist das Distributed Replicated Block Device(DRBD) als Modul im Kernel implementiert. Der DRBD Stack ist im Prinzip ein Raid 1 über eine TCP/IP Verbindung. Es werden alle Schreibzugriffe auf ein Blockdevice vom einem Server auf einem zweiten Server syncronisiert. Sobald die Daten auf dem zweiten Server geschrieben werden erfolgt erst die Rückmeldung auf dem ersten Server. Nachfolgender Beitrag zeigt die Installation und Konfiguration von DRBD auf zwei openSuSE 11.3 Systemen. Das volle Potential von DRBD wird allerdings erst in Hochverfügbarkeitslösungen mit z.B. Heartbeat ausgeschöpft, darauf gehe ich allerdings in diesem Artikel nicht weiter ein.

Folgende Information noch am Rande: DRBD wurde von Philipp Reisner und Lars Ellenberg entwickelt, beide von der österreichischen Firma Linbit, welche DRBD auch supportet. Mittlerweile aktuell ist die Version 8.3, diese wird auch hier verwendet.

Als erstes benötigen wir zwei identische openSuSE 11.3 Installationen. Auf die Art und Weise der Ausprägung, ob virtualisiert oder nicht, welche Komponenten in produktiven Systemen reduntant ausgelegt werden sollten usw. lass ich jetzt mal außen vor.

OpenSuSE 11.3 bringt bereits alle benötigten Programmkomponenten mit. Ein rpm -qa| grep drbd zeigt an, ob eventuell schon DRBD Komponenten installiert sind. Ist das nicht der Fall, installieren wir entweder grafisch per Yast oder auf Kommandozeile auf beiden Servern alle erforderlichen Programmpakete:

# yast -i drbd yast2-drbd

Nun ist auf beiden Servern das Kernel Modul zu laden:

# modprobe drbd

Damit das Modul auch beim Neustart des Servers zur Verfügung steht, ist drbd in der MODULES_LOADED_ON_BOOT Sektion in der Datei /etc/sysconfig/kernel einzutragen.

# sed -i.backup ‘/MODULES_LOADED_ON_BOOT/ s/”$/drbd”/’ /etc/sysconfig/kernel

Als nächstes benötigen wir die Konfigurationsdatei drbd.conf aus dem Verzeichnis /etc. Die vorhandene drbd.conf ist allerdings leer und verweist auf das Beispiel unter /usr/share/doc/packages/drbd/drbd.conf. Das Beispiel ist sehr gut kommentiert. Die drbd.conf gliedert sich in mehrere Abschnitte, die durch geschweifte Klammern getrennt sind. Dieses sind unter anderem global für allgemeine Parameter wie minor-count(reserviert Ressourcen für Devices im Modul), common für syncer Einstellungen wie z.B. die Bandbreite für die Syncronisation und der Abschnitt ressource für die einzelnen DRBD-Devices. Für jedes DRBD-Devices ist ein separater ressource Abschnitt notwendig. Im ressource Abschnitt wird unter anderem das DRBD-Device und die Disk bzw. Partition, das Connection Handling und weitere Parameter für den Fehlerfall, Timeouts usw. konfiguriert

Wichtig sind hier die Connection Handling bzw. Transfer Protokoll Einstellungen. Es sind die Modi A,B und C vorhanden. Der Modus A ist am schnellsten, hier gilt der Schreibvorgang als abgeschlossen, sobald die Daten zum zweiten Server gesendet sind. Der Modus B ist ein Kompromiss zwischen den beiden Modi A und C. Der Modus C ist die sicherste Variante, hier gilt der Schreibvorgang als abgeschlossen, sobald die Daten auf dem zweiten Server auch auf Platte geschrieben wurden und eine Bestätigung des Schreibvorgangs beim ersten Server angekommen ist.

In unserem Beispiel verzichten wir auf LVM oder EVMS. Wir haben auf beiden Servern ein identisches Partitionslayout und nutzen die Disk /dev/sdb1. Das DRBD-Device heißt auf beiden Servern drbd0. Unsere drbd.conf sieht dann folgender Maßen aus:

global {
dialog-refresh 1;
minor-count 5;
usage-count no;
}
common {
syncer {
rate 10M;
}
}
resource r0 {
protocol C;
disk {
on-io-error pass_on;
}
syncer {
}
net {
}
startup {
}
on server1 {
device /dev/drbd0;
address 192.168.10.15:6789;
meta-disk internal;
disk /dev/sdb1;
}
on server2 {
device /dev/drbd0;
address 192.168.10.6:6789;
meta-disk internal;
disk /dev/sdb1;
}
}

Danach ist mit dem DRBD Admin Werkzeug drbadm auf beiden Servern das DRBD-Device anzulegen.

# drbdadm create-md r0
# drbdadm up all

Beim drbdadm create-md r0 wird einmalig eine Verbindung zum Server usage.drbd.org hergestellt und eine eindeutige ID für die Installation generiert. Das ganze geschieht anonym und nur bei der ersten Initialisierung. Dieser Prozess kann durch den Parameter usage-count no in der global Sektion in der drbd.conf auch ausgeschaltet werden. Die Partition oder das Device sollte nicht formatiert sein oder gemountet sein. Ist dieses der Fall, kann es zu unten stehender Fehlermeldung kommen.

md_offset 2146430976
al_offset 2146398208
bm_offset 2146332672
Found ext3 filesystem
2096128 kB data area apparently used
2096028 kB left usable by current configuration
Device size would be truncated, which
would corrupt data and result in
‘access beyond end of device’ errors.
You need to either
* use external meta data (recommended)
* shrink that filesystem first
* zero out the device (destroy the filesystem)
Operation refused.
Command ‘drbdmeta 0 v08 /dev/sdb1 internal create-md’ terminated with exit code 40
drbdadm create-md r0: exited with code 40

Entweder man löscht das Device/Partition und legt sie neu an oder man schreibt mit dem dd auf die Platte. Danach kann create-md fehlerfrei ausgeführt werden.

# dd if=/dev/zero of=/dev/sdb1 bs=1M count=128

Nun kann auf beiden Knoten der DRBD-Service gestartet werden.

# /etc/init.d/drbd start

Das Ergebnis des vorherigen Befehls führt auf beiden Knoten zu einem inkonsistenten Cluster.

server1:~ # cat /proc/drbd
version: 8.3.4 (api:88/proto:86-91)
GIT-hash: 70a645ae080411c87b4482a135847d69dc90a6a2 build by phil@fat-tyre, 2009-10-06 14:36:06
0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Diskless 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:2096348

Als nächstes müssen wir die Prioritäten der Knoten festlegen. Der server1 ist im Beispiel unser primärer Knoten, der server2 ist der sekundäre Knoten. D.h. die Daten werden von server1 nach server2 repliziert. Folgender Befehl, auf server1 ausgeführt, stößt die initiale Konfiguration an und erklärt server1 zum primären Knoten:

# drbdadm — -o primary r0

Alle Statusinformationen, auch der Erfolg des eben ausgeführten Kommandos, sind in /proc/drbd zu sehen.

server1:~ # cat /proc/drbd
version: 8.3.4 (api:88/proto:86-91)
GIT-hash: 70a645ae080411c87b4482a135847d69dc90a6a2 build by phil@fat-tyre, 2009-10-06 14:36:06
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r—-
ns:1095680 nr:0 dw:0 dr:1095936 al:0 bm:66 lo:0 pe:24 ua:0 ap:0 ep:1 wo:b oos:1001116
[=========>..........] sync’ed: 52.4% (1001116/2096028)K
finish: 0:01:38 speed: 10,180 (8,688) K/sec

Der jeweilige Server gibt seine eigene Rolle und seinen Zustand immer als erstes an, d.h. ro:Primary/Secondary ds:UpToDate/Inconsistent zeigt, das server1 der Primäre ist und sein Laufwerkszustand ist aktuell. Beim server2 sieht es umgekehrt aus: ro:Secondary/Primary ds:Inconsistent/UpToDate. Nach dem der Sync erfolgreich war, ist der Zustand auf beiden Knoten UpToDate. Danach kann auf dem primären Server, in unserem Fall server1, auf das DRBD-Device ein Filesystem angelegt werden und das Filesystem kann dann gemountet werden.

# mkfs.ext4 /devdrb0
# mount /dev/drb0 /appl

Unser Verzeichnis /appl ist jetzt sozusagen das Verzeichnis der Anwendung oder der Datenbank oder des Webservers. Wir können jetzt hier zum testen ein paar Dateien anlegen.

Um die neu erstellte Ressource auch auf unserem server2 zu sehen, ist der Status des Clusters zu ändern. Server1 wird sekundär und server2 primär. Folgende Schritte sind dafür auf server1 notwendig:

server1:~ # umount /dev/drbd0
server1:~ # drbadm secondary r0

Der Status der Änderungen läßt sich natürlich wieder in /proc/drbd sehen. Server2 ist jetzt noch zum primären Server zu erklären:

server2:~ # drbadm primary r0
server2:~ # mount /dev/drbd0 /appl

Unsere angelegten Dateien aus dem /appl Verzeichnis sind nun auf server1 zu sehen. Wie bereits erwähnt, läßt sich die volle Funktionalität erst mit Heartbeat erreichen. Hier übernimmt Heartbeat dann auch automatisch die zuletzt manuell aufgeführten Schritte des Mountens und Umschaltens.

Richtig interessant wird DRDB beim Einsatz von Cluster Filesystemen wie z.B. Oracle’s Cluster Filesystem 2 (OCFS2). Da hier beide Systeme im Cluster als aktiv gelten, kann auf beiden geschrieben werden. Bei DRBD nennt sich eine solche Konfiguration Multi-Primary-Betrieb.

Mit DRBD ab Version 8.3 lässt sich sogar dreifache Datenhaltung implementieren. Hierbei wird zusätzlich ein dritter Knoten im Cluster integriert, zu welchem die Daten repliziert werden. Im Gegensatz zum teuren SAN, lassen sich DRBD Hochverfügbarkeitslösungen mit Standard Festplatten realisieren. DRBD ist natürlich auch eine alternative für die Cloud.

Linbit hat eine tolle Management-Oberfläche für DRBD und Heartbeat/Pacemaker entwickelt. Das Tool ist Open Source und unter GPL v3 veröffentlicht.

One Response to “Hochverfügbarkeit – Shared Storage mit DRBD”
  1. Webhosting 12 Februar 2011 at 15:22 #

    Hallo,

    kann das drbd Device auch beim booten automatisch gemountet werden?