HACMP
Der Cluster Manager für AIX wird HACMP (High Availability Cluster Multi-Processing) 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 SmartAssist-Agenten eingeführt, die eine automatische Erkennung und Konfiguration von verschiedenen Applikationen als HA-Lösung ermöglichen.
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 Fileysteme
- einer oder mehrerer IP-Adressen
- eines oder mehrerer Prozessen und dazugehöriger Start-/Stop-Scripte
Beim Aktivieren einer solchen Resource Group auf einem Cluster-Knoten werden zunächst die zugehörigen Filesysteme gemountet, sodann mit Hilfe von in der RG-Definition hinterlegten Start-/Stop-Scripten 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 Applikation beendet, die Filesysteme abgehängt und der IP-Alias mit der Service-IP gelöscht, sodann auf dem anderen Ziel-Knoten die Aktivierungsroutine (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 Korn-Shell) erledigt, lediglich ein kleiner Kernel-Patch (der sogenannte Dead-Man-Switch) greift direkt verändernd in das darunterliegende Betriebssystem ein. Diese offene Architektur macht HACMP sehr flexibel.
Das größte Problem das Clustersoftware lösen muß, 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 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
- die Platten der Resource Groups, auf die ja beide Knoten zugreifen können müssen
- serielle Leitungen (die klassische Methode und bis HACMP 4.4 unbedingt erforderlich)
bewerkstelligt. Kommt ein Knoten aufgrund nicht mehr empfangener Heartbeats zu dem Schluß, 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 2 (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 meist für Mission Critical-Systeme eingesetzt und hat den Vorteil, gut planbar bei relativ geringer Komplexität zu sein. Der Nachteil ist, daß ein erheblicher Teil der Kapazität (der/die Standby-Knoten) die meiste Zeit über nicht genutzt wird.
Cascading Cluster
Die Resource Group mit der Hauptapplikation läuft auf einem Knoten, auf einem weiteren Knoten laufen Resource Groups, die bei Bedarf abgeschaltet werden können. Im Fehlerfalle führt der Standby-Knoten zunächst die Stop-Scripte seiner eigenen Resource Groups aus, danach wird ein Takeover auf die RG der Hauptapplikation 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 stehen sie für einige Zeit nicht zur Verfügung.