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 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 wieder hergestellt. 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

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.

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

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.

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 von CMM erkannt und der Knoten gerät in Panik.

panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 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

Nach der Panik kann der Knoten neu booten und versuchen, dem Cluster wieder beizutreten oder in Clustern aus SPARC-basierten Systemen an der OpenBoot^TM PROM (OBP)-Eingabeaufforderung bleiben. Welche Aktion eingeleitet wird, bestimmt die Einstellung des auto-boot?-Parameters. Sie können auto-boot?mit eeprom(1M) an der OpenBoot PROM ok-Eingabeaufforderung einstellen.

Cluster-Konfigurations-Repository (CCR)

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.