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.

Weitere Informationen zum CMM erhalten Sie unter “Cluster-Mitgliedschaft” im Sun Cluster Overview for Solaris OS.

Zwei Arten von Problemen können aufgrund der Partitionierung von Clustern auftreten:

Split Brain
Amnesie

Split Brain tritt auf, wenn der Cluster-Interconnect zwischen Knoten verloren geht und der Cluster partitioniert wird. Jede Partition verhält sich so, als sei sie die einzige vorhandene Partition, da die Knoten in einer Partition nicht mit den Knoten in anderen Partitionen kommunizieren können.

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 auf einem Knoten starten, der sich nicht in der letzten funktionierenden Cluster-Partition befindet.

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 erhalten 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 Stimmen in Abhängigkeit von seinem Status 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.

Quorum-Geräte steuern Stimmen basierend auf der Anzahl der mit dem Gerät verbundenen Stimmen bei. Wenn Sie ein Quorum-Gerät konfigurieren, weist die Sun Cluster-Software dem Quorum-Gerät eine Stimmenanzahl von N-1 zu, wobei N die Anzahl der mit dem Quorum-Gerät verbundenen Stimmen ist. 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.

Sie konfigurieren Quorum-Geräte während der Cluster-Installation. Für eine spätere Installation befolgen Sie die unter “Verwalten von Quorum-Geräten” im Sun Cluster System Administration Guide for Solaris OS beschriebene Vorgehensweise.

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, 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 Multihostgeräte 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 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 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 Multihostgeräte 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. 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 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 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) 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.

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, bei der N Quorum-Geräte jeweils mit einem der 1 bis N Knoten und dem N+1-Knoten verbunden sind, überlebt der Cluster den Ausfall entweder aller 1 bis N Knoten oder eines beliebigen der N/ 2 Knoten. 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 sämtlicher der N- 1 Knoten ü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 vermieden werden sollten, erhalten Sie unter Unzulässige Quorum-Konfigurationen . Beispiele für empfohlene Quorum-Konfigurationen erhalten Sie unter Empfohlene Quorum-Konfigurationen .

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

Sie müssen folgende Anforderungen erfüllen. Anderenfalls kann die Verfügbarkeit des Clusters beeinträchtigt sein.

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 Multihostplatten, 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. Siehe Abbildung 3–2.

Anwenden der Empfehlungen für den Umgang mit 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. Sie müssen kein 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 ist es manchmal sinnvoll, Ihre gesamte Cluster-Verfügbarkeit herabzusetzen, um Ihren Bedürfnissen gerecht zu werden. Ignorieren Sie in diesen Fällen die genannte Empfehlung. Wenn diese Empfehlung jedoch nicht wahrgenommen wird, wird die Verfügbarkeit insgesamt beeinträchtigt. In der Konfiguration, die unter Untypische Quorum-Konfigurationen beschrieben wird, ist die Verfügbarkeit des Clusters beispielsweise geringer. Die Quorum-Stimmen übersteigen hier die Knotenstimmen. Der Cluster hat die Eigenschaft, dass bei einem Abbruch des Zugriffs auf den gemeinsam genutzten Speicher zwischen Knoten A und Knoten B der gesamte Cluster ausfällt.

Unter Untypische Quorum-Konfigurationen wird die Ausnahme zu dieser Empfehlung beschrieben.
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 Fehlerschutzprozess. Siehe 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

Beispiele für Quorum-Konfigurationen, die vermieden werden sollten, erhalten 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 kommen oder von nur einem der Knoten und einem Quorum-Gerät.

Abbildung 3–2 Zwei-Knoten-Konfiguration

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

Quorum in Konfigurationen mit mehr als zwei Knoten

Es ist zulässig, einen Cluster mit mehr als zwei Knoten ohne Quorum-Gerät zu konfigurieren. Wenn Sie dies tun, können Sie den Cluster jedoch nur starten, wenn der Cluster über die Mehrheit der Knoten verfügt.

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

Untypische Quorum-Konfigurationen

Abbildung 3–3 setzt voraus, dass Sie Mission-Critical-Anwendungen (z.B.Oracle-Datembank) auf Knoten A und Knoten B ausführen. Wenn Knoten A und Knoten 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 der Empfehlung, auf die sich diese Ausnahme bezieht, erhalten Sie unter Anwenden der Empfehlungen für den Umgang mit 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&amp;amp;uuml;r Quorum erforderliche Stimmen = 6.

Unzulässige Quorum-Konfigurationen

Beispiele für empfohlene Quorum-Konfigurationen erhalten Sie unter Empfohlene Quorum-Konfigurationen .

Abbildung: Config1: NodeA/B verbunden mit QD1/2. Config2: NodeA- D. A/B verbunden mit QD1/2. Config3: NodeA-C. A/B verbunden mit QD1/2. C wird mit QD2 verbunden.