Failoververhalten in Clustern mit mindestens drei Knoten

In diesem Artikel wird die Logik beschrieben, mit der Gruppen von einem Knoten zu einem anderen fehlschlagen, wenn drei oder mehr Clusterknotenmitglieder vorhanden sind.

Gilt für: Windows Server 2012 R2
Ursprüngliche KB-Nummer: 299631

Zusammenfassung

Die Verschiebung einer Gruppe kann durch einen Administrator verursacht werden, der eine Gruppe manuell verschiebt, oder durch einen Knoten- oder Ressourcenfehler. Wo die Gruppe verschoben wird, hängt davon ab, wie die Verschiebung initiiert wird und ob die Liste Bevorzugter Besitzer festgelegt ist.

Weitere Informationen

Informationen zur Liste bevorzugter Besitzer werden in der Hilfedatei unter "Servercluster" behandelt, einschließlich Informationen zur Planung und Optimierung von Serverclustern. In diesem Artikel werden die folgenden vier möglichen Szenarien beschrieben:

1. Es liegt ein Knoten- oder Ressourcenfehler vor, und die Liste bevorzugter Besitzer ist festgelegt.
2. Es liegt ein Knoten- oder Ressourcenfehler vor, und die Liste der bevorzugten Besitzer ist nicht festgelegt.
3. Der Administrator verschiebt die Gruppe manuell zu "Best Possible", und die Liste der bevorzugten Besitzer wird festgelegt.
4. Der Administrator verschiebt die Gruppe manuell zu "Best Possible", und die Liste bevorzugter Besitzer ist nicht festgelegt.

Szenario 1

Wenn bei einem Knoten oder einer Ressource ein Fehler auftritt und die Liste bevorzugter Besitzer definiert wurde, schlägt der Clusterdienst die Gruppe auf den nächsten verfügbaren Knoten in der Knotenliste aus. Die Knotenliste besteht aus der Liste der bevorzugten Besitzer, gefolgt von den verbleibenden Knoten, die nach ihrer Knoten-ID angeordnet sind. Die Knoten-ID wird definiert, wenn ein Knoten mit einem Cluster verknüpft wird oder wenn ein Knoten entfernt oder neu hinzugefügt wird.

Sie können die Reihenfolge der Knoten-ID anzeigen, indem Sie die Registrierung unter dem Schlüssel \HKEY_LOCAL_MACHINE\Cluster\Nodes untersuchen.

Angenommen, wir verfügen über einen Cluster mit sechs Knoten, und die Knoten wurden in der folgenden Reihenfolge installiert und in den Cluster eingebunden: NodeA, NodeB, NodeC, NodeD, NodeE und NodeF. Angenommen, für eine Gruppe sind NodeA, NodeC und NodeE als bevorzugte Besitzer aufgeführt.

Mit diesen Informationen würde die Knotenliste für die Gruppe dann wie folgt aussehen:

1. NodeA – Bevorzugter Besitzer Nummer 1
2. NodeC – Bevorzugter Besitzer Nummer 2
3. NodeE – Bevorzugter Besitzer Nummer 3
4. NodeB – Zweiter installierter Knoten
5. NodeD – Vierter installierter Knoten
6. NodeF – Sechster installierter Knoten

Wenn in diesem Szenario ein Knotenfehler oder ein Fehler einer Ressource auftreten und der Schwellenwert für den Neustart erreicht wird, schlägt die gesamte Gruppe fehl, um den nächsten Knoten in der Knotenliste zu erreichen. Wenn NodeC z. B. die ressource enthält, bei der ein Fehler aufgetreten ist, schlägt die gesamte Gruppe zu NodeE fehl. NodeA wird nicht fehlschlagen, obwohl es zuerst in der Liste bevorzugter Besitzer aufgeführt ist. Wenn NodeE fehlschlägt, führt die Gruppe ein Failover auf NodeB und nicht auf NodeA durch.

Szenario 2A

Wenn eine Ressource fehlschlägt und die Liste bevorzugter Besitzer nicht festgelegt ist, folgt die Gruppe einer Knotenliste ähnlich wie in Szenario 1. Die Knotenliste wird nur aus der Knoten-ID erstellt. Wenn ein Knoten oder eine Ressource ausfällt, folgen Ressourcen einem Abwärtspfad, der zum nachfolgenden Knoten in der Knotenliste fehlschlägt. Wenn er den zuletzt aufgeführten Knoten in der Knotenliste erreicht, beginnt er mit dem ersten Knoten in der Knotenliste.

1. NodeA – Erster installierter Knoten

2. NodeC – Zweiter installierter Knoten

3. NodeE – Dritter installierter Knoten

4. NodeB – Vierter installierter Knoten

5. NodeD – Fünfter installierter Knoten

6. NodeF – Sechster installierter Knoten

Diese Liste enthält beispielsweise die Installationsreihenfolge der verschiedenen Clusterknoten. Wenn NodeE fehlschlagen würde, würden alle Gruppen, die ihr gehören, ein Failover auf NodeB und nicht auf NodeF ausführen.

Szenario 2B

Wenn ein Knoten fehlschlägt und die Liste bevorzugter Besitzer für eine Gruppe auf diesem Knoten nicht festgelegt ist, wird nach dem Zufallsprinzip ein verfügbarer Knoten für die Gruppe ausgewählt, in die verschoben werden soll. Dadurch werden die Gruppen auf die verfügbaren Knoten verteilt.

Szenario 3

Wenn ein Clusteradministrator manuell Gruppe verschieben und Best Possible auswählt und die Liste der bevorzugten Besitzer konfiguriert ist, beginnt die Gruppe immer oben in der Knotenliste. Wie in Szenario 1 besteht die Knotenliste aus der Liste bevorzugter Besitzer und der Installationsreihenfolge.

1. NodeA – Bevorzugter Besitzer Nummer 1
2. NodeC – Bevorzugter Besitzer Nummer 2
3. NodeE – Bevorzugter Besitzer Nummer 3
4. NodeB – Zweiter installierter Knoten
5. NodeD – Vierter installierter Knoten
6. NodeF – Sechster installierter Knoten

Wenn in diesem Beispiel Best Possible ausgewählt ist, versucht die Gruppe immer, zu NodeA zu wechseln. Wenn sich die Gruppe bereits auf NodeA befindet oder NodeA nicht verfügbar ist, versucht die Gruppe, zu NodeC zu wechseln. Wenn sich eine Gruppe auf NodeD befindet und der Administrator sie in "Best Possible" verschieben möchte, wechselt die Gruppe zu NodeA. Wenn NodeA, NodeC oder NodeE nicht aktiv sind, wird entweder NodeB oder NodeF nach dem Zufallsprinzip ausgewählt.

Szenario 4

Wenn Sie als Clusteradministrator manuell Gruppe verschieben auswählen und die Option Bestmögliches auswählen und die Liste der bevorzugten Besitzer nicht konfiguriert ist, wird nach dem Zufallsprinzip ein aktiver Knoten zum Hosten der Gruppe ausgewählt. Ohne die Liste der bevorzugten Besitzer ist es möglich, dass eine Gruppe auf einen Knoten verschoben wird, auf dem bereits mehrere andere Gruppen ausgeführt werden.

Es wird empfohlen, die Liste "Bevorzugter Besitzer" in einem Cluster mit großen Knoten zu konfigurieren, wenn sich die Last zwischen Knoten erheblich unterscheidet oder wenn die Knoten nicht homogen sind.

Die öffentliche Eigenschaft AntiAffinityClassNames kann sich auch darauf auswirken, wohin ein Group-Failover ausgeführt wird.