Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen gezeigt.
|
tux:drbd_lan_raid1 [2013/01/01 18:56] wikisysop |
tux:drbd_lan_raid1 [2013/01/03 15:01] (aktuell) wikisysop [Installation und Konfiguration von DRBD] |
||
|---|---|---|---|
| Zeile 3: | Zeile 3: | ||
| 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. | 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. | 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==== | ====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 | * 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: | 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 | <box round green|**/etc/hosts**>127.0.0.1 localhost | ||
| Zeile 51: | Zeile 51: | ||
| cn 3667 1 drbd</xterm> | 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; } | <code bash|/etc/drbd.conf>global { usage-count no; } | ||
| Zeile 79: | Zeile 79: | ||
| }</code> | }</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> | <xterm># <fc #008000>uname -n</fc> | ||
| Zeile 162: | Zeile 162: | ||
| <xterm>root@**<fc #800000>server1</fc>**:~# <fc #008000>mkdir /drbd_data</fc> | <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==== | ====Testen des Setups==== | ||
