[[:tux|{{ :linux.png?40|}}]] =====DRBD: RAID 1 über LAN===== Eine weitere Form der Datenredundanz mit gespiegelten Volumes (RAID 1) bietet >>DRBD<<((http://www.drbd.org/home/what-is-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((http://de.wikipedia.org/wiki/Global_File_System))). 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: 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 [[:tux:ntp|»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 [[:tux:mkfs|»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 [[http://www.drbd.org/download/mainline/|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: 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. FIXME * **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. FIXME * **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 [[http://www.drbd.org/users-guide/re-drbdconf.html|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<<((http://www.drbd.org/users-guide/ch-internals.html)) Dort werden einige Informationen bzgl. der Größe des DRBD-Device, dem >>Generation-Identifier<<((http://www.drbd.org/users-guide/s-gi.html)), einem >>Acitivity-Log<<((http://www.drbd.org/users-guide/s-activity-log.html)) 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. **Verwandte Artikel:** [[:tux:drbd_failed_node|-> DRBD: Ausfall eines Nodes]] [[:tux:drbd_heartbeat|-> DRBD: Integration in Heartbeat]] --- //pronto 2012/12/31 13:42// {{keywords>linux debian drbd primary secondary node drbdadm overwrite-data-of-peer cram-hmac-alg synchronous asynchronous mirroring raid1 lan cluster wfc-timeout degr-wfc-timeout}}