Hoch verfügbares Framework

Das SunPlex-System macht alle Komponenten auf dem “Pfad” zwischen Benutzern und Daten hoch verfügbar, einschließlich der Netzwerkschnittstellen, der Anwendungen selbst, des Dateisystems und der Multihostplatten. Im Allgemeinen ist eine Cluster-Komponente hoch verfügbar, wenn sie trotz eines einzelnen Fehlers (Software oder Hardware) im System in Betrieb bleibt.

Die nachstehende Tabelle zeigt die Arten von SunPlex-Komponentenfehlern (bei Hardware und Software) und die entsprechende Form der Wiederherstellung, die in das hoch verfügbare Framework integriert ist.

Das Hochverfügbarkeits-Framework der Sun Cluster-Software erkennt einen Knotenfehler schnell und erstellt einen neuen, gleichwertigen Server für die Framework-Ressourcen auf einem anderen Knoten im Cluster. Zu keiner Zeit sind alle Framework-Ressourcen nicht verfügbar. Framework-Ressourcen, die von einem abgestürzten Knoten nicht betroffen sind, sind während der Wiederherstellung voll verfügbar. Darüber hinaus sind die Framework-Ressourcen des ausgefallenen Knotens wieder verfügbar, sobald sie wiederhergestellt sind. Eine wiederhergestellte Framework-Ressource muss nicht warten, bis die Wiederherstellung aller anderen Framework-Ressourcen abgeschlossen ist.

Die meisten hoch verfügbaren Framework-Ressourcen werden für die Anwendungen (Datendienste), die sie verwenden, transparent wiederhergestellt. Die Semantik des Framework-Ressourcenzugriffs bleibt bei einem Knotenfehler vollständig erhalten. Die Anwendungen nehmen einfach nicht wahr, dass der Framework-Ressourcenserver auf einen anderen Knoten verschoben wurde. Das Versagen eines einzigen Knotens ist für die Programme auf den restlichen Knoten vollständig transparent, die so lange die mit diesem Knoten verbundenen Dateien, Geräte und Datenträger verwenden, wie ein alternativer Hardwarepfad zu den Platten eines anderen Knotens vorhanden ist. Ein Beispiel ist die Verwendung von Multihostplatten mit Ports für mehrere Knoten.

Cluster-Mitglieder-Monitor (CMM)

Der Cluster-Mitglieder-Monitor (CMM) ist ein verteilter Satz von Agenten mit einem Agenten pro Cluster-Mitglied. Die Agenten tauschen mit folgenden Zielsetzungen Meldungen über den Cluster-Interconnect aus:

• Erzwingen einer konsistenten Mitgliederansicht auf allen Knoten (Quorum),

• Durchführen einer synchronisierten Rekonfiguration infolge von Änderungen der Mitgliedschaft mithilfe von registrierten Rückmeldungen,

• Bearbeiten der Cluster-Partitionierung (Split Brain, Amnesie),

• Sicherstellen der vollen Konnektivität zwischen allen Cluster-Mitgliedern.

Im Unterschied zu früheren Sun Cluster-Softwareversionen wird der CMM vollständig im Kernel ausgeführt.

Cluster-Mitgliedschaft

Die Hauptfunktion des CMM ist das Festlegen einer Cluster-weiten Einigung über den Knotensatz, der zum jeweiligen Zeitpunkt am Cluster teilnimmt. Diese Einschränkung wird als Cluster-Mitgliedschaft bezeichnet.

Zur Feststellung der Cluster-Mitgliedschaft und letzten Endes zur Sicherung der Datenintegrität geht der CMM folgendermaßen vor:

• Er weist eine Änderung bei der Cluster-Mitgliedschaft aus, zum Beispiel ein Knoten, der dem Cluster beitritt oder diesen verlässt.

• Er stellt sicher, dass ein “fehlerhafter” Knoten den Cluster verlässt.

• Er stellt sicher, dass ein “fehlerhafter” Knoten außerhalb des Clusters bleibt, bis er repariert ist.

• Er verhindert, dass der Cluster sich selbst in Knoten-Teilsätze partitioniert.

Weitere Informationen darüber, wie sich der Cluster vor der Partitionierung in mehrere getrennte Cluster schützt, finden Sie unter Quorum und Quorum-Geräte.

Rekonfiguration des CMM

Alle Knoten müssen eine konsistente Einigung hinsichtlich der Cluster-Mitgliedschaft erzielen, um die Daten vor Beschädigung zu schützen. Der CMM koordiniert gegebenenfalls eine Cluster-Rekonfiguration der Cluster-Dienste (Anwendungen) infolge eines Fehlers.

Der CMM erhält Informationen über die Konnektivität mit anderen Knoten aus der Cluster-Transportschicht. Der CMM verwendet während einer Rekonfiguration den Cluster-Interconnect zum Austauschen von Statusinformationen.

Nach dem Erkennen einer Änderung bei der Cluster-Mitgliedschaft führt der CMM eine synchronisierte Konfiguration des Clusters aus, bei der die Cluster-Ressourcen ggf. auf Grundlage der neuen Mitgliedschaft im Cluster neu verteilt werden.

Failfast-Mechanismus

Wenn der CMM ein kritisches Knoten-Problem erkennt, fordert er das Cluster-Framework auf, den Knoten zwangsweise herunterzufahren (Panik) und aus der Cluster-Mitgliedschaft zu entfernen. Der Mechanismus für diesen Vorgang wird als Failfast bezeichnet. Ein Failfast bewirkt das Herunterfahren eines Knotens auf zwei Arten.

• Wenn ein Knoten den Cluster verlässt und dann versucht, einen neuen Cluster ohne Quorum zu starten, wird er vom Zugriff auf die gemeinsam genutzten Platten “geschützt”. Weitere Details zur Verwendung von Failfast finden Sie unter Fehlerschutz.

• Wenn einer oder mehr Cluster-spezifische Dämonen ausfallen (clexecd , rpc.pmfd, rgmd oder rpc.ed), wird der Fehler vom CMM erkannt und der Knoten gerät in Panik.

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" dies 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

Anschließend kann der Knoten neu booten und versuchen, wieder dem Cluster beizutreten, oder kann an der OpenBoot^TM PROM (OBP)-Eingabeaufforderung bleiben. Die durchgeführte Aktion wird von der Einstellung des auto-boot?-Parameters im OBP bestimmt.

Cluster-Konfigurations-Repository (CCR)

Das Cluster-Konfigurations-Repository (CCR) ist eine private, Cluster-weite Datenbank zur Speicherung von Informationen über Konfiguration und Zustand des Clusters. Das CCR ist eine verteilte Datenbank. Jeder Knoten pflegt eine vollständige Kopie der Datenbank. Das CCR stellt sicher, dass alle Knoten ein konsistentes Bild der Cluster-“Welt” haben. Um eine Beschädigung der Daten zu vermeiden, muss jeder Knoten den aktuellen Zustand der Cluster-Ressourcen kennen.

Das CCR verwendet für Aktualisierungen einen Zwei-Phasen-Commit-Algorithmus: Eine Aktualisierung muss auf allen Cluster-Mitgliedern erfolgreich abgeschlossen werden, sonst wird die Aktualisierung zurückgenommen. Das CCR verwendet den Cluster-Interconnect für die Umsetzung der verteilten Aktualisierungen.

Das CCR besteht zwar aus Textdateien, aber Sie dürfen die CCR-Dateien unter keinen Umständen manuell bearbeiten. Jede Datei enthält einen Prüfsummeneintrag, um die Konsistenz zwischen den Knoten zu sichern. Eine manuell Aktualisierung der CCR-Dateien kann dazu führen, dass ein Knoten oder der ganze Cluster nicht mehr funktioniert.

Das CCR stellt mithilfe des CMM sicher, dass ein Cluster nur mit einem festgelegten Quorum läuft. Das CCR ist dafür zuständig, die Datenkonsistenz im ganzen Cluster zu überprüfen, eine ggf. erforderliche Wiederherstellung durchzuführen und Aktualisierungen für die Daten bereitzustellen.