DRBD: RAID 1 über LAN [prontosystems.org]

Sie befinden sich hier: home » Linux / UNIX » DRBD: RAID 1 über LAN

Wiki Quicklinks:

Galerie

Inhaltsverzeichnis

DRBD: RAID 1 über LAN

DRBD: RAID 1 über LAN

Eine weitere Form der Datenredundanz mit gespiegelten Volumes (RAID 1) bietet »DRBD«¹⁾ »Distributed Replicated Block Device«. Hier wird jedoch das Volume oder die Festplatte nicht lokal gespiegelt, sondern über das Netzwerk auf ein Volume in einen anderen Rechner. Dadurch wird ein Hochverfügbarkeits-Cluster (HA-Cluster) erstellt, was nicht nur den Ausfall einer Platte kompensieren kann, sondern den Ausfall des gesamten Rechners abfangen kann.

DRBD legt sich dazu als Zwischenschicht zwischen dem lokalen Filesystem und dem lokalen Volume (»Primary Node«) und kommuniziert über das Netzwerk mit seinem Spiegelpartner auf dem anderen Rechner (»Secondary Node«). Die Änderungen am »Primary Node« werden nun Blockweise über das Netzwerk auf den »Secondary Node« übertragen. Bestimmte Modi (Synchron, Asynchron) bestimmen dabei das Verhalten der Spiegelung. Beim »Synchronous Mirroring« werden die Daten sofort auf den »Secondary Node« übertragen und die Transaktion gilt erst als abgeschlossen, wenn beide Nodes die Daten vollständig erhalten haben. Dieser Modus wird in der DRBD-Terminologie »Protocol C« genannt. Beim »Asynchronous Mirroring« hingegen gilt die Transaktion bereits als abgeschlossen, wenn der »Primary Node« die Daten geschrieben hat. Die findet Verwendung in Fällen, wo die beiden Nodes über eine lange Distanz und langsameren Netzwerken (zB über das Internet) gespiegelt werden, weil andernfalls die Performance des aktiven Nodes durch das langsame Netzwerk ausgebremst wird.

Die meisten Dateisysteme (ext3/4; JFS; XFS etc) sind so konstruiert, dass sie nicht gemeinsam mehreren Rechnern gleichzeitig zur Verfügung gestellt werden können, so dass die Daten immer nur am »Primary Node« zur Verfügung stehen. Um die Daten auch auf dem »Secondary Node« zur Verfügung zu haben, bzw ein »Primary-Primary« Setup zur Verfügung zu haben, könnte aber ein Dateisystem verwendet werden, welches es mehreren Rechner ermöglicht auf einen gemeinsamen Speicher zuzugreifen (zB GFS²⁾).

Dieses Tutorial beschreibt die Erstellung eines HA-Clusters mit zwei Debian Squeeze Fileserver, wobei die Datenpartition über das Netzwerk gespiegelt wird. Es wird im »Synchronous Mode« mit »ext3« betrieben.

Vorbereitungen

Es werden zwei Server mit jeweils einer unpartitionierten Platte »sdb« verwendet:

server1: 192.168.167.135
server2: 192.168.167.136

Beide Server müssen sich mit ihrem Hostnamen ansprechen können, dazu werden, sofern kein DNS-Record dafür zur Verfügung steht, die lokalen hosts-Dateien der beiden Server entsprechend konfiguriert:

Die Datei »/etc/hosts« entspricht auf beiden Rechnern:

/etc/hosts

127.0.0.1 localhost
127.0.1.1 server2.localdomain server2
192.168.167.135 server1 192.168.167.136 server2

# The following lines are desirable for IPv6 capable hosts
…

Bei Synchronisationen über mehrere Rechner hinweg ist es wichtig, dass alle involvierten Rechner die gleiche Zeit eingestellt haben. Synchronisieren Sie die Zeit der verwendeten Server mit geeigneten Mitteln, zB mit »ntpdate«

Partitionieren Sie die beiden leeren Festplatten der Server mit jeweils einer gleichgroßen Partition. Sie können die gesamte Platte verwenden oder auch nur einen teil davon, beiden Partitionen, welche gespiegelt werden sollen, sollten aber idealerweise gleich groß sein. Verwenden Sie dazu zB das »fdisk« Kommando. Installieren Sie aber noch kein Dateisystem.

Installation und Konfiguration von DRBD

Installieren Sie das Paket »drbd8-utils« aus dem Debian Repository auf beiden Nodes oder laden Sie sich die Quellen der benötigten Kernel-Module direkt von der Homepage von drbd.org:

# aptitude update
# aptitude install drbd8-utils

Für den hier verwendeten Kernel »2.6.32« bietet das Debian Repository die DRBD Version »8.3.7« an, auf der DRBD-Seite hingegen wird die Version »8.3.8« angeboten. Wer also die aktuellste Version für seinen Kernel haben möchte, muss sich diese selbst bauen, wir verwenden hier die Debian Repository Version.

Um einen Neustart der Server zu vermeiden, laden wir die Kernel-Module auf beiden Nodes selbst:

# modprobe drbd

Zur Kontrolle:

 lsmod | grep drbd
drbd                  173348  3 
lru_cache               4054  1 drbd
cn                      3667  1 drbd

Jetzt erstellen wir die Konfiguration in der Konfigurations-Datei »/etc/drbd.conf«. Kopieren Sie die Konfigurationsdatei dann mit gleichem Inhalt auf den zweiten Rechner:

/etc/drbd.conf

global { usage-count no; }
common { syncer { rate 30M; } }
resource r0 {
        protocol C;
        startup {
                wfc-timeout  15;
                degr-wfc-timeout 60;
        }
        net {
                cram-hmac-alg sha1;
                shared-secret "secret";
        }
        on server1 {
                device /dev/drbd0;
                disk /dev/sdb1;
                address 192.168.167.135:7788;
                meta-disk internal;
        }
        on server2 {
                device /dev/drbd0;
                disk /dev/sdb1;
                address 192.168.167.136:7788;
                meta-disk internal;
        }
}

In dieser Konfigurationsdatei ist wichtig, dass die Servernamen der beiden Kommunikationspartner dem der Ausgabe von »uname -n« entsprechen:

# uname -n
server1

respektive:

# uname -n
server2

Die restlichen Parameter der Konfigurationsdatei:

uasge-count: Diese Option gibt an, ob eine statistische Erfassung über die Benutzung von DRBD an den Hersteller übertragen werden soll, wenn eine neue Version von DRBD installiert wird. Wir lehnen dies ab, in dem wir diese Option auf »no« setzen.
syncer rate: Gibt die Geschwindigkeit an, mit welcher die beiden Server ihre DRBD-Dateisysteme synchronisieren, angegeben in MB/s. Hier ist darauf zu achten, dass der Wert dem langsamsten Glied in der Kette entsprechend angepasst wird. Als Empfehlung werden 30% des maximal möglichen Replikations-Durchsatzes angegeben. Das bedeutet bei einem Gigabit-Netzwerk mit (netto) ca. 100MB/s Durchsatz und einer Festplatte mit ca. 180MB/s Durchsatz ist das Netzwerk der Flaschenhals. Demnach ergibt 100 * 0,3 eine empfohlene Synchronisationsrate von 30MB/s.
protocol C: Gibt den oben bereits angesprochenen Synchronisations-Modus an (hier »Synchronous Mirroring«)
wfc-timeout: Beim Booten des Systems wird der Bootvorgang durch das DRBD init-Skript solange angehalten, bis die DRBD Ressourcen verbunden sind. Die Angabe »wfc-timeout« setzt hier ein Limit durch die Angabe der Sekunden, wie lange maximal gewartet wird.
degr-wfc-timeout: Gibt die Zeitspanne an, wie lange auf ein Cluster gewartet werden soll, nachdem es als »degraded« markiert worden war. Der »degraded-Status« tritt ein, wenn ein Node wegen eines Crashes oder ähnlichem ausfällt. Meldet sich der Replikationspartner innerhalb dieser Zeitspanne nicht, geht der andere Node davon aus, dass sein Partner ausgefallen ist.
cram-hmac-alg: Gibt den Algorithmus an, mit welchem die Authentifizierung der Cluster-Partner untereinander verschlüsselt wird. Der verwendete Algorithmus muss in »/proc/crypto« spezifiziert sein.
shared-secret: Gibt das Passwort an, mit welchem sich die Cluster-Partner authentifizieren. Dies kann bis zu 64 Zeichen lang sein. Diese Authentifizierung ist solange deaktiviert, solange kein »cram-hmac-alg« angegeben wird.

Eine vollständige Dikumentation der verfügbaren Optionen und Parameter finden Sie im DRBD Users Guide

Die restlichen Angaben unter »server1« resp. »server2« geben das Volume, die Platte, die IP-Adresse und den Hostnamen des jeweiligen Peers an.

Im Anschluss daran initialisieren wir das »Meta Data Storage«³⁾ Dort werden einige Informationen bzgl. der Größe des DRBD-Device, dem »Generation-Identifier«⁴⁾, einem »Acitivity-Log«⁵⁾ und einiges mehr gespeichert.

Dazu führen wir folgendes Kommando an beiden Nodes aus:

# drbdadm create-md r0
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.

Danach starten wir DRBD an beiden Nodes:

root@server1:~# /etc/init.d/drbd start
Starting DRBD resources:[ d(r0) s(r0) n(r0) ]..........
***************************************************************
 DRBD's startup script waits for the peer node(s) to appear.
 - In case this node was already a degraded cluster before the
   reboot the timeout is 60 seconds. [degr-wfc-timeout]
 - If the peer was available before the reboot the timeout will
   expire after 15 seconds. [wfc-timeout]
   (These values are for resource 'r0'; 0 sec -> wait forever)
 To abort waiting enter 'yes' [  14]:

Hier am ersten Server, welcher gestartet wird sehen wir zB den Hinweis, welcher durch die beiden og Optionen »wfc-timeout« und »degr-wfc-timeout« verursacht wird. Wird der zweite Node gestartet fehlt dieser Hinweis, weil der Replikationspartner zur Verfügung steht:

root@server2:~# /etc/init.d/drbd start
Starting DRBD resources:[ d(r0) s(r0) n(r0) ].

Jetzt machen wir »server1« zum »Primary Node«:

root@server1:~# drbdadm -- --overwrite-data-of-peer primary all

Danach startet die Synchronisation beider Nodes. Die kann in der Datei »/proc/drbd« nachvollzogen werden:

root@server1:~# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757 
 0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r----
    ns:1012684 nr:0 dw:0 dr:1013960 al:0 bm:61 lo:0 pe:5 ua:34 ap:0 ep:1 wo:b oos:1083804
	[========>...........] sync'ed: 48.5% (1083804/2096348)K
	finish: 0:00:23 speed: 45,136 (31,640) K/sec

root@server2:~# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757 
 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r----
    ns:0 nr:1370112 dw:1370112 dr:0 al:0 bm:83 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:726236
	[============>.......] sync'ed: 65.5% (726236/2096348)K
	finish: 0:00:20 speed: 35,192 (31,136) K/sec

In dieser Ausgabe können Sie den Status der Synchronisation entnehmen und ob der abgefragte Server zZ der »Primary-« oder der »Secondary-Node« ist. Die sehen das an der Reihenfolge in der Angabe »cs:SyncSource ro:Primary/Secondary«

Jetzt haben wir ein RAID 1 Blockdevice über LAN etabliert. Damit es benutzt werden kann muss jetzt noch ein Dateisystem angelegt. Dies muss nur auf dem »Primary Node« durchgeführt werden!

root@server1:~# mkfs.ext3 /dev/drbd0

Ein Mountpoint angelegt werden und das neue Volume dort eingehängt werden:

root@server1:~# mkdir /drbd_data
root@server1:~# mount /dev/drbd0 /drbd_data

Testen des Setups

Im Prinzip ist unser »RAID 1 over LAN« jetzt einsatzbereit. Wir können das testen in dem wir auf dem »Primary-Node« eine Datei erzeugen und auf dem »Secondary-Node« die Netzwerk- und Festplatten-Aktivität dazu beobachten:

root@server1:~# dd if=/dev/zero of=/drbd_data/testfile.dd bs=1024 count=500000
500000+0 Datensätze ein
500000+0 Datensätze aus
512000000 Bytes (512 MB) kopiert, 7,24433 s, 70,7 MB/s

Während die Datei »/drbd_data/testfile.dd« auf dem »Primary-Node« angelegt wird, können wir auf dem »Secondary-Node« sowohl eine entsprechende Netzwerk- wie auch eine entsprechende Festplattenaktivität auf »/dev/eth0« bzw. »/dev/sdb« feststellen:

root@server2:~# dstat -dn -D sdb -N eth0
--dsk/sdb-- --net/eth0-
 read  writ| recv  send
 169B  558k|   0     0 
   0     0 |  66B  338B
   0     0 | 317B  194B
   0    16M|  17M  350k
   0    45M|  47M  988k
   0    49M|  52M 1098k
   0    52M|  55M 1126k
   0    51M|  54M 1118k
   0    51M|  54M 1117k
   0    51M|  54M 1093k
   0    60M|  63M 1296k
   0    29M|  31M  605k
   0     0 |  66B  210B
   0    36M|  38M  774k
   0    49M|  52M 1051k
   0     0 |  66B  210B^C

Das zeigt an, dass die Synchronisation beider Nodes offensichtlich funktioniert. Aufgrund der oben bereits erwähnten Eigenschaft des »ext3« Dateisystems, nicht als »multi-homed« fungierend zu können, kann dies auf dem »Secondary-Node« nicht so ohne Weiteres nachgeprüft werden. Es liegt jedoch in der Natur der DRBD-Nodes, dass diese umgekehrt werden können, was bedeutet, dass der »Primary-Node« zum »Secondary-Node« gemacht werden kann.

Hängen Sie dazu zuerst das DRBD-Volume aus dem Dateisystem des »Primary-Nodes« ab:

root@server1:~# umount /drbd_data

Und weisen diesem (»server1«) nun die Rolle des »Secondary-Nodes« zu:

root@server1:~# drbdadm secondary r0

Und dem »server2« weisen wir die Rolle des »Primary-Nodes« zu:

root@server2:~# drbdadm primary r0

Wir können das umgekehrte Kräfteverhältnis nun an der Ausgabe der Datei »/proc/drbd« nachvollziehen:

root@server2:~# cat /proc/drbd 
version: 8.3.7 (api:88/proto:86-91)
srcversion: EE47D8BF18AC166BE219757 
 0: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:4167012 dw:4167012 dr:200 al:0 bm:128 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

Abschließend muss (einmalig) noch der Mountpoint für das DRBD-Volume angelegt werden. Dieser muss nicht gleich sein, wie auf »sever1«, kann aber. Danach mounten wir das DRBD-Volume und kontrollieren den Inhalt:

root@server2:~# mkdir /drbd_data
root@server2:~# mount -t ext3 /dev/drbd0 /drbd_data
root@server2:~# ls -l /drbd_data/
insgesamt 500512
drwx------ 2 root root     16384 30. Dez 17:00 lost+found
-rw-r--r-- 1 root root 512000000 30. Dez 17:16 testfile.dd

Funktioniert soweit, auch wenn dieses Setup noch etwas einfach gehalten ist. Als weitere Maßnahme wäre zB zu empfehlen, die beiden Server mit jeweils zwei Netzwerkkarten auszustatten und die direkte Verbindung der Replikationspartner über die zusätzliche Netzwerkkarte zu realisieren. Dadurch ließe sich die Performance signifikant anheben, weil dadurch die Replikation zwischen den beiden Nodes nicht das eigentliche Netzwerkinterface belastet.

— pronto 2012/12/31 13:42

¹⁾ http://www.drbd.org/home/what-is-drbd/

²⁾ http://de.wikipedia.org/wiki/Global_File_System

³⁾ http://www.drbd.org/users-guide/ch-internals.html

⁴⁾ http://www.drbd.org/users-guide/s-gi.html

⁵⁾ http://www.drbd.org/users-guide/s-activity-log.html

tux/drbd_lan_raid1.txt (12142 views) · Zuletzt geändert: 2013/01/03 15:01 von wikisysop

Zeige Quelltext Ältere Versionen

Medien-Manager Nach oben