Einrichten eines Redundanz-Servers mit XEN, DRBD, Heartbeat, LVM und Cryptdevice

Aus DebianforumWiki
(Weitergeleitet von XenDrbdHeartbeat)
Zur Navigation springen Zur Suche springen
Wiki ‹ Weitere Dienste ‹ Einrichten eines Redundanz-Servers mit XEN, DRBD, Heartbeat, LVM und Cryptdevice


XEN, LVM, Cryptdevice, DRBD und Heartbeat

XEN mit Netzwerkraid 1 für redundante Diensteverfügbarkeit in Debian Etch/Lenny.

DRBD (Distributed Replicated Block Device) bei [| Wikipedia]

Der Beitrag im Forum befindet sich [| hier].

Vorbemerkung/Vorüberlegungen

Die Installation von XEN wird nicht extra erklärt, dazu kann man das [[1]] als Ausgangspunkt nehmen. Ich werde hier nur auf die relevanten Teile eingehen, die DRBD und Heartbeat betreffen. Es wird nun davon ausgegangen, dass ein XEN-Kernel läuft und auch die Header zu diesem Kernel installiert sind (apt-get install linux-headers-2.6.18-6-xen-amd64). Das ist der Fall, wenn man den Debian-XEN-Kernel verwendet und DRBD nachträglich kompiliert. Wird ein eigener Kernel gebaut, so wird das DRBD-Modul direkt in den Kernel kompiliert. Weiterhin sollte backports.org für etch in den Sourcen für apt stehen.

Ab Debian/Lenny ist das DRBD-Modul als Paket vorhanden und kann mit apt-get installiert werden. 

apt-get install drbd8-modules-2.6.26-2-xen-amd64

Ein Upgrade der Dom0 von Etch auf Lenny sollte mittels dist-upgrade ohne größere Fehler möglich sein. Zumindest DRBD, Crypt und LVM liefen anschließend wie gewohnt weiter. XEN und die DomUs sollten auch laufen, wenn man nicht zu viele Anpassungen abweichend von Debian gemacht hat.

Damit nicht jeder auf die Daten der XEN-Domains (welche dann verschiedene Serverdienste enthalten) zugreifen kann (z.B. beim Diebstahl des Rechners oder Start mit Boot-CD), soll die entsprechende Partition verschlüsselt werden. Dazu ist ein großer Teil der eingebauten Festplatte vorgesehen.

Um auch das System der Dom0 etwas abzusichern, sind nur /boot und / unverschlüsselt und haben eine eigene Partition. /usr, /var, /tmp und swap liegen ebenfalls in einem Crypt-LVM.

Die zu Beginn angelegten Partitionen werden im Laufe des Betriebes zu klein. Man kann diese später vergrößern. Um dabei Komplikation im Vorfeld auszuschließen, sollte man zum gegenwärtigen Zeitpunkt (04/2011) ext3 verwenden, da sich damit Partitionen und/oder LVs leichter vergrößern lassen.

Überlegungen zu DRBD

DRBD arbeitet blockorientiert, d.h., das Dateisystem (und damit auch die Daten) liegen oberhalb der Schicht von DRBD. Es werden also nicht einzelne Dateien geschrieben, sondern Blöcke, die sich geändert haben. DRBD ist es egal, was für ein Dateisystem oder welche Daten in dem von DRBD angelegten Blockdevice liegen.

An dieser Stelle sollte man sich überlegen, wie später die Funktion des Servers sein soll (und damit auch die Funktion des Spiegelservers). Ich versuche mal das Prinzip von DRBD zu erklären, damit man besser planen kann.

DRBD legt für jedes zu spiegelnde Device ein Blockdevice an, also /dev/drbdX. Das X steht dabei für die Nummer des Gerätes (bis zu 255 bei Version 8). /dev/drbdX zeigt dabei auf die tatsächliche Partition, z.B. /dev/sda4. Wird nur ein Device verwendet, so wird über /dev/drbd0 in diesem Fall auf /dev/sda4 zugegriffen. Alle Operationen (schreiben, lesen, formatieren, ...) müssen auf dem Device /dev/drbd0 durchgeführt werden. Stoppt man auf dem Rechner den Dienst drbd, so kann man wieder normal auf /dev/sda4 zugreifen. Das Blockdevice /dev/drbd0 wurde entfernt. Genauso geht es auch, wenn man LVM verwendet. Hat man ein LV (Logical Volume) angelegt so befindet sich in /dev/volumegroupname/ ein Blockdevice logicalvolumename. Über dieses wird DRBD (also z.B. /dev/drbd0) gelegt und man greift auf das Volume (z.B. /dev/volumegroupename/logicalvolumename) mittels /dev/drbd0 zu, solange drbd läuft und das Modul geladen ist. Wird drbd deaktiviert, kann man wieder über /dev/volumegroupname/logicalvolumename auf seine Daten zugreifen.

Möchte man nun mehrere XEN-Domains spiegeln, werden es mehr Devices (/dev/drbdX). Der einfachste Fall ist, man hat eine unverschlüsselte Partition die gespiegelt werden soll. Auch recht einfach umzusetzen ist ein(ige) LVM-Partion(en), solange es ohne Verschlüsselung stattfindet. Verwendet man Verschlüsselung, so kann man das auf 2 Arten machen:

  • komplettes Device wird mit Schlüssel gespiegelt -- im Falle eines Ausfalles muss dann auf ServerB aber erst das Device entschlüsselt werden
  • Device wird nach Entschlüsselung gespiegelt -- DRBD setzte also z.B. auf /dev/crypt_sda4 auf, wenn z.B. /dev/sda4 als das Blockdevice crypt_sda4 entschlüsselt und eingebunden ist

Gibt man den XEN-Domains mehrere Devices, um /, /usr, /tmp, /var und swap in jeweils eigene Partitionen zu legen (es werden aber immer mind. 2 -> swap und / benötigt), so erhöht sich der Administrationsaufwand. Läuft aber das System, so ist man später sehr flexibel und kann bei Bedarf einzelne Domains auch auf ServerB als primary laufen lassen, oder eine Domain aus der Spiegelung ausschließen um ein Update zu testen. swap und /tmp muss nicht gespiegelt werden. Idealerweise legt man daher diese Partitionen auf eine andere Festplatte. Bei Crash oder defekten im System ist das nicht tragisch, da swap und /tmp keine extrem wichtigen Daten enthalten. Zudem wird die Systemplatte nicht durch I/O in diese Bereiche belastet.

Die Partitionen, oder genauer Blockdevices, müssen vor der Inbetriebnahme von DRBD auf beiden Rechner angelegt sein. Blockdevices können sein: /dev/hdaX, /dev/sdaX, /dev/mapper/lvmdevice, ... Das X steht dabei für eine Partionsnummer.

Ausstattung

In diesem Beispiel ist die nachfolgend beschriebene Ausstattung vorhanden. Man sollte bei Anwendung dieser Spiegelung aus organisatorischen und administrativen Gründen darauf achten, dass die Systeme baugleich sind.

Es sind zwei Server gleichen Bautyps vorhanden. Jeder Server hat einen Raidcontroller mit zwei 1TB Festplatten als Raid 1 sowie mehrere Netzwerkkarten (1000Mbit). Je eine ist für eine Cross-Over-Verbindung zwischen ServerA und ServerB. Dazu kommt jeweils eine Festplatte, welche später swap und /tmp der DomUs aufnehmen soll. Auf beiden Systemen ist Debian Etch mit XEN 3.2 (aus den Backports) installiert, mit dem 2.6.18er XEN-Kernel von Debian. Die Partition mit den XEN-DomUs ist verschlüsselt und es wird LVM verwendet. Bei der Dom0 liegen nur /boot und / auf jeweils einer eigenen, unverschlüsselten Partition, damit der Server beim Systemstart durch eine Diskette entschlüsselt werden kann.

Update

Der Spiegelserver wurde auf Debian/Lenny upgegraded, mit nun Kernel 2.6.26 und einer neueren DRBD-Version. Die Spiegelung funktioniert weiterhin.

Update 2

Der Spiegelserver, also secondary wurde nun auf Debian/Squeeze mit XEN 4.x geupdatet. Bis auf etwas Handarbeit der XEN-Einstellungen im grub und Umstellung der Plattenentschlüsselung auf USB-Stick beim Start, läuft alles reibungslos weiter.

Um auch den bisherigen primary auf Squeeze zu heben, werden alle virtuellen System auf den bisherigen secondary umziehen und dieser zum primary gemacht.

Die Anleitung sollte sich soweit auch auf neue Systeme mit aktueller Software anwenden lassen.

Crypt-Device und LVM

Wichtig! Die nachfolgenden Schritte müssen auf beiden Servern (ServerA und ServerB) vorgenommen werden. Ist das bei einem Schritt nicht der Fall, gebe ich das explizit an.

Benötigt man kein Crypt/LVM können diese Punkte auch übersprungen werden.

Crypt

Die verwendete Partition, welche die Daten der DomUs enthält, soll verschlüsselt und ein LVM-Device sein. Eine recht gute Anleitung zum Einrichten eines Crypt-Devices findet man hier. An dieser Stelle nur eine Kurzfassung. :-)

Das Paket cryptsetup muss auf dem System installiert sein. Als erstes wird die Partition zum Crypt-Container gemacht: 

root@linux:/> cryptsetup -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/sda4

Dabei wird ein Passwort (2-malige Eingabe) abgefragt.

Damit das Device beim Systemstart entschlüsselt und eingebunden wird, muss es in der /etc/crypttab eingetragen sein: 

root@linux:/> echo "sda4_crypt /dev/sda4 none luks" >> /etc/crypttab

sda4_crypt ist der Name des Devices, wie er anschließend in /dev/mapper zu sehen ist. Der Name kann beliebig gewählt werden und sollte eher der Funktion dieser Partition entsprechen um es später leichter zuordnen zu können.

Alternativ kann man auch mittels UUID die Partion entschlüsseln. Dieser Variante sollte man den Vorzug geben. Die UUID bekommt man aus /dev/disk/by-uuid. Hier das Ziel der symbolischen Links suchen, welches der frisch angelegten Partition entspricht. 

root@linux:/> echo "sda4_crypt /dev/disk/by-uuid/01bb5g11-b41c-4218-b635-9geb4400w58d none luks" >> /etc/crypttab

Nun muss allerdings bei jedem Systemstart ein Passwort eingegeben werden. Das ist bei einem Server lästig.

Wie man diesen Umstand umgeht, kann hier nachgelesen werden.

Damit ist das Crypt-Device fertig angelegt und steht für die weitere Administration zur Verfügung. Um es zu verwenden, muss man dieses jedoch erst entschlüsseln. Gibt man kein keyfile an, wird die hinterlegte Passphrase abgefragt. 

root@linux:/> cryptsetup luksOpen [--key-file /media/usb/keyfile] /dev/sda4 sda4_crypt

LVM

Ist LVM noch nicht installiert, kann das mit apt-get install lvm2 nachgeholt werden. Hier ein Howto zu LVM.

Damit Volumes angelegt werden können, muss ein PV (Physical Device) angelegt sein. Für /tmp und swap ist eine eigene Platte vorhanden, welche komplett partitioniert ist (/dev/sdb1). Diese Partion wird auch für LVM vorbereitet. 

root@linux:/> pvcreate /dev/mapper/sda4_crypt
root@linux:/> pvcreate /dev/sdb1

sda4_crypt ist der entschlüsselte Crypt-Container. Mit pvscan -v sollte man nun die PV sehen (/dev/dm-0 oder /dev/dm-1). Nun erstellt man zwei VG (Volume Group) und weist diesen das jeweilige Device zu. 

root@linux:/> vgcreate vg0 /dev/mapper/sda4_crypt
root@linux:/> vgcreate vgtmp /dev/sdb1

Die VG stellt eine Art Pool dar, in dem man LV (Logical Volume) anlegen kann.

Es werden nun einige LVs angelegt, die später die Partitionen der ersten XEN-DomU enthalten. Mindestens erforderlich sind 2 LV (eine für / und eine für swap). 

root@linux:/> lvcreate -n domu-root -L 250M vg0
root@linux:/> lvcreate -n domu-usr -L 200M vg0
root@linux:/> lvcreate -n domu-var -L 500M vg0
root@linux:/> lvcreate -n domu-tmp -L 50M vgtmp
root@linux:/> lvcreate -n domu-swap -L 256M vgtmp

Mit dem Schalter -n gibt man den Namen des LV an und -L legt die Größe fest. Am Ende steht der Name des VG, zu welchem das LV gehört. Da swap und /tmp nicht gespiegelt werden (müssen), wird auf diesen LV ein Dateisystem angelegt: 

root@linux:/> mkswap /dev/vgtmp/domu-swap
root@linux:/> mkfs.ext3 /dev/vgtmp/domu-tmp

Das Dateisystem der anderen LVs wird angelegt, sobald DRBD eingerichtet und aktiv ist.

Hinweis! Diese Schritte müssen, wie schon geschrieben, auf beiden Servern vorgenommen werden.

DRBD

Installation ab Lenny

Die Installation ab Debian/Lenny gestaltet sich recht einfach. 

root@linux:> apt-get install drbd8-modules-2.6.26-2-xen-amd64 drbd8-utils

Installation in Etch

In Etch ist das Modul leider nicht dabei. Der Teil der Anleitung ist aus historischen Gründen dabei. Die gesamte Anleitung zu diesem Thema basiert aus der Zeit als Etch noch Stable war. Um jetzt noch die Pakete von Etch nutzen zu können, muss folgender Eintrag in die sources.list. 

deb http://archive.debian.org/debian-archive/debian/ etch main contrib non-free

Modul nachträglich kompilieren

Das DRBD-Modul ist leider nicht im 2.6.18er Kernel enthalten und muss daher kompiliert werden. Das geht aber recht einfach mit dem module-assistant. 

root@linux:/usr/src> apt-get install module-assistant build-essential drbd8-source drbd8-utils heartbeat-2

Weitere Pakete werden mit installiert. Da das in der Dom0 stattfindet, können diese Pakete später wieder entfernt werden, wenn das Modul installiert ist.

Das Modul für drbd8 befindet sich nicht in der Liste vom module-assistant und wird daher mit folgendem Befehl hinzugefügt: 

root@linux:/usr/src> m-a get drbd8

Nun kann das Modul kompiliert, installiert und zu einem Paket gebaut werden: 

root@linux:/usr/src> m-a a-i drbd8

Es sollte nun in /usr/src ein entsprechend benanntes Debian-Paket liegen (drbd8-2.6.18-6-xen-amd64_8.0.11-1~bpo40). Dieses Paket mit "drbd8-utils heartbeat-2" auf dem zweiten Server installieren. Damit ist die Installation abgeschlossen.

Kernel patchen

Baut man einen neuen Kernel, so kann man das Modul auch gleich in diesen einfügen. Dazu installiert man die Sourcen. 

root@linux:/usr/src>  apt-get install drbd8-source

und wechselt in das Sourcen-Verzeichnis. Das mitgelieferte Makefile ermöglicht einem die leichte Erstellung eines Patchfiles. Wichtig ist dabei das richtige Kernelsource-Verzeichnis anzugeben. 

root@linux:/usr/src> cd drbd-8.2.6
root@linux:/usr/src/drbd-8.2.6> make KDIR=/usr/src/linux-2.6.18 kernel-patch

Man hat nun in dem Verzeichnis eine Datei mit patch im Namen liegen: 

root@linux:/usr/src/drbd-8.2.6> ls -l patch*
patch-linux-2.6.18-drbd-8.2.6

Der Name kann je nach Kernelsource-Verzeichnisnamen abweichen. Diesen Patch kann man nun in die Kernelsourcen einspielen. 

root@linux:/usr/src/drbd-8.2.6> cd /usr/src/linux-2.6.18
root@linux:/usr/src/linux-2.6.18> patch -p1 < /usr/src/drbd-8.2.6/patch-linux-2.6.18-drbd-8.2.6

Der Kernel kann nun mit make menuconfig konfiguriert und anschließend nach eigenem belieben kompiliert werden.

Modul laden

Werden eine Menge DRBD-Devices benötigt, lädt man das Modul mit der Option minor_count=255. Am einfachsten geht das mit dem Tool modconf aus dem gleichnamigen Paket.

Konfiguration

Die Konfiguration von DRBD wird in den unten aufgeführten Links ebenfalls erklärt.

Zuerst wird die original Konfigurationsdatei gesichert: 

root@linux:/etc> mv drbd.conf drbd.conf_orig

Nun kann eine neue erstellt werden. Die Originaldatei ist recht gut Dokumentiert und man kann sie weiter zum nachlesen nutzen. 

root@linux:/etc> vi drbd.conf

global {
 usage-count no;
}
resource domu-root {
 protocol C;
 startup { 
 degr-wfc-timeout 120;
 }
 disk { 
  on-io-error   detach;
 }
 net {
  cram-hmac-alg "sha1";
  shared-secret "geheim";
 }
 syncer { 
  rate 10M;
 }
 on host1 { 
  device       /dev/drbd0;
  disk        /dev/mapper/domains-domu--root;
  address 192.168.1.1:7700;
  flexible-meta-disk    internal;
 }
 on host2 { 
  device  /dev/drbd0;
  disk    /dev/mapper/domains-domu--root;
  address 192.168.1.2:7700;
  flexible-meta-disk      internal;
 }
}

Nun aber der Reihe nach. :-)

global

  • hier legt man globale Optionen fest, also solche, die für alle eingebunden Ressourcen gelten sollen
    • usage-count ist für den Nutzerzähler von DRBD; hat man das nicht angegeben, wird beim ersten Start gefragt, ob man das nutzen möchte

Es gibt noch einige andere Sektionen als die hier abgebildeten. Diese werden ich vielleicht später noch einbinden und erklären. Im Moment wird das aber nicht benötigt.

resource

  • Hier definiert man die einzelnen Devices, die gespiegelt werden sollen. Der Name ist frei wählbar, sollte aber für einen spätere leichte Wiedererkennung aussagekräftig sein.
Option Parameter Erklärung
protocol A Schreibvorgang gilt als abgeschlossen, sobald die Daten zum zweiten Server geschickt wurden
B Schreibvorgang gilt als abgeschlossen, sobald die Daten den zweiten Server erreicht haben (Kompromiss aus A und C)
C Schreibvorgang gilt als abgeschlossen, sobald die Daten den zweiten Server auf Platte geschrieben wurden (am sichersten)
startup ... ...
disk on-io-error ...
net ... ...
syncer rate gibt die maximale Datenübertragungsrate an (möglich in K, M und G)
on host1 device ist das DRBD-Device /dev/drbdX
disk ist das tatsächliche Device, welches die Daten enthalten soll
adresse Gibt die IP-Adresse/Portnummer des eigenen Rechners an. Auf diesem Socket wird die Verbindung aufgebaut. Jedes DRBD-Device benötigt eine eigene Portnummer
flexible-meta-disk ...
on host2 device ist das DRBD-Device /dev/drbdX
disk ist das tatsächliche Device, welches die Daten enthalten soll
adresse gibt die IP-Adresse und Portnummer des entfernten Rechners an. Auf diesem Socket wird die Verbindung aufgebaut. Jedes DRBD-Device benötigt eine eigene Portnummer.
flexible-meta-disk ...

Um die Konfigurationsdatei etwas übersichtlicher zu gestalten, kann man die Sektionen auch etwas zusammenrücken. Hat man eine Menge Ressourcen und alle Einträge sind wie im obigen Beispiel, ist die Datei sehr lang. Man kann die Einträge auch etwas zusammenrücken. Hier ein Beispiel dafür mit weiteren Resourcen, da die XEN-DomU aus mehreren Partitionen bestehen soll. 

global {
 # minor-count 255; 
 usage-count no;
}
resource domu-root {
 protocol C;
 startup { degr-wfc-timeout 120; }
 disk { on-io-error   detach; }
 net { cram-hmac-alg "sha1"; shared-secret "geheim"; }
 syncer { rate 10M; }
 on host1 { device /dev/drbd0; disk /dev/mapper/domains-domu--root; address 192.168.1.1:7700; flexible-meta-disk internal; }
 on host2 { device /dev/drbd0; disk /dev/mapper/domains-domu--root; address 192.168.1.2:7700; flexible-meta-disk internal; }
}
resource domu-usr {
 protocol C;
 startup { degr-wfc-timeout 120; }
 disk { on-io-error   detach; }
 net { cram-hmac-alg "sha1"; shared-secret "geheim"; }
 syncer { rate 10M; }
 on host1 { device /dev/drbd1; disk /dev/mapper/domains-domu--usr; address 192.168.1.1:7701; flexible-meta-disk internal; }
 on host2 { device /dev/drbd1; disk /dev/mapper/domains-domu--usr; address 192.168.1.2:7701; flexible-meta-disk internal; }
}
resource domu-var {
 protocol C;
 startup { degr-wfc-timeout 120; }
 disk { on-io-error   detach; }
 net { cram-hmac-alg "sha1"; shared-secret "geheim"; }
 syncer { rate 10M; }
 on host1 { device /dev/drbd2; disk /dev/mapper/domains-domu--var; address 192.168.1.1:7702; flexible-meta-disk internal; }
 on host2 { device /dev/drbd2; disk /dev/mapper/domains-domu--var; address 192.168.1.2:7702; flexible-meta-disk internal; }
}

Die Konfigurationsdatei muss nun auf den zweiten Rechner kopiert werden: 

root@linux:/> scp /etc/drbd.conf IP-ZWEITDRBDSERVER://etc/

Bevor DRBD nun neu gestart wird, müssen für alle Resourcen noch die Meta-Daten angelegt werden. Dazu ruft man auf beiden Rechnern folgende Befehle auf: 

root@linux:/>  drbdadm create-md domu-root
root@linux:/>  drbdadm create-md domu-usr
root@linux:/>  drbdadm create-md domu-var

Nach dem Restart auf beiden Servern kann man mit 

root@linux:/> watch cat /proc/drbd

sehen, dass beide Server als Secondary eingetragen sind. Es findet noch kein Datenabgleich statt. Auf dem Master müssen nun die Resourcen zu 'primary' gemacht werden. Die Option -- --overwrite-data-of-peer ist nur bei Erstinitialisierung einzusetzen. Die extra Bindestriche ( -- ) nicht vergessen. 

root@primary:/> drbdadm -- --overwrite-data-of-peer primary domu-root
root@primary:/> drbdadm -- --overwrite-data-of-peer primary domu-usr
root@primary:/> drbdadm -- --overwrite-data-of-peer primary domu-var

Lässt man den watch-Befehl auf dem Secundary weiter laufen, so sieht man die Synchronisierung mit dem Primary. Kommt es zu einer Fehlermeldung beim festlegen des Primary, dann muss beim erstmaligen Anlegen dieses Kommando aufgerufen werden: 

root@primary:/> drbdadm -- --overwrite-data-of-peer primary all

Siehe dazu auch [| dieser Beitrag] aus der drbd-user Mailingliste.

Auf dem zweiten Server werden die Resourcen zu 'secondary' gemacht. Da beide Server beim Start als Secondary markiert sind, ist das nicht unbedingt nötig. 

root@secondary:/> drbdadm secondary domu-root
root@secondary:/> drbdadm secondary domu-usr
root@secondary:/> drbdadm secondary domu-var

Damit ist die Grundkonfiguration abgeschlossen und die Synchronisation sollte laufen. Weitere Resourcen können der drbd-Konfigurationsdatei hinzugefügt werden. Werden beide Rechner neu gestartet, dann sind beide als Secondary markiert. Man könnte nun die Startskripte bearbeiten, oder Heartbeat festlegen lassen, welcher Server Primary ist. Daher wird an dieser Stelle nach dem Neustart der Primary von Hand festgelegt. Erst mit der Konfiguration von Heartbeat hält die automatische Festlegung einzug. 

root@primary:/> drbdadm primary all

Wie immer läßt sich das Ergebnis mit watch cat /proc/drbd verfolgen.

weitere Devices/Resourcen einbinden

Möchte man nachträglich weitere Resourcen einbinden, so kann man nach der Konfiguration von /etc/drbd.conf nicht einfach einen restart machen. Die neuen Resourcen müssen dann manuel aktiviert werden.

Anhand weiterer LVs soll gezeigt werden, wie das funktioniert. Anlegen der LVs wird im Abschnitt LVM weiter oben gezeigt.

Liste der durchzuführenden Schritte:

  • LV auf beiden Rechnern anlegen
  • LVs welche nicht gespiegelt werden sollen auf beiden Rechnern mit Dateisystem versehen
  • drbd.conf bearbeiten und neue Resourcen eintragen
    • Wichtig! Jede Resource benötigt einen eigenen Port. Auch muss die Nummer bei /dev/drbdX fortlaufend sein.
  • drbd.conf per scp auf den zweiten Server kopieren
  • drbd-md (Meta Data) auf beinden Servern schreiben
  • Resource manuell einbinden

Nehmen wir an, es wurde die Resource foo hinzugefügt. Die auf dem Primary geänderte Datei /etc/drbd.conf muss nun auf den Secondary kopiert werden. Dann auf beien Rechnern die "Meta Data" schreiben und auf dem Secondary DRBD mit restart neu starten. 

root@primary:/> drbdadm create-md foo
root@secondary:/> drbdadm create-md foo
root@secondary:/> /etc/init.d/drbd restart

Anschließend sollte wieder mit watch cat /proc/drbd der Status von DRBD kontrolliert werden. Neben der bereits konfigurierten Resource (z.B. domu-root) sollte es eine neue Anzeige geben: 

3: cs:WFConnection st:Secondary/Unknown ds:Inconsistent/DUnknown C r---
   ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:511948

Die Zahl am Anfang kann abweichen. Das hängt von den bereits eingebundenen Resourcen ab. Die Anzeige sagt uns, dass der Status auf dem Primary nicht bekannt ist. Dort wird nun die Resource eingebunden und aktiviert.

Hinzufügen der Resource zum DRBD: 

root@primary:/> drbdadm attach foo

Verbindung aktivieren: 

root@primary:/> drbdadm connect foo

Resource zu Primary machen: 

root@primary:/> drbdadm -- --overwrite-data-of-peer primary foo

Es sollte nun sofort die Anzeige auf dem Secondary umschalten und eine synchronisation erfolgen. 

root@secondary:/> watch cat /proc/drbd



Every 2,0s: cat /proc/drbd
Wed Jun 25 12:22:12 2008 version: 8.2.6 (api:88/proto:86-88)
....
....
3: cs:SyncTarget st:Secondary/Primary ds:Inconsistent/UpToDate C r---
   ns:0 nr:1728 dw:1728 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:510220
       [>....................] sync'ed:  0.8% (510220/511948)K
       finish: 0:21:15 speed: 344 (344) K/sec

Damit ist das Einbinden der neuen Resource abgeschlossen und es kann auf dem primary Server das Dateisystem auf den DRBD-Devices angelegt werden.

XEN

Die Installation von XEN wird nicht extra erklärt. Das kann man den unter Links aufgeführten Seiten nachlesen. Folgendes Paket wird noch benötigt, falls noch nicht installiert: 

root@linux:/> apt-get install debootstrap


Wir haben nun ein verschlüsseltes LVM-Device laufen. Mehrere LVs wurden angelegt. Die geplante XEN DomU(s) bestehen aus mehreren Partitionen, von denen aber nicht alle synchronisiert werden müssen (swap und /tmp). Daher gibt es bei der ersten XEN-DomU nur 3 Partitionen (/, /usr, /var) welche in DRBD aufgenommen werden. Die jeweiligen LVs wurden auf beiden Servern angelegt. Die folgenden Schritte sind nur auf dem Primary-Server auszuführen, unter Verwendung der Devices /dev/drbdX. Hierbei darauf achten, dass man das richtige Device bearbeitet und nicht ein bereits genutztes.

Auf den drei ins DRBD eingebundenen Partitionen muss ein Dateisystem angelegt werden. Auf dem Secondary-Server sollte weiterhin der watch-Befehl laufen. Damit kann man die Aktivität von DRBD kontrollieren. 

root@primary:/> mkfs.ext3 /dev/drbd0
root@primary:/> mkfs.ext3 /dev/drbd1
root@primary:/> mkfs.ext3 /dev/drbd2

Als nächstes werden die Devices für die XEN-DomU gemountet. Als erstes das, welches das Wurzeldateisystem enthält (also /). Darin werden die Verzeichnisse für /usr, /var und /tmp erstellt und anschließend die entsprechenden Devices dahin gemountet. Hierbei darauf achten, welches Device unter /dev/drbdX liegt. 

root@primary:/> mount /dev/drbd0 /mnt/
root@primary:/> mkdir /mnt/{usr,var,tmp}
root@primary:/> mount /dev/drbd1 /mnt/usr/
root@primary:/> mount /dev/drbd2 /mnt/var/
root@primary:/> mount /dev/domains/domu-tmp /mnt/tmp/

Mit dem Befehl mount kann man nun noch kontrollieren, ob alles richtig eingebunden ist. Nun wird mit debootstrap Debian/Lenny (oder Squeeze) installiert. 

root@primary:/> debootstrap --arch amd64 lenny /mnt http://ftp.de.debian.org/debian

Im Verlaufe der Installation sollte man auf dem Secondary die Synchronisation verfolgen können (mit watch cat /proc/drbd).

Ist die Installation abgeschlossen, wird ein chroot nach /mnt gemacht, um einige Konfigurationen in der DomU anzupassen. Die weiteren Schritte können z.B. [| hier] nachgelesen werden. Eventuell schreibe ich die mal noch hier rein.

Heartbeat

... wird noch geschrieben.

LVM-Device vergrößern

Man hat vorgeplant und es ist doch passiert. Die Partition ist voll. Dank LVM und DRBD kein Problem, man kann sie vergrößern.

Dazu auch [| dieser Link].

Kurzübersicht:

  • LV vergrößern auf primary und secondary
  • drbd resize auf das DRBD Device auf primary
  • fs check auf das drbd device auf primary
  • fs resize auf das drbd device auf primary

Und nun die Schritte im einzelnen

WICHTIG! Die betreffende DomU sollte während der Vergrößerung deaktiviert werden. Alternativ kann man auch das entsprechende Device aus der (Linux-)DomU entfernen und nach der Vergrößerung wieder einfügen.

LVM-Device vergrößern

Beide Nodes müssen online und verbunden sein, einer als primary, der andere als secondary.

Die Vergrößerung wird mit dem üblichen LVM-Kommando auf beiden Servern durchgeführt. Wichtig ist, kein resize mit z.B. resize2fs auf das LV durchzuführen., Dadurch werden die DRBD-Metadaten (und damit alle anderen Daten auch) entfernt. Die bisherige Größe beträgt 30GB und soll auf 40GB erweitert werden. Die Volumegroup (vg) lautet vg0, das LV homelv.

Primary: 

root@primary:/> lvextend -L +10G /dev/vg0/homelv

Secondary: 

root@secondary:/> lvextend -L +10G /dev/vg0/homelv

Damit ist das LV auf 40GB vergrößert. Mit 

root@primary:/> lvscan -v | grep homelv

kann man sich die neue Größe bestätigen lassen.

DRBD-Device anpassen

Nun kann mit einem DRBD-eigenem Kommando das Dateisystem angepasst werden. Es erfolgt dann ein sync der beiden Nodes, welches man mit 

watch cat /proc/drbd

beobachten kann.

In der /etc/drbd.conf wurde die Resource mit home konfiguriert. Das angenommene DRBD-Device ist /dev/drbd3. Entsprechend lautet der Resize-Befehl: 

root@primary:/> drbdadm resize home

Je nach Größe des Devices dauert der Sync etwas.

Nun erfolgt auf dem Primary ein Filesystemcheck auf das DRBD-Device, ohne den die Dateisystemvergrößerung nicht durchgeführt werden kann. 

root@primary:/> e2fsck -f /dev/drbd3

Abschließend wird das Dateisystem auf das DRBD-Device vergrößert. 

root@primary:/> resize2fs /dev/drbd3

Die DomU kann wieder gestartet werden. Parallel erfolgt weiterhin der Sync auf den Secondary (oder ist fertig, je nach Größe des LV und der Bandbreite).

Links

Crypt

LVM

DRBD

XEN

Heartbeat

Nachwort

Diese Anleitung ist noch lange nicht fertig. Ich werde nach und nach weitere Details hinzufügen. Wenn jemand die Anleitung verwendet und einige Stellen für Unklarheiten sorgen, so bitte ich um eine PN mit dem Hinweis darauf. Ich werde dann versuchen die entsprechende Stelle anders und/oder zu formulieren.

--Mcaldo 23:22, 12. Dez. 2010 (UTC)

Abgerufen von „https://wiki.debianforum.de/wiki/?title=Einrichten_eines_Redundanz-Servers_mit_XEN,_DRBD,_Heartbeat,_LVM_und_Cryptdevice&oldid=12155“