DB2 Universal Database - Systemverwaltung


Clusterkonfiguration

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:

  1. % bedeutet Modulus.

  2. In allen Fällen werden die Operatoren von links nach rechts ausgewertet.

Es folgen einige Beispiele zur Erstellung von Behältern mit Hilfe dieses Spezialarguments:

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

Kein einzelner Fehlerpunkt

Abbildung 105. Konfiguration von Datenträgergruppe und logischem Datenträger

Konfiguration von Datenträgergruppe und logischem Datenträger

Konfigurieren einer DB2-Datenbankpartition

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.

Beispiel für ein Konfiguration im Bereitschaftsmodus (Hot Standby)

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

Beispiel für eine Konfiguration für gegenseitige Übernahme (Mutual Takeover)

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

Konfiguration eines NFS-Server-Knotens

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:

Beispiel für eine NFS-Server-Übernahmekonfiguration

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:

Überlegungen zur Konfiguration des SP-Switch

Bei der Implementierung von HACMP ES mit dem SP-Switch sind folgende Punkte zu beachten:

Beispiele für DB2-HACMP-Konfigurationen

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

Gegenseitige Übernahme mit NFS-Funktionsübernahme - Normal

Abbildung 107. Gegenseitige Übernahme mit NFS-Funktionsübernahme - NFS-Funktionsübernahme

Gegenseitige Übernahme mit NFS-Funktionsübernahme - NFS-Funktionsübernahme

Abbildung 108. Gegenseitige Übernahme mit NFS-Funktionsübernahme - DB2-Funktionsübernahme

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

Bereitschaft mit NFS-Funktionsübernahme - Normal

Abbildung 110. Bereitschaft mit NFS-Funktionsübernahme - DB2-Funktionsübernahme

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

Gegenseitige Übernahme ohne NFS-Funktionsübernahme - Normal

Abbildung 112. Gegenseitige Übernahme ohne NFS-Funktionsübernahme - DB2-Funktionsübernahme

Gegenseitige Übernahme ohne NFS-Funktionsübernahme - DB2-Funktionsübernahme

Empfehlungen für den DB2-HACMP-Systemstart

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 Services
Wenn 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 AIX
Der Eintrag muß der letzte Eintrag in der Datei /etc/inittab sein.


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