Cluster-Lösung LinuxHA in Version 2
Hochverfügbarkeit mit Open Source
Für eine funktionierende Cluster-Lösung muss man nicht zwangsläufig tief in die Tasche greifen. LinuxHA liegt mittlerweile in Version 2 vor und kann als Beispiel für eine quelloffene Software mit großem Feature-Umfang dienen.
Auch die Vertreter quelloffener Software sind auf dem Gebiet Hochverfügbarkeit nicht untätig. Zu
den bekanntesten Projekten in diesem Bereich zählen sicher Linux Vitual Server
(www.linuxvirtualserver.org) als Load Balancer und LinuxHA (www.linuxha.org) als Cluster-Lösung.
Dieser Artikel zeigt die Vorteile und Fähigkeiten der Version 2 von LinuxHA, auch bekannt als
Heartbeat. Interessant sind auch die neuesten Entwicklungen mit Pacemaker als Nachfolger des
bisherigen Herzstücks.
Cluster-Probleme
Ein Verbund aus Rechnern, der Dienste hoch verfügbar anbieten soll, steht immer vor einigen
Problemen. Eine zusätzliche Software als Schicht zwischen Betriebssystem und Anwendung, in diesem
Zusammenhang Ressource genannt, muss für die Verwaltung sorgen. Ressourcen dürfen nur einmal im
gesamten Cluster gestartet werden, bei Problemen ist es erforderlich, die Anwendungen auf einen
anderen Knoten zu verschieben, und nicht zuletzt ist eventuell der Zugriff aller Knoten auf einen
gemeinsamen Speicher (Shared Storage) zu regeln.
Im Grunde treten diese Probleme bei allen Clustern auf, und die Hersteller haben ähnliche
Lösungen dafür gefunden. Diese Grundlagen dazu sind in einem Whitepaper (www.linuxha.org)
zusammengefasst, das auch die Basis aller Überlegungen zu Heartbeat bildet. Im Umfeld freier
Software hat sich das Projekt LinuxHA der Lösung dieser Probleme verschreiben. Weltweit setzen
bereits viele Administratoren die entsprechende Software ein. Das Projekt wird inzwischen
hauptsächlich von Suse/Novell unterstützt, sodass zu den bekannten Vorteilen offener Software
(Sicherheit, schnelle Entwicklungszyklen) und einer großen Benutzergemeinschaft auch der Vorteil
eines professionellen Supports kommt.
In der Version 2 der Software startet der Heartbeat-Prozess weiterhin alle Ressourcen, die
hoch verfügbar angeboten werden sollen. Heartbeat ist auch für die Kommunikation zwischen den
Knoten zuständig. Im Hintergrund berechnet der Cluster Ressource Manager (CRM), wie die Ressourcen
auf den zur Verfügung stehenden Knoten optimal zu verteilen sind. Der Administrator kann diese
Entscheidung mit verschiedenen Bedingungen steuern.
In der neuen Version ist Konfiguration intern in XML repräsentiert. Der Administrator hat die
Wahl, seine Ressourcen und Bedingungen ebenfalls per Kommandozeile in XML einzugeben oder eine GUI
zu nutzen.
Entwicklung
Aufgrund von strategischen Überlegungen ist der zentrale CRM aus dem Projekt herausgelöst und
firmiert nun unter dem Namen Pacemaker. Der Vorteil dieser Schrittes ist, dass Pacemaker nun nicht
mehr allein auf Heartbeat als Kommunikationsplattform angewiesen ist, sondern ebenfalls OpenAIS
nutzen kann. Damit ist der erste Schritt zu einer einheitlichen Cluster-Lösung beider großer
Distributionen (Red Hat und Suse) getan.
In den Distributionen ist oft noch die alte Lösung zu finden, bei der noch der CRM die
Ressourcen verteilt. Wer unbedingt die neue Version ausprobieren will, sei auf den Build Service
von Suse verwiesen, der Binärpakete für alle gängigen Distributionen bietet. Da das
Open-Source-Modell zugrunde liegt, kann man auch den letzten Entwicklungsstand direkt aus dem
Repository heraus selbst übersetzen.
Ein Beispiel
Die Konfiguration der Version 2 der Software liegt in einer zentralen Konfigurationsdatei,
der Cluster Information Base (CIB), und ist in XML kodiert. Die CIB darf nie direkt bearbeitet
werden, Änderungen wie neue Ressourcen oder Bedingungen sind vielmehr als XML-Schnipsel als Updates
per Kommandozeile einzupflegen. Alternativ existiert auch eine GUI, die die CIB grafisch
aufbereitet.
Im Beispiel für die Konfiguration gilt es, einen Web-Server mit einer virtuellen IP-Adresse
und dem Apache-Dienst als Gruppe zu konfigurieren. Eine Gruppe hat den Vorteil, dass die Ressourcen
auf einem Knoten nacheinander angeordnet gestartet (und auch wieder gestoppt) werden. In der GUI
sieht die Übersichtsseite mit dem Status der Knoten und der Ressourcen wie in Bild 1 aus: Die
Web-Server sind als Gruppe konfiguriert. Aktuell hat der Webserver offensichtlich ein Problem und
läuft nicht.
Die Definition dieser Ressourcen sieht in XML wie folgt aus:
name=“monitor“ onfail=“
restart“ role=“Started“/>
value=“3″/>
value=“/etc/apache2/apache2.conf“/>
name=“monitor“ onfail=“
restart“ role=“Started“/>
value=“3″/
>
Der Vorteil der Definition der Attribute von Ressourcen – etwa der IP-Adresse oder der
Konfigurationsdatei von Apache – innerhalb des Clusters liegt auf der Hand: Änderungen müssen nicht
in Konfigurationsdateien auf allen Knoten des Clusters manuell nachgepflegt werden, die
Cluster-Software selbst verteilt diese vielmehr automatisch und zentral. Falls sich ein Parameter
ändert, kann der Administrator dieses mit wenigen Mausklicks eingeben.
Neben den Attributen von Ressourcen kann der Administrator in Version 2 von Heartbeat auch
Operationen definieren. Im Beispiel oben werden beide Ressourcen alle 20 Sekunden mit dem Aufruf "
monitor" auf ihre Funktion hin überprüft. Falls dieser Aufruf scheitert, startet der Cluster die
Ressource einfach neu (onfail=“restart“). Dies versucht er jedoch nur dreimal, da ein Meta-Attribut
die Fehlertoleranz (migrationthreshold) begrenzt. Falls der Fehler nach drei Neustarts nicht
beseitigt ist, wandert die komplette Gruppe einfach auf einen anderen Knoten. Der Cluster als
Ganzes bietet den Apache Web-Server also weiterhin an, auch wenn ein Knoten Probleme macht.
Bedingungen sind das Werkzeug des Administrators, um das Verhalten des Clusters zu steuern.
Mit den Typen
Lokation einer Ressource auf einem Knoten, wenn eine Voraussetzung erfüllt ist,
Colokation einer Ressource in Abhängigkeit von einer anderen und
Anordnung einer Ressourcen in Abhängigkeit von einer anderen
lassen sich beliebige Konfigurationen eingeben. Die beiden letzten Bedingungen dienen dazu,
den Bezug von Ressourcen untereinander herzustellen. Dieser Bezug ist in Gruppen automatisch
gegeben. Mit Lokationsbedingungen kann der Administrator Präferenzen von Ressourcen für bestimmte
Knoten vorgeben, wenn sie bestimmte Vorgaben erfüllen.
Ping-Knoten
Einfache Vorgaben sind zum Beispiel der Name des Knotens oder die Erreichbarkeit im Netz, die
jeder Knoten selbstständig überprüft, indem er so genannte Ping-Knoten andauernd anspricht. Weitere
vordefinierte Bedingungen sind die Prozessorlast oder die freie Kapazität einer Partition der
Festplatte. Letztendlich ist der Administrator in dieser Stelle völlig frei und kann beliebige
Bedingungen eingeben, also auch den Wochentag oder die aktuelle Niederschlagsmenge. Die Bedingung,
um die oben eingegebene Gruppe mit einer Präferenz von 100 Punkten auf dem Knoten mit dem Namen
knoten1 laufen zu lassen, lautet in XML-Notation:
Andere Bedingungen beziehen sich auf andere Attribute, die in der CIB definiert sind. Diese
Attribute werden zum Teil von internen Prozessen des Clusters verwaltet, sind aber auch per
Kommandozeile von außen steuerbar.
Um beide Knoten eines Clusters mit denselben Daten zu versorgen, sind die Distributed
Redundant Block Devices (DRBD, www.drbd.org) in LinuxHA integriert. Daten, die das File-System
eines Knoten auf das aktive Block-Device schreibt, werden durch DRBD auf das passive Block-Device
des anderen Knotens repliziert. Im Fehlerfall stehen somit alle aktuellen Daten sofort auf dem
zweiten Knoten zur Verfügung. Heartbeat nutzt DRBD als Ressource und kann über Bedingungen andere
Ressourcen vom Zustand des DRBDs abhängig machen. So ist das File-System nur auf dem Knoten
eingebunden, auf dem das DRBD im Zustand "Master" vorliegt. Im Fehlerfall übernimmt das andere
Gerät die Master-Rolle. Das File-System und davon abhängige Ressourcen wie zum Beispiel eine
Datenbank ziehen mit um und können mit dem selben Datenstand weiterarbeiten.
Fazit: für den produktiven Einsatz geeignet
LinuxHA umfasst in der Version 2 einen brauchbaren Ansatz, um die ganze Bandbreite von
einfachen bis komplexen Cluster-Konfigurationen abzubilden. Durch den Reifegrad der Software, die
seit zehn Jahren zur Verfügung steht, ist sie durchaus für den produktiven Einsatz empfehlenswert.
Der LinuxHA-Ansatz hat sich außerdem in vielen Installationen weltweit bewährt.
Lesen Sie mehr zum Thema
