Red Hat Cluster Suite: Konfiguration und Management eines Cluster | ||
---|---|---|
Zurück | Nach vorne |
Die Information in den folgenden Abschnitten kann beim Management der Cluster Software Konfiguration helfen.
Ein Cluster benutzt verschiedene Mechanismen zur Kommunikation im Cluster, um Datenintegrität und ein richtiges Verhalten des Cluster im Fehlerfall sicherzustellen. Der Cluster benutzt diese Mechanismen aus folgenden Gründen:
Zur Kontrolle wann ein System ein Cluster Member werden kann
Zum Feststellen des Status eines Cluster Systems
Zur Kontrolle des Verhaltens des Cluster im Fehlerfall
Die Mechanismen zur Kommunikation im Cluster sind die folgenden:
Gemeinsame (Quorum) Partitionen
Jedes der Cluster Systeme schreibt in periodischen Intervallen einen Timestamp, sowie seinen Systemstatus zur gemeinsamen primären und Shadow-Partition. Diese sind Raw-Partitionen, die sich auf dem gemeinsamen Speicher befinden. Jedes Cluster-System liest Statusinformation und Timestamp, die von dem anderen System geschrieben wurden, um festzustellen, ob diese up-to-date sind. Das Cluster System versucht diese Information zuerst von der primären Partition zu lesen. Sollte diese korrupt sein, versucht das Cluster System die Information von der Shadow-Partition zu lesen und dabei gleichzeitig die primäre Partition zu reparieren. Datenkonsistenz wird durch checksums überprüft und Inkonsistenzen werden automatisch beseitigt.
Sollte ein Cluster-System neustarten, kann allerdings zu keiner der beiden gemeinsamen Partitionen schreiben, wird dem System der Eintritt in den Cluster nicht erlaubt. Sollte ein Cluster-System nicht länger in der Lage sein auf beide Partitionen zu schreiben, wird es sich selbst aus dem Cluster entfernen, indem es herunterfährt.
Gemeinsame Partitionen werden lediglich als Kommunikationsmechanismus in Zwei-Member Clustern, die Tie-Breaker deaktiviert haben, verwendet.
Überwachung des anderen Stromschalters
In periodischen Abständen prüft jedes der Cluster-Member die Betriebsbereitschaft des Remote-Stromschalters, sollte ein solcher vorhanden sein. Das Cluster-System benutzt diese Information um den Status des anderen Systems zu ermitteln. Ein Ausfall der Kommunikation mit dem Stromschalter führt nicht zwangsweise zu einem Failover. Sollte der Stromschalter ein hängendes System nicht erfolgreich neustarten können, wird kein Failover stattfinden und die Cluster-Infrastruktur kann den Status des Members nicht bestimmen.
Ethernet-Heartbeats
Die Cluster-Systeme sind durch Punkt-zu-Punkt Ethernet-Verbindungen verbunden. In periodischen Abständen sendet jedes der Systeme Heartbeat-Signale (pings) über diese Kanäle. Der Cluster benutzt diese Information um den Status des Systems zu ermitteln und richtige Clusteroperation zu gewährleisten. Der komplette Ausfall der Heartbeat-Kommunikation führt nicht automatisch zu einem Failover.
Sollte ein Cluster-System feststellen, dass der Timestamp eines anderen Cluster-Systems nicht up-to-date ist, wird dieses den Heartbeat-Status überprüfen. Sollten Heartbeat-Signale zu diesem System noch erfolgreich sein, wird der Cluster zu diesem Zeitpunkt noch keine Aktion einleiten. Sollte ein Cluster System seinen Timestamp für einige Zeit nicht aktualisieren, und nicht auf Heartbeat-pings reagieren, wird dieses als ausgefallen betrachtet.
Der Cluster bleibt betriebsbereit, solange eines der Systeme auf die gemeinsamen Partitionen schreiben kann, auch wenn alle anderen Kommunikationsmechanismen ausfallen.
Beachten Sie, dass gemeinsame Partitionen lediglich als Backup in einigen Zwei-Member Konfigurationen verwendet werden. Der Netzwerk-Membership-Algorithmus ist der bestimmende Faktor in der Festlegung welche Cluster-Member aktiv sind, und welche nicht. Ein Member, das in dieser Konfiguration seinen Zeitstempel nicht aktualisiert, ruft keinen Failover hervor, solange der clumembd dieses Member nicht als "down" erkennt.
Zurück | Zum Anfang | Nach vorne |
SCSI Identifikationsnummern | Nach oben | Failover und Recovery Szenarios |