Login
Login-Name Passwort


 
Newsletter
Werbung

Do, 23. Januar 2014, 15:00

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

Kommentare (Insgesamt: 5 || Alle anzeigen || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung