DB2 Universal Database - Systemverwaltung


Sun Cluster 2.2

Sun Cluster 2.2 (SC2.2) ist das Produkt zur Clusterung und Implementierung hoher Verfügbarkeit von Sun Microsystems. SC2.2 unterstützt bis zu vier Maschinen in einem einzigen Cluster. Bei Einsatz von vier Ultra Enterprise 10000s kann ein Cluster bis zu 256 CPUs und 256 GB RAM besitzen.

Unterstützte Systeme


System UltraSPARC Speicherkapazität E/A
Ultra Enterprise 1 1 64 MB - 1 GB 3 SBus
Ultra Enterprise 2 1-2 64 MB - 2 GB 4 SBus
Ultra Enterprise 450 1-4 32 MB - 4 GB 10 PCI
Ultra Enterprise 3000 1-6 64 MB - 6 GB 9 SBus
Ultra Enterprise 4000 1-14 64 MB - 14 GB 21 SBus
Ultra Enterprise 5000 1-14 64 MB - 14 GB 21 SBus
Ultra Enterprise 6000 1-30 64 MB - 30 GB 45 SBus
Ultra Enterprise 10000 1-64 512 MB - 64 GB 64 SBus

Agenten

Die Sun Cluster-Software enthält eine Anzahl von Agenten für hohe Verfügbarkeit (HA-Agenten), die unterstützt und mit dem Produkt SC2.2 ausgeliefert werden. Andere HA-Agenten, wie zum Beispiel der für DB2, werden außerhalb von Sun entwickelt und nicht zusammen mit der Sun Cluster-Software ausgeliefert. Der HA-Agent für DB2 gehört zum Lieferumfang von DB2 und wird von IBM unterstützt.

Die Sun Cluster-Software arbeitet mit hochverfügbaren Datenbankservices, indem sie eine Möglichkeit gibt, Methoden (Prozeduren (Skripte) bzw. Programme) zu registrieren, die verschiedenen Komponenten der Sun Cluster-Software entsprechen. Mit Hilfe dieser Methoden kann die Software von SC2.2 einen Datenbankservice steuern, ohne über eingehende Kenntnisse über ihn zu verfügen. Zu diesen Methoden gehören folgende:

START
Dient zum Starten von Teilen des Datenbankservice, bevor die logischen Netzschnittstellen online sind.

START_NET
Dient zum Starten von Teilen des Datenbankservice, nachdem die logischen Netzschnittstellen online gebracht sind.

STOP
Dient zum Stoppen von Teilen des Datenbankservice, nachdem die logischen Netzschnittstellen offline genommen wurden.

STOP_NET
Dient zum Stoppen von Teilen des Datenbankservice, bevor die logischen Netzschnittstellen offline genommen werden.

ABORT
Wie die Methode STOP, jedoch wird sie ausgeführt unmittelbar, bevor eine Maschine durch die Cluster-Software heruntergefahren wird. In diesem Fall ist der einwandfreie Zustand der Maschine fraglich, und ein Datenbankservice könnte noch einige "letzte" Anforderungen ausführen, bevor die Maschine heruntergefahren wird. Wird ausgeführt, nachdem die logischen Netzschnittstellen offline genommen wurden.

ABORT_NET
Wie die Methode ABORT, allerdings wird sie ausgeführt, bevor die logischen Netzschnittstellen offline genommen werden.

FM_INIT
Dient zur Initialisierung von Fehlermonitoren.

FM_START
Dient zum Starten von Fehlermonitoren.

FM_STOP
Dient zum Stoppen von Fehlermonitoren.

FM_CHECK
Wird durch den Befehl hactl aufgerufen. Liefert den aktuellen Status des entsprechenden Datenbankservice.

Der DB2-Agent besteht aus folgenden Prozeduren: START_NET, STOP_NET, FM_START und FM_STOP. Die folgenden Prozeduren werden bei der Neukonfiguration des Clusters nicht ausgeführt: ABORT, ABORT_NET und FM_CHECK.

Ein Agent für hohe Verfügbarkeit besteht aus mindestens einer dieser Methoden. Die Methoden werden bei SC2.2 durch den Befehl hareg registriert. Nach der Registrierung ruft die Sun Cluster-Software die entsprechende Methode auf, um den Datenbankservice zu steuern.

Es ist sehr wichtig, zu beachten, daß die Methoden ABORT und STOP eines Service möglicherweise nicht aufgerufen werden. Diese Methoden sind zum kontrollierten Herunterfahren eines Datenbankservice gedacht, und der Datenbankservice muß wiederhergestellt werden können, wenn eine Maschine ausfällt, ohne diese Methoden aufzurufen.

Weitere Informationen finden Sie in der Sun Cluster-Dokumentation.

Logische Hosts

Die SC2.2-Software arbeitet mit dem Konzept eines logischen Hosts. Ein logischer Host besteht aus einer Gruppe von Platten und einer oder mehreren öffentlichen Netzschnittstellen. Ein hochverfügbarer Datenbankservice wird einem logischen Host zugeordnet und benötigt die Platten, die in den Plattengruppen des logischen Hosts sind. Logische Hosts können auf verschiedenen Maschinen im Cluster untergebracht sein und sich die CPUs und den Hauptspeicher der Maschine "entleihen", auf der sie aktiv sind.

Logische Netzschnittstellen

Ebenso wie andere auf UNIX basierende Betriebssysteme verfügt Solaris über die Möglichkeit, neben der primären IP-Adresse für eine Netzschnittstelle zusätzliche IP-Adressen zu besitzen. Die zusätzlichen IP-Adressen befinden sich auf einer logischen Schnittstelle in der gleichen Weise, wie sich die primäre IP-Adresse auf der physischen Netzschnittstelle befindet. Das folgende Beispiel zeigt die logischen Schnittstellen auf zwei Maschinen in einem Cluster. Es gibt zwei logische Hosts, die sich zur Zeit beide auf der Maschine "thrash" befinden.

   scadmin@crackle(202)# netstat -in
   Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
   lo0 8232 127.0.0.0 127.0.0.1 289966 0 289966 0 0 0
   hme0 1500 9.21.55.0 9.21.55.98 121657 6098 764122 0 0 0
   scid0 16321 204.152.65.0 204.152.65.1 489307 0 476479 0 0 0
   scid0:1 16321 204.152.65.32 204.152.65.33 0 0 0 0 0 0
   scid1 16321 204.152.65.16 204.152.65.17 347317 0 348073 0 0 0
 
     1. lo0 ist die loopback-Schnittstelle
     2. hme0 ist die öffentliche Netzschnittstelle (ethernet)
     3. scid0 ist die erste private Netzschnittstelle (SCI oder Scalable
        Coherent Interface)
     4. scid0:1 ist eine logische Netzschnittstelle, die von der
        Sun Cluster-Software intern verwendet wird
     5. scid1 ist die zweite private Netzschnittstelle
 
   scadmin@thrash(203)# netstat -in
   Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
   lo0 8232 127.0.0.0 127.0.0.1 1128780 0 118780 0 0 0
   hme0 1500 9.21.55.0 9.21.55.92 1741422 5692 757127 0 0 0
   hme0:1 1500 9.21.55.0 9.21.55.109 0 0 0 0 0 0
   hme0:2 1500 9.21.55.0 9.21.55.110 0 0 0 0 0 0
   scid0 16321 204.152.65.0 204.152.65.2 476641 0 489476 0 0 0
   scid0:1 16321 204.152.65.32 204.152.65.34 0 0 0 0 0 0
   scid1 16321 204.152.65.16 204.152.65.18 348199 0 347444 0 0 0
 
     1. hme0:1 ist eine logische Netzschnittstelle für einen logischen Host
     2. hme0:2 ist eine log. Netzschnittstelle für einen anderen log. Host

Einem logischen Host können eine oder mehrere logische Schnittstellen zugeordnet sein. Diese logischen Schnittstellen werden mit dem logischen Host von einer Maschine zur anderen versetzt und dienen dem Zugriff auf den Datenbankservice, der dem logischen Host zugeordnet ist. Da diese logischen Schnittstellen mit den logischen Hosts versetzt werden, können Clients auf den Datenbankservice unabhängig von der Maschine, auf dem er sich befindet, zugreifen.

Ein hochverfügbarer Datenbankservice sollte an die TCP/IP-Adresse INADDR_ANY gebunden werden. Dadurch wird gewährleistet, daß jede IP-Adresse auf dem System Verbindungen für den Datenbankservice empfangen kann. Wenn ein Datenbankservice statt dessen an eine bestimmte IP-Adresse gebunden wird, muß er an die logische Schnittstelle gebunden werden, die dem logischen Host zugeordnet ist, auf dem der Datenbankservice aktiv ist. Das Binden an INADDR_ANY beseitigt die Notwendigkeit, den Service an eine neue IP-Adresse zu binden, wenn eine auf dem System eintrifft, die vom Datenbankservice benötigt wird.
Anmerkung:Clients eines HA-Exemplars sollten die Datenbank mit dem Host-Namen für die logische IP-Adresse eines logischen Hosts katalogisieren. Sie sollten nie den primären Host-Namen für eine Maschine verwenden, weil es keine Garantie gibt, daß DB2 auf dieser Maschine ausgeführt wird.

Plattengruppen und Dateisysteme

Platten für einen Datenbankservice werden einem logischen Host in Gruppen (bzw. Sätzen) zugeordnet. Wenn der Cluster mit Sun StorEdge Volume Manager (Veritas) arbeitet, verwendet die Sun Cluster-Software das Veritas-Dienstprogramm "vxdg", um die Plattengruppen für jeden logischen Host zu importieren und zu deportieren. Das folgende Beispiel zeigt die Plattengruppen für zwei logische Hosts "log0" und "log1", die auf einer Maschine namens "thrash" untergebracht sind. Die Maschine mit dem Namen "crackle" beherbergt zur Zeit keine logischen Hosts.

   scadmin@crackle(206)# vxdg list
   NAME STATE ID
   rootdg enabled 899825206.1025.crackle
 
   scadmin@thrash(205)# vxdg list
   NAME STATE ID
   rootdg enabled 924176206.1025.thrash
   data0 enabled 925142028.1157.crackle=
   data1 enabled 899826248.1108.crackle

Die Plattengruppen "data0" und "data1" entsprechen jeweils den logischen Hosts "log0" und "log1". Die Plattengruppe "data0" kann von "thrash" mit folgendem Befehl deportiert werden:

   vxdg deport data0

Und mit folgendem Befehl auf "crackle" importiert werden:

   vxdg import data1

Dies wird durch die Sun Cluster-Software automatisch durchgeführt und sollte auf einem im Betrieb befindlichen Cluster nicht manuell vorgenommen werden.

Jede Plattengruppe enthält eine Anzahl von Platten, die von zwei oder mehr Maschinen im Cluster gemeinsam benutzt werden können. Ein logischer Host kann nur zu einer anderen Maschine versetzt werden, die physischen Zugriff auf die Platten in den Plattengruppen hat, die ihm zugeordnet sind.

Zwei Dateien steuern die Dateisysteme für jeden logischen Host:

   /etc/opt/SUNWcluster/conf/hanfs/vfstab.<logischer_host>
   /etc/opt/SUNWcluster/conf/hanfs/dfstab.<logischer_host>

Dabei ist logischer_host der Name des zugeordneten logischen Hosts.

Die Datei vfstab ist der Datei /etc/vfstab ähnlich, abgesehen davon, daß sie Einträge für die Dateisysteme enthält, die angehängt (mount) werden sollen, nachdem die Plattengruppen für einen logischen Host importiert wurden. Die Datei dfstab ist der Datei /etc/dfs/dfstab ähnlich, jedoch enthält sie Einträge für die Dateisysteme, die über HA-NFS für einen logischen Host exportiert werden sollen. Jede Maschine verfügt über eine eigene Kopie dieser Datei, und es sollte sorgfältig darauf geachtet werden, daß sie auf jeder Maschine im Cluster den gleichen Inhalt haben.
Anmerkung:Die Pfade für die Dateien vfstab und dfstab eines logischen Hosts sind irreführend, weil sie das Verzeichnis hanfs enthalten. Nur die Datei dfstab für einen logischen Host wird für HA-NFS verwendet. Die Datei vfstab wird verwendet, selbst wenn HA-NFS nicht konfiguriert ist.

Die folgenden Beispiele stammen aus einem Cluster, auf dem DB2 Universal Database Enterprise - Extended Edition (EEE) in einer Konfiguration zur gegenseitigen Übernahme ausgeführt wird:

   scadmin@thrash(217)# ls -l /etc/opt/SUNWcluster/conf/hanfs
   total 8
   -rw-r--r-- 1 root build 173 Apr 14 15:01 dfstab.log0
   -rw-r--r-- 1 root build 316 Apr 26 12:07 vfstab.log0
   -rw-r--r-- 1 root build 389 Apr 13 21:04 vfstab.log1
 
   scadmin@thrash(218)# cat dfstab.log0
   share -F nfs -o root=crackle:thrash:\
   jolt:bump:crackle.torolab.ibm.com:thrash.torolab.ibm.com:\
   jolt.torolab.ibm.com:bump.torolab.ibm.com /log0/home

Die Hosts, denen die Berechtigung zum Anhängen (mount) des Dateisystems /log0/home erteilt wird, stammen von allen Netzschnittstellen (logischen und physischen) auf jeder Maschine im Cluster. Die Dateisysteme werden mit Root-Berechtigung exportiert.

scadmin@thrash(220)# cat vfstab.log0
#device to mount             device  to fsck               mount       FS   fsck mount   options
#                                                          point       type pass at boot 
 
/dev/vx/dsk/data0/data1-stat /dev/vx/rdsk/data0/data1-stat /log0       ufs  2    no      -
/dev/vx/dsk/data0/vol01      /dev/vx/rdsk/data0/vol01      /log0/home  ufs  2    no      -
/dev/vx/dsk/data0/vol02      /dev/vx/rdsk/data0/vol02      /log0/data  ufs  2    no      -
 
scadmin@thrash(221)# cat vfstab.log1
#device to mount             device  to fsck               mount       FS   fsck mount   options
#                                                          point       type pass at boot
 
/dev/vx/dsk/data1/data1-stat /dev/vx/rdsk/data1/data1-stat /log1       ufs  2    no      -
/dev/vx/dsk/data1/vol01      /dev/vx/rdsk/data1/vol01      /log1/home  ufs  2    no      -
/dev/vx/dsk/data1/vol02      /dev/vx/rdsk/data1/vol02      /log1/data  ufs  2    no      -
/dev/vx/dsk/data1/vol03      /dev/vx/rdsk/data1/vol03      /log1/data1 ufs  2    no      -

Die Datei vfstab.log0 enthält drei gültige Einträge für Dateisysteme unter dem Verzeichnis /log0. Beachten Sie, daß die Dateisysteme für den logischen Host log0 logische Datenträgereinheiten (volume devices) verwenden, die Teil der Plattengruppe data0 sind, die dem logischen Host zugeordnet ist.

Die Dateisysteme in den Dateien vfstab werden der Reihe nach von oben nach unten angehängt (mount), so daß es wichtig ist, sicherzustellen, daß die Dateisysteme in der richtigen Reihenfolge aufgelistet sind. Dateisysteme, die unterhalb eines bestimmten Dateisystems angehängt werden, müssen unter diesem Dateisystem aufgelistet werden. Die tatsächlich für einen logischen Host benötigten Dateisysteme hängen von den Anforderungen des Datenbankservice ab und werden sich von diesen Beispielen erheblich unterscheiden.

Während einer Funktionsübernahme ist die SC2.2-Software dafür zuständig, zu gewährleisten, daß die Plattengruppen und logischen Schnittstellen, die einem logischen Host zugeordnet sind, dem Host im Cluster von Maschine zu Maschine folgen. Der hochverfügbare Datenbankservice erwartet, daß ihm zumindest diese Ressourcen auf einem neuen System nach einer Funktionsübernahme zur Verfügung stehen. Tatsächlich ist es so, daß die meisten Datenbankservices selbst gar nicht erkennen, daß sie hochverfügbar sind, so daß diese Ressourcen auch nach einer Funktionsübernahme als exakt die gleichen erscheinen müssen.

Steuermethoden

Die Steuermethoden werden mit folgendem Befehl registriert:

   hareg(1m)

Wenn ein HA-Service registriert ist, ist SC2.2 dafür zuständig, die Methoden, die für den HA-Service registriert wurden, zu gegebener Zeit während einer Änderung der Clusterkonfiguration oder einer Funktionsübernahme aufzurufen.

Während einer Änderung der Clusterkonfiguration (kontrollierten Funktionsübernahme) finden die folgenden Aktionen (in der angegebenen Reihenfolge) statt. Die Aktionen vor Schritt 5c werden nicht durchgeführt, falls die Maschine abstürzt. (Weitere Informationen zur Änderung der Clusterkonfiguration finden Sie in der SC2.2-Dokumentation.)

  1. Methode FM_STOP wird ausgeführt.
  2. Methode STOP_NET wird ausgeführt.
  3. Logische Schnittstellen für den logischen Host werden offline gebracht.
       - ifconfig hme0:1 0.0.0.0 down
  4. Methode STOP wird ausgeführt.
  5. Plattengruppen und Dateisysteme werden versetzt.
       a. Abhängen von Dateisystemen des logischen Hosts.
       b. vxdg deportiert Plattengruppen auf einer Maschine.
 
  - - Nur die folgenden Schritte werden ausgeführt, wenn eine Maschine abstürzt - -
 
       c. vxdg importiert Plattengruppen auf der anderen Maschine.
       d. Ausführen von fsck für Dateisysteme des logischen Hosts.
       e. Anhängen (Mount) der Dateisysteme des logischen Host.
  6. Methode START wird ausgeführt.
  7. Logische Schnittstellen für den logischen Host werden online gebracht.
       - ifconfig hme0:1 <ip address> up
  8. Methode START_NET wird ausgeführt.
  9. Methode FM_INIT wird ausgeführt.
 10. Methode FM_START wird ausgeführt.

Die Steuermethoden werden mit den folgenden Befehlszeilenparametern ausgeführt:

   METHODE <untergebrachte logische Hosts> <nicht untergebrachte logische Hosts> <Zeitlimit>

Der erste Parameter ist eine durch Kommas getrennte Liste logischer Hosts, die momentan auf der Maschine untergebracht sind, und der zweite Parameter eine durch Kommas getrennte Liste logischer Hosts, die nicht auf der Maschine untergebracht sind. Der letzte Parameter ist ein Zeitlimit für die Methode, d. h. die Zeit, die die Methode aktiv sein kann, bevor die SC2.2-Software sie abbricht.

Konfiguration von Platten und Dateisystemen

SC2.2 unterstützt zwei Datenträgermanager: Sun StorEdge Volume Manager (Veritas) und Solstice Disk Suite. Obwohl beide gut funktionieren, besitzt StorEdge Volume Manager einige Vorteile in einer Clusterumgebung. In einigen Clusterkonfigurationen kann die Controllernummer für eine Platteneinheit von Maschine zu Maschine im Cluster unterschiedlich sein. Wenn sich eine Controllernummer unterscheidet, unterscheiden sich auch die Pfade für die Platteneinheiten für den Controller. Da Disk Suite direkt mit den Pfaden der Plattengeräte arbeitet, funktioniert das Produkt in diesem Fall nicht gut. StorEdge Volume Manager arbeitet hingegen mit den Platten selbst, unabhängig von der Controllernummer, und wird durch unterschiedliche Controllernummern nicht beeinträchtigt.

Da das Ziel von HA in einer Erhöhung der Verfügbarkeit für einen Datenbankservice liegt, spielt es eine wichtige Rolle, sicherzustellen, daß alle Dateisysteme und Platteneinheiten gespiegelt werden oder in einer RAID-Konfiguration angeordnet sind. Dadurch werden Funktionsübernahmen aufgrund einer ausgefallenen Platte vermieden und die Stabilität des Clusters erhöht.

HA-NFS

DB2 UDB EEE erfordert ein gemeinsam benutztes Dateisystem, wenn ein Exemplar über mehrere Maschinen konfiguriert wird. Eine typische DB2 UDB EEE-Konfiguration besitzt ein Ausgangsverzeichnis (home), das aus einer Maschine über NFS exportiert wird und auf allen Maschinen, die an dem EEE-Exemplar beteiligt sind, angehängt wird. Bei einer Konfiguration zur gegenseitigen Übernahme ist DB2 UDB EEE davon abhängig, daß HA-NFS ein gemeinsam benutztes, hochverfügbares Dateisystem bereitstellt. Einer der logischen Hosts exportiert ein Dateisystem durch HA-NFS, und jede Maschine im Cluster hängt das Dateisystem als Ausgangsverzeichnis (home) des EEE-Exemplars an. Weitere Informationen zu HA-NFS finden Sie in der Sun Cluster-Dokumentation.

Die Dienstprogramme cconsole und ctelnet

Zwei nützliche Dienstprogramme, die mit SC2.2 geliefert werden, sind cconsole und ctelnet. Diese Dienstprogramme können dazu verwendet werden, einen einzelnen Befehl an mehrere Maschinen in einem Cluster gleichzeitig abzusetzen. Wenn eine Konfigurationsdatei mit Hilfe dieser Dienstprogramme editiert wird, ist sichergestellt, daß sie auf allen Maschinen im Cluster gleich bleiben wird. Diese Dienstprogramme können außerdem dazu genutzt werden, Software in exakt der gleichen Weise auf jeder Maschine zu installieren. Weitere Informationen zu diesen Dienstprogrammen finden Sie in der Sun Cluster-Dokumentation.

Campus-Clusterung und kontinentale Clusterung

Ein Cluster wird als Campus-Cluster bezeichnet, wenn sich die zugehörigen Maschinen nicht im selben Gebäude befinden. Ein Campus-Cluster ist nützlich, um das Gebäude an sich als einzelnen Fehlerpunkt auszuschließen. Wenn sich zum Beispiel die Maschinen im Cluster alle im selben Gebäude befinden und das Gebäude abbrennt, ist der gesamte Cluster betroffen. Befinden sich die Maschinen hingegen in verschiedenen Gebäuden und ein Gebäude brennt ab, bleibt der Cluster bestehen.

Ein kontinentaler Cluster ist ein Cluster, dessen Maschinen über verschiedene Städte verteilt sind. In diesem Fall liegt das Ziel darin, die geografische Region als einzelnen Fehlerpunkt auszuschließen. Diese Art von Cluster bietet einen Schutz gegen Katastrophen wie Erdbeben und Tsunami-Wellen.

Zur Zeit kann Sun Cluster Maschinen unterstützen, die bis zu 10 km (ca. 6 Meilen) auseinander liegen. Dies macht ein Campus-Clusterung zu einer funktionsfähig Option für Benutzer, die Hochgeschwindigkeitsverbindungen zwischen zwei verschiedenen Standorten benötigen. Ein Cluster erfordert zwei private wechselseitige Verbindungen und eine Anzahl von Glasfaserkabeln für die gemeinsam genutzten Platten. Die Kosten von Hochgeschwindigkeitsverbindungen zwischen zwei Standorten könnten die Vorteile relativieren.

Häufige Probleme

Die SC2.2-Software verwendet Cluster Configuration Database bzw. CCD(4), um eine einziges clusterweites Repository für die Clusterkonfiguration bereitzustellen. CCD besitzt eine private API und ist unter dem Verzeichnis /etc/opt/SUNWcluster/conf gespeichert. In seltenen Fällen kann CCD die Synchronisierung verlieren und muß dann eventuell repariert werden. Die beste Methode zur Reparatur von CCD in diesem Fall ist die Wiederherstellung von CCD von einer Sicherungskopie.

Zur Sicherung von CCD fahren Sie die Clustersoftware auf allen Maschinen im Cluster herunter, packen das Verzeichnis /etc/opt/SUNWcluster/conf mit "tar" zusammen und speichern die tar-Datei an einem sicheren Ort. Wenn die Clustersoftware bei der Erstellung der Sicherung nicht heruntergefahren ist, haben Sie vielleicht Schwierigkeiten bei der Wiederherstellung von CCD. Stellen Sie sicher, daß die Sicherungskopie auf aktuellem Stand gehalten wird, indem Sie die Sicherung nach jeder Änderung der Clusterkonfiguration aktualisieren. Zur Wiederherstellung von CCD fahren Sie die Clustersoftware auf allen Maschinen im Cluster herunter, versetzen (move) das Verzeichnis conf nach conf.old und entpacken (untar) die Sicherungskopie. Der Cluster kann anschließend mit der wiederhergestellten CCD-Datenbank gestartet werden.


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