Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 8
DRBD, KVM und Heartbeat
Heartbeat
Nun wollen wir auch den Cluster zum Leben erwecken, das heißt, Heartbeat zu konfigurieren. Eigentlich wollte ich den neuen Cluster Resource Manager zum Einsatz bringen, doch es stellte sich heraus, dass in diesem die Unterstützung von DRBD noch in den Anfängen steckt. Es ist nicht nur massive Bastelarbeit gefragt, sondern auch eine sehr neue Version von Heartbeat nötig. Selbst in Debian-Backports ist derzeit keine ausreichend neue Version vorhanden. Aus diesem Grund behalte ich die Konfiguration von früher bei, nur dass jetzt Xen durch KVM ersetzt wird.
Die Konfiguration bleibt weiterhin ziemlich einfach, da wir nicht einzelne Dienste ausfallsicher machen, sondern die ganzen VMs mit allen enthaltenen Diensten.
In Debian sind sowohl Version 1 als auch Version 2 von Heartbeat verfügbar. Wir nehmen natürlich Version 2, da diese mittlerweile als ausgereift und stabil gilt: apt-get install heartbeat-2. Nun legen wir einige Konfigurationsdateien an, was ganz nach Vorschrift und ohne Nachdenken vor sich geht:
cd /etc/ha.d cp -a /usr/share/doc/heartbeat-2/authkeys . chmod 0600 authkeys cp -a /usr/share/doc/heartbeat-2/ha.cf.gz . gunzip ha.cf.gz cp -a /usr/share/doc/heartbeat-2/haresources.gz . gunzip haresources.gz
Jetzt müssen wir ha.cf anpassen. Wir schalten das Loggen ein (use_logd on), ebenso das automatische Zurückmigieren der Ressourcen (auto_failback on), und benennen die beteiligten Rechner. Die mit ucast beginnenden Zeilen legen fest, auf welchem Weg die Rechner bestimmen, ob ihre Cluster-Partner noch leben. Fehlerhafte Einträge hier führen dazu, dass ein Rechner fälschlicherweise als tot erkannt wird - mit unerwünschten Folgen.
Heartbeat ignoriert bei den ucast-Zeilen alle Einträge, die den eigenen Rechner betreffen. Durch dieses praktische Feature kann man die Datei auf allen Clusterknoten identisch halten. Beim Einrichten einer Bridge droht noch ein Fallstrick: Hier muss man das Bridge-Device und nicht eth1 angeben, sonst klappt die Kommunikation nicht und der Partner wird für tot erklärt (zumindest wenn eth2 auch versagt).
use_logd on ucast br1 172.16.1.1 ucast br1 172.16.1.2 ucast eth2 192.168.2.1 ucast eth2 192.168.2.2 auto_failback on node erdbeere node himbeere
Noch einfacher ist die Datei haresources:
erdbeere drbddisk::vm100 \ Filesystem::/dev/drbd0::/mnt/vm100::xfs \ KVM::vm100
Diese Einträge besagen, dass Heartbeat die Ressourcen drbddisk, Filesystem und KVM verwalten soll. Sie sollen bevorzugt auf Erdbeere laufen (d.h. sie werden immer zurückmigriert, sobald Erdbeere läuft). Die Ressourcen werden durch gleichnamige Skripte in /etc/ha.d/resource.d verwaltet. Werden sie dort nicht gefunden, wird im Verzeichnis /etc/init.d nachgesehen - davon machen wir hier keinen Gebrauch. Die Ressourcen besitzen Parameter, die mit :: hinter den Namen geschrieben werden. So besagt die Ressource Filesystem::/dev/drbd0::/mnt/vm100::xfs, dass /dev/drbd0 ein XFS-Dateisystem enthält und nach /mnt/vm100 gemountet werden soll.
Die Reihenfolge der Ressourcen spielt natürlich auch eine Rolle. drbddisk ermittelt, welcher Rechner die aktuelle Version des DRBD-Volumes hat, und macht den richtigen Rechner zum Primary. Nur wenn das gelingt und der Rechner Primary ist, kann die Dateisystem gemountet und die VM vm100 gestartet werden.
Die Datei KVM wird leider in Heartbeat nicht mitgeliefert. Nach dem Vorbild von vorhandenen Dateien schrieb ich mir daher selbst ein Skript. Dabei lernte ich, dass man solche Skripte sorgfältig testen muss, sonst funktioniert es nicht. /etc/ha.d/resource.d/KVM sieht momentan so aus:
#!/bin/bash
#
# This script is inteded to be used as resource script by heartbeat
#
# Apr 2008 by hjb
#
###
case "$2" in
start)
/etc/kvm/$1
;;
stop)
pid=$(ps ax| grep $1 | grep -v grep | grep -v "$0" | awk '{print $1}')
if [ -n "$pid" ]; then
kill $pid
else
echo "not running"
fi
;;
status)
pid=$(ps ax| grep $1 | grep -v grep | grep -v "$0" | awk '{print $1}')
if [ -n "$pid" ]; then
echo "running"
else
echo "stopped"
fi
;;
*)
echo "Usage: $0 [resource] {start|stop|status}"
exit 1
;;
esac
exit 0
Den Start der VM habe ich in separate Skripte /etc/kvm/[vm-name] ausgelagert, in Analogie zum Vorgehen bei Xen, wobei [vm-name] natürlich der Name der VM ist. Da jede VM mit unterschiedlichen Parametern gestartet wird, ist das die flexibelste Lösung. Einige Parameter treten allerdings immer in berechenbarer Weise auf, so dass es denkbar wäre, dafür einen gemeinsamen Rahmen zu schaffen. Bisher habe ich darauf verzichtet, und daher sieht eine Datei in /etc/kvm beispielsweise so aus:
#!/bin/sh /usr/local/bin/qemu-system-x86_64 -name krakatau -m 256 -smp 2 \ -kernel /boot/linux-2.6.23.12-vm -hda /mnt/vm100/vm100.image \ -net nic,macaddr=66:66:66:66:66:00,model=rtl8139 -net tap -vnc :0 -k de &
Der Aufruf ähnelt dem bereits weiter oben als Beispiel gegebenen. Er setzt voraus, dass auf dem Host ein Tap-Device angelegt werden kann (daher unser Konstrukt mit den Bridges), bildet einen SMP-Rechner mit zwei CPUs und 256 MB RAM nach, verwendet Kernel 2.6.23.12 in meiner eigens erstellten Konfiguration »-vm« und ist über das VNC-Display :0 zu erreichen.
Sobald sichergestellt ist, dass auf beiden Hosts die Konfigurationsdateien vollständig und identisch sind, kann man Heartbeat starten. Am besten startet man zuerst auf Erdbeere, wo die Ressourcen ja bevorzugt laufen sollen. Das DRBD-Gerät sollte nach einer kleinen Verzögerung den Zustand Primary annehmen und auf /mnt/vm100 gemountet werden. Dann sollte die VM starten. Der Start von Heartbeat auf Himbeere solle daran nichts ändern. Wird nun Heartbeat auf Erdbeere heruntergefahren (oder der ganze Rechner), dann sollten die Ressourcen auf den anderen Server wandern.
