Das Herunterfahren von DB2-Datenbankpartitionen auf einem physischen AIX-Knoten, wenn der Seitenwechselbereich (Paging-Bereich) einen bestimmten Prozentsatz der Füllung erreicht, oder das erneute Starten einer DB2-Datenbankpartition bzw. die Einleitung einer Übernahmeoperation, wenn ein Prozeß auf einem bestimmten Knoten unterbrochen wird, sind zwei Beispiele für benutzerdefinierte Ereignisse. Beispiele, die benutzerdefinierte Ereignisse illustrieren, wie zum Beispiel das Herunterfahren einer Datenbankpartition und das Erzwingen eines Transaktionsabbruchs, um Seitenwechselbereich freizugeben, befinden sich im Unterverzeichnis samples.
Eine rules-Datei /user/sbin/cluster/events/rules.hacmprd enthält Definitionen von HACMP-Ereignissen. Jede Ereignisbeschreibung in dieser Datei besitzt die folgenden neun Komponenten:
Jedes Objekt benötigt eine Zeile in der Ereignisdefinition, auch wenn die Zeile nicht verwendet wird. Wenn solche Zeilen gelöscht werden, kann HACMP ES Cluster Manager die Ereignisdefinition nicht korrekt analysieren, was zu einer Blockierung des Systems führen kann. Jede Zeile die mit einem Zeichen "#" beginnt, wird als Kommentarzeile behandelt.
Anmerkung: | Die rules-Datei verlangt exakt neun Zeilen für jede Ereignisdefinition, wobei die Kommentarzeilen nicht mitgezählt werden. Beim Hinzufügen eines benutzerdefinierten Ereignisses am Ende der rules-Datei, muß unbedingt darauf geachtet werden, nicht benötigte Leerzeilen am Ende der Datei zu entfernen. Ansonsten kommt es zu einem Blockieren des Knotens. |
Das folgende Beispiel zeigt eine Ereignisdefinition für das Ereignis node_up:
##### Beginning of the Event Definition: node_up # TE_JOIN_NODE 0 /usr/sbin/cluster/events/node_up.rp 2 0 # 6) Resource variable - only used for event management events # 7) Instance vector - only used for event management events # 8) Predicate - only used for event management events # 9) Rearm predicate - only used for event management events ###### End of the Event Definition: node_up
Dies ist nur ein Beispiel für die Ereignisdefinitionen, die sich in der Datei rules.hacmprd befinden können. In diesem Beispiel wird das Wiederherstellungsprogramm /usr/sbin/cluster/events/node_up.rp ausgeführt, wenn das Ereignis node_up eintritt. Werte sind für den Status, den Wiederherstellungstyp und die Wiederherstellungsebene angegeben. Es gibt vier leere Zeilen für Ressourcenvariable, Exemplarvariable, Vergleichselement (Predicate) und Rearm-Vergleichselement (Rearm predicate).
Sie können andere Ereignisse definieren, um auf andere als die Standardereignisse von HACMP ES zu reagieren. Zum Beispiel muß die Datei rules.hacmprd geändert werden, um das Ereignis zu definieren, daß das Dateisystem /tmp zu über 90 % gefüllt ist.
Zahlreiche Ereignisse sind in IBM Parallel System Support Program (PSSP) vordefiniert. Diese Ereignisse können (durch Verwendung innerhalb benutzerdefinierter Ereignisse) wie folgt genutzt werden:
HACMP ES verwendet die PSSP-Ereigniserkennung zur Behandlung benutzerdefinierter Ereignisse. Das PSSP-Subsystem zur Ereignisverwaltung (Event Management) stellt eine umfassende Ereigniserkennung durch Überwachung verschiedener Hardware- und Softwareressourcen zur Verfügung.
Die Ressourcenstatus werden durch verschiedene Ressourcenvariablen dargestellt. Ressourcenbedingungen werden durch Ausdrücke wiedergegeben, die als Vergleichselemente (Predicates) bezeichnet werden.
Die Ereignisverwaltung (Event Management) empfängt Ressourcenvariablen vom Ressourcenmonitor (Resource Monitor), der den Status spezieller Systemressourcen beobachtet und diesen Status in verschiedene Ressourcenvariablen umsetzt. Diese Variablen werden in regelmäßigen Abständen an die Ereignisverwaltung (Event Management) übermittelt. Die Ereignisverwaltung wendet Vergleichselemente, die durch HACMP ES Cluster Manager in der Datei rules.hacmprd angegeben werden, für jede Ressourcenvariable an. Wenn das Vergleichselement als wahr ausgewertet wird, wird ein Ereignis generiert und an Cluster Manager gesendet. Cluster Manager initiiert das Wahlprotokoll, und die Wiederherstellungsprogrammdatei (xxx.rp) wird (nach Ereignispriorität) auf einer Gruppe von Knoten ausgeführt, die durch "node sets" im Wiederherstellungsprogramm angegeben sind.
Die Wiederherstellungsprogrammdatei (xxx.rp) besteht aus einer oder mehreren Wiederherstellungsprogrammzeilen. Jede Zeile ist auf das folgende Format festgelegt:
beziehung auszuführender-befehl erwarteter-status NULL
Zwischen den einzelnen Werten in der Zeile muß mindestens ein Leerzeichen sein. "beziehung" ist ein Wert, der zu der Entscheidung herangezogen wird, welches Programm auf welchen Knoten auszuführen ist. Es werden drei Werte für die Beziehung unterstützt:
"auszuführender-befehl" ist eine in Anführungszeichen gesetzte Zeichenfolge mit oder ohne Angabe eines vollständigen Pfads zu einem ausführbaren Programm. Nur zum Lieferumfang von HACMP gehörende Ereignisprozeduren können eine relative Pfaddefinition verarbeiten. Andere Prozeduren oder Programme müssen eine vollständige Pfadangabe verwenden, auch wenn sie sich im selben Verzeichnis wie die HACMP-Ereignisprozeduren befinden.
"Erwarteter-status" ist der Rückkehrcode des angegebenen Befehls bzw. Programms. Dabei kann entweder ein Ganzzahlwert oder ein "x" angegeben werden. Wenn "x" verwendet wird, ignoriert Cluster Manager den Rückkehrcode. Alle anderen Codes müssen mit dem erwarteten Rückkehrcode übereinstimmen, ansonsten erkennt Cluster Manager einen Ereignisfehler. Die Behandlung diesses Ereignisses blockiert den Prozeß, bis eine Behebung (durch einen manuellen Eingriff) erfolgt. Ohne manuellen Eingriff wird der Knoten nicht mit den anderen Knoten synchronisiert. Die Synchronisierung über alle Knoten hinweg ist eine Voraussetzung für Cluster Manager, um alle Knoten steuern zu können.
"NULL" ist ein für zukünftige Zwecke reserviertes Feld. Das Wort "NULL" muß am Ende jeder Zeile außer der barrier-Zeile stehen. Wenn mehrere Wiederherstellungsbefehle zwischen zwei barrier-Befehlen (oder vor dem ersten) angegeben werden, werden die Wiederherstellungsbefehle auf dem Knoten selbst und zwischen den Knoten parallel ausgeführt.
Der Befehl barrier dient zur Synchronisierung aller Befehle über alle Clusterknoten hinweg. Wenn ein Knoten auf die barrier-Anweisung im Wiederherstellungsprogramm trifft, initiiert Cluster Manager das barrier-Protokoll auf diesem Knoten. Da das barrier-Protokoll ein zweiphasiges Protokoll ist, werden alle Knoten benachrichtigt, daß beide Phasen abschlossen wurden, wenn alle Knoten die barrier-Anweisung im Wiederherstellungsprogramm erreicht und "gewählt" haben, das Protokoll zu bestätigen.
Der Prozeß kann folgendermaßen zusammengefaßt werden:
Die folgenden Beispielprozeduren zur Fehlerbehebung durch Funktionsübernahme und für benutzerdefinierte Ereignisse gehören zum Lieferumfang von DB2 UDB EEE. Die Prozedurdateien befinden sich im Verzeichnis $INSTNAME/sqllib/samples/hacmp/es. Diese Prozeduren sind in der vorliegenden Form funktionsfähig. Die Wiederherstellungsaktion kann aber auch angepaßt werden.
Die Wiederherstellungsprozeduren müssen auf jedem Knoten installiert werden, der Wiederherstellungsoperationen ausführen soll. Die Prozedurdateien können zentral von der SP-Steuer-Workstation bzw. einem anderen zuvor festgelegten SP-Knoten aus installiert werden:
db2_inst_ha $INSTNAME/sqllib/samples/hacmp/es <knotenliste> <DATENBANKNAME> Dabei gilt folgendes: $INSTNAME/sqllib/samples/hacmp/es ist Verzeichnis mit den Prozeduren und den Ereignissen <knotenliste> ist die Knotenangabe im pcp- oder pexec-Format; z. B. 1-16 oder 1,2,3,4 <DATENBANKNAME> ist der Name der Datenbank für die Dateien mit den regulären Parametern und den Funktionsübernahmeparametern.
Die Dateien reg.parms.SAMPLE und failover.parms.SAMPLE werden auf jeden Knoten kopiert und in reg.parms.DATENBANKNAME umbenannt. db2_inst_ha kopiert Dateien auf jeden Knoten in das Verzeichnis /usr/bin und aktualisiert die HACMP-Ereignisdateien:
/usr/sbin/cluster/events/rules.hacmprd /usr/sbin/cluster/events/network_up_complete /usr/sbin/cluster/events/network_down_complete
ha_db2stop
Anmerkung: | Sie müssen warten, bis der Befehl beendet ist. Durch Drücken der Tasten Strg-C oder durch Abbrechen des Prozesses kann die Fehlerbehebung durch Funktionsübernahme vorzeitig wieder aktiviert werden, und einige Datenbankpartitionen werden vielleicht nicht gestoppt. |
HACMP ES ruft die DB2-Wiederherstellungsprozeduren auf folgende Weise auf:
HACMP fordert mit der node_up-Sequenz Datenträgergruppen (Volume Groups), logische Datenträger (Logical Volumes), Dateisysteme (Filesystems) und IP-Adressen an, die in den Ressourcengruppen angegeben sind, deren Eigner (durch Hintereinanderschalten (Cascading)) der Knoten ist bzw. die diesem Knoten (durch Rotation) zugeordnet sind.
Wenn node_up_local_complete ausgeführt wird, wird die Anwendungs-Server-Definition, die rc.db2pe enthält, initiiert, um die Datenbankpartition zu starten, die in den Anwendungs-Server-Definitionen auf diesem physischen Knoten angegeben ist.
Anmerkung: | rc.db2pe paßt bei Ausführung im Startmodus die in der Datei reg.parms.DATENBANK angegebenen DB2-Parameter für jede DATENBANK im Datenbankverzeichnis an, die einer Parameterdatei (parms-Datei) entspricht. |
Auf jedem Knoten spielt sich diese Abfolge von Aktionen beim Start ab. Wenn Sie mehrere HACMP-Cluster haben und diese parallel starten, werden mehrere Knoten gleichzeitig hochgefahren.
HACMP fordert die Datenträgergruppen, logischen Datenträger, Dateisysteme und IP-Adressen an, die in der Ressourcengruppe auf dem designierten Übernahmeknoten angegeben sind.
Bei Ausführung von node_down_remote_complete führt HACMP rc.db2pe als Startprozedur für den Anwendungs-Server aus, die in der Ressourcengruppe für diese Datenbankpartition angegeben ist.
Anmerkung: | Bei Ausführung im Modus der gegenseitigen Übernahme stoppt rc.db2pe die auf dem Knoten ausgeführte DB2-Datenbankpartition, paßt die DB2-Parameter in failover.parms.DATENBANK für jede DATENBANK im Datenbankverzeichnis an, die einer Parameterdatei (parms) entspricht, und startet anschließend beide Datenbankpartitionen auf dem physischen Übernahmeknoten. |
Bei der Ausführung von node_up_remote auf dem alten Übernahmeknoten bewirkt die Anwendungs-Server-Definition, daß rc.db2pe im Stoppmodus ausgeführt wird.
Anmerkung: | Wenn rc.db2pe in einem Reintegrationsmodus (bei gegenseitiger Übernahme) ausgeführt wird, stoppt rc.db2pe beide auf dem Knoten aktiven Datenbankpartitionen, paßt die DB2-Parameter an, die in reg.parms.DATENBANK für jede Datenbank im Datenbankverzeichnis angegeben sind, die einer Parameterdatei (parms) entspricht, und startet anschließend nur die Datenbankpartition, die auf diesem physischen Übernahmeknoten behalten werden soll. |
Der alte Übernahmeknoten gibt die Datenträgergruppen, logischen Datenträger, Dateisysteme und IP-Adressen frei, die in Ressourcengruppen, deren Eigner der wieder integrierte Knoten sein soll, angegeben sind.
HACMP fordert erneut Datenträgergruppen, logische Datenträger, Dateisysteme und IP-Adressen an, die in der Ressourcengruppe angegeben sind, deren Eigner jetzt der sich wieder integrierende Knoten ist.
Wenn node_up_local_complete ausgeführt wird, wird die Anwendungs-Server-Definition initiiert, die rc.db2pe enthält, um die in der Anwendungs-Server-Definition auf diesem wieder zu integrierenden physischen Knoten angegebene DB2-Datenbankpartition zu starten.
Anmerkung: | rc.db2pe paßt bei Ausführung im Startmodus die in der Datei reg.parms.DATENBANK angegebenen DB2-Parameter für jede DATENBANK im Datenbankverzeichnis an, die einer Parameterdatei (parms-Datei) entspricht. |
Wenn node_down_local auf dem zu stoppenden Knoten ausgeführt wird, bewirkt die Anwendungs-Server-Definition, daß rc.db2pe im Stoppmodus ausgeführt wird.
Anmerkung: | Bei Ausführung im Stoppmodus paßt rc.db2pe die DB2-Parameter an, die in failover.parms.DATENBANK für jede DATENBANK im Datenbankverzeichnis angegeben sind, die einer Parameterdatei (parms) entspricht, und stoppt anschließend die DB2-Datenbankpartition (dies geschieht für die Übernahme). |
HACMP gibt die Datenträgergruppen, logischen Datenträger, Dateisysteme und IP-Adressen frei, die in Ressourcengruppen angegeben sind, deren Eigner jetzt der Knoten ist.
Alle Knoten führen die Prozedur db2_proc_restart aus. Der Knoten, auf dem der Fehler auftrat, startet die richtige DB2-Datenbankpartition.
Alle Knoten führen die Prozedur db2_paging_action aus. Wenn auf einem Knoten mehr als 70 % des Seitenwechselbereichs gefüllt sind, wird ein wall-Befehl abgesetzt. Wenn auf einem Knoten mehr als 90 % des Seitenwechselbereichs gefüllt sind, werden die DB2-Datenbankpartitionen auf diesem physischen Knoten gestoppt und dann erneut gestartet.
Alle Knoten führen die Prozedur rc.db2pe im NFS-Modus aus. Wird die Ausführung eines NFS-Prozesses gestoppt, wird er erneut gestartet. In ähnlicher Weise wird der Prozeß für automatisches Anhängen bei einem Ausfall erneut gestartet.
Die Prozedur net_down wird aufgerufen. Diese Prozedur überprüft, ob das Netzwerk ein SP-Switch-Netzwerk und außer Funktion ist. Ist dies der Fall, wartet die Prozedur ein benutzerdefiniertes Zeitintervall ab. Das Standardzeitintervall sind 100 Sekunden.
Ist das SP-Switch-Netzwerk wieder verfügbar, wie durch das Ereignis network_up_complete mitgeteilt wird, wird keine Wiederherstellung durchgeführt.
Wenn das Zeitlimit erreicht ist, wird HACMP mit Funktionsübernahme gestoppt.
Anmerkung: | Alle Ereignisse können über die SP-Fehlerverwaltung (Problem Management) und die GUI SP Perspectives überwacht werden. |
Es stehen noch weitere Prozedurdienstprogramme (Skripte) für Sie bereit:
ha_cmd <knotenbereich> <START|STOP|TAKE|FORCE> Dabei gilt folgendes: <knotenbereich> ist ein SP-Knotenbereich im pcp- oder pexec-Format. Z. B.: "ha_cmd 3-6 START" startet HACMP auf den Knoten 3,4,5,6. "ha_cmd 5 TAKE" beendet HACMP auf Knoten 5 für gegenseitige Übernahme.
ha_mon <knoten> Dabei gilt folgendes: <knoten> ist der zu überwachende SP-Knoten. ha_mon wendet "tail -f" auf die Datei /tmp/hacmp.out auf dem angegebenen Knoten an.
db2_turnoff_recov <knotenliste>
db2_turnon_recov <knotenliste>