Home 
ORDIX News 4/2008 Datenbanken
ORDIX News 4/2008 Datenbanken
ORDIX News 4/2008 Datenbanken
durch den Einsatz von TSA den Failover bei HADR automatisieren wollen.
| TSA IBM Tivoli System Automation |
| HADR High Availability Disaster Recovery |
Die meisten Cluster-Software Produkte arbeiten nach einem ähnlichen Prinzip. Tivoli System Automation bildet da keine Ausnahme. Auf jedem am Cluster beteiligten Rechner (Knoten) muss TSA installiert sein. In der Konfiguration wird vorgegeben, welche Knoten an dem Cluster beteiligt sind. Die von der TSA verwalteten Ressourcen werden in so genannten Resource Groups zusammengefasst. Zusätzlich gibt es Skripte, mit denen die Ressourcen auf einem Knoten deaktiviert und auf einem anderen Knoten aktiviert werden können.
Die TSA-Komponenten auf jedem Knoten prüfen regelmäßig über das Netzwerk, ob die anderen Knoten des Clusters noch vorhanden sind. Stellt ein Knoten dabei fest, dass der andere Knoten ausgefallen ist, führt er die Skripte zur Aktivierung der Resource Groups aus. Dabei übernimmt er die Ressourcen des anderen Knotens und bietet somit die Dienste des ausgefallenen Knotens an.
Um zu verhindern, dass bei einem Netzwerkausfall alle Knoten versuchen, die Ressourcen gleichzeitig zu starten, wird zusätzlich ein Quorum Device definiert. Dahinter verbirgt sich eine Netzwerkadresse, die, wenn das Netzwerk zur Verfügung steht, von allen Knoten "angepingt" werden kann. Stellt TSA auf einem Knoten fest, dass der andere Knoten und das Quorum Device nicht zu erreichen sind, werden keine Aktionen ausgeführt. TSA geht dann davon aus, dass der Knoten selbst ein Problem hat.
Unter den Betriebssystemen AIX und Linux bietet der DB2-Installer die zusätzliche Option "Installation SA MP Base Component" an. Ist diese Option bei der Installation von DB2 aktiviert, wird neben DB2 auch TSA installiert und so konfiguriert, dass die Grundkomponenten von TSA aktiviert sind.
Soll TSA nachträglich installiert bzw. deinstalliert werden, stehen dafür die beiden Skripte installSAM und uninstallSAM zur Verfügung. Sie sind auf dem Installationsmedium im Verzeichnis db2/<Platform>/tsamp zu finden.
In der Version 9.1 war TSA zwar auch schon Bestandteil von DB2, musste aber mit den üblichen TSA-Kommandos konfiguriert werden. Einige Konfigurationseinstellungen mussten daher bei TSA und DB2 konfiguriert werden.
Dies hat IBM ab der DB2 Version 9.5 mit dem DB2 High Availability Instance Configuration Utility sehr vereinfacht. Die komplette Konfiguration wird mit dem Skript db2haicu vorgenommen. Das textbasierte Werkzeug für die Konfiguration und Administration führt alle notwendigen Anpassungen an der Datenbankmanager- und der Cluster-Konfiguration durch. Dabei müssen keine TSA- oder DB2-Kommandos verwendet werden.
Voraussetzung für den Einsatz von TSA ist eine funktionsfähige HADR-Umgebung und die Installation von TSA auf den beiden Datenbank-Servern. Die Primär- und die Standby-Datenbank müssen sich im Peer-Status befinden.
Bevor das Tool db2haicu genutzt werden kann, muss es initialisiert werden. Dazu muss der Benutzer root auf beiden Datenbankservern das Kommando preprpnode aufrufen (siehe Abbildung 1). Dadurch wird eine TSA Domain angelegt.
Weiterhin ist es wichtig, dass der DB2-Verwaltungsserver angelegt und gestartet ist.
|
Die Konfiguration des Clusters mit dem Skript db2haicu ist auf beiden Rechnern des Clusters vorzunehmen. Der erste Schritt ist auf dem Rechner mit der Standby-Datenbank auszuführen: Hierzu ruft der Instanz-Owner das Script db2haicu auf.
Der Reihe nach werden die Fragen zum Anlegen der Domain, dem Domain-Namen, der Anzahl der Knoten im Cluster, die Namen der Rechner im Cluster, IP-Adresse und Subnetz des Quorum Device und optional zur virtuellen IP-Adresse beantwortet.
Danach ist das Skript auf dem Standby-System abzubrechen und auf dem Primärsystem fortzusetzen. Dies erfolgt durch Eingabe von 2 (No) auf die Frage, ob der automatisierte Failover für die Datenbank eingerichtet werden soll (siehe Abbildung 2).
|
Die Konfiguration wird fortgesetzt, indem der Instanz-Owner auf dem Primärrechner das Skript db2haicu startet. Im Dialog werden hier nur die Fragen nach dem Cluster-Manager beantwortet und danach das automatische Failover für die Datenbank eingerichtet. Damit ist die Konfiguration abgeschlossen. Die angelegten Ressourcen lassen sich mit dem Kommando lssam von der Kommandozeile anzeigen.
Die Ergänzung von HADR durch TSA ermöglichte schon ab der Version 9.1 einen automatischen Failover. Mit dem DB2 High Availability Instance Configuration Utility ist es jetzt auch möglich, die Konfiguration auf einfache Art und Weise vorzunehmen, ohne sich tief mit TSA beschäftigen zu müssen.
Holger Demuth (info@ordix.de).