DB2 Universal Database - Systemverwaltung


Verwalten von DB2 in einer MSCS-Umgebung

Der Einsatz von MSCS-Clustern bringt für das DB2-Exemplar zusätzliche Planung im Hinblick auf den täglichen Betrieb, die Datenbankverteilung und die Datenbankkonfiguration mit sich. Damit DB2 auf jedem MSCS-Knoten transparent ausgeführt werden kann, sind zusätzliche administrative Maßnahmen erforderlich. Alle von DB2 abhängigen Betriebssystemressourcen müssen auf allen MSCS-Knoten verfügbar sein. Einige dieser Betriebssystemressourcen gehören nicht zum Bereich von MSCS. Das heißt, sie können nicht als eine MSCS-Ressource definiert werden. Sie müssen daher sicherstellen, daß jedes System so konfiguriert ist, daß die gleichen Betriebssystemressourcen auf allen MSCS-Knoten zur Verfügung stehen. In den folgenden Abschnitten werden die zusätzlichen Maßnahmen beschrieben, die durchgeführt werden müssen.

Starten und Stoppen von DB2-Ressourcen

Sie müssen DB2-Ressourcen vom Clusterverwaltungsprogramm (Cluster Administrator) aus starten und stoppen. Es sind verschiedene Möglichkeiten verfügbar, ein DB2-Exemplar zu starten, wie zum Beispiel der Befehl db2start und die Option Dienste in der Systemsteuerung. Wird DB2 jedoch nicht über Cluster Administrator gestartet, erkennt die MSCS-Software den Status des DB2-Exemplars nicht. Wenn ein DB2-Exemplar über Cluster Administrator gestartet und mit dem Befehl db2stop gestoppt wird, interpretiert die MSCS-Software den Befehl db2stop als Softwarefehler und versucht, DB2 erneut zu starten. (Die gegenwärtigen MSCS-Schnittstellen ermöglichen keine Benachrichtigung über einen Ressourcenstatus.)

Analog gilt, daß, wenn Sie ein DB2-Exemplar mit dem Befehl db2start starten, MSCS nicht erkennen kann, daß die Ressource online ist. Wenn ein Datenbank-Server ausfällt, bringt MSCS die DB2-Ressource in diesem Fall nicht auf der Übernahmemaschine im Cluster wieder online.

Drei Operationen können auf ein DB2-Exemplar angewendet werden:

Online
Diese Operation ist äquivalent zur Verwendung des Befehls db2start. Wenn DB2 bereits aktiv ist, kann diese Operation einfach dazu verwendet werden, MSCS darüber zu informieren, daß DB2 aktiv ist. Fehler während der Ausführung dieser Operation werden in das Windows NT-Ereignisprotokoll (Event Log) geschrieben.

Offline
Diese Operation ist äquivalent zur Verwendung des Befehls db2stop. Wenn es aktive Attach-Verbindungen zu einem Exemplar gibt, schlägt diese Operation fehl. Dies stimmt mit der Funktionsweise des Befehls db2stop überein.

Ressource abbrechen (Fail Resource)
Diese Operation ist äquivalent zur Verwendung des Befehls db2stop unter Angabe der Option force. DB2 trennt alle Anwendungen vom DB2-System und stoppt alle Datenbank-Server.

Ausführen von Prozeduren

Sie können Prozeduren ausführen, bevor eine DB2-Ressource online gebracht wird und nachdem Sie online gebracht wurde. Diese Prozeduren müssen sich im Exemplarprofilverzeichnis befinden, das für die Umgebungsvariable DB2INSTPROF angegeben ist. Dieses Verzeichnis ist der Verzeichnispfad, der durch den Parameter "-p" des Befehls db2icrt angegeben wird. Sie können diesen Wert durch folgenden Befehl abrufen:

   db2set -i:exemplarname DB2INSTPROF

Dieser Dateipfad muß auf einer Platte im Cluster sein, so daß das Exemplarverzeichnis auf allen Clusterknoten verfügbar ist.

Diese Prozedurdateien sind nicht erforderlich und werden nur ausgeführt, wenn Sie im Exemplarverzeichnis gefunden werden. Sie werden vom MSCS-Cluster-Service (Dienst) im Hintergrund gestartet. Die Prozedurdateien müssen Standardausgaben umleiten, um alle Ausgaben als Ergebnis von Befehlen innerhalb der Prozedurdateien aufzufangen. Die Ausgaben werden nicht auf dem Bildschirm angezeigt.

In einer partitionierten Datenbankumgebung wird standardmäßig die gleiche Prozedur von jedem Datenbankpartitions-Server im Exemplar verwendet. Wenn Sie zwischen verschiedenen Datenbankpartitions-Servern im Exemplar Unterschiede machen müssen, ordnen Sie unterschiedliche Werte der Umgebungsvariable DB2NODE zu, um bestimmte Zielknotennummern anzugeben. (Verwenden Sie dazu zum Beispiel die Anweisung IF in den Dateien db2cpre.bat und db2cpost.bat.)

Ausführen von Prozeduren, bevor DB2-Ressourcen online gebracht werden

Wenn Sie eine Prozedur ausführen wollen, bevor Sie eine DB2-Ressource online bringen, muß die Prozedur den Namen db2cpre.bat erhalten. DB2 ruft Funktionen auf, die diese Stapeldatei (Batch-Datei) über den Befehlszeilenprozessor (CLP) von Windows NT starten und auf die Beendigung der Ausführung durch den Befehlszeilenprozessor warten, bevor die DB2-Ressource online gebracht wird. Sie können diese Stapeldatei für Operationen wie das Ändern der DB2-Datenbankmanagerkonfiguration verwenden. Es ist zum Beispiel sinnvoll, einige Parameterwerte des Datenbankmanagers zu ändern, wenn das Übernahmesystem begrenzte Kapazitäten hat und die Systemressourcen, die von DB2 beansprucht werden, verringert werden müssen.

Die Befehle, die in die Prozedur db2cpre.bat gestellt werden, sollten synchron ausgeführt werden. Ansonsten könnte die DB2-Ressource online gebracht werden, bevor alle Operationen in der Prozedur beendet sind, wodurch sich unvorhergesehene Resultate ergeben können. Insbesondere sollte der Befehl db2cmd nicht in der Prozedur db2cpre.bat ausgeführt werden, weil er seinerseits einen anderen Befehlsprozessor startet, der DB2-Befehle asynchron zum Programm db2cmd ausführt.

Wenn Sie DB2-CLP-Befehle in der Prozedur db2cpre.bat ausführen wollen, sollten die Befehle in eine Datei gestellt und als CLP-Stapeldatei von einem Programm aus ausgeführt werden, das die DB2-Umgebung für den DB2-Befehlszeilenprozessor initialisiert und anschließend auf die Beendigung des DB2-Befehlszeilenprozessors wartet. Beispiel:

#include <windows.h>
 
int WINAPI DB2SetCLPEnv_api(DWORD pid);
 
void main ( int argc, char *argv [ ] )
{
      STARTUPINFO         startInfo   = {0};
      PROCESS_INFORMATION pidInfo     = {0};
      char     title  [32]   = "Synchrone Ausführung";
      char     runCmd [64]  =
                             "DB2 -z c:\\run.out -tvf c:\\run.clp";
/* Aufrufen der API zum Einrichten einer CLP-Umgebung */
      if ( DB2SetCLPEnv_api (GetCurrentProcessId ()) == 0 ) (1)
      {
         startInfo.cb          = sizeof(STARTUPINFO);
         startInfo.lpReserved  = NULL;
         startInfo.lpTitle     = title;
         startInfo.lpDesktop   = NULL;
         startInfo.dwX         = 0;
         startInfo.dwY         = 0;
         startInfo.dwXSize     = 0;
         startInfo.dwYSize     = 0;
         startInfo.dwFlags     = 0L;
         startInfo.wShowWindow = SW_HIDE;
         startInfo.lpReserved2 = NULL;
         startInfo.cbReserved2 = 0;
               if ( CreateProcessA( NULL,
                              runCmd, (2)
                              NULL,
                              NULL,
                              FALSE,
                              NORMAL_PRIORITY_CLASS CREATE_NEW_CONSOLE,
                              NULL,
                              NULL,
                              &startInfo,
                              &pidInfo))
         {
            WaitForSingleObject (pidInfo.hProcess, INFINITE);
            CloseHandle (pidInfo.hProcess);
            CloseHandle (pidInfo.hThread);
         }
      }
      return;
}

(1)
Die API DB2SetCLPEnv_api wird durch die Importbibliothek DB2API.LIB aufgelöst. Diese API definiert eine Umgebung, die das Aufrufen von CLP-Befehlen ermöglicht. Wenn dieses Programm aus der Prozedur db2cpre.bat heraus aufgerufen wird, wird der Befehlsprozessor warten, bis die CLP-Befehle abgeschlossen sind.

(2)
runCmd ist der Name der Prozedurdatei, die die DB2-CLP-Befehle enthält.

Im Unterverzeichnis MISC des DB2-Installationspfads befindet sich ein Beispielprogramm namens db2clpex.exe. Diese ausführbare Datei ist dem angeführten Beispiel ähnlich, jedoch akzeptiert sie den DB2-CLP-Befehl als Befehlszeilenparameter. Wenn Sie dieses Beispielprogramm verwenden wollen, kopieren Sie es in das Unterverzeichnis BIN. Sie können diese ausführbare Datei in der Prozedur db2cpre.bat wie folgt verwenden (INSTHOME ist das Exemplarverzeichnis):

   db2clpex "DB2 -Z INSTHOME\pre.log -tvf INSTHOME\pre.clp"

Alle DB2-Befehle ATTACH oder Anweisungen CONNECT sollten explizit einen Benutzer angeben. Ansonsten werden sie unter dem Benutzerkonto ausgeführt, das dem Clusterdienst (Service) zugeordnet ist. CLP-Prozeduren sollten außerdem mit dem Befehl TERMINATE schließen, um den CLP-Hintergrundprozeß zu beenden.

Es folgt ein Beispiel einer Datei db2cpre.bat:

   db2cpre.bat : (1)
   ------------------------
   db2clpex "db2 -z INSTHOME\pre-%DB2NODE%.log -tvf INSTHOME\pre.clp" (2) - (5)
   ------------------------
 
   PRE.CLP (6)
   ------------------------
   update dbm cfg using MAXAGENTS 200;
   get dbm cfg;
   terminate;
   ------------------------

(1)
Die Prozedur db2cpre.bat wird unter dem Benutzerkonto ausgeführt, das dem Clusterdienst zugeordnet ist. Wenn DB2-Aktionen erforderlich sind, muß das dem Clusterdienst zugeordnete Benutzerkonto eine gültige SQL-Kennung sein, wie sie von DB2 definiert wird.

(2)
INSTHOME ist das Exemplarverzeichnis.

(3)
Der Name der Protokolldatei (Log) muß für jeden Knoten unterschiedlich sein, um Dateikonflikte zu vermeiden, wenn beide logischen Knoten gleichzeitig online gebracht werden.

(4)
db2clpex.exe ist ein Beispielprogramm, das ein Befehlszeilenargument zur Angabe des auszuführenden CLP-Befehls akzeptiert.

(5)
Das Beispielprogramm db2clpex.exe muß auf allen MSCS-Clusterknoten verfügbar gemacht werden.

(6)
Die CLP-Befehle in diesem Beispiel begrenzen die Anzahl von Agenten.

Ausführen von Prozeduren, nachdem DB2-Ressourcen online gebracht wurden

Wenn Sie eine Prozedur ausführen wollen, nachdem Sie eine DB2-Ressource online gebracht haben, muß die Prozedur den Namen db2cpost.bat erhalten. Die Prozedur wird von MSCS asynchron ausgeführt, wenn die DB2-Ressource erfolgreich online gebracht wurde. Der Befehl db2cmd kann in dieser Prozedur verwendet werden, um DB2-CLP-Prozedurdateien auszuführen. Verwenden Sie den Parameter "-c" des Befehls db2cmd, um anzugeben, daß das Dienstprogramm alle Fenster nach Beendigung der Operation schließen soll. Beispiel:

   db2cmd -c db2 -tvf mycmds.clp

Der Parameter "-c" muß das erste Argument für den Befehl db2cmd sein, da er verwaiste Befehlsprozessoren im Hintergrund verhindert.

Die Prozedur db2cpost.bat ist nützlich, wenn Sie Datenbankaktivitäten unmittelbar, nachdem die DB2-Ressource von einer anderen Maschine übernommen und wieder aktiv wird, durchführen wollen. Zum Beispiel können Sie Datenbanken im Exemplar erneut starten oder aktivieren, so daß sie für den Benutzerzugriff vorbereitet sind.

Es folgt ein Beispiel einer Prozedur db2cpost.bat:

   db2cpost.bat (1)
   ------------------------
   db2cmd -c db2 -z INSTHOME\post-%DB2NODE%.log -tvf INSTHOME\post.clp (2) - (4)
   ------------------------
 
   POST.CLP (5)
   ------------------------
   restart database SAMPLE;
   connect reset;
   activate database SAMPLE;
   terminate;
   ------------------------

(1)
Die Prozedur db2cpost.bat wird unter dem Benutzerkonto ausgeführt, das dem Clusterdienst zugeordnet ist. Wenn DB2-Aktionen erforderlich sind, muß das dem Clusterdienst zugeordnete Benutzerkonto eine gültige SQL-Kennung sein, wie sie von DB2 definiert wird.

(2)
INSTHOME ist das Exemplarverzeichnis.

(3)
Der Name der Protokolldatei (Log) muß für jeden Knoten unterschiedlich sein, um Dateikonflikte zu vermeiden, wenn beide logischen Knoten gleichzeitig online gebracht werden.

(4)
Der Befehl db2cmd kann verwendet werden, weil die Prozedur db2cpost.bat asynchron ausgeführt werden kann. Der Parameter "-c" muß zur Beendigung des Befehlsprozessors verwendet werden.

(5)
Die CLP-Prozedur in diesem Beispiel enthält Befehle zum Neustarten und Aktivieren der Datenbank. Diese Prozedur versetzt die Datenbank unmittelbar nach dem Starten des Datenbankmanagers zurück in einen aktiven Status. In einem partitionierten Datenbanksystem sollten Sie den Befehl ACTIVATE DATABASE entfernen, weil mehrere DB2-Ressourcen gleichzeitig online gebracht werden. Der Befehl RESTART DATABASE kann fehlschlagen, weil ein anderer Knoten die Datenbank gerade aktiviert. Wenn dies eintritt, führen Sie die Prozedur erneut aus, um sicherzugehen, daß die Datenbank korrekt erneut gestartet wird.

Überlegungen zu Datenbanken

Stellen Sie bei der Erstellung einer Datenbank sicher, daß der Datenbankpfad eine freigegebene gemeinsame Platte angibt. Dadurch wird die Datenbank auf allen MSCS-Knoten sichtbar. Alle Protokolle und anderen Datenbankdateien müssen ebenfalls auf Platten im Cluster angelegt werden, damit die DB2-Funktionsübernahme erfolgreich durchgeführt werden kann. Wenn Sie diese Punkte nicht beachten, tritt ein DB2-Systemfehler auf, weil es für DB2 so aussieht, als ob Dateien gelöscht wurden oder nicht mehr verfügbar sind.

Stellen Sie darüber hinaus sicher, daß die Konfigurationsparameter des Datenbankmanagers und der Datenbank so eingestellt sind, daß die von DB2 beanspruchten Systemressourcen auf beiden MSCS-Knoten vorhanden sind. Der Konfigurationsparameter autorestart der Datenbank sollte auf ON gesetzt sein, so daß die erste Datenbankverbindung nach der Funktionsübernahme die Datenbank in einen konsistenten Status bringt. (Die Standardeinstellung für autorestart ist ON.) Die Datenbank kann auch mit Hilfe der Prozedur db2cpost.bat zum erneuten Starten und Aktivieren der Datenbank in einen bereiten Status versetzt werden. Diese Methode ist vorzuziehen, weil sie von autorestart unabhängig ist und die Datenbank unabhängig von einer Verbindungsanforderung eines Benutzers in einen bereiten Status versetzt wird.

Benutzer- und Gruppenunterstützung

DB2 ist für die Unterstützung der Benutzerauthentifizierung und Gruppen auf Windows NT angewiesen. Damit ein DB2-Exemplar eines MSCS-Knotens von einem anderen reibungslos übernommen werden kann, muß jeder MSCS-Knoten Zugriff auf die gleichen Sicherheitsdatenbanken von Windows NT haben. Sie können dies erreichen, indem Sie die Domänensicherheit von Windows NT (Domain Security) nutzen.

Definieren Sie alle DB2-Benutzer und DB2-Gruppen in einer Domänensicherheitsdatenbank. Die MSCS-Knoten müssen dieser Domäne angehören oder die Domäne muß eine akzeptierte Domäne (Trusted Domain) sein. DB2 verwendet dann die Domänensicherheitsdatenbank zur Authentifizierung und für die Gruppenunterstützung, unabhängig von dem MSCS-Knoten, auf dem DB2 aktiv ist.

Wenn Sie lokale Konten verwenden, müssen die Konten auf jedem MSCS-Knoten repliziert werden. Dieses Verfahren wird nicht empfohlen, weil es fehlerträchtig ist und eine doppelte Pflege verlangt.

DCE-Sicherheit ist ebenfalls eine unterstützte Identifikationsüberprüfungsart, wenn alle MSCS-Knoten Clients in der gleichen DCE-Zelle sind.

Sie sollten dem MSCS-Dienst ein Benutzerkonto zuordnen, das der DB2-Namenskonvention entspricht. Dadurch kann der MSCS-Dienst Aktionen für DB2 ausführen, die in den Prozeduren db2cpre.bat und db2cpost.bat aufgerufen werden.

Weitere Informationen zur Unterstützung von Benutzern und Gruppen unter Windows NT finden Sie in Benutzerauthentifizierung mit DB2 für Windows NT .

Überlegungen zur Kommunikation

DB2 unterstützt zwei LAN-Protokolle in einer MSCS-Umgebung:

TCP/IP wird unterstützt, weil es ein unterstützter Clusterressourcentyp ist. Zur Aktivierung von DB2 zur Verwendung von TCP/IP als Übertragungsprotokoll für ein partitioniertes Datenbanksystem, erstellen Sie eine IP-Adressenressource und plazieren sie in derselben Gruppe wie die DB2-Ressource, die den Datenbankpartitions-Server repräsentiert, den Sie als Koordinatorknoten für ferne Anwendungen verwenden wollen. Dann erstellen Sie eine Abhängigkeit mit Hilfe von Cluster Administrator, um sicherzustellen, daß die IP-Ressource online ist, bevor die DB2-Ressource gestartet wird. DB2-Clients können dann TCP/IP-Knotenverzeichniseinträge katalogisieren, um diese TCP/IP-Adresse zu verwenden.

Der TCP/IP-Anschluß, der dem Konfigurationsparameter svcename des Datenbankmanagers zugeordnet ist, muß zur Verwendung durch das DB2-Exemplar auf allen Maschinen reserviert werden, die am Exemplar beteiligt sind. Der Servicename, der der Anschlußnummer zugeordnet ist, muß außerdem in der Datei services auf allen Maschinen identisch sein.

Obwohl NetBIOS keine unterstützte Clusterressource ist, können Sie NetBIOS als LAN-Protokoll verwenden, weil das Protokoll sicherstellt, daß NetBIOS-Namen im LAN eindeutig sind. Wenn DB2 einen NetBIOS-Namen registriert, stellt NetBIOS sicher, daß der Name im LAN nicht bereits verwendet wird. Wenn DB2 im Szenario einer Funktionsübernahme von einem System auf ein anderes übertragen wird, wird der von DB2 verwendete nname von einer Partnermaschine im MSCS-Cluster deregistriert und auf der anderen Maschine registriert.

Die DB2-Unterstützung für NetBIOS verwendet NetBIOS-Frames (NBF). Dieser Protokollstapelspeicher kann verschiedenen logischen Adapternummern (LANA) zugeordnet werden. Damit ein konsistenter NetBIOS-Zugriff auf den Server sichergestellt ist, sollte die dem NBF-Protokollstapel zugeordnete LANA auf allen Knoten im Cluster gleich sein. Sie können dies mit Hilfe der Option Netzwerke der Systemsteuerung konfigurieren. Sie sollten NBF der LANA 0 zuordnen, weil dies die von DB2 erwartete Standardeinstellung ist.

Überlegungen zur Systemzeit

DB2 verwendet die Systemzeit, um bestimmte Operationen mit einer Zeitmarke zu versehen. Alle MSCS-Knoten, die an einer DB2-Funktionsübernahme beteiligt sind, müssen eine synchronisierte Systemzeitzone und Systemzeit haben, um eine konsistente Funktionsweise von DB2 auf allen Maschinen sicherzustellen.

Stellen Sie die Systemzeitzone mit Hilfe der Option Datum/Uhrzeit der Systemsteuerung ein. MSCS hat einen Zeitdienst, der das Datum und die Uhrzeit synchronisiert, wenn die MSCS-Knoten zu einem Cluster verbunden werden. Der Zeitdienst synchronisiert die Zeit allerdings nur alle zwölf Stunden. Dadurch kann es zu Problemen kommen, wenn die Zeit auf einem System geändert wird und DB2 übernommen wird, bevor die Zeit synchronisiert wird.

Wenn die Zeit auf einem der MSCS-Clusterknoten geändert wird, sollte sie manuell auf den anderen Clusterknoten mit folgendem Befehl synchronisiert werden:

   net time /set /y \\ferner_knoten

Dabei ist ferner_knoten der Maschinenname des Clusterknotens.

Überlegungen zu Verwaltungs-Server und Steuerzentrale in Umgebungen mit partitionierten Datenbanken

Der DB2-Verwaltungs-Server wird (wahlfrei) während der Installation von DB2 Universal Database erstellt. Er ist kein partitioniertes Datenbanksystem. Die Steuerzentrale verwendet vom Verwaltungs-Server zur Verfügung gestellte Dienste, um DB2-Exemplare und DB2-Datenbanken zu verwalten.

In einem partitionierten Datenbanksystem kann sich ein DB2-Exemplar auf mehreren Knoten befinden. Dies impliziert, daß ein DB2-Exemplar auf mehreren Systemen unter der Steuerzentrale katalogisiert sein muß, so daß der Zugriff auf das Exemplar erhalten bleibt, unabhängig davon, auf welchem MSCS-Knoten das DB2-Exemplar aktiv ist.

Das Exemplarverzeichnis des Verwaltungs-Servers wird nicht gemeinsam verwendet. Sie müssen alle benutzerdefinierten Dateien im Verzeichnis des Verwaltungs-Servers auf allen MSCS-Knoten spiegeln, um die gleiche Verwaltungsstufe auf allen MSCS-Knoten zur Verfügung zu stellen. Insbesondere müssen Benutzerprozeduren und nach Zeitplan terminierte ausführbare Dateien auf allen Knoten verfügbar sein. Außerdem müssen Sie sicherstellen, daß nach Zeitplan terminierte Aktivitäten auf allen Maschinen in einem MSCS-Cluster terminiert sind.

Alternativ zum Duplizieren des Verwaltungs-Servers auf allen Maschinen kann es wünschenswert sein, eine Funktionsübernahme für den Verwaltungs-Server zu ermöglichen. Nehmen Sie für das folgende Beispiel an, Sie hätten zwei MSCS-Knoten mit den Namen MACH0 und MACH1 im Cluster. MACH0 hat Zugriff auf eine Clusterplatte, die vom Verwaltungs-Server verwendet wird. Nehmen Sie außerdem an, daß MACH0 und MACH1 einen Verwaltungs-Server haben. Um den Verwaltungs-Server hochverfügbar zu machen, würden Sie folgende Schritte ausführen:

  1. Stoppen Sie den Verwaltungs-Server auf beiden Maschinen, indem Sie den Befehl db2admin stop auf jeder Maschine ausführen.
  2. Entkatalogisieren Sie auf allen Verwaltungs-Client-Maschinen alle Verweise auf die Verwaltungs-Server von MACH0 und MACH1 mit dem Befehl UNCATALOG NODE. (Mit Hilfe des Befehls LIST NODE DIRECTORY auf der Client-Maschine können Sie feststellen, ob Verweise auf den Verwaltungs-Server vorhanden sind.)
  3. Löschen Sie den Verwaltungs-Server von MACH1, indem Sie von MACH1 aus den Befehl db2admin drop ausführen. (Dieser Schritt wäre nur erforderlich, wenn auf beiden Maschinen ein Verwaltungs-Server vorhanden wäre.)
  4. Stellen Sie den Namen des Verwaltungs-Servers fest, indem Sie von MACH0 aus den Befehl db2admin ausführen. (Der Standardname ist DB2DAS00.)
  5. Verwenden Sie das Dienstprogramm DB2MSCS, um die Unterstützung für die Funktionsübernahme des Verwaltungs-Servers einzurichten. Dies zieht die Erstellung einer DB2-Ressource auf MSCS namens DB2DAS00 nach sich, die Abhängigkeiten von der IP-Ressource und den Plattenressourcen (DISK) hat. (Wenn Sie eine Konfiguration zur gegenseitigen Übernahme haben, würden Sie die Ressource in die Gruppe stellen, die die DB2-Ressource für NODE0 enthält.) Diese Ressource wird als die MSCS-Ressource verwendet, die den Verwaltungs-Server unterstützt. Die Datei DB2MSCS.ADMIN sähe wie folgt aus:
       #
       # db2mscs.admin für Verwaltungs-Server
       # run db2mscs -f:db2mscs.admin
       #
       DB2_INSTANCE=DB2DAS00
       CLUSTER_NAME=CLUSTERA
       DB2_LOGON_USERNAME=db2admin
       DB2_LOGON_PASSWORD=db2admin
       # den Verwaltungs-Server in die gleiche Gruppe wie DB2 Knoten 0 stellen
       GROUP_NAME=DB2NODE0 (1)
       DISK_NAME=DISK E:
       INSTPROF_DISK=DISK E:
       IP_NAME= IP-Adresse für Verwaltungs-Server
       IP_ADDRESS=9.9.9.8
       IP_SUBNET=255.255.255.0
       IP_NETWORK=Ethernet
    

    (1)
    Diese Gruppe kann die gleiche wie die vorhandene sein. Auf diese Weise benötigen Sie keine zusätzliche Platte für das Exemplarprofilverzeichnis.
  6. Führen Sie auf MACH1 den folgenden Befehl aus, um DB2DAS00 als den Verwaltungs-Server zu definieren:
       db2set -g db2adminserver=DB2DAS00
    
  7. Ändern Sie auf MACH0 die Startmerkmale von DB2DAS00 über das Programm Services, so daß er manuell, und nicht automatisch, gestartet wird, da DB2DAS00 nun von MSCS gesteuert wird.

Wenn der Verwaltungs-Server für die Funktionsübernahme eingerichtet ist, sollten alle fernen Zugriffe eine MSCS-IP-Ressource zur Kommunikation mit dem Verwaltungs-Server verwenden. Der Verwaltungs-Server hat nun die folgenden Merkmale:

Einschränkungen und Bedingungen

Bei der Ausführung von DB2 in einer MSCS-Umgebung gibt es folgende Einschränkungen:


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