In einer Konfiguration im Bereitschaftsmodus (Hot Standby) hat der AIX-Prozessorknoten, der als Übernahmeknoten fungiert, keine andere Arbeitsbelastung. Bei einer Konfiguration zur gegenseitigen Funktionsübernahme, hat der AIX-Prozessorknoten, der als Übernahmeknoten fungiert, andere Arbeitsbelastungen.
Im allgemeinen arbeitet DB2 Universal Database Enterprise - Extended Edition (UDB EEE) im Modus der gegenseitigen Übernahme mit Partitionen auf jedem Knoten. Eine Ausnahme bildet eine Konstellation, in der der Katalogknoten Teil einer Bereitsschaftskonfiguration ist.
Bei der Planung einer umfangreichen DB2-Installation auf einem RISC System/6000 SP mit HACMP ES müssen Sie besonderes Augenmerk auf die Verteilung der Knoten des Clusters innerhalb oder zwischen den RISC System/6000 SP-Frames legen. Wenn ein Knoten und der zugehörige Ausweichknoten in verschiedenen SP-Frames angelegt sind, ist eine Funktionsübernahme möglich, wenn ein ganzer Frame ausfällt (d. h. die Stromversorgung/Switch Boards des Frame ausfallen). Dies ist jedoch eine sehr seltene Ausnahme, weil es N+1 Stromversorgungen in jedem SP-Frame gibt und jeder SP-Switch redundante Pfade mit N+1 Ventilatoren und Stromzuführungen besitzt. Im Fall eines Frame-Ausfalls ist eventuell ein manueller Eingriff erforderlich, um die übrigen Frames wieder in Funktion zu setzen. Diese Wiederherstellungsprozedur ist im Handbuch SP Administration Guide dokumentiert. HACMP ES ermöglicht die Wiederherstellung nach SP-Knotenausfällen. Die Wiederherstellung nach Frame-Ausfällen ist von einer geeigneten Anordnung von Clustern innerhalb eines oder mehrerer SP-Frames abhängig.
Eine weitere Überlegung zur Planung ist die Verwaltung großer Cluster. Die Verwaltung eines kleinen Clusters ist einfacher als die eines großen. Aber die Verwaltung eines einzelnen großen Clusters ist immer noch einfacher als die vieler kleiner Cluster. Bei der Planung ist auch zu bedenken, wie die Anwendungen in der Clusterumgebung verwendet werden. Wenn zum Beispiel eine einzige, umfangreiche und homogene Anwendung auf 16 Knoten betrieben wird, ist die Konfiguration als ein Cluster wahrscheinlich einfacher zu verwalten, als sie in acht Cluster mit jeweils zwei Knoten zu zerlegen. Wenn dieselben 16 Knoten viele verschiedene Anwendungen mit verschiedenen Netzwerken, Platten und Knotenanordnungsbeziehungen enthalten, ist es wahrscheinlich besser, die Knoten in kleinere Cluster zu gruppieren. Beachten Sie, daß Knoten nur nacheinander, d. h. nur einer gleichzeitig, starten und sich in einen HACMP-Cluster integrieren. Eine Konfiguration mit mehreren Clustern läßt sich schneller starten als ein einziger großer Cluster. HACMP ES unterstützt sowohl einzelne als auch mehrere Cluster, vorausgesetzt ein Knoten und der zugehörige Ausweichknoten befinden sich im selben Cluster.
Die Fehlerbehebung durch Funktionsübernahme von HACMP ES (Failover) ermöglicht eine vordefinierte Zuordnung einer Ressourcengruppe zu einem physischen Knoten (auch als hintereinanderschalten (cascading) bezeichnet). Die Funktionsübernahme ermöglicht außerdem eine gleitende (auch als rotierende bezeichnete) Zuordnung einer Ressourcengruppe zu einem physischen Knoten. IP-Adressen und externe Datenträgergruppen (Volume Groups) oder Dateisysteme (Filesystems) oder NFS-Dateisysteme und Anwendungs-Server innerhalb jeder Ressourcengruppe geben entweder eine Anwendung oder eine Anwendungskomponente an, die von HACMP ES zwischen den physischen Knoten durch Funktionsübernahme und Wiedereingliederung (Reintegration) beeinflußt werden können. Die Funktionsübernahme und Reintegration wird durch die Art der erstellten Ressourcengruppe und durch die Anzahl der in der Ressourcengruppe angelegten Knoten angegeben.
Betrachten Sie zum Beispiel eine DB2-Datenbankpartition (logischen Knoten). Wenn die Protokoll- und Tabellenbereichsbehälter auf externen Platten angelegt und andere Knoten mit diesen Platten verbunden würden, wäre es möglich, daß die anderen Knoten auf diese Platten zugreifen und die Datenbankpartition (auf einem Übernahmeknoten) neu starten. Gerade diese Art von Operation wird durch HACMP automatisiert. HACMP ES kann außerdem dazu verwendet werden, NFS-Dateisysteme wiederherzustellen, die von Hauptbenutzerverzeichnissen des DB2-Exemplars verwendet werden.
Lesen Sie sich im Rahmen Ihrer Planung für die Wiederherstellung mit DB2 UDB EEE die Dokumentation zu HACMP ES gut durch. Sie sollten die Handbücher zu Konzepten, Planung, Installation und Verwaltung lesen und anschließend die Wiederherstellungsarchitektur für Ihre Umgebung entwerfen. Ermitteln Sie für die einzelnen Subsysteme, die Sie für die Wiederherstellung anhand bekannter möglicher Fehlerpunkte bestimmt haben, die benötigten HACMP-Cluster und die Wiederherstellungsknoten (entweder im Bereitschaftsmodus oder im Modus der gegenseitigen Übernahme). Dies dient als Ausgangspunkt für das Ausfüllen der HACMP-Arbeitsblätter, die der Dokumentation beigefügt sind.
Es ist ausdrücklich zu empfehlen, sowohl Platten als auch Adapter in der externen Plattenkonfiguration zu spiegeln. Bei physischen DB2-Knoten, die für HACMP konfiguriert sind, muß sorgfältig sichergestellt werden, daß die Knoten in der Datenträgergruppe von den gemeinsamen externen Platten abweichen können. In einer Konfiguration für gegenseitige Übernahme macht diese Anordnung eine zusätzliche Planung erforderlich, so daß die zu Paaren verbundenen Knoten ohne Konflikt auf die Datenträgergruppen des jeweils anderen zugreifen können. Für DB2 UDB EEE bedeutet dies, daß alle Behälternamen über alle Datenbanken hinweg eindeutig sein müssen.
Eine Methode zur Sicherstellung der Eindeutigkeit besteht darin, die
Partitionsnummer als Teil des Namens zu verwenden. Sie können einen
Knotenausdruck für die Syntax von Behälterzeichenfolgen angeben, wenn Sie SMS-
oder DMS-Behälter erstellen. Wenn Sie den Ausdruck angeben, kann die
Knotennummer Teil des Behälternamens sein, oder, wenn Sie zusätzliche
Argumente angeben, können die Ergebnisse dieser Argumente Teil des
Behälternamens sein. Verwenden Sie das Argument " $N"
([leerzeichen]$N) zur Angabe des Knotenausdrucks. Das
Argument muß an das Ende der Behälterzeichenfolge gesetzt werden und kann nur
in einem der folgenden Formate verwendet werden:
Tabelle 56. Argumente zur Behältererstellung
Als Knotennummer wird fünf (5) angenommen. | ||
Syntax | Beispiel | Wert |
---|---|---|
[leerzeichen]$N | " $N" | 5 |
[leerzeichen]$N+[zahl] | " $N+1011" | 1016 |
[leerzeichen]$N%[zahl] | " $N%3" | 2 |
[leerzeichen]$N+[zahl]%[zahl] | " $N+12%13" | 4 |
[leerzeichen]$N%[zahl]+[zahl] | " $N%3+20" | 22 |
Anmerkungen:
|
Es folgen einige Beispiele zur Erstellung von Behältern mit Hilfe dieses Spezialarguments:
CREATE TABLESPACE TS1 MANAGED BY DATABASE USING (device '/dev/rcont $N' 20000)Die folgenden Behälter würden verwendet:
/dev/rcont0 - auf Knoten 0 /dev/rcont1 - auf Knoten 1
CREATE TABLESPACE TS2 MANAGED BY DATABASE USING (file '/DB2/containers/TS2/container $N+100' 10000)Die folgenden Behälter würden verwendet:
/DB2/containers/TS2/container100 - auf Knoten 0 /DB2/containers/TS2/container101 - auf Knoten 1 /DB2/containers/TS2/container102 - auf Knoten 2 /DB2/containers/TS2/container103 - auf Knoten 3
CREATE TABLESPACE TS3 MANAGED BY SYSTEM USING ('/TS3/cont $N%2, '/TS3/cont $N%2+2')Die folgenden Behälter würden verwendet:
/TS3/cont0 - auf Knoten 0 /TS3/cont2 - auf Knoten 0 /TS3/cont1 - auf Knoten 1 /TS3/cont3 - auf Knoten 1
Abbildung 104 und Abbildung 105 zeigen ein Beispiel für die Konfiguration eines DB2-SSA-E/A-Subsystems sowie einige Gesichtspunkte der Planung, die zur Sicherstellung einer hochverfügbaren Konfiguration externer Platten und der Möglichkeit des konfliktfreien Zugriffs auf alle Datenträgergruppen gehört.
Abbildung 104. Kein einzelner Fehlerpunkt
Abbildung 105. Konfiguration von Datenträgergruppe und logischem Datenträger
Nach der Konfiguration werden die Datenbankpartitionen in einem Exemplar durch HACMP ES nacheinander, ein physischer Knoten nach dem anderen gestartet. Mehrere Cluster werden empfohlen, wenn parallele DB2-Konfigurationen mit mehr als vier Knoten gestartet werden sollen. Beachten Sie, daß es in einer parallelen DB2-Konfiguration mit 64 Knoten schneller ist, 32 HACMP-Cluster mit zwei Knoten als vier Cluster mit 16 Knoten parallel zu starten.
Eine Prozedurdatei rc.db2pe gehört zum Lieferumfang von DB2 UDB EEE (und wird auf jedem Knoten in /usr/bin intalliert), um Hilfestellung bei der Konfiguration für HACMP ES-Funktionsübernahme bzw. -Wiederherstellung auf Bereitschaftsknoten (Hot Standby) bzw. Knoten mit gegenseitiger Übernahme (Mutual Takeover) zu geben. Zusätzlich können aus rc.db2pe heraus DB2-Pufferpoolgrößen während der Funktionsübernahme bei Konfigurationen mit gegenseitiger Übernahme angepaßt werden. (Pufferpoolgrößen müssen konfiguriert werden, um einen ordnungsgemäßen Betrieb sicherzustellen, wenn zwei Datenbankpartitionen auf demselben physischen Knoten ausgeführt werden.)
Wenn Sie einen Anwendungs-Server in einer HACMP-Konfiguration einer DB2-Datenbankpartition erstellen, geben Sie auf folgende Weise rc.db2pe als Start- und Stopprozedur an:
/usr/bin/rc.db2pe <exemplar> <dpn> <sekundäre dpn> start <switch> /usr/bin/rc.db2pe <exemplar> <dpn> <sekundäre dpn> stop <switch> Dabei gilt folgendes: <exemplar> ist der Exemplarname. <dpn> ist die Datenbankpartitionsnummer. <sekundäre dpn> ist die Datenbankpartitionsnummer des Pendants Konfigurationen mit gegeseitiger Übernahme. In Bereitschafts- konfigurationen gleich <dpn>. <switch> ist in der Regel leer. Ist dies der Fall, zeigt dieser Parameter an, daß das SP-Switch-Netzwerk für das Feld hostname in der Datei db2nodes.cfg verwendet wird (der gesamte Verkehr für DB2 wird über den SP-Switch geleitet). Falls nicht leer, ist der verwendete Name der Host-Name des zu verwendenden SP-Knotens.
Der DB2-Befehl LIST DATABASE DIRECTORY wird innerhalb von rc.db2pe zum Auffinden aller Datenbanken verwendet, die für diese Datenbankpartition konfiguriert sind. Die Prozedurdatei sucht anschließend die Dateien /usr/bin/reg.parms.DATENBANK und /usr/bin/failover.parms.DATENBANK, wobei DATENBANK jeweils die Datenbanken darstellt, die für diese Datenbankpartition konfiguriert sind. In einer Konfiguration zur gegenseitigen Übernahme ist es empfehlenswert, diese Parameterdateien reg.parms.xxx und failover.parms.xxx zu erstellen. In der Datei failover.parms.xxx sollten die Einstellungen für BUFFPAGE, DBHEAP und ggf. anderen Parametern, die die Pufferpools betreffen, angepaßt werden, um der Möglichkeit, daß mehr als ein Pufferpool vorhanden sein kann, Rechnung zu tragen. Die Beispieldateien reg.parms.SAMPLE und failover.parms.SAMPLE sind für Sie vorbereitet.
Einer der wichtigen Parameter in dieser Umgebung ist der Konfigurationsparameter start_stop_time des Datenbankmanagers, dessen Standardwert 10 Minuten ist. Die Prozedur rc.db2pe setzt diesen Parameter jedoch auf 2 Minuten. Sie sollten diesen Parameter durch rc.db2pe auf einen Wert von 10 Minuten oder etwas mehr setzen. In diesem Kontext ist die angegebene Zeitdauer das Intervall zwischen dem Ausfall der Partition und der Wiederherstellung der Partition. Wenn in den Anwendungen, die auf einer Partition ausgeführt werden, häufig COMMIT-Anforderungen abgesetzt werden, sollten zehn Minuten nach dem Ausfall einer Datenbankpartition ausreichen, um nicht festgeschriebene Transaktionen rückgängig zu machen (ROLLBACK) und einen Konsistenzzustand in der Datenbank in dieser Partition zu erreichen. Wenn Sie eine hohe Auslastung oder viele Partitionen haben, müssen Sie die Zeitdauer eventuell verlängern, um die Wahrscheinlichkeit zu verringern, daß Zeitlimitüberschreitungen auftreten, bevor die ROLLBACK-Operation beendet ist.
Die folgenden Beispiele beschreiben eine Konfiguration im Bereitschaftsmodus (Hot Standby) und eine Konfiguration zur gegenseitigen Übernahme (Mutual Takeover). In beiden Beispielen enthalten die Ressourcengruppen eine Service-IP-Switch-Aliasadresse. Diese Adresse dient zu folgenden Zwecken:
Wenn in Ihrer Implementierung diese Aliasnamen nicht erforderlich sind, können sie entfernt werden. Wenn sie entfernt werden, stellen Sie sicher, daß in der Prozedurdatei rc.db2pe der Parameter MOUNT_NFS auf den Wert NO gesetzt wird.
Dieses Beispiel geht davon aus, daß eine Konfiguration im Bereitschaftsmodus zwischen den physischen Knoten 1 und 2 besteht und daß der Name des DB2-Exemplars POWERTP lautet. Die Datenbankpartition ist 1, der Name der Datenbank TESTDATA, die sich im Dateisystem /database befindet.
Resource group name: db2_dp_1 Node Relationship: cascading Participating nodenames: node1_eth, node2_eth Service_IP_label: nfs_switch_1 (<<< dies ist die Switch-Aliasadresse) Filesystems: /database/powertp/NODE0001 Volume Groups: DB2vg1 Application Servers: db2_dp1_app Application Server Start Script: /usr/bin/rc.db2pe powertp 1 1 start Application Server Stop Script: /usr/bin/rc.db2pe powertp 1 1 stop
Dieses Beispiel geht davon aus, daß eine Konfiguration für gegenseitige Übernahme zwischen den physischen Knoten 1 und 2 besteht und daß der Name des DB2-Exemplars POWERTP lautet. Die Datenbankpartitionen sind 1 und 2, der Name der Datenbank ist TESTDATA, die sich im Dateisystem /database befindet.
Resource group name: db2_dp_1 Node Relationship: cascading Participating nodenames: node1_eth, node2_eth Service_IP_label: nfs_switch_1 (<<< dies ist die Switch-Aliasadresse) Filesystems: /database/powertp/NODE0001 Volume Groups: DB2vg1 Application Servers: db2_dp1_app Application Server Start Script: /usr/bin/rc.db2pe powertp 1 2 start Application Server Stop Script: /usr/bin/rc.db2pe powertp 1 2 stop Resource group name: db2_pd_2 Node Relationship: cascading Participating nodenames: node2_eth, node1_eth Service_IP_label: nfs_switch_2 (<<< dies ist die Switch-Aliasadresse) Filesystems: /database/powertp/NODE0002 Volume Groups: DB2vg2 Application Servers: db2_dp2_app Application Server Start Script: /usr/bin/rc.db2pe powertp 2 1 start Application Server Stop Script: /usr/bin/rc.db2pe powertp 2 1 stop
Die Prozedur rc.db2pe kann außerdem dazu verwendet werden, über NFS angehängte Verzeichnisse paralleler DB2-Exemplarbenutzerverzeichnisse verfügbar zu machen. Dies kann erreicht werden, indem der Parameter MOUNT_NFS in der Prozedurdatei rc.db2pe auf den Wert YES gesetzt wird und das NFS-Übernahme-Server-Paar wie folgt konfiguriert wird:
Zum Beispiel kann ein JFS-Dateisystem /nfshome an alle Knoten als /dbhome exportiert werden. Jeder Knoten erstellt ein NFS-Dateisystem /dbname, das dem Dateisystem nfs_server:/nfshome entspricht. Daher wäre das Benutzerverzeichnis des DB2-Exemplareigners /dbhome/powertp, wenn der Exemplarname "powertp" wäre.
Stellen Sie sicher, daß in /etc/filesystems die NFS-Parameter "hard", "bg", "intr" und "rw" für das Anhängen (Mount) verwendet werden.
Die Benutzerdefinitionen in einer SP-Umgebung werden typischerweise auf der Steuer-Workstation (control workstation) erstellt, und "supper" oder "pcp" werden zur Verteilung von /etc/passwd, /etc/security/passwd, /etc/security/user und /etc/security/group an alle Knoten verwendet.
Dieses Beispiel geht davon aus, daß es ein NFS-Server-Dateisystem /nfshome in der Datenträgergruppe nfsvg über die IP-Adresse "nfs_server" gibt. Der DB2-Exemplarname ist POWERTP und das Ausgangsverzeichnis /dbhome/powertp.
Resource group name: nfs_server Node Relationship: cascading Participating nodenames: node1_eth, node2_eth Service_IP_label: nfs_server (<<< dies ist die Switch-Aliasadresse) Filesystems: /nfshome Volume Groups: nfsvg Application Servers: nfs_server_app Application Server Start Script: /usr/bin/rc.db2pe powertp NFS SERVER start Application Server Stop Script: /usr/bin/rc.db2pe powertp NFS SERVER stop
In diesem Beispiel gilt:
Bei der Implementierung von HACMP ES mit dem SP-Switch sind folgende Punkte zu beachten:
ifconfig css0 inet alias sw_alias_1 up
Die folgenden Beispiele zeigen verschiedene Konfigurationen zur Unterstützung von Funktionsübernahmen und erläutern, was im Fall eines Ausfalls geschieht.
Im Fall von DB2-HACMP-Konfigurationen für gegenseitige Übernahme (Abbildung 106, Abbildung 107 und Abbildung 108) gilt:
Abbildung 106. Gegenseitige Übernahme mit NFS-Funktionsübernahme - Normal
Abbildung 107. Gegenseitige Übernahme mit NFS-Funktionsübernahme - NFS-Funktionsübernahme
Abbildung 108. Gegenseitige Übernahme mit NFS-Funktionsübernahme - DB2-Funktionsübernahme
Im Fall von DB2-HACMP-Konfigurationen im Bereitschaftsmodus (Abbildung 109 und Abbildung 110) gilt:
Abbildung 109. Bereitschaft mit NFS-Funktionsübernahme - Normal
Abbildung 110. Bereitschaft mit NFS-Funktionsübernahme - DB2-Funktionsübernahme
Im Fall von DB2-HACMP-Konfigurationen für gegenseitige Übernahme ohne NFS-Übernahme (Abbildung 111 und Abbildung 112) gilt:
Abbildung 111. Gegenseitige Übernahme ohne NFS-Funktionsübernahme - Normal
Abbildung 112. Gegenseitige Übernahme ohne NFS-Funktionsübernahme - DB2-Funktionsübernahme
Es wird empfohlen, HACMP nicht für den Start bei Systemstart in /etc/inittab anzugeben. HACMP sollte nach dem Booten der Knoten manuell gestartet werden. Dadurch wird eine ungestörte Wartung des ausgefallenen Knotens ermöglicht.
Betrachten Sie als Beispiel für eine störende Wartung den Fall, in dem auf einem Knoten ein Hardwarefehler mit Systemabsturz auftritt. Die Funktionsübernahme wird von HACMP automatisch eingeleitet und die Wiederherstellung erfolgreich durchgeführt. Allerdings muß der ausgefallene Knoten repariert werden. Wäre HACMP in /etc/inittab zum Starten bei erneutem Booten konfiguriert, würde dieser Knoten nach Abschluß des Bootens versuchen, sich erneut einzugliedern, was in diesem Fall jedoch nicht wünschenswert ist.
Zur unterbrechungsfreien Wartung sollte ein manuelles Starten von HACMP auf jedem Knoten in Betracht gezogen werden. Auf diese Weise können ausgefallene Knoten repariert und wieder integriert werden, ohne die anderen Knoten zu beeinträchtigen. Die Prozedur ha_cmd wird zur Steuerung der HACMP-Befehle zum Starten und Stoppen über die Steuer-Workstation bereitgestellt.
Anmerkung: | Wenn zum ersten Mal ein DB2-Exemplar erstellt wird, wird der folgende Eintrag
an die Datei /etc/inittab angehängt:
rcdb2:2:once:/etc/rc.db2 > /dev/console 2>&1 # Autostart DB2 ServicesWenn HACMP oder HACMP ES aktiviert ist, aktualisieren Sie die Datei /etc/inittab, indem Sie die obige Zeile vor dem HACMP-Eintrag einordnen. Das folgende Beispiel zeigt einen HACMP-Eintrag in der Datei /etc/inittab: clinit:a:wait:touch /usr/sbin/cluster/.telinit # HACMP for AIXDer Eintrag muß der letzte Eintrag in der Datei /etc/inittab sein. |