Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 5
DRBD, Xen und Heartbeat
Xen ist in aller Munde und hat in Version 3.0.x in alle größeren Linux-Distributionen Einzug gehalten oder tut dies in den demnächst erscheinenden neuen Versionen. Dieser Artikel beschreibt die Einrichtung von Xen zusammen mit den Hochverfügbarkeitslösungen DRBD und Heartbeat. DRBD und Heartbeat können auch weggelassen werden, wenn man auf Hochverfügbarkeit keinen Wert legt. Da DRBD, Xen und Heartbeat stark miteinander verzahnt werden, werden sie in diesem Artikel gemeinsam abgehandelt.
Einleitung
Nachdem wir bereits OpenVZ als Virtualisierungslösung betrachtet haben, ist nun Xen an der Reihe. OpenVZ hat den Nachteil, dass es einige kernelbasierte Dienste nicht virtualisiert - zumindest im Moment nicht. Für mich war konkret zum einen der NFS-Server ein Problem, auch wenn hier immerhin ein Userspace-NFS-Server als Alternative zur Verfügung steht. Das andere Problem war das Loopback-Blockdevice, ohne das sich keine Dateien als Blockgeräte mounten lassen. Auch der Automount-Dienst hätte nicht funktioniert oder zumindest hätte ich eine andere Konfiguration als bisher wählen müssen.
Viele Anwender dürften mit diesen Einschränkungen leben können, für alle anderen bietet sich Xen als Alternative an. Infolgedessen beschreibt dieser Artikel die Einrichtung von Xen zusammen mit den Hochverfügbarkeitslösungen DRBD und Heartbeat. DRBD und Heartbeat können auch weggelassen werden, wenn man auf Hochverfügbarkeit keinen Wert legt. Die Einrichtung von Xen und virtuellen Maschinen unter Xen bietet durchaus ihre Stolperfallen, wie wir noch sehen werden.
Die Funktionsprinzipien und Fachbegriffe von Xen sollen in diesem Artikel nicht erklärt werden. An dieser Stelle soll es genügen, auf den Artikel »Virtualisierung im Vergleich« zu verweisen, der die Grundlagen recht ausführlich beschreibt.
Installation des Xen-Kernels
Die erste Maßnahme ist die Installation des Xen-Kernels und eines darauf aufbauenden Linux-Kernels für dom0, das Hostsystem. Wir könnten Xen (aktuell 3.0.4) aus den offiziellen Quellen compilieren, würden damit jedoch nur einen nicht ganz frischen Kernel 2.6.16 bekommen. Deshalb greifen wir in diesem Fall lieber zum Debian-Kernel, der auf dem Stand von Linux 2.6.18 ist. Folgende Pakete sind zu installieren:
linux-image-2.6-xen-amd64 linux-image-2.6.18-4-xen-amd64 linux-image-xen-amd64 linux-modules-2.6.18-4-xen-amd64 xen-hypervisor-3.0.3-1-amd64 xen-tools xen-utils-3.0.3-1 xen-utils-common
Zum Compilieren von Kernel-Modulen, insbesondere DRBD, benötigt man auch die passenden Headerdateien:
linux-headers-2.6-xen-amd64 linux-headers-2.6.18-4-xen linux-headers-2.6.18-4-xen-amd64
Die Namen können auf Ihrem System eventuell leicht abweichen. Sie sollten auf jeden Fall die aktuellste Version verwenden, die zum einen angeblich die Leistung verbessert hat (besonders beim Netz), zum anderen möglicherweise auch Fehler behebt.
Partitionierung für die VMs
Xen benötigt für jede virtuelle Maschine eine oder mehrere Swap- und Imagedateien. Statt Dateien kann man jedoch auch Partitionen verwenden. Ich vermutete, dass Partitionen eine bessere Performance als Dateien ergeben würden. Dies wurde von einzelnen Lesern angezweifelt. Tatsächlich zeigten spätere Messungen, dass beide gleichauf liegen. Dennoch wähle ich in diesem Artikel diesen Weg. Ein wichtiger Grund hierfür ist DRBD. Wenn wir die VMs im Normalbetrieb auf beide Server verteilen wollen, benötigen wir für jede VM eine eigene DRBD-Partition, da die Synchronisation nur in eine Richtung funktioniert. Möglicherweise werde ich im nächsten Artikel eine Alternative vorstellen.
Dank LVM ist es ein Leichtes, neue Partitionen anzulegen und nach Belieben zu vergrößern. Durch die Verwendung von drei Festplatten im RAID0-Modus ist der Schreibaufwand zwar etwas größer. Aber bei etwa drei geplanten VMs hält er sich noch in Grenzen. Falls man nur eine Festplatte verwendet oder ein RAID unter das LVM gelegt hat, reduziert sich der Konfigurationsaufwand natürlich entsprechend.
Wir geben jeder VM drei Swap-Partitionen (gleichmäßig auf die drei Platten verteilt) und eine Dateisystem-Partition. Letztere müssen wir aber wie schon bei OpenVZ als Striped-Partition aus jeweils einer Partition auf den drei Platten zusammensetzen. Die Swap-Partitionen machen wir jeweils 2 GB und die Dateisystem-Partitionen jeweils 100 GB groß, was eine ziemlich große VM mit 6 GB Swap und 300 GB Festplattenplatz ergibt. Die Werte sind natürlich beliebig anpassbar. Eine gute Strategie ist es, die LVM-Partitionen zunächst nicht viel größer als nötig zu machen, denn eine spätere Vergrößerung ist einfach.
Zur Namensgebung ist noch anzumerken, dass die Gastsysteme (DomU) unter Xen eine eindeutige numerische ID haben müssen. Ich wähle die Zahlen ab 100, damit alles dreistellig ist. Die Swap-Partitionen nenne ich daher swap100 für die VM mit der ID 100, swap101 für die VM 101 und so weiter. Analog benenne ich die Dateisystem-Partitionen.
lvcreate -L 2G --name swap100 vg-sda lvcreate -L 2G --name swap100 vg-sdb lvcreate -L 2G --name swap100 vg-sdc lvcreate -L 100G --name root100 vg-sda lvcreate -L 100G --name root100 vg-sdb lvcreate -L 100G --name root100 vg-sdc
Die Swap-Partitionen können wir gleich entsprechend vorbereiten:
mkswap /dev/vg-sda/swap100 mkswap /dev/vg-sdb/swap100 mkswap /dev/vg-sdc/swap100
Dann legen wir die Datei /etc/dmtab.100 an, in der wir die Definition des RAID0-Arrays ablegen:
0 629145600 striped 3 64 /dev/vg-sda/root100 0 /dev/vg-sdb/root100 0 /dev/vg-sdc/root100 0
Mit dmsetup create root100 /etc/dmtab.100 wird das RAID0-Array zum Leben erweckt. Es steht nun als Device /dev/mapper/root100 zur Verfügung. Der nächste Schritt ist die Einrichtung des DRBD-Gerätes, das wir über das RAID legen wollen. Dazu erweitern wir die Datei /etc/drbd.conf um (zunächst) einen Eintrag, der die Ressource vm100 beschreibt. In dieser Datei stehen zahlreiche Optionen, die aber alle auskommentiert (nicht aktiv) sind und von uns auch nicht benötigt werden. Die komplette Datei (ohne Kommentarzeilen) muss daher nur unsere neue Ressource enthalten:
resource vm100 {
protocol C;
startup {
degr-wfc-timeout 120; # 2 minutes.
}
disk {
on-io-error detach;
}
syncer {
group 100;
al-extents 257;
}
on erdbeere {
device /dev/drbd0;
disk /dev/mapper/root100;
address 192.168.2.1:7788;
meta-disk internal;
}
on himbeere {
device /dev/drbd0;
disk /dev/mapper/root100;
address 192.168.2.2:7788;
meta-disk internal;
}
}
Diese Datei besagt nichts anderes, als dass wir ausschließlich die Datenpartition duplizieren. Die Swap-Partitionen bleiben außen vor, da sie im Falle eines Absturzes oder einer Migration nutzlos sind - die VM wird ohnehin neu gestartet. Im Falle einer Live-Migration könnte das anders werden, aber soweit sind wir noch nicht.
DRBD kann nun aktiviert werden mit:
drbdadm up vm100 drbdadm -- --do-what-I-say primary vm100
Nun legen wir ein XFS-Dateisystem an und mounten es:
mkfs.xfs /dev/drbd0 mkdir -p /mnt/tmp mount /dev/drbd0 /mnt/tmp
Wir mounten es nur temporär, um die VM einzurichten. Im laufenden Betrieb der VM darf es nicht gemountet sein, da es sonst sehr wahrscheinlich zu Schäden am Dateisystem kommt.
