Workshops::Virtueller hochverfügbarer Linux-Server

Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 9

Einrichtung von Heartbeat mit CRM auf einem Testsystem

Constraints

Constraints kann man weiter unten in der Baumdarstellung der Oberfläche sehen und anlegen. Es gibt sie in den Variationen Locations, Orders und Colocations. Locations legen fest, auf welchem Rechner eine Ressource laufen soll. Natürlich nur, wenn der Rechner läuft und aktiv ist, sonst wird versucht, sie auf dem anderen Rechner zu starten.

Das Hinzufügen einer Location ist einfach. Durch die Auswahl von Add New Item aus dem Kontextmenü von Locations erhalten wir eine Dialogbox, aus der wir den Ressourcentyp auswählen können. Wir nehmen das vorgegebene Locations. In der nächsten Dialogbox geben wir einen Namen für die Regel ein, z.B. loc_ip_192_168_2_1 und wählen die Ressource aus, die wir bearbeiten wollen, hier ip_192_168_2_1. Die Regel erscheint nun in der Baumdarstellung, aber ihre Definition ist noch nicht beendet. Wir selektieren sie und können nun in der rechten Fensterseite Attribute definieren. Zunächst setzen wir oben rechts den Score auf 100, dann klicken wir Add Expression, lassen das vorgegebene #uname so stehen und wählen für die dritte Zeile debianha1. Dies besagt, dass unsere Ressource, wenn möglich, auf debianha1 laufen soll (#uname, also der Rechnername, ist debianha1). Nach einem Klick auf OK müssen wir noch unten rechts auf Apply klicken, sonst erscheint eine Dialogbox, die fragt, ob die Änderungen gespeichert werden sollen. Apply führt dazu, dass die Regel sofort angewandt wird, und die IP-Adresse migriert auf debianha1, wenn sie vorher noch nicht dort war.

Mit den Constraints Orders und Colocations kann man unser noch ausstehendes Problem lösen, dass DRBD und Dateisystem auf demselben Knoten laufen müssen. Außerdem muss natürlich zuerst DRBD Primary auf dem Knoten sein, bevor sich das Dateisystem mounten lässt. Doch es gibt eine einfachere Alternative zu diesen Constraints, nämlich die Gruppen. Alle Ressourcen in einer Gruppe werden auf demselben Knoten gestartet und auch immer als Einheit migriert. Außerdem werden sie in genau der Reihenfolge gestartet, in der sie in der Gruppe stehen.

Wir hätten eine Gruppe gleich bei der Definition des Ressourcen anlegen können. Da wir das nicht gemacht haben, versuchen wir es nachträglich zu ändern. Wir legen eine Gruppe genauso an, wie wir zuvor eine Ressource erzeugt haben: Über den Menüpunkt Add New Item. Nur wählen wir nun als Item Type nicht native, sondern group. In der nachfolgenden Dialogbox vergeben wir einen sinnvollen Namen, z.B. group_app in Erinnerung an den Mountpoint des Dateisystems. Die beiden anderen Punkte Ordered und Colocated lassen wir auf »true«.

Hans-Joachim Baader (hjb)

Konfiguration der Monitoring-Operation

Nun folgt die bereits bekannte Dialogbox zum Hinzufügen einer Ressource zu der Gruppe. Es stellt sich heraus, dass es nicht möglich ist, eine bereits vorhandene Ressource nachträglich in eine Gruppe zu verschieben. Macht nichts, da dies ja nur ein Test ist. Wir müssen die bereits definierten Ressourcen disk0 und fs_drbd0 löschen und dann im Rahmen der Definition einer neuen Gruppe neu anlegen.

Ist dies geschehen, kann man der Gruppe genau wie einer einzelnen Ressource eine Location zuweisen.

Überwachung

Ein Punkt fehlt uns jetzt noch in unserer Zielsetzung. In der bisherigen Konfiguration sorgt Heartbeat nicht nur dafür, dass Ressourcen gestartet werden, es prüft auch, ob diese noch laufen, und startet sie gegebenenfalls neu. In Heartbeat 2 mit CRM kümmert sich Heartbeat nicht automatisch um ausgefallene Ressourcen. Wir müssen eine Operation dafür definieren.

Wir nehmen wieder den IP-Alias als Beispiel. Wir selektieren die Ressource, worauf im rechten Fensterteil drei Tabs mit Attributes, Parameters und Operations sichtbar werden. Wir wählen den Tab Operations und klicken auf Add Operation. Die nun erscheinende Dialogbox füllen wir wie im Bild angegeben aus. Danach klicken wir Apply, und ab sofort wird die Ressource überwacht. Entfernen wir den IP-Alias von Hand, erscheint er flugs wieder. Ein solches Monitoring ist für die meisten angelegten Ressourcen sinnvoll.

Nächste Schritte

hb_gui ist ein großartiges Programm, das die Konfiguration der Ressourcen wesentlich vereinfacht und sogar recht komfortabel ist. Ohne es müsste man sich mit komplexen XML-Definitionen auseinandersetzen. Sollte irgendetwas sich nicht über die GUI einstellen lassen, kann man immer noch die XML-Datei anpassen, was dann wesentlich einfacher ist, als bei Null anzufangen.

hb_gui ist allerdings, in manchen Versionen jedenfalls, ein Speichenfresser, daher sollte man das Programm nicht für längere Zeit laufen lassen, nur um den Cluster zu beobachten, sondern es beenden, wenn man es nicht mehr benötigt.

Im nächsten Artikel der Folge wenden wir die hier gewonnenen Erkenntnisse auf den realen Cluster an. Bis dahin können Sie nach Herzenslust mit Heartbeat herumspielen. Es gibt eine Menge Parameter zu erkunden, deren Funktion nicht gerade offensichtlich ist. Mit Hilfe der Heartbeat-Dokumentation und der Mailingliste sollten sich aber alle Fragen lösen lassen.

Endlich ist auch ein Punkt abgehakt, der schon von Anfang an auf der Wunschliste stand: Ein Testsystem, auf dem man neue Dinge ausprobieren kann, während der Cluster unverändert läuft. In Teil 10 wird dann auch das Ziel der Umstellung auf den CRM endgültig erledigt. Die nächsten drängenden Probleme werden dann wohl Geschwindigkeitsoptimierung und Live-Migration sein. Aber am Horizont tauchen bereits weitere Ideen auf, die ich im Bericht vom Linux-Kongress 2008 schon beschrieben habe. Zum einen ist Heartbeat 3 unterwegs, von dem man sich noch einmal wesentliche Verbesserungen erhoffen kann. Heartbeat und OpenAIS werden verschmelzen, so dass es nur noch einen freien Cluster-Stack statt zwei geben wird. Die Basis wird OpenAIS bilden, dazu kommt Pacemaker von Heartbeat als CRM-Nachfolger. Auch DRBD wird weiterentwickelt und als Modul in LVM integriert, was vielleicht unsere Konfiguration vereinfacht und mehr Geschwindigkeit bringt.