DB2 Universal Database - Systemverwaltung


Bereitschaftsmodus (Hot Standby)

Der Bereitschaftsmodus (Hot hot) kann verwendet werden, um die automatische Übernahme des gesamten Exemplars einer Datenbank mit Einzelpartition oder einer Partition einer partitionierten Datenbankkonfiguration einzurichten. Wenn ein Prozessor ausfällt, kann ein anderer Prozessor im Cluster die Funktionen des ausgefallenen Prozessors durch eine automatische Übertragung des Exemplars übernehmen. Das Datenbankexemplar und die Datenbank selbst müssen sowohl für den primären Prozessor als auch für den Ersatzprozessor zugänglich sein.

Detaillierte Informationen zu den tatsächlichen Installationsvoraussetzungen und zur Exemplarerstellung finden Sie im Handbuch HACMP for AIX, Version 4.2: Installation Guide, SC23-1940.

Beispiele

Für alle folgenden Beispiele gibt es jeweils eine Beispielprozedurdatei, die im Verzeichnis sqllib/samples/hacmp von DB2 für AIX-Installationen gespeichert ist.

Exemplarübernahme

Das folgende Beispiel eines Szenarios mit Funktionsübernahme im Bereitschaftsmodus beschreibt einen HACMP-Cluster mit zwei Prozessoren, auf dem ein Datenbankexemplar mit einer Einzelpartition ausgeführt wird (Abbildung 44). Informationen zum Konfigurieren eines HACMP-Clusters finden Sie in Zusätzliche HACMP-Informationen.

Abbildung 44. Beispiel für eine Funktionsübernahmekonfiguration im Bereitschaftsmodus

Beispiel für eine Funktionsübernahmekonfiguration im Bereitschaftsmodus

Beide Prozessoren haben Zugriff auf das Installationsverzeichnis, das Exemplarverzeichnis und das Datenbankverzeichnis. Das Datenbankexemplar "db2inst" wird aktiv auf Prozessor 1 ausgeführt. Prozessor 2 ist nicht aktiv, sondern wird als sofort einsatzfähiger Bereitschaftsprozessor verwendet. Auf Prozessor 1 kommt es zu einem Ausfall, und das Exemplar wird von Prozessor 2 übernommen. Sobald die Übernahme vollzogen ist, können sowohl ferne als auch lokale Anwendungen auf die Datenbank innerhalb des Exemplars "db2inst" zugreifen. Die Datenbank muß manuell erneut gestartet werden, oder sie wird, falls der Parameter AUTORESTART aktiviert ist, durch die erste Verbindung zur Datenbank erneut gestartet. In der vorbereiteten Beispielprozedur wird angenommen, daß der Parameter AUTORESTART nicht aktiv ist (OFF) und daß die Übernahmeprozedur den Neustart für die Datenbank ausführt. Weitere Informationen zum Parameter AUTORESTART finden Sie in Überblick über die Wiederherstellung .

Beispielprozedur:

   hacmp-s1.sh

Partitionsübernahme

Im folgenden Funktionsübernahmeszenario mit Bereitschaftsmodus (Hot Standby) wird eine Exemplarpartition anstelle des gesamten Exemplars verwendet. Dieses Szenario enthält wie im vorigen Beispiel einen HACMP-Cluster mit zwei Prozessoren, jedoch stellt die Maschine hier eine der Partitionen eines partitionierten Datenbank-Servers dar. Prozessor 1 betreibt eine einzelne Partition der Gesamtkonfiguration, während Prozessor 2 als übernehmender Prozessor fungiert. Wenn Prozessor 1 ausfällt, wird die Partition auf dem zweiten Prozessor neu gestartet. Bei der Übernahme wird die Datei db2nodes.cfg aktualisiert, so daß sie nun auf den Host-Namen und den Netznamen von Prozessor 2 zeigt, und anschließend die Partition auf dem neuen Prozessor gestartet.

Das folgende Beispiel zeigt einen Abschnitt aus der Datei db2nodes.cfg vor und nach der Funktionsübernahme. In diesem Beispiel wird Knotennummer 2 auf Prozessor 1 der HACMP-Maschine ausgeführt, die als Host-Namen und als Netznamen den Namen "node201" besitzt. Nach der Übernahme wird Knotennummer 2 auf Prozessor 2 der HACMP-Maschine mit dem Host-Namen und dem Netznamen "node202" ausgeführt.

Vorher:
        1 node101 0 node101
        2 node201 0 node201    <= HACMP
        3 node301 0 node301
 
   db2start nodenum 2 restart hostname node202 port 0 netname node202
 
Nachher:
        1 node101 0 node101
        2 node202 0 node202    <= HACMP
        3 node301 0 node301

Beispielprozedur:

   hacmp-s2.sh

Automatische Übernahme mehrerer logischer Knoten

Diese komplexere Variante als das vorige Beispiel beschreibt die automatische Übernahme mehrerer logischer Knoten von einem Prozessor durch einen anderen. Es wird wieder derselbe HACMP-Cluster mit zwei Prozessoren wie oben verwendet. In diesem Beispielszenario betreibt Prozessor 1 allerdings drei logische Partitionen. Die Ausgangssituation gleicht dem Szenario mit der einfachen Partitionsübernahme, jedoch muß in diesem Fall bei einem Ausfall von Prozessor 1 jede der logischen Partitionen auf Prozessor 2 gestartet werden. Jede logische Partition muß in der Reihenfolge gestartet werden, die in der Datei db2nodes.cfg definiert ist: die logische Partition mit der Anschlußnummer (Port) 0 muß immer als erste gestartet werden.

Das folgende Beispiel zeigt einen Abschnitt aus der Datei db2nodes.cfg vor und nach der Funktionsübernahme. In diesem Beispiel gibt es drei logische Partitionen auf Prozessor 1 in einem HACMP-Cluster mit zwei Prozessoren.

Vorher:
        1 node101 0 node101
        2 node201 0 node201    <= HACMP
        3 node201 1 node201    <= HACMP
        4 node201 2 node201    <= HACMP
        5 node301 0 node301
 
   db2start nodenum 2 restart hostname node202 port 0 netname node202
   db2start nodenum 3 restart hostname node202 port 1 netname node202
   db2start nodenum 4 restart hostname node202 port 2 netname node202
 
Nachher:
        1 node101 0 node101
        2 node202 0 node202    <= HACMP
        3 node202 1 node202    <= HACMP
        4 node202 2 node202    <= HACMP
        5 node301 0 node301

Beispielprozedur:

   hacmp-s3.sh


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]