Inhalt gelöscht Inhalt hinzugefügt
KKeine Bearbeitungszusammenfassung
Zeile 10:
Zeile 10:
* eines oder mehrerer [[Dateisystem]]e
* eines oder mehrerer [[Dateisystem]]e
* einer oder mehrerer IP-Adressen
* einer oder mehrerer IP-Adressen
* eines oder mehrerer [[Prozess (Informatik)#Prozesse beim Betriebssystem UNIX|Prozesse]] und dazugehöriger Start-/(削除) Stopp (削除ここまで)-Skripte
* eines oder mehrerer [[Prozess (Informatik)#Prozesse beim Betriebssystem UNIX|Prozesse]] und dazugehöriger Start-/(追記) Stop (追記ここまで)-Skripte
Beim Aktivieren einer solchen Resource Group auf einem Clusterknoten werden zunächst die zugehörigen (削除) Dateisysteme (削除ここまで) (削除) eingehängt (削除ここまで), anschließend mit Hilfe von in der RG-Definition hinterlegten Start-/(削除) Stopp (削除ここまで)-Skripten die Prozesse der RG gestartet. Danach wird die IP-Adresse (die sogenannte ''Service IP'') als IP-Alias auf eine dafür (削除) bestimmte (削除ここまで) (削除) Schnittstelle (削除ここまで) aufgebracht.
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 eine dafür (追記) bestimmtes (追記ここまで) (追記) Interface (追記ここまで) aufgebracht.
Wird die Resource Group auf einen anderen Clusterknoten verschoben (''Takeover''), so wird erst mit Hilfe des (削除) Stopp (削除ここまで)-(削除) Skripts (削除ここまで) die Anwendung beendet, die (削除) Dateisysteme (削除ここまで) (削除) ausgehängt (削除ここまで) und der IP-Alias mit der Service-IP gelöscht, anschließend auf dem (削除) anderen (削除ここまで) (削除) Zielknoten (削除ここまで) (削除) 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.
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 das Start-Script (追記ここまで) (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 (削除) Skripte (削除ここまで) (in der [[Kornshell]]) 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.
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'') 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 verschiedene Kommunikationsstrecken definiert, über die sich die Clusterknoten wechselseitig Nachrichten über ihre Funktionsfähigkeit zukommen lassen. Dies wird ''Heartbeat'' genannt und kann über
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 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-(削除) Schnittstellen (削除ここまで)
* eigens dafür eingerichtete IP-(追記) Interfaces (追記ここまで)
* (削除) die Festplatten (削除ここまで) (削除) der Resource Groups (削除ここまで), auf die beide Knoten zugreifen können müssen
* (追記) 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)
* serielle Leitungen (die klassische Methode und bis HACMP 4.4 unbedingt erforderlich)
Zeile 30:
Zeile 30:
==== Rotating 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".
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 (削除) meist (削除ここまで) für (削除) [[missionskritisch]]e (削除ここまで) 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.
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 ====
==== 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 (削除) Stopp (削除ここまで)-Skripte seiner eigenen Resource Groups aus, danach wird ein Takeover auf die RG der Hauptanwendung durchgeführt.
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 [[Datenbank]]en. 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.
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 [[Datenbank]]en. 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.
Version vom 26. November 2014, 02:03 Uhr
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 Dateisysteme
- einer oder mehrerer IP-Adressen
- eines oder mehrerer Prozesse und dazugehöriger Start-/Stop-Skripte
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 eine 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 das Start-Script (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) 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 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 stehen sie für einige Zeit nicht zur Verfügung.
Weblinks