Hoch verfügbares Framework

Das Sun Cluster-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 Multihostgeräte. 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 Sun Cluster -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 können einfach nicht erkennen, dass der Framework-Ressourcenserver auf einen anderen Knoten verschoben wurde. Der Ausfall eines einzelnen Knotens ist für die Programme auf verbleibenden Knoten vollständig transparent, indem die zu dem Knoten gehörenden Dateien, Geräte und Plattendatenträger verwendet werden. Diese Transparenz besteht, sofern ein alternativer Hardwarepfad zu den Platten von einem anderen Knoten aus vorhanden ist. Ein Beispiel ist die Verwendung von Multihostgeräten mit Ports für mehrere Knoten.

Cluster-Mitgliedschaftsüberwachung (Cluster Membership Monitor, 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 einer synchronisierten Konfiguration können Cluster-Ressourcen 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 Informationen zum Fehlerschutz .

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 Informationen zum 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.

Wenn der Ausfall eines Cluster-Dämons einen Knoten in Panik versetzt, wird in der Konsole für diesen Knoten eine Meldung angezeigt, die in etwa folgendermaßen aussieht.

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. Alternativ kann der Knoten in Clustern aus SPARC-basierten Systemen an der OpenBoot^TM PROM (OBP)-Eingabeaufforderung bleiben. Die nächste Aktion des Knotens wird durch die Einstellung des auto-boot?-Parameters festgelegt. Sie können auto-boot? mit eeprom(1M) an der OpenBoot PROM ok-Eingabeaufforderung einstellen.

Cluster-Konfigurations-Repository (Cluster Configuration 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.