Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 9
Einrichtung von Heartbeat mit CRM auf einem Testsystem
In diesem Artikel wagen wir uns an die Umkonfiguration von Heartbeat heran. Doch um auf der sicheren Seite zu sein, erproben wir alle Änderungen auf einem Testsystem, das wir als Paar von virtuellen Maschinen realisieren.
Einleitung
Dies ist Teil 9 des Workshops »Virtueller hochverfügbarer Linux-Server«. Die weiteren Teile finden Sie über das Inhaltsverzeichnis.
Dieser Teil ist recht anspruchsvoll, bietet aber auch Möglichkeiten zum Experimentieren. Leser sollten mit den Konzepten von DRBD und Heartbeat vertraut sein und in der Lage sein, eine virtuelle Maschine einzurichten. Ob hierfür Qemu, VirtualBox, VMware oder sonst etwas gewählt wird, spielt dabei keine Rolle.
Ein Testsystem für Heartbeat
Auf den hochverfügbaren Servern läuft nun Heartbeat 2.1. Unser nächstes Ziel ist es, die Konfiguration von Heartbeat zu aktualisieren, da wir bisher noch die von Heartbeat 1 geerbte Konfiguration verwenden.
Es stellte sich heraus, dass Heartbeat 2 mit dem Cluster Resource Manager (CRM) nicht so einfach zu konfigurieren ist, insbesondere nicht mit DRBD. Um nicht an den produktiv laufenden Servern herumbasteln zu müssen, benötigen wir eine Testumgebung. Diese kann man mit zwei virtuellen Maschinen, z.B. mit Qemu/KVM oder VirtualBox, einrichten.
Zwei virtuelle Maschinen
Wir legen also zwei virtuelle Maschinen an und installieren in der ersten VM Debian 4.0 »Etch«. Hier genügt eine minimale Installation. Man sollte sicherstellen, dass SSH (Client und Server) installiert sind, denn damit kann man am besten die Netzwerkverbindung mit dem Host testen. Heartbeat ist nicht erforderlich, denn eine ausreichend neue Version von Heartbeat findet man erst in »Lenny«. Also ändern wir nach der Installation /etc/apt/sources.list, um Pakete nur noch von Lenny zu beziehen, und installieren dann Heartbeat mit
apt-get install heartbeat
Dies ist eine etwas krude Methode. Eine Konfiguration von APT über /etc/apt/preferences wäre besser gewesen, aber wir wollen hier keinen Schönheitspreis gewinnen. Die Installation aktualisiert gleich noch einige andere Pakete wie libc. Man könnte natürlich auch direkt Lenny installieren, aber wer auf den realen Servern Debian Etch einsetzt, wird ein Testsystem vorziehen, das möglichst weitgehend den realen Servern entspricht.
Von dieser VM kann man dann eine Kopie machen (das Kopieren von Dateisystem-Images ist in Qemu trivial, aber bei VirtualBox muss man darauf achten, dass das kopierte Dateisystem-Image eine neue UUID erhält). Die VMs nennen wir debianha1 und debianha2. Da man mit dem grafischen Clustermanager von außen auf diese VMs zugreifen will, muss man das Netzwerk der VMs so einrichten, dass sie eine statische IP-Adresse bekommen und von anderen Rechnern aus sichtbar sind. Mit Qemu verwendet man dafür die Option -net tap..., mit VirtualBox verwendet man den Netzwerktyp Hostinterface mit entsprechenden Skripten, wie in der Dokumentation von VirtualBox beschrieben. Im Beispiel verwenden wir die Adressen 192.168.1.1 und 192.168.1.2.
DRBD
Um auch DRBD testen zu können, installieren wir DRBD. Auch dieses muss man aus dem Lenny-Archiv beziehen, da Etch nur Version 0.7 enthält. Benötigt werden die Pakete drbd8-modules-2.6.26-1-i486 und drbd8-utils. Dies zieht natürlich ein Kernel-Update nach sich.
Nun benötigen wir eine Partition, die wir für DRBD nutzen können. Dafür kann man für jede VM ein zusätzliches virtuelles Laufwerk von 2 GB Größe anlegen. Dieses erscheint (beispielsweise) als /dev/hdb in den VMs und wird ganz einfach mit einer einzelnen Partition /dev/hdb1 versehen, Partitionstyp 83 (Linux).
Die Konfigurationsdatei /etc/drbd.conf von DRBD ist hier ziemlich einfach gehalten. Sie enthält eine Ressource disk0 und ein paar globale bzw. gemeinsame Definitionen.
global {
usage-count no;
}
common {
protocol C;
handlers {
pri-on-incon-degr "halt -f";
pri-lost-after-sb "halt -f";
}
syncer { rate 125M; }
startup {
wfc-timeout 60;
degr-wfc-timeout 60;
}
disk { on-io-error detach; }
net {
after-sb-0pri disconnect;
after-sb-1pri disconnect;
after-sb-2pri disconnect;
}
}
resource disk0 {
on debianha1 {
device /dev/drbd0;
disk /dev/hdb1;
address 192.168.1.1:7780;
meta-disk internal;
}
on debianha2 {
device /dev/drbd0;
disk /dev/hdb1;
address 192.168.1.2:7780;
meta-disk internal;
}
}
Diese Datei muss auf beiden Rechnern immer identisch sein! Jetzt können wir auf beiden Servern das Gerät initialisieren:
drbdadm create-md disk0 drbdadm up disk0
Nur auf einem von beiden dürfen wir das folgende Kommando ausführen. Damit bestimmen wir diesen Rechner zum primären Knoten für diese Ressource.
drbdadm -- --overwrite-data-of-peer primary disk0
Testen Sie mit cat /proc/drbd, ob alles angelegt wurde, und versuchen Sie auf dem Primary /dev/drbd0 erst zu formatieren (z.B. mit ext3 oder xfs) und dann zu mounten.
Konfiguration von Heartbeat
Heartbeat muss in den VMs nur minimal konfiguriert werden, da wir die Ressourcen später über die GUI einstellen. Zunächst geben wir dem Benutzer hacluster das triviale Passwort »1«: passwd hacluster. Das benötigen wir zum Einloggen über die GUI. Das Passwort muss auch in /etc/ha.d/authkeys eingetragen werden.
/etc/ha.d/authkeys
auth 1 1 crc
Diese Datei sollte die Permissions 0600 bekommen.
/etc/ha.d/ha.cf
Der entscheidende Part ist die Konfigurationsdatei /etc/ha.d/ha.cf von Heartbeat. Die Einträge sollten Ihnen bekannt vorkommen. Neu sind die Zeilen ab crm on. Sie aktivieren den Cluster Resource Manager, ermöglichen das Anmelden am Manager mit der User-ID hacluster (sollte durch Installation des Heartbeat-Paketes automatisch angelegt werden) und starten den CIB Monitor.
use_logd on ucast eth0 192.168.1.1 ucast eth0 192.168.1.2 auto_failback on node debianha1 node debianha2 crm on apiauth cibmon uid=hacluster respawn hacluster /usr/lib/heartbeat/cibmon -d
Es ist nicht nötig, jeder VM den Namen der jeweils anderen bekannt zu machen.
