Sun Cluster Konzepthandbuch für Solaris OS

Quorum und Quorum-Geräte

Dieses Kapitel umfasst die folgenden Themen:

Hinweis –

Eine Liste der Geräte, die von der Sun Cluster-Software als Quorum-Geräte unterstützt werden, erhalten Sie bei Ihrem Sun-Dienstanbieter.

Da Cluster-Knoten Daten und Ressourcen gemeinsam nutzen, darf ein Cluster nie in getrennte Partitionen aufgeteilt werden, die zur gleichen Zeit aktiv sind. Mehrere aktive Partitionen können zur Beschädigung von Daten führen. Durch den Cluster-Mitglied-Monitor (CMM) und den Quorum-Algorithmus wird gewährleistet, dass immer höchstens eine Instanz desselben Clusters in Betrieb ist, auch wenn der Cluster-Interconnect partitioniert ist.

Eine Einführung in Quorum und CMM finden Sie unter Cluster-Mitgliedschaft in Sun Cluster Überblick für das Betriebssystem Solaris.

Bei Cluster-Partitionen ergeben sich zwei Arten von Problemen:

Split Brain
Amnesie

Split Brain tritt auf, wenn der Cluster-Interconnect zwischen Knoten verloren geht und der Cluster partitioniert wird. Jede Partition "glaubt", dass sie die einzige Partition ist, da der Knoten in der einen Partition nicht mit dem Knoten in der anderen Partition kommunizieren kann.

Zur Amnesie kommt es, wenn der Cluster nach dem Herunterfahren mit Cluster-Konfigurationsdaten neu startet, die älter als die Daten zum Zeitpunkt des Herunterfahrens sind. Dieses Problem kann auftreten, wenn Sie den Cluster an einem Knoten starten, der nicht Teil der letzten funktionierenden Cluster-Partition war.

Die Sun Cluster-Software vermeidet das Autreten von Split Brain und Amnesie durch folgende Vorgänge:

Zuweisung einer Stimme für jeden einzelnen Knoten
Festlegung einer Stimmenmehrheit für einen betriebsbereiten Cluster

Eine Partition mit der Mehrheit der Stimmen erhält ein Quorum und erhält die Erlaubnis zum Arbeiten. Dieser auf einer Stimmenmehrheit basierende Mechanismus vermeidet Split Brain und Amnesie für den Fall, dass mehr als zwei Knoten in einem Cluster konfiguriert wurden. Das Zählen der Knotenstimmen allein reicht jedoch nicht aus, wenn mehr als zwei Knoten in einem Cluster konfiguriert wurden. In einem Zwei-Knoten-Cluster ist zwei eine Mehrheit. Wenn ein solcher Zwei-Knoten-Cluster partitioniert wird, benötigen beide Partitionen jeweils eine externe Stimme, um ein Quorum zu erhalten. Diese externe Stimme wird von einem Quorum-Gerät beigesteuert.

Informationen zur Quorum-Stimmenanzahl

Verwenden Sie den Befehl scstat -q, um folgende Informationen festzulegen:

Gesamte konfigurierte Stimmen
Aktuell vorhandene Stimmen
Für Quorum erforderliche Stimmen

Weitere Informationen zu diesem Befehl finden Sie unter scstat(1M).

Beide Knoten und Quorum-Geräte steuern Stimmen für den Cluster bei, um ein Quorum zu bilden.

Ein Knoten steuert je nach Status eine unterschiedliche Stimmenanzahl bei:

Ein Knoten hat eine Stimmenanzahl von eins, wenn er gestartet wird und ein Cluster-Mitglied wird.
Ein Knoten verfügt über null Stimmen, wenn er installiert wird.
Wenn ein Systemadministrator einen Knoten in den Wartungszustand versetzt, hat der Knoten eine Stimmenanzahl von null.

Die von Quorum-Geräten beigesteuerten Stimmen basieren auf der Anzahl der Stimmen, die mit dem Gerät verbunden sind. Wenn Sie ein Quorum-Gerät konfigurieren, weist die Sun Cluster-Software dem Quorum-Gerät eine Stimmenanzahl von N-1 zu. Hierbei ist N die Anzahl der mit dem Quorum-Gerät verbundenen Stimmen. 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).

Ein Quorum-Gerät steuert Stimmen bei, wenn eine der beiden folgenden Bedingungen erfüllt ist:

Bei mindestens einem der Knoten, an die das Quorum-Gerät derzeit angeschlossen ist, handelt es sich um ein Cluster-Mitglied.
Mindestens einer der Knoten, an die das Quorum-Gerät derzeit angeschlossen ist, wird gerade gestartet und der entsprechende Knoten war ein Mitglied der Cluster-Partition, die zuletzt Eigentümer des Quorum-Geräts war.

Quorum-Geräte werden während der Cluster-Installation oder zu einem späteren Zeitpunkt mithilfe der in Kapitel 5, Verwalten des Quorums in Sun Cluster Handbuch Systemverwaltung für Solaris OS beschriebenen Verfahren konfiguriert.

Informationen zum 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, sodass 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 Multihostgeräte und die Eigentümerschaft zu haben. Wenn mehrere Knoten versuchen, auf die Platten zu schreiben, können Datenfehler auftreten.

Der Fehlerschutz schränkt den Knotenzugriff auf die Multihostgeräte 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 Multihostgeräte verwenden. Wenn ein Cluster-Mitglied, das zurzeit als Primärknoten (Eigentümer) der Plattengerätegruppe dient, ausfällt oder nicht mehr erreichbar ist, wird ein neuer Primärknoten ausgewählt. Der neue Primärknoten ermöglicht den weiteren Zugriff auf die Plattengerätegruppe nach einer geringfügigen Unterbrechung. Während dieses Vorgangs muss der alte Primärknoten den Zugriff auf die Geräte freigeben, 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 Sun Cluster-System verwendet SCSI-Plattenreservierungen zur Implementierung des Fehlerschutzes. Mit den SCSI-Reservierungen werden die Multihostgeräte vor den ausgefallenen Knoten "geschützt" und der Zugriff auf diese Platten wird verhindert.

SCSI-2-Plattenreservierungen unterstützen eine Reservierungsform, die entweder allen mit der Platte verbundenen Knoten den Zugriff gestattet (wenn keine Reservierung vorliegt) oder den Zugriff auf einen einzelnen Knoten beschränkt (der Knoten, der die Reservierung aufweist).

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. Wenn dieser Fehlerschutz eintritt, gerät der geschützte Knoten in Panik und eine Meldung zum "Reservierungskonflikt" wird auf seiner Konsole angezeigt.

Die Entdeckung, dass ein Knoten nicht länger Mitglied des Clusters ist, bewirkt eine SCSI-Reservierung auf allen Platten, die von diesem und anderen Knoten gemeinsam genutzt werden. Der geschützte Knoten ist sich möglicherweise nicht "bewusst", dass er geschützt wird, und wenn er versucht, auf eine der gemeinsam genutzten Platten zuzugreifen, entdeckt er die Reservierung und gerät in Panik.

Failfast-Mechanismus für den Fehlerschutz

Der Mechanismus, durch den das Cluster-Framework sicherstellt, dass ein ausgefallener Knoten nicht neu booten und auf gemeinsam genutzten 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 Direktive für den Plattentreiber. Das ioctl gibt einem Knoten die Möglichkeit, selbst in Panik zu geraten, wenn er durch eine Reservierung eines anderen Knotens nicht auf die Platte zugreifen kann.

Das ioctl MHIOCENFAILFAST veranlasst den Treiber, die Fehlerrückgabe jedes Lese- und Schreibvorgangs, den ein Knoten an die Platte ausgibt, auf den Fehlercode Reservation_Conflict zu überprüfen. Das ioctl gibt im Hintergrund regelmäßig einen Testvorgang an die Platte aus, um sie auf die Meldung Reservation_Conflict zu überprüfen. Sowohl der Vordergrund- als auch der Hintergrund-Flussaufzeichnungspfad 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. Bei 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 funktioniert stets auf dieselbe Weise, ob Sie nun 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, der Teil der Partition ist, die ein Quorum erzielen kann, belegt die gemeinsam genutzten Platten mit Reservierungen. Wenn der Knoten, der über kein Quorum verfügt, versucht, auf die gemeinsam genutzten Platten zuzugreifen, wird ein Reservierungskonflikt gemeldet und der Knoten gerät, bewirkt durch den 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 an der OpenBoot^TM PROM (OBP)-Eingabeaufforderung bleiben. Welche Aktion eingeleitet wird, bestimmt die Einstellung des auto-boot?-Parameters. Sie können den Parameter auto-boot? mit eeprom(1M) an der OpenBoot PROM-Eingabeaufforderung ok in einem SPARC-basierten Cluster einstellen. Alternativ dazu können Sie diesen Parameter auch mit dem SCSI-Dienstprogramm einstellen, das Sie nach dem Booten des BIOS in einem x86-basierten Cluster ausführen können.

Informationen zu Quorum-Konfigurationen

Die folgende Liste enthält Informationen zu Quorum-Konfigurationen:

Quorum-Geräte können Benutzerdaten enthalten.
In einer N+1-Konfiguration, in der N Quorum-Geräte mit einem der 1 bis N Knoten und dem N+1-Knoten verbunden sind, überlebt der Cluster den Ausfall aller 1 bis N Knoten oder eines der N/2-Knoten. Bei dieser Verfügbarkeit wird vorausgesetzt, dass das Quorum-Gerät ordnungsgemäß funktioniert.
In einer N-Knotenkonfiguration, in der ein einzelnes Quorum-Gerät mit allen Knoten verbunden ist, kann der Cluster den Ausfall aller N-1Knoten überleben. Bei dieser Verfügbarkeit wird vorausgesetzt, dass das Quorum-Gerät ordnungsgemäß funktioniert.
In einer N-Knoten-Konfiguration, bei der ein einzelnes Quorum-Gerät mit allen Knoten verbunden wird, kann der Cluster den Ausfall des Quorum-Geräts überleben, sofern alle Cluster-Knoten verfügbar sind.

Beispiele für Quorum-Konfigurationen, die Sie besser vermeiden sollten, finden Sie unter Unzulässige Quorum-Konfigurationen . Beispiele für empfohlene Quorum-Konfigurationen finden Sie unter Empfohlene Quorum-Konfigurationen .

Erfüllen der Anforderungen für Quorum-Geräte

Sie müssen folgende Anforderungen erfüllen. Wenn Sie diese Anforderungen missachten, kann die Verfügbarkeit Ihres Clusters beeinträchtigt werden.

Stellen Sie sicher, dass die Sun Cluster-Software Ihr Gerät als Quorum-Gerät unterstützt.

Hinweis –
Eine Liste der Geräte, die von der Sun Cluster-Software als Quorum-Geräte unterstützt werden, erhalten Sie bei Ihrem Sun-Dienstanbieter.

Die Sun Cluster-Software unterstützt zwei Arten von Quorum-Geräten:
- Gemeinsam genutzte Multihost-Platten, die SCSI-3-PGR-Reservierungen unterstützen
- Gemeinsam genutzte Dual-Host-Platten, die SCSI-2-Reservierungen unterstützen
In einer Konfiguration mit zwei Knoten müssen Sie mindestens ein Quorum-Gerät konfigurieren, um sicherzustellen, dass ein einzelner Knoten weiterbesteht, wenn der andere Knoten ausfällt. Informationen hierzu finden Sie in Abbildung 3–2.

Einhalten von Empfehlungen für Quorum-Geräte

Ermitteln Sie mithilfe der folgenden Informationen, welche Quorum-Konfiguration am besten für Ihre Topologie geeignet ist:

Verfügen Sie über ein Gerät, das an alle Knoten des Clusters angeschlossen werden kann?
- Falls ja, konfigurieren Sie dieses Gerät als Ihr Quorum-Gerät. Es ist nicht nötig, dass Sie ein weiteres Quorum-Gerät konfigurieren, da Ihre Konfiguration bereits optimal ist.
  
  Achtung –
  Wenn Sie diese Anforderung ignorieren und ein weiteres Quorum-Gerät konfigurieren, wird die Verfügbarkeit des Clusters durch das zusätzliche Quorum-Gerät verringert.
- Falls nicht, konfigurieren Sie Ihr Gerät bzw. Ihre Geräte mit zwei Anschlüssen.
Stellen Sie sicher, dass die Gesamtanzahl der Stimmen, die von Quorum-Geräten bereitgestellt werden, grundsätzlich geringer ist als die Gesamtanzahl der von Knoten bereitgestellten Stimmen. Ist dies nicht der Fall, können die Knoten keinen Cluster bilden, wenn alle Platten verfügbar sind – auch wenn sämtliche Knoten funktionsfähig sind.

Hinweis –
In bestimmten Umgebungen sollten Sie die allgemeine Cluster-Verfügbarkeit reduzieren, um sie Ihren Bedürfnissen anzupassen. Ignorieren Sie in diesen Fällen die genannte Empfehlung. Wenn diese Empfehlung jedoch nicht wahrgenommen wird, wird die Verfügbarkeit insgesamt beeinträchtigt. Die unter Untypische Quorum-Konfigurationen beschriebene Konfiguration beispielsweise ist weniger verfügbar: Die Quorum-Stimmen übersteigen hier die Knotenstimmen. Der Cluster ist so konfiguriert, dass der gesamte Cluster ausfällt, wenn der Zugriff auf den von Nodes A und Node B gemeinsam genutzten Speicher verloren geht.

Unter Untypische Quorum-Konfigurationen finden Sie eine Ausnahme für diese Empfehlung.
Geben Sie ein Quorum-Gerät für sämtliche Knotenpaare an, die auf ein gemeinsam genutztes Speichergerät zugreifen. Diese Quorum-Konfiguration beschleunigt den Fehlerschutzvorgang. Informationen hierzu finden Sie unter Quorum in Konfigurationen mit mehr als zwei Knoten .
Im Allgemeinen steigt die Cluster-Verfügbarkeit, falls durch das Hinzufügen eines Quorum-Geräts die Gesamtanzahl der Cluster-Stimmen gerade wird.
Quorum-Geräte verlangsamen die Neukonfiguration nach dem Beitritt eines Knotens bzw. dem Ausfall eines Knotens geringfügig. Fügen Sie aus diesem Grund nicht mehr Quorum-Geräte als erforderlich hinzu.

Empfohlene Quorum-Konfigurationen

Dieser Abschnitt enthält Beispiele für empfohlene Quorum-Konfigurationen. Beispiele für Quorum-Konfigurationen, die besser vermieden werden sollten, finden Sie unter Unzulässige Quorum-Konfigurationen .

Quorum in Zwei-Knoten-Konfigurationen

Zwei Quorum-Stimmen sind erforderlich, damit ein Zwei-Knoten-Cluster gebildet werden kann. Diese beiden Stimmen können von den beiden Cluster-Knoten oder von einem Knoten und einem Quorum-Gerät stammen.

Abbildung 3–2 Zwei-Knoten-Konfiguration

Abbildung: Dargestellt: Knoten A und Knoten B mit einem Quorum-Gerät, das an zwei Knoten angeschlossen ist.

Quorum in Konfigurationen mit mehr als zwei Knoten

Cluster mit mehr als zwei Knoten können auch ohne ein Quorum-Gerät konfiguriert werden. In diesem Fall können Sie den Cluster nicht ohne eine Knotenmehrheit im Cluster starten.

Abbildung: Config1: NodeA-D. A/B verbunden mit (->) QD1. C/D -> QD2. Config2: NodeA-C. A/C -> QD1. B/C -> QD2. Config3: NodeA-C -> 1 QD.

Untypische Quorum-Konfigurationen

In Abbildung 3–3 wird vorausgesetzt, dass auf Node A und Node B sehr wichtige Anwendungen (beispielsweise Oracle-Datenbanken) ausgeführt werden. Wenn Node A und Node B nicht verfügbar sind und nicht auf gemeinsam genutzte Daten zugreifen können, sollten Sie den gesamten Cluster herunterfahren. Anderenfalls ist diese Konfiguration nicht optimal, da sie keine Hochverfügbarkeit bietet.

Informationen zu Empfehlungen, für die diese Ausnahme gilt, finden Sie unter Einhalten von Empfehlungen für Quorum-Geräte .

Abbildung 3–3 Untypische Konfiguration

Abbildung: NodeA-D. Node A/B verbunden mit QD1-4. NodeC verbunden mit QD4. NodeD verbunden mit QD4. Gesamtanzahl der Stimmen = 10. Für Quorum erforderliche Stimmen = 6.

Unzulässige Quorum-Konfigurationen

Dieser Abschnitt enthält Beispiele für Quorum-Konfigurationen, die Sie vermeiden sollten. Beispiele für empfohlene Quorum-Konfigurationen finden Sie unter Empfohlene Quorum-Konfigurationen .

Abbildung: Config1: NodeA-B. A/B connect to -> QD1/2. Config2: NodeA-D. A/B -> QD1/2. Config3: NodeA-C. A/B-> QD1/2 & C -> QD2.