Dieser Abschnitt behandelt die folgenden Themen:
Anwendungen, die von einem hochverfügbaren DB2-Exemplar abhängig sind, müssen in der Lage sein, im Falle einer Funktionsübernahme eine neue Verbindung herzustellen. Da der Host-Name und die IP-Adresse eines logischen Host gleich bleiben, muß keine Verbindung zu einem anderen Host-Namen hergestellt oder die Datenbank erneut katalogisiert werden.
Betrachten Sie das Beispiel eines Clusters mit zwei Maschinen und einem Exemplar von DB2 Universal Database Enterprise Edition (EE). Das EE-Exemplar befindet sich im Normalfall auf einer der Maschinen im Cluster. Clients des HA-Exemplars stellen die Verbindung zur logischen IP-Adresse (oder zum Host-Namen) des logischen Hosts her, dem das HA-Exemplar zugeordnet ist.
Aus Sicht eines HA-Clients gibt es zwei Arten von Funktionsübernahme. Eine Art tritt auf, wenn die Maschine abstürzt, auf der das HA-Exemplar aktiv ist. Die andere Art tritt auf, wenn das HA-Exemplar eine Möglichkeit erhält, ordnungsgemäß herunterzufahren.
Wenn eine Maschine abstürzt und das HA-Exemplar außer Betrieb setzt, werden sowohl die vorhandenen Verbindunen als auch neue Verbindungen zu Datenbank blockiert. Die Verbindungen werden blockiert, weil es keine Maschinen im Netzwerk mit der IP-Adresse gibt, die die Clients für die Datenbank verwendeten. Wenn die Datenbank ordnungsgemäß heruntergefahren wird, unterbricht ein Befehl db2stop force vorhandene Verbindungen zur Datenbank und es wird eine Fehlernachricht zurückgegeben.
Während der Funktionsübernahme ist die der Datenbank zugeordnete logische IP-Adresse offline, entweder weil sie von der SC2.2-Software offline genommen wurde oder weil die Maschine, die den logischen Host beherbergte, abgestürzt ist. Zu diesem werden alle neuen Verbindungen zur Datenbank für eine kurze Zeit blockiert.
Die der Datenbank zugeordnete logische IP-Adresse wird schließlich auf einer anderen Maschine wieder funktionsfähig gemacht, bevor DB2 gestartet wird. In diesem Stadium wird eine Verbindung zur Datenbank nicht blockiert, jedoch empfängt sie einen Übertragungsfehler, weil DB2 im System noch nicht wieder gestartet wurde. DB2-Clients, die immer noch mit der Datenbank verbunden sind, erhalten nun ebenfalls Übertragungsfehler. Obwohl die Clients weiterhin annehmen, daß sie verbunden sind, sind der Maschine, die die logische IP-Adresse übernommen hat, keine vorhandenen Verbindungen bekannt. Die Verbindungen werden einfach zurückgesetzt, und der DB2-Client empfängt einen Übertragungsfehler. Nach einer kurzen Zeit wird DB2 auf der Maschine gestartet, so daß eine Verbindung zur Datenbank erfolgreich hergestellt werden kann. An diesem Punkt kann die Datenbank inkonsistent sein, und die Clients müssen möglicherweise warten, bis die Konsistenz wiederhergestellt ist.
Bei der Entwicklung einer Anwendung für eine HA-Umgebung ist es nicht nötig, speziellen Code für die Phasen zu schreiben, in denen die Datenbankverbindungen blockiert werden. Die Verbindungen sind nur kurze Zeit blockiert, während die Sun Cluster-Software die logische IP-Adresse versetzt. Jeder Datenbankservice, der unter Sun Cluster ausgeführt wird, erfährt die gleichen blockierten Verbindungen während dieser Phase. Unabhängig davon, wie die Datenbank außer Betrieb gesetzt wird, empfangen die Clients eine Fehlernachricht und müssen versuchen, die Verbindung wiederherzustellen, bis sie erfolgreich sind. Aus der Perspektive des Clients sieht es so aus, als wäre das HA-Exemplar ausgefallen und auf derselben Maschine wieder verfügbar gemacht worden. Bei einer kontrollierten Funktionsübernahme erscheint es dem Client so, als ob er zwangsweise getrennt wurde und später eine neue Verbindung zur Datenbank auf derselben Maschine herstellen könnte. Bei einer unkontrollierten Funktionsübernahme hat der Client den Eindruck, daß der Datenbank-Server abgestürzt ist und auf derselben Maschine in kurzer Zeit wieder verfügbar gemacht wurde.
DB2 erwartet, daß die erforderlichen Platteneinheiten bzw. Dateisysteme auf jeder Maschine im Cluster gleich erscheinen. Um dies zu gewährleisten, sollten die erforderlichen Platten oder Dateisysteme so konfiguriert werden, daß sie dem logischen Host, dem das HA-Exemplar zugeordnet ist, folgen und auf jeder Maschine im Cluster die gleichen Pfadnamen besitzen.
Sowohl DMS- als auch SMS-Tabellenbereiche werden in einer HA-Umgebung unterstützt. Einheitenbehälter für DMS-Tabellenbereiche müssen vom Datenträgermanager erstellte unformatierte Einheiten (Raw Devices) verwenden, die entweder gespiegelt werden oder in einer RAID-Konfiguration eingerichtet sind. Reguläre Platteneinheiten (Disk devices), wie zum Beispiel /dev/rdsk/c20t0d0s0, sollten aus folgenden Gründen nicht eingesetzt werden:
Wenn DB2 in dieser Situation von einer anderen Maschine übernommen wird, sehen die erforderlichen Platteneinheiten nicht genauso aus, wie auf der anderen Maschine, und DB2 wird nicht gestartet. Dateibehälter für DMS-Tabellenbereiche und Behälter für SMS-Tabellenbereiche müssen sich auf angehängten (mounted) Dateisystemen befinden. Die Dateisysteme für einen logischen Host werden automatisch angehängt, wenn sie in die Datei vfstab für den logischen Host aufgenommen wurden.
Die Datei vfstab für einen logischen Host befindet sich in folgendem Pfad:
/etc/opt/SUNWcluster/conf/hanfs/vfstab.<logischer_host>
Dabei ist logischer_host der Name des logischen Hosts, dem die Datei vfstab zugeordnet ist.
Jeder logische Host besitzt eine eigene Datei vfstab, die Dateisysteme enthält, die anzuhängen sind, nachdem die Plattengruppen für den logischen Host auf die aktuelle Maschine verlegt wurden, jedoch bevor die HA-Services gestartet werden. Die Sun Cluster-Software versucht, jedes ordnungsgemäß definierte Dateisystem nach der Ausführung von fsck (Dateisystemprüfung) anzuhängen, um den einwandfreien Zustand des Dateisystems sicherzustellen. Wenn fsck fehlschlägt, wird das Dateisystem nicht angehängt und eine Fehlernachricht protokolliert.
Anmerkung: | Wenn ein Prozeß eine geöffnete Datei besitzt oder sich das zugehörige aktuelle Arbeitsverzeichnis unter einem Mount-Punkt befindet, schlägt das Anhängen (Mount) fehl. Zur Vermeidung dieses Fehlers müssen Sie sicherstellen, daß keine Prozesse unter Mount-Punkten verbleiben, die in der Datei vfstab des logischen Hosts enthalten sind. |
Als Dateisystemlayout für ein EEE-Exemplar kann bei Verwendung von SMS-Tabellenbereichen eine beliebige Konvention verwendet werden. Das folgende Beispiel zeigt die Konvention, die vom Dienstprogramm hadb2_setup verwendet wird:
scadmin@crackle(190)# pwd /export/ha_home/db2eee/db2eee scadmin@crackle(191)# ls -l total 18 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0000 -> /log0/disks/db2eee/NODE0000 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0001 -> /log0/disks/db2eee/NODE0001 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0002 -> /log0/disks/db2eee/NODE0002 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0003 -> /log0/disks/db2eee/NODE0003 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0004 -> /log0/disks/db2eee/NODE0004 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0005 -> /log1/disks/db2eee/NODE0005 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0006 -> /log1/disks/db2eee/NODE0006 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0007 -> /log1/disks/db2eee/NODE0007 lrwxrwxrwx 1 root build 28 Aug 12 19:08 NODE0008 -> /log1/disks/db2eee/NODE0008 scadmin@crackle(192)#
Der Exemplareigner ist db2eee und das Standarddatenbankverzeichnis für das Exemplar db2eee ist /export/ha_home/db2eee. Der logische Host log0 beherbergt die Datenbankpartitionen 0, 1, 2,3 und 4, während der logische Host log1 die Datenbankpartitionen 5, 6, 7 und 8 beherbergt.
Für jede Datenbankpartition gibt es ein entsprechendes Verzeichnis NODExxxx. Die Knotenverzeichnisse für die Datenbankpartitionen zeigen auf ein Verzeichnis unter dem Dateisystem des zugeordneten logischen Hosts.
Bei der Auswahl einer Pfadkonvention müssen Sie folgendes sicherstellen:
Für ein EE-Exemplar sollte das Ausgangsverzeichnis (home) ein Dateisystem sein, das in der Datei vfstab für einen logischen Host definiert ist. Dieses Verzeichnis wird verfügbar, bevor DB2 gestartet wird, und wird mit DB2 versetzt, wenn der logische Host im Cluster versetzt wird. Jede Maschine verfügt über eine eigene Kopie der Datei vfstab, und es sollte sorgfältig darauf geachtet werden, daß sie auf jeder Maschine im Cluster den gleichen Inhalt hat. Das folgende Beispiel zeigt das Ausgangsverzeichnis für ein EE-Exemplar:
/log0/home/db2ee
Dabei ist /log0 das Dateisystem für den logischen Host log0 und db2ee der Name des DB2-Exemplars. Dieser Ausgangsverzeichnispfad sollte in die Datei /etc/passwd auf jeder Maschine im Cluster eingefügt werden, die als Host für das Exemplar "db2ee" fungieren kann.
Für ein EEE-Exemplar kann das Ausgangsverzeichnis auf zwei Arten eingerichtet werden. Bei einer Konfiguration im Bereitschaftsmodus (Hot Standby) kann das Ausgangsverzeichnis auf die gleiche Art wie für ein EE-Exemplar eingerichtet werden. Bei einer Konfiguration zur gegenseitigen Übernahme (Mutual Takeover) muß HA-NFS für das Ausgangsverzeichnis verwendet und vor dem Einrichten des EEE-Exemplars ordnungsgemäß konfiguriert werden.
Eine der Maschinen im Cluster muß mit Hilfe der Datei dfstab für einen ausgewählten logischen Host das Dateisystem für das EEE-Exemplar exportieren. Die Datei dfstab enthält Dateisysteme, die durch NFS exportiert werden sollten, wenn eine Maschine einen logischen Host beherbergt. Jede Maschine verfügt über eine eigene Kopie der Datei dfstab, und es sollte sorgfältig darauf geachtet werden, daß sie auf jeder Maschine im Cluster den gleichen Inhalt hat.
Informationen für das HA-NFS-Dateisystem werden in der Datei hadb2tab (durch das Programm hadb2_setup) abgelegt. Wenn ein HA-Agent die Informationen für das Exemplar liest, hängt er das HA-NFS-Dateisystem für das Exemplar automatisch an (siehe Die Datei hadb2tab).
Der Mount-Punkt für das HA-NFS-Dateisystem ist in der Regel /export/ha_home. Auf jeder Maschine im Cluster wäre dies das NFS, das vom logischen Host angehängt wird, der das HA-NFS-Verzeichnis exportiert. Das Ausgangsverzeichnis des EEE-Exemplareigners wird unter diesem Verzeichnis angelegt und hat den folgenden Namen:
/export/ha_home/<exemplar>
Dabei ist exemplar der Name des Exemplareigners.
Es wäre möglich, ein Ausgangsverzeichnis für ein Exemplar auf jeder Maschine anzulegen, um ein Anhängen oder Abhängen dieses Verzeichnisses zu vermeiden. Dieses Verfahren erfordert einen zusätzlichen administrativen Aufwand, um sicherzustellen, daß die Ausgangsverzeichnisse auf allen Maschinen identisch bleiben. Wenn dies nicht gewährleistet wird, kann DB2 eventuell nicht ordnungsgemäß gestartet werden oder wird mit einer anderen Konfiguration gestartet. Dies ist keine unterstützte Konfiguration.
Ein logischer Host wird in der Regel dazu ausgewählt, als Host für eine oder mehrere Datenbankpartitionen zu fungieren sowie dazu das HA-NFS-Dateisystem zu exportieren. Wenn es zum Beispiel vier Datenbankpartitionen und zwei Maschinen im Cluster gäbe, sollte es einen logischen Host für jede Maschine geben (siehe Abbildung 119). Ein logischer Host würde als Host zweier Datenbankpartitionen fungieren und das HA-NFS-Dateisystem exportieren, während der andere logische Host die verbleibenden zwei Datenbankpartitionen beherbergt.
Standardmäßig ordnet ein DB2 UDB EEE-Exemplar genügend Ressourcen zum erfolgreichen Hinzufügen von bis zu zwei Datenbankpartitionen einer Maschine zu, die bereits eine oder mehrere im Betrieb befindliche Datenbankpartitionen für dieses Exemplar besitzt. Wenn es beispielsweise vier Datenbankpartitionen für ein einziges Exemplar in einem Cluster gibt, kann es nur dann zu Problemen kommen, wenn es eine Datenbankpartition pro logischen Host gibt oder ein logischer Host als Host von drei Datenbankenpartitionen fungiert. In beiden Fällen ist es möglich, daß drei Datenbankpartitionen von einer Maschine übernommen werden, die bereits für eine Datenbankpartition desselben Exemplars zuständig ist.
Die Registrierungsvariable DB2_NUM_FAILOVER_NODES kann dazu verwendet werden, die Ressourcenmenge zu erhöhen, die für zu übernehmende Datenbankpartitionen reserviert wird.
Abbildung 119. Ein logischer Host für jede Maschine
Das Dateisystem, in dem DB2 installiert wird, sollte gespiegelt werden oder zumindest in einer RAID-Konfiguration angelegt werden. Wenn DB2 auf normalen Platten installiert wird, ist ein Plattenausfall wahrscheinlicher. Die sich daraus ergebende Funktionsübernahme gilt als vermeidbar und verringert die Stabilität des Clusters.
DB2 kann nicht auf Platten in einer Plattengruppe für einen logischen Host installiert werden, weil der HA-Agent ständig Zugriff auf die DB2-Bibliotheken benötigt. Wenn die HA-Agenten keinen Zugriff auf die DB2-Bibliotheken haben, werden sie mit einem Fehler beendet. DB2 muß auf jeder Maschine im Cluster normal installiert werden.
Die Konfigurationsparameter des Datenbankmanagers können nach einer Funktionsübernahme und vor dem Starten von DB2 mit Hilfe der Prozedur pre_db2start (siehe Benutzerprozeduren) geändert werden. Diese ausführbare Prozedur (Skript) wird (falls vorhanden) unter dem Verzeichnis sqllib/ha des Ausgangsverzeichnisses des Exemplareigners ausgeführt. Wie der Name verrät, wird sie unmittelbar vor db2start ausgeführt. Die gleichen Parameter, die an die Steuermethoden übergeben werden, werden auch an die Prozedur pre_db2start übergeben, wenn das Exemplar kein EEE-Exemplar ist. Für ein EEE-Exemplar wird der Prozedur pre_db2start außerdem die Knotennummer für den Befehl db2start übergeben.
Die Wiederherstellung nach einem Systemabsturz in einer HA-Umgebung erfolgt auf dieselbe Weise wie in einer regulären Umgebung. Selbst wenn das HA-Exemplar auf einer anderen Maschine als der Absturzmaschine wieder gestartet wird, sehen die Dateien und Platteneinheiten für das Exemplar gleich aus und die Aktionen, die zur Wiederherstellung der Datenbank durchzuführen sind, unterscheiden sich ebenfalls nicht. Weitere Informationen zur Wiederherstellung nach einem Systemabsturz finden Sie in Kapitel 19, Wiederherstellen einer Datenbank .
Obwohl eine Datenbank manuell (oder durch eine der Benutzerprozeduren) erneut gestartet werden kann, wird empfohlen, den Konfigurationsparameter autorestart der Datenbank, insbesondere für ein EEE-Exemplar, auf den Wert ON zu setzen. Dadurch wird der Zeitraum minimiert, den die Datenbank in einem inkonsistenten Zustand ist.
Die Verfügbarkeit von Daten kann auch durch Replikation verbessert werden. Durch das Replizieren von Daten zwischen zwei Servern läßt sich eine Form hoher Verfügbarkeit erreichen. Wenn einer der Server ausfällt, kann der andere Server die Funktion übernehmen und den Datenbankservice weiterhin bereitstellen.
Da die Replikation jedoch asynchron erfolgt, wurden von einem Server, der ausfällt, möglicherweise einige Änderungen noch nicht auf den anderen Server weitergegeben.