GPFS-Dateisysteme in der Hochverfügbarkeitskonfiguration

GPFS-Software (IBM® General Parallel File System) wird für die gemeinsame Nutzung von Dateisystemen über das gesamte System verwendet. Die Hochverfügbarkeitskonfiguration (High Availability - HA) umfasst redundante GPFS-NSD-Server (Network Shared Disk) und erzwingt Abhängigkeiten zwischen HA-Ressourcen und GPFS-Dateisystemen.

Im System sind mehrere GPFS-Cluster definiert:

GPFS-Management-Cluster
Dieser GPFS-Cluster wird MANAGEMENT.GPFS genannt und enthält den Management-Host und den Standby-Management-Host. Er enthält die für die Warehouse-Tools und den Datenbankleistungsmonitor erforderlichen Dateisysteme und hängt die clusterweiten Dateisysteme (/db2home, /dwhome und /stage), die vom GPFS-Basiscluster bereitgestellt werden, über Cross-Mount-Operationen an.
GPFS-Basiscluster
Dieser GPFS-Cluster wird FOUNDATION.GPFS genannt und enthält die Administrationshosts in der ersten vagabundierenden Hochverfügbarkeitsgruppe (HA-Gruppe) und die Datenhosts in der zweiten vagabundierenden HA-Gruppe. Der GPFS-Basiscluster stellt allen anderen GPFS-Clustern in der Umgebung die clusterübergreifenden Dateisysteme bereit.
Weitere GPFS-Cluster
Jeder weitere GPFS-Cluster enthält die Hosts in jeder nachfolgenden vagabundierenden HA-Gruppe und wird hagroup#.GPFS genannt, wobei # bei 3 beginnt und für jede weitere HA-Gruppe im Cluster um 1 erhöht wird.

Damit die GPFS-Dateisysteme hoch verfügbar werden, werden zwei Hosts in jeder HA-Gruppe als GPFS-NSD-Server zugeordnet und arbeiten gleichzeitig. Die beiden Hosts, die als GPFS-NSD-Server fungieren, werden dem externen Speicher zugeordnet und geben die GPFS-Dateisysteme über das interne Anwendungsnetz für die anderen Hosts in der HA-Gruppe frei. Wenn ein als GPFS-Server zugeordneter Host ausfällt, bleibt der andere GPFS-Server betriebsbereit und gibt weiterhin das Dateisystem für die Client-Hosts frei. Die Client-Hosts sind die übrigen Hosts in der HA-Gruppe.

Die folgenden Dateisysteme werden von GPFS verwaltet und für alle Hosts im System freigegeben:
  • /db2home: Dateisystem des Instanzausgangsverzeichnisses
  • /dwhome: Dateisystem des Benutzerausgangsverzeichnisses
  • /stage: Temporärer Speicherplatz
Die folgenden Dateisysteme werden von GPFS verwaltet und für alle Hosts in derselben vagabundierenden HA-Gruppe freigegeben:
  • /db2fs/bcuaix/NODEnnnn: Container für die Tabellenbereiche für persistente Tabellen, wobei nnnn die Datenbankpartitionsnummer darstellt
  • /bkpfs/bcuaix/NODEnnnn: Backup-Dateisystem für die Datenbankpartition nnnn
  • /db2path/bcuaix/NODEnnnn: Datenbankverzeichnis-Dateisystem für die Datenbankpartition nnnn
Die folgenden Dateisysteme werden von GPFS verwaltet und vom Management-Host und Standby-Management-Host gemeinsam genutzt:
  • /opmfs: Vom Datenbankleistungsmonitor verwendetes Dateisystem
  • /usr/IBM/dwe/appserver_001: Von Warehouse-Tools-Anwendungen verwendetes Dateisystem
Der Management-Host und der Standby-Management-Host werden als GPFS-NSD-Server für die Hochverfügbarkeitskonfiguration für die Management-Hosts zugeordnet.

Jeder GPFS-Cluster mit Ausnahme des GPFS-Basisclusters wird einer HA-Gruppe zugeordnet. Der GPFS-Basiscluster dient als zwei separate HA-Gruppen. Die erste HA-Gruppe enthält den Administrationshost und den Standby-Administrationshost. Die zweite HA-Gruppe enthält alle Datenhosts im GPFS-Basiscluster. In der Regel können alle Hosts in derselben HA-Gruppe einen Mount für alle dieser HA-Gruppe zugeordneten Dateisysteme für Datenbankpartitionen durchführen. Ausschlussdateien werden konfiguriert, damit für die von den Datenbankpartitionen in der ersten HA-Gruppe verwendeten Dateisysteme nur ein Mount auf den Administrationshosts durchgeführt wird und damit für die von den Datenbankpartitionen in der zweiten HA-Gruppe verwendeten Dateisysteme nur ein Mount auf den Datenhosts in der zweiten HA-Gruppe durchgeführt wird.

Beispiel: Angenommen, für ein System mit der Standardkonfiguration befinden sich die ersten drei aktiven Datenhosts (host003, host004, host005) und ein Standby-Datenhost (host006) in derselben vagabundierenden HA-Gruppe. Auf jedem aktiven Datenhost werden zehn Datenbankpartitionen ausgeführt, sodass die Dateisysteme, für die auf den Hosts in der HA-Gruppe ein Mount durchgeführt wurde, für die Datenbankpartitionen 6 bis 35 verwendet werden. Die Ausschlussdateien für den GPFS-Basiscluster sind so konfiguriert, dass nur die Hosts host003, host004, host005 und host006 einen Mount für die folgenden Dateisysteme für die Datenbankpartitionen 6 bis 35 durchführen, wobei nnnn die Datenbankpartitionsnummer darstellt:
  • /db2fs/bcuaix/NODEnnnn
  • /db2path/bcuaix/NODEnnnn
  • /bkpfs/bcuaix/NODEnnnn
In Abbildung 1 sind die Dateisysteme, für die auf allen Hosts im System ein Mount durchgeführt wurde, die Dateisysteme, für die ein Mount auf den Management-Hosts durchgeführt wurde, und die Dateisysteme dargestellt, für die ein Mount auf allen Hosts in einem Kernwarehouse einer vagabundierenden HA-Gruppe durchgeführt wurde. In jedem HA-Paar oder jeder vagabundierenden HA-Gruppe müssen zwei Hosts als NSD-Server und zwei Hosts als Quorum-Manager definiert sein.
Abbildung 1. GPFS-DateisystemeGPFS-Dateisysteme

Die HA-Konfiguration für die Kernwarehouseinstanz umfasst Abhängigkeiten zwischen den Datenbankpartitionsressourcen und dem von GPFS verwalteten Dateisystem des Instanzausgangsverzeichnisses /db2home. Durch diese Abhängigkeiten wird verhindert, dass IBM Tivoli System Automation for Multiplatforms (Tivoli SA MP) die Datenbankpartitionen zu starten versucht, wenn für das Dateisystem von /db2home kein Mount durchgeführt wurde. Die Abhängigkeiten lösen auch eine Funktionsübernahme aus, wenn ein Fehler im Dateisystem des Instanzausgangsverzeichnisses auf einem aktiven Host auftritt.

Die Mounts des GPFS-Dateisystems werden auch über die Tivoli SA MP verwaltet. Während normaler Operationen behält die GPFS-Software die Mounts der GPFS-Dateisysteme auf den entsprechenden Hosts bei. Wenn beispielsweise ein Warmstart für einen Host durchgeführt wird, führt die GPFS-Software automatisch Mounts für die verwalteten Dateisystemressourcen durch. Wenn jedoch ein Mount für ein GPFS-Dateisystem nicht automatisch von der GPFS-Software durchgeführt wird oder wenn für das GPFS-Dateisystem ein Unmount durchgeführt wird, erkennt die Tivoli SA MP-Software, dass kein Mount für das Dateisystem durchgeführt wurde, und führt den Mount für das GPFS-Dateisystem automatisch durch, bevor sie versucht, die Kernwarehousedatenbank zu starten.

Führen Sie den folgenden Befehl als Root auf dem Management-Host aus, um den Status der GPFS-Software auf allen Hosts im System zu ermitteln:
dsh -n ${ALL} "/usr/lpp/mmfs/bin/mmgetstate -Y | tail -1" | sort
Der Befehl sollte für jeden Host den Status active zurückgeben, ähnlich wie in der folgenden Beispielausgabe:
host01: mmgetstate::0:1:::host01:1:active:1:2:2:quorum node:(undefined):
host02: mmgetstate::0:1:::host02:1:active:1:4:5:quorum node:(undefined):
host03: mmgetstate::0:1:::host03:2:active:1:2:2:quorum node:(undefined):
host04: mmgetstate::0:1:::host04:2:active:1:4:5:quorum node:(undefined):
host05: mmgetstate::0:1:::host05:3:active:1:4:5:quorum node:(undefined):
host06: mmgetstate::0:1:::host06:4:active:1:4:5:quorum node:(undefined):
host07: mmgetstate::0:1:::host07:5:active:1:4:5::(undefined):