HACMP
Der Cluster Manager für AIX wird HACMP (
) genannt. Er wird bei Applikationen eingesetzt, die eine hohe Verfügbarkeit aufweisen müssen. Dies sind in der Regel unternehmenskritische Applikationen (z. B. das Abrechnungssystem für Wertpapiergeschäfte bei einer Bank).
Mit Version 6.1 wurde HACMP in PowerHA umbenannt. Auch wenn die Software mittlerweile nicht mehr so heißt, ist die Bezeichnung HACMP – auch für neue Versionen – in Fachkreisen immer noch üblich.
Mit Version 7.1 wurden sogenannte SmartAssists eingeführt, die eine automatische Erkennung und Konfiguration von verschiedenen Applikationen als HA-Lösung ermöglichen sollen.
Funktionsweise
Teilnehmende Maschinen an einem HACMP-Cluster werden Knoten genannt. Auf diesen Knoten laufen sogenannte Resource Groups (RG), die den zentralen Begriff in HACMP darstellen: eine RG ist die logische Zusammenfassung
- eines oder mehrerer Dateisysteme
- einer oder mehrerer IP-Adressen
- eines oder mehrerer Prozesse und dazugehöriger Start-/Stop-Scripte
Beim Aktivieren einer solchen Resource Group auf einem Clusterknoten werden zunächst die zugehörigen Filesysteme gemountet, anschließend mit Hilfe von in der RG-Definition hinterlegten Start-/Stop-Skripten die Prozesse der RG gestartet. Danach wird die IP-Adresse (die sogenannte Service IP) als IP-Alias auf ein dafür bestimmtes Interface aufgebracht.
Wird die Resource Group auf einen anderen Clusterknoten verschoben (Takeover), so wird erst mit Hilfe des Stop-Scripts die Anwendung beendet, die Filesysteme unmountet und der IP-Alias mit der Service-IP gelöscht, anschließend auf dem in der Reihenfolge nächsten Knoten der Aktivierungsvorgang (siehe oben) abgearbeitet. Für den Client entsteht lediglich eine kurze Unterbrechung (die notwendige Zeit für den Wechsel) bis der Service wieder unter derselben IP-Adresse zur Verfügung steht. Dass diese IP-Adresse nun eine andere Maschine repräsentiert, merkt der Client nicht.
Der größte Teil der Funktionen in HACMP bzw. PowerHA wird durch Scripte (in der Kornshell) erledigt, lediglich ein kleiner Kernel-Patch (der sogenannte Dead-Man-Switch, DMS) greift direkt verändernd in das darunterliegende Betriebssystem ein. Diese offene Architektur macht HACMP sehr flexibel.
Das größte Problem, das Clustersoftware lösen muss, ist die sogenannte Split Brain Condition: beide Knoten glauben, der aktive zu sein bzw. werden zu müssen. In HACMP/PowerHA werden bei der Konfiguration des Clusters dafür verschiedene Kommunikationsstrecken definiert, über die sich die Clusterknoten wechselseitig Nachrichten über ihre Funktionsfähigkeit zukommen lassen. Dies wird Heartbeat genannt und kann über
- eigens dafür eingerichtete IP-Interfaces
- jene hdisk-Devices, auf die beide Knoten zugreifen können müssen (Disk-Heartbeat, bzw. bei älteren Versionen "Target Mode Disk")
- serielle Leitungen (die klassische Methode und bis HACMP 4.4 unbedingt erforderlich)
bewerkstelligt werden. Kommt ein Knoten aufgrund nicht mehr empfangener Heartbeats zu dem Schluss, nicht mehr mit dem Partner bzw. der Außenwelt kommunizieren zu können, wird der Dead-Man-Switch ausgelöst und der Knoten schaltet sich je nach Konfiguration entweder ab oder startet neu. Der jeweils aktive Knoten prüft darüber hinaus, ob die Kommunikation mit den Clients noch möglich ist, bevor er sich abschaltet, damit der Standby-Knoten übernehmen kann.
Typische Konfigurationen
Mit HACMP/PowerHA ist eine Vielzahl von Clusterkonfigurationen möglich, die bei weitem häufigsten sind aktiv/passiv-Cluster (im HACMP-Jargon rotating Cluster genannt) und aktiv/aktiv-Cluster (cascading Cluster).
Rotating Cluster
Die Resource Group läuft auf einem von üblicherweise zwei (bei Bedarf aber auch mehr) Knoten, auf dem anderen Knoten läuft lediglich das Betriebssystem und der Cluster Manager. Fällt der aktive Knoten aus, so führt der andere einen Takeover durch. Der Modus wird rotating genannt, weil die Resource Group zwischen den Knoten hin- und herverschoben wird, also quasi "rotiert".
Diese Betriebsart wird bevorzugt für unabdingbar notwendige Systeme eingesetzt und hat den Vorteil, gut planbar bei relativ geringer Komplexität zu sein. Der Nachteil ist, dass ein erheblicher Teil der Kapazität (der/die Standby-Knoten) die meiste Zeit über nicht genutzt wird.
Cascading Cluster
Die Resource Group mit der Hauptanwendung läuft auf einem Knoten, auf einem weiteren Knoten laufen Resource Groups, die bei Bedarf abgeschaltet werden können. Im Fehlerfall führt der Standby-Knoten zunächst die Stop-Skripte seiner eigenen Resource Groups aus, danach wird ein Takeover auf die RG der Hauptanwendung durchgeführt.
Diese Betriebsart ist typisch für Systeme, bei denen eine Produktivinstanz einer oder mehreren Test- bzw. Entwicklungsinstanzen gegenübersteht, etwa bei SAP ERP oder größeren Datenbanken. Die Testinstanzen werden dann, solange kein Fehler auftritt, auf dem Standby-Knoten betrieben. Im Fehlerfall übernimmt dieser die Produktivinstanz und die Testinstanzen stehen solange nicht zur Verfügung.
