Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 6
Xen mit Image-Dateien und Lastverteilung
Dieser Artikel beschreibt die Einrichtung von Xen zusammen mit den Hochverfügbarkeitslösungen DRBD und Heartbeat. Anders als in Teil 5 des Workshops werden die virtuellen Maschinen nun mit Image-Dateien betrieben, was die Anzahl der benötigten Partitionen reduziert und die Konfiguration entsprechend vereinfacht. Die virtuellen Maschinen können danach komfortabel auf die Hosts verteilt werden.
Einleitung
){kind=small}
Hans-Joachim Baader (hjb)
Trio Infernale: USV, 1. Server, 2. Server
In Teil 5 unseres Workshops hatten wir Xen, DRBD und Heartbeat zum Laufen überredet. Dabei war es pro virtueller Maschine (VM) notwendig, sechs LVM-Partitionen anzulegen. Wir wollen dies auf drei reduzieren und dabei den Swap gleich noch in die Spiegelung mit DRBD einbeziehen, was eine eventuelle Live-Migration von Xen-VMs, die für einen späteren Zeitpunkt geplant ist, deutlich vereinfachen sollte. Der Text setzt nicht voraus, dass Sie Teil 5 ganz gelesen haben - wir werden das Aufsetzen der VMs noch einmal von vorn beschreiben. Lediglich das Kapitel »Installation des Xen-Kernels« sollten Sie in Teil 5 nachschlagen. Kenntnis der Teile 1 bis 3 ist von Vorteil.
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 Leistung ergeben würden als Dateien, und verwendete daher anfänglich Partitionen, wie in meinen vorangegangenen Artikeln beschrieben. Dies wurde von einzelnen Lesern angezweifelt. Tatsächlich zeigten spätere Messungen, dass beide gleichauf liegen. Von der Leistung her könnte man also bei Partitionen bleiben. Dennoch gebe ich sie in diesem Artikel auf und wähle den Weg der Dateien. 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.
Vorbereitung
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 eine Swap-Partition und eine Dateisystem-Partition. Diese Partitionen werden nun aber als Dateien auf dem Host angelegt. Beide Dateien liegen gemeinsam in einer Partition, die sie vollständig ausfüllen. Die Partitionen wiederum werden mittels LVM angelegt und unter die Kontrolle von DRBD gestellt. Wieder dürfte es eine gute Strategie sein, die LVM-Partitionen zunächst nicht größer als nötig zu machen, denn eine spätere Vergrößerung ist einfach, eine Verkleinerung, um für andere Partitionen Platz zu schaffen, dagegen nicht.
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 alle IDs dreistellig sind. Die Dateisystem-Partitionen nenne ich daher vm100 für die VM mit der ID 100, vm101 für die VM 101 und so weiter.
Dieses neue Schema hat, wie sich erst später herausstellt, eine zusätzliche Anforderung. Da ich bereits über dieses Problem gestolpert bin, ist es natürlich sinnvoll, es bereits im Vorfeld zu beseitigen. Und zwar erfordert das neue Vorgehen pro Image-Datei ein Loop-Device. Standardmäßig stellt das Modul loop unter Linux acht dieser Geräte zur Verfügung. Das reicht aus, solange man nicht mehr als vier VMs einrichtet. Das Starten der fünften VM wird dann jedoch scheitern. Aus diesem Grund sorgen wir dafür, dass das Modul beim Laden gleich 128 Geräte anlegt, in der Hoffnung, dass wir uns nie mehr mit dem Problem herumschlagen müssen. Dazu öffnen wir die Datei /etc/modprobe.d/options (oder legen sie neu an) und fügen folgende Zeile ein:
options loop max_loop=128
Dann müssen wir die maßgebliche Datei /etc/modules.conf neu generieren, was durch Aufruf von update-modules geschieht.
Weil wir gerade dabei sind, heben wir auch gleich ein Limit von DRBD auf. DRBD legt standardmäßig nur zwei Geräte an, wenn es als Modul geladen wird. Man muss mit der Direktive options drbd minor_count=8 dafür sorgen, dass DRBD beim Laden mehr Geräte anlegt. 8 ist derzeit das Maximum. Wir fügen diese Zeile gleich noch zur Datei /etc/modprobe.d/options hinzu.
Einrichtung der LVM-Partitionen
Falls wir noch Überreste des alten Setups auf der Platte haben, beseitigen wir sie nun. Wer eine bereits eingerichtete VM sichern will, sollte vorher die VM herunterfahren, die Datenpartition mounten und z.B. mit tar deren gesamten Inhalt sichern.
drbdadm secondary vm100 drbdadm down vm100 dmsetup remove root100 lvremove vg-sda/swap100 lvremove vg-sdc/swap100 lvremove vg-sdc/swap100 lvremove vg-sda/root100 lvremove vg-sdc/root100 lvremove vg-sdc/root100
Diese Kommandos sind auf beiden Servern auszuführen. Wie auch die folgenden, die eine neue Partition anlegen:
lvcreate -L 2G --name vm100 vg-sda lvcreate -L 2G --name vm100 vg-sdb lvcreate -L 2G --name vm100 vg-sdc
Dies ergibt eine Partition von 6 GB Größe. Passen Sie die Werte nach Belieben an Ihre Bedürfnisse an. Dann legen wir die Datei /etc/dmtab.100 an, in der wir die Definition des RAID0-Arrays ablegen.
0 12582912 striped 3 64 /dev/vg-sda/vm100 0 /dev/vg-sdb/vm100 0 /dev/vg-sdc/vm100 0
Mit dmsetup create vm100 /etc/dmtab.100 wird das RAID0-Array zum Leben erweckt. Es steht nun als Device /dev/mapper/vm100 zur Verfügung. Dieses Kommando sollte automatisch beim Systemstart ausgeführt werden, daher tragen wir es in /etc/init.d/lvm ein, und zwar ans Ende des Abschnitts, der den Start behandelt. Auch das Herunterfahren implementieren wir gleich, indem wir an den Anfang des Stop-Abschnitts die Zeile dmsetup remove vm100 setzen.
