DB2 UDB im Microsoft Cluster

Datenbanksysteme im Cluster zu installieren und zu betreiben, ist häufig eine Kunst für sich. Für die Integration von DB2 UDB bietet IBM vorgefertigte Lösungen für verschiedene Cluster Systeme. Dieser Artikel zeigt, wie leicht sich DB2 auf dem Cluster Server von Microsoft integrieren lässt.

Der Microsoft Cluster Server

Der Microsoft Cluster Server (MSCS) ist eine Software, die es ermöglicht, Cluster mit 2 bis 4 Knoten unter dem Windows Betriebssystem aufzubauen.

Der MSCS verwaltet die im Cluster definierten Ressourcen und ist in der Lage, diese beim Ausfall eines Rechners auf einen anderen Knoten des Clusters zu übertragen und sie dort zu starten.

Dabei ist jeder Knoten des Clusters mit 2 Netzwerkkarten ausgestattet. Über die eine Netzwerkkarte greifen die Clients auf den Rechner zu (öffentliches Netz). Die andere ist für die interne Kommunikation im Cluster reserviert (privates Netz). Neben der physikalischen Netzwerkadresse der öffentlichen Netzwerkkarte wird vom Cluster noch eine virtuelle Adresse verwaltet. Diese ist nur auf dem jeweils aktiven Knoten des Clusters gültig.

Jeder Knoten des Clusters verfügt über eine lokale Platte. Auf ihr sind das Betriebssystem und die Anwendungen (z. B. DB2 UDB) installiert. Über einen gemeinsamen Speicherbus kann jeder Knoten auf die gemeinsam genutzten Platten zugreifen. Auf diesen Platten werden die Daten (Instanzen und Datenbanken) gespeichert. Durch die Cluster Software ist sichergestellt, dass immer nur ein Knoten Zugriff auf eine gemeinsam genutzte Platte hat.

Funktionsweise des MSCS

Die kleinsten Einheiten, die der MSCS verwalten kann, werden als Ressourcen bezeichnet. Dabei kann es sich z. B. um physische Platten, Netzwerkadressen, Netzwerknamen oder generische Dienste handeln. Alle für eine Anwendung notwendigen Ressourcen werden in einer MSCS-Gruppe zusammengefasst.

Zwischen den Ressourcen können auch Abhängigkeiten definiert werden. Damit wird sichergestellt, dass z. B. die DB2-Instanz nur dann gestartet wird, wenn auch die virtuelle IP-Adresse auf dem entsprechenden Knoten des Clusters verfügbar ist.

DB2 und MSCS

Zu beachten ist, dass nur die folgenden drei DB2 UDB Editionen MSCS unterstützen: Workgroup Server Edition, Enterprise Server Edition (DB2 ESE) und Connect Enterprise Edition (DB2 CEE).

Die DB2 Software wird auf jedem Knoten des Clusters auf einer lokalen Platte installiert. Die Daten der Instanzen und Datenbanken befinden sich auf den gemeinsam genutzten Platten des Clusters. Dabei gibt es allerdings eine Einschränkung.

Da der MSCS keine Raw-Devices unterstützt, ist es nicht möglich, Raw-Devices für DB2 zu verwenden.

MSCS-Ressourcen für DB2

Für DB2 wird der Ressourcentyp „DB2“ im MSCS erstellt. Dieser verwaltet die DB2-Instanz. Der Name der DB2-Ressource ist dabei der Name der DB2-Instanz. Bei partitionierten Datenbanken wird für jede Partition eine eigene DB2-Ressource angelegt. Der Name setzt sich dann aus dem Namen der Instanz und der Nummer der Partition zusammen.

Das Anlegen des Ressourcentyps wird von DB2 vorgenommen. Manuelle Konfigurationen im MSCS sind dazu nicht notwendig.

DB2-Gruppen

Alle für eine DB2-Instanz notwendigen Ressourcen werden zu einer DB2-Gruppe zusammengefasst. Die Ressourcen einer Gruppe werden dann vom MSCS auf einem Knoten des Clusters gestartet und im Fehlerfall auf einen anderen Knoten des Clusters übertragen.

Für eine nicht partitionierte Instanz besteht eine Gruppe aus den folgenden Ressourcen:

• Die DB2-Ressource verwaltet die DB2-Instanz und ist von allen folgenden Ressourcen abhängig.
• Die Ressource „IP-Adresse“ verwaltet die virtuelle Netzwerkadresse. Über diese Adresse greifen die Clients auf die Datenbank zu.
• Die optionale Ressource „Netzwerkname“ verwaltet den Netzwerknamen, über den Clients auf die Datenbank zugreifen. Diese Ressource ist von der Ressource „IP-Adresse“ abhängig und entsprechend mit ihr verknüpft.
• Mindestens eine Ressource „Physische Platte“ verwaltet den Plattenplatz, auf dem Instanzen und Datenbanken ihre Daten ablegen.

Konfigurationstypen

Im MSCS gibt es für DB2 zwei unterschiedliche Konfigurationen: den Bereitschaftsmodus und die gegenseitige Übernahme.

Beim Bereitschaftsmodus ist ein Knoten des Clusters die aktive Maschine. Auf dieser Maschine läuft das Datenbanksystem. Der andere Knoten befindet sich im Bereitschaftsmodus und hat keine aktive Funktion.

Beim Ausfall der aktiven Maschine oder einer Ressource dieser Maschine werden alle Ressourcen der Gruppe auf dem aktiven Knoten gestoppt, auf den anderen Knoten übertragen und dort gestartet.

Bei der gegenseitigen Übernahme sind alle Knoten des Clusters aktiv. Auf jeder Maschine läuft ein eigenes Datenbanksystem.

Bei Ausfall eines Knotens wird dessen Funktion (Datenbanksystem) auf den anderen Knoten des Clusters übertragen. Auf diesem Knoten laufen dann zwei Datenbanksysteme. Dabei ist dafür zu sorgen, dass die Rechner über genügend Ressourcen (Prozessoren, Hauptspeicher) für beide Datenbanksysteme verfügen.

Das Kommando

Mit Hilfe des Kommandos db2mscs wird eine DB2-Instanz in ein Microsoft Cluster aufgenommen.

Dabei werden im MSCS alle notwendigen Ressourcen, Gruppen und Abhängigkeiten angelegt. Einträge der lokalen Registry, die für die Instanz von Bedeutung sind, werden in den vom Cluster verwalteten Teil der Registry übertragen. Das lokale Verzeichnis der Instanz wird auf die gemeinsam genutzte Platte übertragen.

Datenbanken werden von dem Kommando nicht auf die gemeinsam genutzte Platte übertragen. Dies muss nachträglich manuell vorgenommen werden.

Was das Kommando db2mscs tatsächlich ausführt, wird über eine Konfigurationsdatei gesteuert. Der Name der Datei wird dem Kommando beim Aufruf mit der Option -f mitgegeben. Das Kommando muss vom „Owner“ der zu übertragenden Instanz ausgeführt werden.

Die zweite Funktion des Kommandos db2mscs dient dazu, eine Cluster-Instanz wieder in eine „normale“ Instanz umzuwandeln. Dazu wird dem Kommando mit der Option -u der Name der Instanz mitgegeben.

Die DB2MSCS-Konfigurationsdatei

In der Konfigurationsdatei werden die für den Cluster notwendigen Parameter definiert. Die für ein einfaches Beispiel notwendigen Parameter sind in Abbildung 1 beschrieben.

Abb. 1: Einige der Parameter aus der DB2MSCS-Konfigurationsdatei.

Hot Standby - Single Partition

Bei dieser Beispielkonfiguration wird ein Cluster aus zwei Knoten und einer DB2-Instanz für den Hot Standby Modus konfiguriert (siehe Abbildung 2). Dabei sind folgende Schritte notwendig:

Abb. 2: Hot Standby: Der zweite Rechner steht für den Fall der Übernahme bereit.

• Auf beiden Rechnern ist der MSCS zu installieren und zu konfigurieren.
• Auf beiden Knoten des Clusters ist die DB2 Software zu installieren.
• Die DB2-Instanz, die im Cluster aufgenommen werden soll, ist auf einem der beiden Knoten anzulegen. Auf dem anderen Knoten darf diese Instanz nicht vorhanden sein. Die Startart der zur Instanz gehörenden Dienste ist auf „manuell“ umzustellen, da die Instanz über den MSCS gestartet wird.

Die MSCS-Konfigurationsdatei db2mscs.cfg ist wie folgt zu erstellen:

DB2_INSTANCE=DB2
CLUSTER_NAME=DB2CL
GROUP_NAME=DB2 Group 0
IP_NAME=DB2 IP
IP_ADDRESS=192.168.6.211
IP_SUBNET=255.255.255.0
IP_NETWORK=Public Cluster Connection
NETNAME_NAME=Network Name for DB2
NETNAME_VALUE=DB2SRV
NETNAME_DEPENDENCY=DB2 IP
DISK_NAME=Disk E: Q:
INSTPROF_PATH=E:\db2profs

Aufruf des Kommandos

Mit dem Kommando db2mscs wird die Instanz dann in den Cluster integriert. Dies erfolgt mit folgendem Aufruf:

C:\>db2mscs -f:db2mscs.cfg
DB21500I The DB2MSCS command complete successfully.

Zur Überprüfung kann der Inhalt der Variablen db2instprof aus der DB2-Profileregistry angezeigt und das Kommando db2ilist aufgerufen werden:

C:\>db2set db2instprof
:w E:\DB2PROFS

Die Variable db2instprof sollte den in der Datei db2mscs.cfg eingetragenen Wert haben.

C:\>db2ilist
DB2 C : DB2CL

Hinter dem Namen der DB2-Instanz steht jetzt „C:“ und der Name des Clusters, auf dem die Instanz jetzt läuft.

Manuelle Nacharbeiten

Nachdem die DB2-Instanz im Cluster läuft, sind einige manuelle Tätigkeiten notwendig. Mit dem Cluster Administrator (siehe Abbildung 3) müssen die „Preferred Owner“ der neuen Gruppe eingetragen werden. Dort sind alle Knoten des Clusters einzutragen, auf denen die DB2-Instanz laufen soll. Dabei ist die Reihenfolge der Einträge zu beachten.

Danach sind neue Datenbanken anzulegen oder vorhandene auf die Instanz im Cluster zu übertragen. Dabei ist jeweils darauf zu achten, dass die Datenbank auf dem gemeinsam genutzten Laufwerk angelegt wird. Vorhandene Datenbanken werden über ein umgeleitetes Wiederherstellen (Redirected Restore) auf die gemeinsam genutzten Laufwerke übertragen.

Abb. 4: Gegenseitige Übernahme: Auf beiden Rechnern des Clusters läuft eine DB2-Instanz. Im Falle der Übernahme laufen beide Instanzen auf einem Rechner.

Gegenseitige Übernahme

Bei der Konfiguration des Clusters als gegenseitige Übernahme ist auf jedem Knoten des Clusters eine DB2-Instanz aktiv (siehe Abbildung 4). Die Vorgehensweise für den ersten Knoten ist die gleiche wie bei der Hot Standby Konfiguration. Zusätzlich ist dann noch die Instanz auf dem zweiten Knoten in das Cluster zu überführen. Dazu wird mindestens eine zusätzliche, gemeinsam genutzte Platte benötigt.

Die MSCS-Konfigurationsdatei db2mscs.cfg ist für den zweiten Knoten wie folgt zu erstellen:

DB2_INSTANCE=DB3
CLUSTER_NAME=DB2CL
GROUP_NAME=DB2 Group 1
IP_NAME=DB3 IP
IP_ADDRESS=192.168.6.212
IP_SUBNET=255.255.255.0
IP_NETWORK=Public Cluster Connection
NETNAME_NAME=Network Name for DB3
NETNAME_VALUE=DB3SRV
NETNAME_DEPENDENCY=DB3 IP
DISK_NAME=Disk F:
INSTPROF_PATH=F:\db2profs

Die manuellen Nacharbeiten für beide Knoten sind die gleichen wie bei der Hot Standby Konfiguration.

Fazit

Das Hauptproblem bei der Integration von DB2 UDB in ein MSCS ist die Konfigurationsdatei. Wenn man aus der Vielzahl der möglichen Parameter die herausgesucht hat, die wirklich verwendet werden, ist der Rest fast ein Kinderspiel. Die Beispiele in diesem Artikel sollten dabei sehr hilfreich sein.

Holger Demuth (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen