Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 11
Corosync und Pacemaker, libvirt und Live-Migration von KVM
In diesem Artikel wird der hochverfügbare Server auf Corosync und Pacemaker umgestellt. Die virtuellen Maschinen werden über libvirt verwaltet, was eine saubere Einbindung in den Cluster Resource Manager (CRM) und die Live-Migration ermöglicht.
Einleitung
Dies ist Teil 11 des Workshops »Virtueller hochverfügbarer Linux-Server«. Die weiteren Teile finden Sie über das Inhaltsverzeichnis.
In der 10. Folge der Serie hatten wir einen stabilen Zustand erreicht, der nur noch wenige Wünsche offenließ, nämlich die KVM-Live-Migration und den Wechsel zur neuesten Version von Heartbeat. Seither ist eine sehr lange Zeit vergangen - fast fünf Jahre. Ich möchte kurz einen Rückblick auf diese Zeit geben, die natürlich nicht ganz ereignislos waren, aber in den ersten drei Jahren nicht zu Resultaten führten, die für einen neuen Artikel ausreichten.
Natürlich beschäftigte ich mich mit der KVM-Live-Migration, die damals eigentlich schon funktionieren sollte. Leider scheiterte ich daran mehrfach. Voraussetzung für die Live-Migration war eine Möglichkeit, die virtuellen Maschinen (VMs) zuverlässig zum Herunterfahren zu bringen - mit KVM/Qemu war das nur schwer lösbar. Um das zu erleichtern, installierte ich libvirt und stellte die VMs auf libvirt um. Dann konnte ich zwar die Migration starten - die VM stürzte aber ab. Trotz Kernel-Updates auf VMs und Servern - bis zur Version 2.6.37 - und Updates von Qemu blieb das Problem bestehen.
Bei Heartbeat wollte ich anstelle des eingebauten Cluster Resource Managers (CRM), der nach Angaben des Projektes selbst recht primitiv gehalten war, Pacemaker testen. In einer Testumgebung klappte das auch; als ich aber das Programm in der Produktivumgebung installiert und mit einer größeren Konfiguration gefüttert hatte, stürzte es ständig ab. Im Nachhinein ist mir klar, wie es zu diesen Problemen kam. Mit etwas mehr Zeit und Recherchen wären sie lösbar gewesen, doch in der Zwischenzeit hatte ich zuviel anderes zu tun.
Damit war Heartbeat für mich unbrauchbar geworden. Ich schaltete es ab und ließ die Server ohne Failover laufen. Im Falle eines Absturzes (der VM), Lüfterausfalls oder Netzteilausfalls (zweimal vorgekommen) der Server musste ich die Dienste und VMs von Hand wieder starten. Das war der Zustand, bis das längst überfällige Update auf Debian 6.0 »Squeeze« neue Versionen der Software ins System brachte. Von da an kamen die Dinge ins Lot, und der Artikel beschreibt den Zustand, der nun bereits seit mehr als zwei Jahren sehr zuverlässig läuft.
Dieser Artikel wird das Aufsetzen der virtuellen Server noch einmal von Grund auf beschreiben, da im Lauf der Zeit einige neue Erkenntnisse hinzugekommen sind. Danach kommt das Einrichten von DRBD, die Installation von libvirt und das Einrichten der virtuellen Maschinen, gefolgt von der Einrichtung der Hochverfügbarkeit.
Grundinstallation von Debian
Wer bereits Debian auf seinen Servern betreibt, sollte längst auf Debian 6.0 oder gar schon Debian 7.0 umgestellt haben. Bei einer Neuinstallation verwendet man gleich Debian 7.0; dieser Artikel baut allerdings noch auf 6.0 auf.
Debian 6.0 »Squeeze« brachte erstmals eine vollständige Softwareausstattung für Hochverfügbarkeit mit. Corosync (das Heartbeat ablöst), Pacemaker, aber auch libvirt und Qemu sind in neuen Versionen oder zum ersten Mal vorhanden. DRBD ist nun im Kernel, muss also auch nicht mehr separat installiert werden. Im Repositorium »squeeze-backports« finden sich von all diesen Komponenten neuere Versionen, und da neuer bei freier Software fast immer auch besser bedeutet und besseren Support ermöglicht, sind es diese Versionen, die wir verwenden werden. Erstmals können wir auch darauf verzichten, einen eigenen Kernel zu compilieren, weshalb das in diesem Artikel nicht beschrieben wird.
Die Hardware-Voraussetzung ist, zur Erinnerung, dass zwei Ethernetanschlüsse pro Server vorhanden sind, sinnvollerweise mit der Geschwindigkeit 1 Gbit/s oder höher. Weitere Netzwerkschnittstellen für die Anbindung weiterer Netze sind optional. Eine unterbrechungsfreie Stromversorgung (USV) für jeden Server ist dringend anzuraten, sonst wäre das »hochverfügbar« im Titel ein Witz. Es sollte eine von Linux unterstützte USV sein, die vom Server aus steuerbar ist, insbesondere ausgeschaltet werden kann. Dass in den Servern hocheffiziente Netzteile zum Einsatz kommen, die im optimalen Leistungsbereich betrieben werden (also nicht überdimensioniert sein sollten), versteht sich fast von selbst.
Bei einer Neuinstallation sind nur zwei Partitionen anzulegen, eine für /boot und eine für den ganzen Rest, der mit LVM verwaltet werden soll. Wer mehrere Platten als RAID1, RAID5 etc. betreiben will, sollte zuerst ein Linux-Software-RAID aufsetzen, was ein Gerät /dev/md0 ergibt. In der folgenden Darstellung ist dann einfach /dev/sda2 durch /dev/md0 zu ersetzen, ansonsten ändert sich nichts. Die Partitionierung mit Sektoren als verwendete Einheit könnte ungefähr so aussehen:
Device Boot Start End Blocks Id System /dev/sda1 2048 409999 203976 83 Linux /dev/sda2 410000 2930277167 1464933584 8e Linux LVM
Hier ist die /boot-Partition 200 MB groß. Damit kann man heute an die Grenzen stoßen, wenn man mehrere Distributions-Kernel installieren will. Man sollte hier nicht am falschen Ende sparen, da aktuelle Festplatten riesig sind und diese Aufteilung später nicht mehr zu ändern ist. Man sollte also ruhig 500 MB vorsehen. Für diese Partition ist ext2 als Dateisystem ausreichend.
Das LVM kann den Rest der Festplatte umfassen, man kann es aber auch kleiner machen, wenn man sich Raum für andere Zwecke oder Tests freilassen will. Die erstellte Volume Group sollte man eindeutig benennen, beispielsweise nach dem Namen des Rechners (wir verwenden hier aber den generischen Namen vg0). Die Größe der Extents sollte 128 MB betragen, auf jeden Fall wesentlich mehr als der Standard von 4 MB, denn nach verschiedenen Angaben ist die Standard-Größe meist viel zu klein. Eine Granularität von 1 Promille des gesamten Volumes ist ausreichend. Die gesamte Zahl der zu verwaltenden Extents wird damit verringert. Wem 128 MB zu groß erscheint, der kann 64 oder 32 probieren. Auch größere Werte sind möglich. Die Kommandos zur Erstellung der Volume Group lauten, wenn man sie von Hand ausführt:
pvcreate /dev/sda2 vgcreate -s 128m vg0 /dev/sda2
Wegen der Spiegelung durch DRBD sind RAID-Konfigurationen wie RAID1 oder RAID5 unnötig. RAID0 zur Vergrößerung der Kapazität ist möglich, in diesem Fall würde man das LVM auf /dev/md0 legen. Alternativ kann man auch die einzelnen Platten zu einem logischen Volume verbinden, doch das RAID scheint eher empfohlen zu werden.
Wir legen drei logische Volumes an, weitere kommen später hinzu, wenn wir DRBD einrichten. Die Volumes sind:
Name | Größe | Mountpoint | Bemerkung |
root | 2,0 GB | / | |
log | 1,0 GB | /var/log | Verhindert, dass / volläuft |
swap | ca. 4 GB | swap | |
Als Dateisysteme eignen sich xfs und ext4 gleichermaßen. Wer xfs einsetzt, sollte die Mount-Option logbufs=8
hinzufügen, da das die Geschwindigkeit steigert. Die Größe der Swap-Partition hängt von den Anforderungen ab. Wer viel RAM hat und davon ausgeht, dass es selten voll ausgenutzt wird, kann die Swap-Partition deutlich kleiner als das RAM machen. Ansonsten macht man es eher größer als das RAM; auch wenn man den Einsatz von kexec oder Hibernate plant, sollte sie größer als das RAM sein.
Tipp: Tragen Sie die generierte UUID in die Datei /etc/fstab ein, das ist flexibler als die Pfadangabe /dev/mapper/vg0-swap. Die gesamte /etc/fstab sieht damit ungefähr so aus:
# /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/mapper/vg0-root / xfs noatime,nodiratime,attr2,logbufs=8 0 1 /dev/mapper/vg0-log /var/log ext4 noatime,nodiratime 0 1 /dev/sda1 /boot ext2 noatime,errors=remount-ro 0 1 UUID=8f10a0ed-514a-4767-9d61-84a794b360c0 none swap sw 0 0