Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 11
Corosync und Pacemaker, libvirt und Live-Migration von KVM
Ressourcen definieren
Wir benötigen folgende Ressourcen im Cluster:
- STONITH
- IP-Adressen, auf denen der DNS-Server und der Router laufen
- DNS- und Zonen-Server
- DRBD-Partitionen
- Virtuelle Maschinen
Es ist erwähnenswert, dass wir keine Datenbank und andere Dienste benötigen, da diese in einer oder mehreren der laufenden VMs installiert werden. Die VMs selbst benötigen keine Dateisystem-Ressource, kein NFS und kein Cluster-Dateisystem, da sie immer direkt die DRBD-Partitionen nutzen.
){kind=small}
Hans-Joachim Baader
Globale Optionen für den Cluster
Allgemeine Konfiguration
Starten wir also LCMC mit java -jar /opt/LCMC-1.5.14.jar oder ähnlich. Man muss zunächst das Root-Passwort für einen der Server eingeben, danach ermittelt LCMC die aktuelle Konfiguration. Sollte einer der beiden Server nicht erreichbar sein, kann immer noch der andere genutzt werden. Wir gehen direkt zum Menüpunkt . Auf der rechten Seite werden nun die Optionen für das gewählte Element, hier den ganzen Cluster, angezeigt. Wir setzen auf ein und auf aus. Das ist aber nur vorübergehend, damit während der Konfiguration kein Server versehentlich ausgeschaltet wird. Im Normalbetrieb ist eine STONITH-Einrichtung zwingend. STONITH steht für »Shoot the other node in the head« und bedeutet, dass in dem Fall, dass einer der Server ausfällt oder die Verbindung zwischen beiden, der »überlebende« Server den anderen abschaltet. Macht man das nicht, könnte der zweite Server versuchen, wieder zu starten, und schwere Synchronisationsprobleme verursachen, die nur manuell aufgelöst werden könnten.
Die Option setzen wir auf ignore, denn für ein Quorum bräuchte man mindestens drei Server im Cluster. Die (Kosten der Migration) setzen wird auf 100, damit nicht sinnlos zurückmigriert wird. Ein Wert von 0 würde bedeuten, dass eine Ressource auf ihren ursprünglichen Server zurückwandern könnte, sobald der wieder verfügbar ist. Die Felder sollte man auf eine kleine Zahl setzen, auf keinen Fall auf -1, was eine unbegrenzte Speicherung von Logs bedeuten würde.
Die geänderte Konfiguration wird durch einen Klick auf den -Button gespeichert und - wichtig - sofort angewandt.
){kind=small}
Hans-Joachim Baader
Kontextmenü zur Ressourcendefinition
IP-Adressen
Wir wollen auf dem Cluster einen DNS-Server betreiben, der eine von den Servern unabhängige IP-Adresse haben soll. Da unser Netz die Adressen 172.16.1.0/24 nutzt, könnte diese Adresse 172.16.1.250 lauten, und die Adressen 251-253 könnten für Slave-DNS-Server verwendet werden. Wir legen eine Ressource an, indem wir im mittleren Panel die rechte Maustaste klicken, und darunter IPaddr2 auswählen.
Rechts können wir nun die IP-Adresse 172.16.1.250, die Schnittstelle br1 und die Netzmaske 24 eingeben. muss started sein, den Rest lassen wir. Nach sollte die Ressource die Farbe gelb oder blau annehmen und somit auf einem der beiden Knoten laufen. Mit ping kann das getestet werden.
Analog definieren wir die Adresse 172.16.1.254. Diese Adresse soll das Default Gateway für alle Rechner im Netz sein (außer den Servern selbst); der Server, der diese Adresse besitzt, ist somit der Router ins Internet oder andere Netze. Falls die Netzwerktopologie eine andere ist und ein anderer Router genutzt wird, entfällt dieser Schritt.
Nun wollen wir noch festlegen, dass beide IP-Adressen auf demselben Rechner liegen sollen. Dazu klicken wir auf einer der beiden Adressen rechts (in diesem Fall ist es im Prinzip egal, auf welcher von beiden), und wählen und dann die Ressource der anderen IP. Standardmäßig werden sowohl die Kolokation (die Ressourcen müssen auf dem gleichen Server laufen oder auf unterschiedlichen) als auch die Reihenfolge festgelegt. Beides kann man am Ende des Menüs abschalten, man kann es aber auch später noch entfernen.
DNS- und Zonen-Server
Der DNS-Server muss vor der Definition dieser Option konfiguriert worden sein, und beide Server sollten die gleiche Konfiguration haben. Der der Server in der Regel über ein Skript in /etc/init.d gestartet wird, benötigen wir jetzt eine LSB-Ressource. Bei Verwendung von MaraDNS ist das lsb:maradns. Weitere Angaben braucht man nicht. Nach dem Abspeichern sollte MaraDNS starten. Durch Rechtsklick auf die Ressource der IP-Adresse 172.16.1.250 kann man dann festlegen, dass MaraDNS erst startet, wenn die Adresse vorhanden ist, und zwar auf demselben Server. Im Falle von MaraDNS muss außerdem noch der Zoneserver-Dienst lsb:zoneserver angelegt werden; dieser erhält die gleichen Abhängigkeiten.
Wichtig ist noch, dass der Server komplett unter der Kontrolle des CRM läuft. Die Links /etc/rc*/*maradns* und /etc/rc*/*zoneserver* sind daher zu entfernen.
){kind=small}
Hans-Joachim Baader
Definition einer DRBD Master-Slave-Ressource
DRBD-Partitionen
Die DRBD-Partitionen definiert man durch . Vorsicht, es gibt weitere Ressourcen mit DRBD im Namen, die nicht geeignet sind. Diese Ressource wird als Master-Slave-Ressource definiert. Die Parameter M/S Master-Max und Clone Max setzen wir auf 2, da es zwei Knoten gibt und beide zugleich Primary sein sollen. Die Parameter Notify und Interleave schalten wir ein.
Virtuelle Maschinen
Auf jeder DRBD-Partition läuft in unserem Setup eine VM. Wir verwenden die Ressource , die für libvirt gemacht wurde. Wir müssen die Definitionsdatei der VM mit vollem Pfad angeben, z.B. /etc/libvirt/test.xml. Die Hypervisor-URI ist qemu:///system. Die Option Allow Migrate wird auf ein gesetzt. Es empfiehlt sich, anders als bei anderen Ressourcen, die Timeouts für Start, Stop und Migration deutlich zu erhöhen. Ich habe sie auf 240 Sekunden gesetzt.
Auch die virtuellen Maschinen haben wieder Abhängigkeiten, und zwar auf die DRBD-Partitionen, die sie benutzen. Per Rechtsklick auf jede DRBD-Ressource definieren wir diese wie gewohnt. Allerdings verwenden wir hier keine Kolokation, da die DRBD-Partitionen auf allen Knoten zur Verfügung stehen und die VMs beliebig migrieren können.
Wenn alles gut geht, sollten nun alle Ressourcen laufen, und wenn man alle Partitionen und VMs definiert hat und die Objekte ein wenig in der GUI ausgerichtet hat, sollte man eine hübsche Übersicht über den Cluster haben.
){kind=small}
Hans-Joachim Baader
Der vollständige Cluster in der Übersicht
STONITH
Wenn alles läuft, ist als letztes STONITH fällig. In professionellen Umgebungen, wo sowieso nichts an einer unterbrechungsfreien Stromversorgung (USV) vorbeiführt, lässt man die Server die USVen schalten. Jeder Server überwacht und schaltet dabei die USV eines anderen - selbstverständlich nicht seine eigene, da das unzuverlässig wäre.
Corosync bietet eine Reihe von STONITH-Ressourcen an. Wer keine USV besitzt, kann evtl. einen Stromschalter verwenden, oder wenn es wirklich sein muss, SSH. Als letzte Alternative steht auch die Meatware zur Verfügung - soll heißen, ein Operator wird alarmiert und muss von Hand ausschalten.
Wie dem auch sei, eine Ressource muss für jeden Knoten angelegt werden. Dazu nutzt man für eine USV. Hostname, USV-Name und Zugangsdaten müssen konfiguriert werden, außerdem muss man sicherstellen, dass die Pfade von upscmd und upsd stimmen. Außerdem ist hier der Ort entscheidend, auf dem sie laufen. Dazu setzt man die Host Locations für den Server, auf dem sie nicht laufen sollen, auf -Infinity.
Zu guter Letzt können wir in der Cluster-Konfiguration einschalten.
