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.
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 |
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:
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.
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.
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. |
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.
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.
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.
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.
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.
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.
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.