Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 8
DRBD, KVM und Heartbeat
In diesem Artikel wird ein vollständig neuer Ansatz für den hochverfügbaren Server vorgestellt: Vereinfachte Partitionierung, KVM statt Xen und neue Versionen von DRBD und Heartbeat.
Einleitung
Dies ist Teil 8 der Workshops »Virtueller hochverfügbarer Linux-Server«. Die weiteren Teile finden Sie über das Inhaltsverzeichnis.
Nachdem wir in Teil 5 bzw. 6 einen Server mit Xen aufgebaut hatten, war eine Phase der Stabilität erreicht, in der das System produktiv genutzt wurde. Etwas unterbrochen wurde diese durch den Upgrade der Prozessoren auf Dual-Core-CPUs mit Hardware-Virtualisierung, was dem zuvor recht trägen Xen ordentlich Beine machte. Aufgrund von Problemen wurde Xen 3.0 durch 3.1 ersetzt, wie ich in Teil 7 beschrieb, und weitere Verbesserungen vorgenommen. Soweit schien alles bestens.
Bis ich eines Tages entdeckte, dass das Kopieren von großen Dateien, also von 100 MB bis einige GB, von einem Client in eine virtuelle Maschine (domU) zu einer Kernel-Panic auf dem Host (dom0) führte. Danach war das XFS-Dateisystem der domU beschädigt und musste repariert werden.
Vermutlich handelt es sich bei dem Problem um einen Fehler, der in neueren Kernels längst behoben ist. Xen baut jedoch dummerweise weiterhin auf Linux 2.6.18, das Mitte 2006 erschienen ist. Ein Update von XFS oder des Netzwerktreibers erschien mir aufgrund der vielen Änderungen seither nicht realistisch. Eine Alternative hätte ein Xen-Kernel z.B. von Fedora sein können - oder einfach auf die nächste Xen-Version warten. Andererseits schien die Zeit reif, auf KVM umzuschwenken, das bereits seit Anfang 2007 im Kernel ist und es daher ermöglicht, den aktuellsten Kernel einzusetzen.
Ein neuer Plan
KVM setzt ein leicht modifiziertes Qemu als Userspace-Komponente ein. Qemu kann verschiedene Image-Formate für seine virtuellen Laufwerke verwenden. Es bietet jedoch keine Möglichkeit, ein Image einer einzelnen Partition einzubinden, wie das unter Xen üblich zu sein scheint. Meine Xen-Installation konnte also nicht direkt übernommen werden.
Meine erste Idee war, vor einer Migration zu KVM die Xen-Images zu ändern, so dass sie später von KVM direkt verwendet werden könnten. Doch nachdem erste Experimente gezeigt hatten, dass Xen in dieser Version beim Zugriff auf solche Images extrem langsam ist (über hundertmal langsamer als bei den bisherigen Images), nahm ich davon Abstand.
Also entwarf ich folgenden Plan:
- Trennung der beiden Server. Auf dem einen sollen die virtuellen Maschinen weiterlaufen, der zweite soll neu aufgesetzt werden.
- Neuinstallation des zweiten Servers mit Debian 4.0. Dabei soll erstmals ein neues Partitionierungsschema zum Einsatz kommen: Eine dedizierte Boot-Partition am Anfang der drei Festplatten, LVM über den ganzen Rest der Platten. Auch Root- und Swap-Partition des Hosts sollen in LVM liegen. Ferner wird LVM hinsichtlich optimaler Geschwindigkeit angelegt. Die Partitionierung wird zudem vereinfacht.
- Compilierung und Einsatz eines eigenen Kernels (mit KVM natürlich). DRBD wird nachträglich hinzugefügt. Statt DRBD 0.7 soll die neue Version 8 zum Einsatz kommen.
- Die Geschwindigkeit der Partitionen sowie der virtuellen Laufwerke soll gemessen und verglichen werden.
- Die Daten der virtuellen Maschinen werden in separate Image-Dateien ausgelagert. Dies vergrößert zwar die Zahl der DRBD-Geräte, sollte aber eine spätere Migration (worauf auch immer) erleichtern.
- Die Migration der VMs beginnt mit der kleinsten VM, bei Erfolg werden die anderen nachgezogen. Die Installation erfolgt mittels einer Live-CD, die unter KVM gestartet wird. Mit ihr wird das Laufwerk der VM formatiert, dann werden mit rsync alle Daten von der Original-VM kopiert, die ja auf dem Produktivserver weiterläuft. Nach dem Kopieren wird die Original-VM auf dem Xen-Server heruntergefahren und die Kopie unter KVM gestartet.
- Wenn der eine Rechner so weit eingerichtet ist, dass alle VMs auf ihm laufen, wird der andere ebenso behandelt und die Synchronisation über DRBD wieder hergestellt.
- Heartbeat soll in der aktuellsten Version 2.1 zum Einsatz kommen und mit den modernen auf XML beruhenden Dateien konfiguriert werden.
Soweit der Plan. Wir werden gleich sehen, ob und wie er aufging.
