Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 11
Corosync und Pacemaker, libvirt und Live-Migration von KVM
Ein Minimalsystem genügt für den Server. Auf die Installation muss nicht weiter eingegangen werden. Nachdem das neue System erstmals gebootet wurde, müssen wir die Netzwerkschnittstellen einrichten. Die erste soll mit dem Standort-Netz verbunden werden, die zweite soll beide Server durch ein Kabel direkt verbinden. Dazu erhält sie auf dem ersten Server die (willkürlich gewählte) Adresse 192.168.2.1 und auf dem zweiten die Adresse 192.168.2.2.
Als nächstes müssen wir dafür sorgen, dass das Repositorium »squeeze-backports« zur Verfügung steht. Dazu fügen wir zur Datei /etc/apt/sources.list die Zeile
deb http://backports.debian.org/debian-backports squeeze-backports main
hinzu und führen apt-get update aus. Wir nutzen das sogleich aus, um einen aktuelleren Kernel zu installieren. Die Auswahl der Version ist einfach, da es nur einen Kernel auf Basis von Linux 3.2.x gibt.
apt-get install -t squeeze-backports linux-image-3.2.0-0.bpo.4-amd64
Da als nächste Maßnahme die Einrichtung von DRBD ansteht, schieben wir gleich ein
apt-get install drbd8-utils
hinterher (hier kann optional auch die Backports-Version verwendet werden). Nun benötigen wir Partitionen für DRBD, und zwar eine pro virtueller Maschine. Eine Live-Migration der VMs ist nur möglich, wenn jede DRBD-Partition im Dual-Primary-Modus betrieben wird - eine Änderung gegenüber dem früheren Setup. Nun könnte man sich die Frage stellen, fällt damit nicht der Grund weg, für jede VM eine eigene Partition anzulegen? Denn dies geschah nur, um die VMs flexibel auf die beiden Server verteilen zu können, je nach Last.
Die Antwort ist ja, falls man das resultierende DRBD-Gerät mit fdisk oder einem weiteren LVM weiter partitionieren würde. Ich plane selbst, in diese Richtung zu gehen, aber erst, wenn ich einen Weg gefunden habe, die Partitionierung weiter zu vereinfachen. Das wird ein Thema in der nächsten Folge sein.
Die VM-Partitionen werden in diesem Beispiel mit vm100, vm101 usw. benannt. Wir kreieren also Partitionen für die VMs mit Kommandos wie folgendem, das ein 6 GB großes logisches Volume in der Volume Group vg0 anlegt:
lvcreate --name=vm100 -L 6G vg0
Nun können wir die Datei /etc/drbd.conf bearbeiten. Diese enthält Definitionen global und common sowie eine Definition pro Ressource (DRBD-Gerät). Der Abschnitt common vereinfacht die Konfiguration erheblich, da er für alle DRBD-Geräte gilt. Die Konfiguration ist gegenüber früher leicht modifiziert, insbesondere sollen beide Rechner die Volumes als Primary mounten können. Mit einem Gerät vm100 und unter Weglassen von Kommentaren und Leerzeilen kann die Datei so aussehen:
global {
usage-count no;
}
common {
protocol C;
handlers {
pri-on-incon-degr "halt -f";
pri-lost-after-sb "halt -f";
fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
}
syncer { rate 125M; }
startup {
wfc-timeout 60;
degr-wfc-timeout 60;
}
disk {
on-io-error detach;
fencing resource-only;
}
net {
ping-timeout 10; # 1 second
after-sb-0pri discard-younger-primary;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
allow-two-primaries;
}
}
resource vm100 {
on erdbeere {
device /dev/drbd0;
disk /dev/mapper/vg0-vm100;
address 192.168.2.1:7780;
meta-disk internal;
}
on himbeere {
device /dev/drbd0;
disk /dev/mapper/vg0-vm100;
address 192.168.2.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 vm100 drbdadm up vm100
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 vm100
Auf dem anderen Rechner dürfen wir allerdings auch
drbdadm primary vm100
eingeben, denn wir erlauben anders als früher ja zwei Primarys.
Nun haben wir das Blockgerät /dev/drbd0, das wir auf einem der beiden Rechner mit fdisk formatieren können, um dann eine virtuelle Maschine damit zu starten. Oder wir starten die virtuelle Maschine direkt und erledigen die Partitionierung innerhalb - so würde man vorgehen, wenn man eine Distribution in der VM installieren würde.
Nun sollte man einmal neu booten - erstens um den neuen Kernel zu aktivieren und zweitens, um zu sehen, ob die DRBD-Volumes korrekt starten.
