Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

--- tux:drbd_lan_raid1 [2012/12/31 13:17]
wikisysop [Ausfall eines Nodes]
+++ tux:drbd_lan_raid1 [2013/01/03 15:01] (aktuell)
wikisysop [Installation und Konfiguration von DRBD]
@@ Zeile 1: / Zeile 1: @@
 [[:tux|{{ :linux.png?40|}}]]
-=====RAID 1 über LAN mit DRBD=====
+=====DRBD: RAID 1 über LAN=====
 Eine weitere Form der Datenredundanz mit gespiegelten Volumes (RAID 1) bietet >><fc #008000>DRBD</fc><<((http://www.drbd.org/home/what-is-drbd/)) >><fc #008000>Distributed Replicated Block Device</fc><<. 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 (>><fc #008000>Primary Node</fc><<) und kommuniziert über das Netzwerk mit seinem Spiegelpartner auf dem anderen Rechner (>><fc #008000>Secondary Node</fc><<). 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 >><fc #008000>Synchronous Mirroring</fc><< 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 wir in der DRBD-Terminologie >><fc #008000>Protocol C</fc><< genannt. Beim >><fc #008000>Asynchronous Mirroring</fc><< 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.
+DRBD legt sich dazu als Zwischenschicht zwischen dem lokalen Filesystem und dem lokalen Volume (>><fc #008000>Primary Node</fc><<) und kommuniziert über das Netzwerk mit seinem Spiegelpartner auf dem anderen Rechner (>><fc #008000>Secondary Node</fc><<). Die Änderungen am >><fc #008000>Primary Node</fc><< werden nun Blockweise über das Netzwerk auf den >><fc #008000>Secondary Node</fc><< übertragen. Bestimmte Modi (Synchron, Asynchron) bestimmen dabei das Verhalten der Spiegelung. Beim >><fc #008000>Synchronous Mirroring</fc><< werden die Daten sofort auf den >><fc #008000>Secondary Node</fc><< übertragen und die Transaktion gilt erst als abgeschlossen, wenn beide Nodes die Daten vollständig erhalten haben. Dieser Modus wird in der DRBD-Terminologie >><fc #008000>Protocol C</fc><< genannt. Beim >><fc #008000>Asynchronous Mirroring</fc><< hingegen gilt die Transaktion bereits als abgeschlossen, wenn der >><fc #008000>Primary Node</fc><< 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 >><fc #008000>Primary-Primary</fc><< 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))).
+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 >><fc #008000>Primary Node</fc><< zur Verfügung stehen. Um die Daten auch auf dem >><fc #008000>Secondary Node</fc><< zur Verfügung zu haben, bzw ein >><fc #008000>Primary-Primary</fc><< 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 >><fc #008000>Synchronous Mode</fc><< mit >><fc #008000>ext3</fc><< betrieben.
 ====Vorbereitungen====
-Es werden zwei Server mit jeweils einer unpartitionierten Platte >>sdb<< verwendet:
+Es werden zwei Server mit jeweils einer unpartitionierten Platte >><fc #008000>sdb</fc><< verwendet:
   * server1: 192.168.167.135
@@ Zeile 17: / Zeile 17: @@
 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:
+Die Datei >><fc #008000>/etc/hosts</fc><< entspricht auf beiden Rechnern:
 <box round green|**/etc/hosts**>127.0.0.1       localhost
@@ Zeile 51: / Zeile 51: @@
 cn                      3667  1 drbd</xterm>
-Jetzt erstellen wir die Konfiguration in der Konfigurations-Datei >><fc #008000>/etc/drbd.conf</fc><<:
+Jetzt erstellen wir die Konfiguration in der Konfigurations-Datei >><fc #008000>/etc/drbd.conf</fc><<. Kopieren Sie die Konfigurationsdatei dann mit gleichem Inhalt auf den zweiten Rechner:
 <code bash|/etc/drbd.conf>global { usage-count no; }
@@ Zeile 79: / Zeile 79: @@
 }</code>
-In dieser Konfigurationsdatei ist wichtig, dass die Servernamen der beiden Kommunikationspartner dem der Ausgabe von >>uname -n<< entsprechen:
+In dieser Konfigurationsdatei ist wichtig, dass die Servernamen der beiden Kommunikationspartner dem der Ausgabe von >><fc #008000>uname -n</fc><< entsprechen:
 <xterm># <fc #008000>uname -n</fc>
@@ Zeile 162: / Zeile 162: @@
 <xterm>root@**<fc #800000>server1</fc>**:~# <fc #008000>mkdir /drbd_data</fc>
-root@server1:~# <fc #008000>mount /dev/drbd0 /drbd_data</fc></xterm>
+root@<fc #800000>**server1**</fc>:~# <fc #008000>mount /dev/drbd0 /drbd_data</fc></xterm>
 ====Testen des Setups====
@@ Zeile 226: / Zeile 226: @@
 -rw-r--r-- 1 root root 512000000 30. Dez 17:16 **testfile.dd**</xterm>
-====Ausfall eines Nodes====
+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.
-===Ausfall des Secondary Nodes===
-Fällt nun ein Node aus, muss das Cluster System seine Stärke unter Beweis stellen. Dazu schalte ich einfach mal den >><fc #008000>Secondary-Node</fc><< ab, erstelle in der Zwischenzeit eine weitere Datei auf dem >><fc #008000>Primary-Node</fc><< und fahre anschließend den >><fc #008000>Secondary-Node</fc><< wieder hoch ... ups ... jetzt sollte sich eigentlich das DRBD Volume automatisch wieder verbinden, dagegen verhält es sich aber gar nicht so. Beim Booten wird folgende Meldung angezeigt:
-''<fc #800000>block drbd0: bind before connect failed, err = -99</fc>''
+**Verwandte Artikel:**
+[[:tux:drbd_failed_node|-> DRBD: Ausfall eines Nodes]]
+[[:tux:drbd_heartbeat|-> DRBD: Integration in Heartbeat]]
-und im Syslog findet sich passend dazu noch etwas mehr Information:
+ --- //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}}
-<code|/var/log/syslog>Dec 30 15:26:43 server2 kernel: [    4.164983] block drbd0: conn( StandAlone -> Unconnected )
-Dec 30 15:26:43 server2 kernel: [    4.165011] block drbd0: Starting receiver thread (from drbd0_worker [1399])
-Dec 30 15:26:43 server2 kernel: [    4.166285] block drbd0: receiver (re)started
-Dec 30 15:26:43 server2 kernel: [    4.166286] block drbd0: conn( Unconnected -> WFConnection )
-Dec 30 15:26:43 server2 kernel: [    4.166289] block drbd0: bind before connect failed, err = -99
-Dec 30 15:26:43 server2 kernel: [    4.166345] block drbd0: conn( WFConnection -> Disconnecting ) </code>
-Sollte eigentlich nicht sein((http://www.drbd.org/users-guide-8.3/s-node-failure.html)) und es hat mich einen ganzen Abend gekostet darauf zu kommen, was das Problem sein könnte. Nachdem ich stundenlang mit den Möglichkeiten zur automatischen Auflösung eines Split-Brains((http://www.drbd.org/users-guide/s-split-brain-notification-and-recovery.html)) experimentiert habe (>><fc #008000>after-sb-0pri</fc><<, >><fc #008000>after-sb-1pri</fc><<, >><fc #008000>after-sb-2pri</fc><<) bin ich dann darauf gekommen, dass der DRBD-Daemon einfach zu früh startet und noch bevor das Netzwerk zur Verfügung steht versucht wird, den Replikationspartner zu kontaktieren.
-Obwohl das Init-Skript von DRBD >><fc #008000>/etc/init.d/drbd</fc><< einen korrekten LSB-Header((http://wiki.debian.org/LSBInitScripts)) besitzt und ich die Startreihenfolge manuell auf ganz zum Ende in Runlevel 2 gesetzt habe...:
-<xterm>root@server1:/etc/rc2.d# <fc #008000>mv S19drbd S99drbd</fc></xterm>
-...hat mir vermutlich der DHCP Server in Verbindung mit meinen VMs auf SSD Platten in die Suppe gespuckt. Das Teil bootet einfach so schnell, dass es vom DHCP Server noch keine IP-Adresse bekommen hat, bevor der DRBD-Daemon startet. Abhilfe hat jetzt ein >><fc #008000>sleep 5</fc><< Kommando im Init-Skript >><fc #008000>/etc/init.d/drbd</fc><< geschaffen, welches die weitere Ausführung des Skripts für fünf Sekunden anhält... Mann Mann.
-<code bash|/etc/init.d/drbd>#!/bin/bash
-#
-# chkconfig: - 70 08
-# description: Loads and unloads the drbd module
-#
-# Copright 2001-2008 LINBIT Information Technologies
-# Philipp Reisner, Lars Ellenberg
-#
-### BEGIN INIT INFO
-# Provides: drbd
-# Required-Start: $local_fs $network $syslog
-# Required-Stop:  $local_fs $network $syslog
-# Should-Start:   sshd multipathd
-# Should-Stop:    sshd multipathd
-# Default-Start:  2 3 4 5
-# Default-Stop:   0 1 6
-# X-Start-Before: heartbeat corosync
-# X-Stop-After:   heartbeat corosync
-# Short-Description:    Control drbd resources.
-### END INIT INFO
-sleep 5
-DEFAULTFILE="/etc/default/drbd"
-DRBDADM="/sbin/drbdadm"
-DRBDSETUP="/sbin/drbdsetup"
-PROC_DRBD="/proc/drbd"
-MODPROBE="/sbin/modprobe"
-RMMOD="/sbin/rmmod"
-UDEV_TIMEOUT=10
-ADD_MOD_PARAM=""
-.
-.
-.</code>
-Was lernen wir daraus? Ein Netzwerksubsystem zu starten ist die eine Sache, eine funktionierende Netzwerkverbindung aufzubauen wieder eine ganz andere... ;-)
-Anyway, nachdem das Startproblem behoben war, hat DRBD sich so verhalten wie es soll. Dazu habe ich den >><fc #008000>Secondary Node</fc><<  abgeschaltet, auf dem >><fc #008000>Primary Node</fc><< Daten gelöscht und neue hinzugefügt und den >><fc #008000>Secondary Node</fc><< wieder gestartet. Nachdem der >><fc #008000>Secondary Node</fc><< wieder gestartet war, hat der >><fc #008000>Primary Node</fc><< automatisch die Daten synchronisiert, ein >><fc #008000>dstat -n -N eth0</fc><< auf dem >><fc #008000>Primary Node</fc><< hat dies angezeigt.
-===Ausfall des Primary Nodes===

tux/drbd_lan_raid1.1356956221.txt.gz (12156 views) · Zuletzt geändert: 2012/12/31 13:17 von wikisysop

Seite anzeigen Ältere Versionen

Medien-Manager Nach oben