Sun Cluster Konzepthandbuch für Solaris OS

Quorum und Quorum-Geräte

Die Cluster-Knoten nutzen gemeinsam Daten und Ressourcen. Daher ist es wichtig, dass ein Cluster niemals in getrennte Partitionen zerfällt, die gleichzeitig aktiv sind. Der CMM stellt selbst bei partitionierten Cluster-Interconnects sicher, dass maximal jeweils ein Cluster in Betrieb ist.

Es gibt zwei Arten von Problemen, die aufgrund der Partitionierung von Clustern auftreten: Split Brain und Amnesie. Zum Split Brain kommt es, wenn der Cluster-Interconnect zwischen den Knoten verloren geht und der Cluster in Teil-Cluster zerfällt, die sich jeweils als die einzige Partition wahrnehmen. Die Ursache sind Kommunikationsprobleme zwischen den Cluster-Knoten. Zur Amnesie kommt es, wenn der Cluster nach dem Herunterfahren mit Cluster-Daten neu startet, die älter als die Daten zum Zeitpunkt des Herunterfahrens sind. Dazu kann es kommen, wenn mehrere Versionen der Framework-Daten auf der Platte gespeichert sind und eine neue Cluster-Zusammensetzung ohne die neueste Version gestartet wird.

Split Brain und Amnesie können vermieden werden, indem jeder Knoten eine Stimme erhält und eine Stimmenmehrzahl für den Betrieb eines Clusters vorgeschrieben wird. Eine Partition mit der Mehrheit der Stimmen hat ein Quorum und erhält die Erlaubnis zum Arbeiten. Dieser Mechanismus der Stimmenmehrheit arbeitet einwandfrei, wenn der Cluster aus mehr als zwei Knoten besteht. In einem Zwei-Knoten-Cluster ist zwei eine Mehrheit. Wenn ein solcher Cluster in Partitionen zerfällt, wird eine externe Stimme benötigt, damit eine der Partitionen das Quorum erreicht. Diese externe Stimme wird von einem Quorum-Gerät beigesteuert. Ein Quorum-Gerät kann jede Platte sein, die von beiden Knoten gemeinsam genutzt wird. Als Quorum-Geräte verwendete Platten können Benutzerdaten enthalten.

Der Quorum-Algorithmus arbeitet dynamisch: Da seine Berechnungen durch Cluster-Ereignisse ausgelöst werden, können sich die Rechenergebnisse während der Lebenszeit eines Clusters ändern.

Stimmenanzahl Quorum

Sowohl Cluster-Knoten als auch Quorum-Geräte geben eine Stimme für das Quorum ab. Standardmäßig erhalten Cluster-Knoten eine Stimmenanzahl von Eins für das Quorum, sobald sie booten und Cluster-Mitglieder werden. Knoten können auch eine Stimmenanzahl von Null haben, wenn zum Beispiel der Knoten gerade installiert wird oder wenn ein Verwalter den Knoten in Wartungszustand versetzt hat.

Quorum-Geräte erhalten eine Stimmenanzahl für das Quorum, die sich nach der Anzahl von Knotenverbindungen mit dem Gerät richtet. Wenn ein Quorum-Gerät konfiguriert wird, erhält es eine maximale Stimmenanzahl von N-1, wobei N der Anzahl der mit dem Quorum-Gerät verbundenen Stimmen entspricht. Ein Quorum-Gerät, das zum Beispiel mit zwei Knoten mit einer Stimmenanzahl von nicht Null verbunden ist, hat einen Quorum-Zählwert von Eins (Zwei minus Eins).

Sie konfigurieren Quorum-Geräte entweder im Verlauf der Cluster-Installation oder später mit den Verfahren, die im Sun Cluster System Administration Guide beschrieben sind.


Hinweis –

Ein Quorum-Gerät trägt nur dann zur Stimmenanzahl bei, wenn mindestens einer der Knoten, mit dem es derzeit verbunden ist, ein Cluster-Mitglied ist. Auch beim Booten von Clustern trägt ein Quorum-Gerät nur dann zur Anzahl bei, wenn mindestens einer der Knoten, mit denen es derzeit verbunden ist, bootet und Mitglied des vor dem Herunterfahren zuletzt gebooteten Clusters war.


Quorum-Konfigurationen

Quorum-Konfigurationen hängen von der Anzahl der Knoten im Cluster ab:

Abbildung 3–2 Beispiele zu Quorum-Gerätekonfigurationen

Abbildung: Die Erläuterung zur Grafik ergibt sich aus dem vorstehenden Kontext.

Quorum-Richtlinien

Befolgen Sie beim Konfigurieren von Quorum-Geräten folgende Richtlinien:

Fehlerschutz

Ein wichtiges Thema bei Clustern ist ein Fehler, der zur Partitionierung des Clusters führt (als Split Brain bezeichnet). In diesem Fall können nicht mehr alle Knoten miteinander kommunizieren, so dass einzelne Knoten oder Knoten-Teilsätze ggf. versuchen, Einzel- oder Untermengen-Cluster zu bilden. Jede Untermenge oder Partition kann davon überzeugt sein, alleinigen Zugriff auf die Multihostplatten und die Eigentümerschaft zu haben. Der Versuch mehrerer Knoten, auf die Platten zu schreiben, kann zur Beschädigung von Daten führen.

Der Fehlerschutz schränkt den Knotenzugriff auf die Multihostplatten ein, indem der Zugriff auf die Platten real verhindert wird. Wenn ein Knoten den Cluster verlässt (aufgrund eines Ausfalls oder Partitionierung), wird mit dem Fehlerschutz sichergestellt, dass der Knoten keinen Zugriff mehr auf die Platte hat. Nur aktuelle Mitgliederknoten haben Zugriff auf die Platten. Das sichert die Datenintegrität.

Plattengerätedienste stellen Failover-Funktionen für Dienste zur Verfügung, die Multihostplatten verwenden. Wenn ein aktuell als Primärknoten (Eigentümer) der Plattengruppe fungierendes Cluster-Mitglied ausfällt oder nicht mehr erreicht werden kann, wird ein neuer Primärknoten ausgewählt, und nach einer einer unbedeutenden Unterbrechung kann wieder auf die Plattengerätegruppe zugegriffen werden. Während dieses Prozesses muss der alte Primärknoten den Zugriff auf die Geräte abgeben, bevor der neue Primärknoten gestartet werden kann. Wenn ein Mitglied jedoch aus dem Cluster ausscheidet und nicht mehr erreichbar ist, kann der Cluster diesen Knoten nicht zur Freigabe der Geräte auffordern, für die er als Primärknoten fungierte. Sie brauchen also ein Mittel, mit dessen Hilfe die funktionsfähigen Mitglieder die Steuerung und den Zugriff auf die globalen Geräte der ausgefallenen Mitglieder übernehmen können.

Das SunPlex-System verwendet SCSI-Plattenreservierungen zur Implementierung des Fehlerschutzes. Mit den SCSI-Reservierungen werden die Multihostplatten vor den ausgefallenen Knoten “geschützt” und der Zugriff auf diese Platten wird verhindert.

SCSI-2-Plattenreservierungen unterstützen eine Form der Reservierung, die entweder allen mit der Platte verbundenen Knoten Zugriff erteilt (wenn keine Reservierung vorliegt) oder den Zugriff auf einen einzigen Knoten beschränkt (auf den Knoten, für den die Reservierung gilt).

Wenn ein Cluster-Mitglied erkennt, dass ein anderer Knoten nicht mehr über den Cluster-Interconnect kommuniziert, leitet er ein Fehlerschutzverfahren ein, um den anderen Knoten am Zugriff auf die gemeinsam genutzten Platten zu hindern. Bei einem solchen Fehlerschutz ist es normal, dass der geschützte Knoten in Panik gerät und mit einer Meldung “reservation conflict” in der Konsole reagiert.

Der Reservierungskonflikt tritt nach der Feststellung auf, dass ein Knoten kein Cluster-Mitglied mehr ist, da auf allen Platten, die dieser Knoten mit den restlichen Knoten teilt, eine SCSI-Reservierung erfolgte. Der geschützte Knoten nimmt den Schutz möglicherweise nicht wahr. Wenn er versucht, auf eine der gemeinsam genutzten Platten zuzugreifen, erkennt er die Reservierung und gerät in Panik.

Failfast-Mechanismus zum Fehlerschutz

Der Mechanismus, mit dem Cluster Framework sicherstellt, dass ein ausgefallener Knoten nicht neu booten und in gemeinsam genutzte Speicher schreiben kann, wird als Failfast bezeichnet.

Knoten, die Cluster-Mitglieder sind, aktivieren kontinuierlich ein spezifisches ioctl, MHIOCENFAILFAST, für die Platten, auf die sie zugreifen. Hierzu gehören auch die Quorum-Platten. Dieses ioctl ist eine Anweisung für den Plattentreiber. Damit kann sich der Knoten selbst in einen Panik-Zustand versetzen, wenn er nicht auf die Platte zugreifen kann, weil diese von anderen Knoten reserviert wurde.

Das MHIOCENFAILFAST-ioctl löst eine Prüfung der Fehlerrückgaben aus jedem Lese- und Schreibvorgang aus, die von einem Knoten für den Fehlercode Reservation_Conflict an die Platte zurückgegeben werden. Das ioctl führt im Hintergrund regelmäßige Testvorgänge auf der Platte aus, um sie auf Reservation_Conflict zu prüfen. Sowohl der Kontrollflusspfad im Vordergrund als auch der im Hintergrund geraten in Panik, wenn Reservation_Conflict zurückgegeben wird.

Bei SCSI-2-Platten sind die Reservierungen nicht dauerhaft — sie werden beim erneuten Booten von Knoten gelöscht. Für SCSI-3-Platten mit PGR (Persistent Group Reservation) werden die Reservierungsinformationen auf der Platte gespeichert und bleiben auch nach dem Booten von Knoten erhalten. Der Failfast-Mechanismus arbeitet immer gleich, unabhängig davon, ob Sie SCSI-2- oder SCSI-3-Platten verwenden.

Wenn ein Knoten die Konnektivität mit anderen Knoten im Cluster verliert und nicht zu einer Partition gehört, die ein Quorum erzielen kann, wird er erzwungenermaßen von einem anderen Knoten aus dem Cluster entfernt. Ein anderer Knoten führt als Teil der Partition, die ein Quorum erzielt, Reservierungen auf den gemeinsam genutzten Platten aus. Wenn der Knoten ohne Quorum nun versucht, auf die gemeinsam genutzten Platten zuzugreifen, erhält er einen Reservierungskonflikt als Antwort und gerät infolge des Failfast-Mechanismus in Panik.

Nach der Panik kann der Knoten neu booten und versuchen, dem Cluster wieder beizutreten oder in Clustern aus SPARC-basierten Systemen am OpenBootTM PROM (OBP)-Eingabeaufforderung bleiben. Welche Aktion eingeleitet wird, bestimmt die Einstellung des auto-boot?-Parameters. Sie können auto-boot? mit eeprom(1M) in einem SPARC-basierten Cluster an der OpenBoot PROM ok-Eingabeaufforderung einstellen oder mit dem SCSI-Dienstprogramm, das Sie optional nach dem Starten der Bios in einem x86-basierten Cluster ausführen.