Freigeben über


Problem mit Knoten, die aus der aktiven Failoverclustermitgliedschaft entfernt werden

In diesem Artikel wird beschrieben, wie Sie die Probleme beheben, bei denen Knoten nach dem Zufallsprinzip aus der aktiven Failoverclustermitgliedschaft entfernt werden.

Symptome

Wenn das Problem auftritt, werden Ereignisse wie dieses im Systemereignisprotokoll protokolliert:

Screenshot eines Beispiels für Ereignis 1135.

Dieses Ereignis wird auf allen Knoten im Cluster protokolliert, mit Ausnahme des Knotens, der entfernt wurde. Der Grund für dieses Ereignis ist, dass einer der Knoten im Cluster diesen Knoten als ausgefallen markiert hat. Anschließend werden alle anderen Knoten des Ereignisses benachrichtigt. Wenn die Knoten benachrichtigt werden, werden sie eingestellt und ihre Heartbeatverbindungen mit dem heruntergefahrenen Knoten abgebrochen.

Was hat dazu geführt, dass der Knoten nach unten markiert wurde

Alle Knoten in einem Windows 2008- oder 2008 R2-Failovercluster kommunizieren über die Netzwerke, die so festgelegt sind, dass die Clusternetzwerkkommunikation in diesem Netzwerk möglich ist. Die Knoten senden Heartbeatpakete über diese Netzwerke hinweg an alle anderen Knoten. Diese Pakete sollen von den anderen Knoten empfangen werden, und dann wird eine Antwort zurückgesendet. Jeder Knoten im Cluster verfügt über eigene Heartbeats, die überwacht werden, um sicherzustellen, dass das Netzwerk betriebsbereit und die anderen Knoten aktiviert sind. Das folgende Beispiel sollte dabei helfen, dieses Verhalten zu verdeutlichen:

Diagramm von zwei Knoten, die miteinander kommunizieren.

Wenn eines dieser Pakete nicht zurückgegeben wird, gilt der spezifische Heartbeat als fehlgeschlagen. Beispielsweise sendet W2K8-R2-NODE2 eine Anforderung und empfängt eine Antwort von W2K8-R2-NODE1 an ein Heartbeatpaket, sodass das Netzwerk bestimmt und der Knoten betriebsbereit ist. Wenn W2K8-R2-NODE1 eine Anforderung an W2K8-R2-NODE2 sendet und W2K8-R2-NODE1 die Antwort nicht erhält, wird dies als verlorener Heartbeat betrachtet, und W2K8-R2-NODE1 verfolgt sie. Diese verpasste Antwort kann dazu führen, dass W2K8-R2-NODE1 das Netzwerk als ausgefallen anzeigt, bis eine weitere Heartbeatanforderung empfangen wird.

Standardmäßig gilt für Clusterknoten ein Grenzwert von fünf Fehlern in 5 Sekunden, bevor die Verbindung deaktiviert wird. Wenn W2K8-R2-NODE1 die Antwort also nicht fünfmal im Zeitraum empfängt, wird diese bestimmte Route zu W2K8-R2-NODE2 als ausgefallen betrachtet. Wenn andere Routen weiterhin als aktiv betrachtet werden, bleibt W2K8-R2-NODE2 als aktives Mitglied erhalten.

Wenn alle Routen für W2K8-R2-NODE2 markiert sind, wird es aus der aktiven Failoverclustermitgliedschaft entfernt, und das ereignis 1135, das Im ersten Abschnitt angezeigt wird, wird protokolliert. Auf W2K8-R2-NODE2 wird der Clusterdienst beendet und dann neu gestartet, damit er versuchen kann, dem Cluster erneut beizulaufen.

Weitere Informationen zum Umgang mit bestimmten Routen mit drei oder mehr Knoten finden Sie im Blog "Partitionierte" Clusternetzwerke , der von Jeff Hughes geschrieben wurde.

Da wir nun wissen, wie der Taktprozess funktioniert, was sind einige der bekannten Ursachen für das Fehlschlagen des Prozesses

  1. Tatsächliche Netzwerkhardwarefehler. Wenn das Paket auf der Verbindung zwischen den Knoten verloren geht, schlagen die Heartbeats fehl. Eine Netzwerkablaufverfolgung von beiden beteiligten Knoten zeigt dies an.

  2. Das Profil für Ihre Netzwerkverbindungen könnte möglicherweise von Domäne zu Öffentlich und wieder zurück zur Domäne springen. Während des Übergangs dieser Änderungen können Netzwerk-E/A blockiert werden. Sie können überprüfen, ob dies der Fall ist, indem Sie sich das Betriebsprotokoll des Netzwerkprofils ansehen. Sie finden dieses Protokoll, indem Sie die Ereignisanzeige öffnen und zu Anwendungs- und Dienstprotokolle\Microsoft\Windows\NetworkProfile\Operational navigieren. Sehen Sie sich die Ereignisse in diesem Protokoll auf dem Knoten an, der in der Ereignis-ID 1135 erwähnt wurde, und überprüfen Sie, ob sich das Profil zu diesem Zeitpunkt geändert hat. Wenn ja, lesen Sie Die Netzwerkadressenprofil ändert sich in Windows 7 oder windows Server 2008 R2 von "Domäne" in "Öffentlich".

  3. Sie haben IPv6 auf den Servern aktiviert, aber die folgenden beiden Regeln für eingehenden und ausgehenden Datenverkehr in der Windows-Firewall sind deaktiviert:

    • Core Networking – Neighbor Discovery Advertisement
    • Core Networking – Neighbor Discovery Solicitation
  4. Anti-Virus-Software könnte diesen Prozess ebenfalls stören. Wenn Sie dies vermuten, testen Sie, indem Sie die Software deaktivieren oder deinstallieren. Tun Sie dies auf eigenes Risiko, da Sie an diesem Punkt nicht vor Viren geschützt sind.

  5. Dies kann auch durch die Latenz in Ihrem Netzwerk verursacht werden. Die Pakete gehen möglicherweise nicht zwischen den Knoten verloren, aber sie gelangen möglicherweise nicht schnell genug zu den Knoten, bevor der Timeoutzeitraum abläuft.

  6. IPv6 ist das Standardprotokoll, das vom Failoverclustering für die Heartbeats verwendet wird. Der Heartbeat selbst ist ein UDP-Unicast-Netzwerkpaket, das über Port 3343 kommuniziert. Wenn Switches, Firewalls oder Router nicht ordnungsgemäß konfiguriert sind, um diesen Datenverkehr zuzulassen, können Probleme wie die folgenden auftreten.

  7. IPsec-Sicherheitsrichtlinienaktualisierungen können dieses Problem ebenfalls verursachen. Das spezifische Problem besteht darin, dass während eines IPSec-Gruppenrichtlinienupdates alle IPsec-Sicherheitszuordnungen (SAs) von der Windows-Firewall mit erweiterter Sicherheit (WFAS) heruntergerissen werden. Während dieses Ereignisses wird die gesamte Netzwerkkonnektivität blockiert. Wenn bei der Neuverhandlung der Sicherheitszuordnungen Verzögerungen bei der Durchführung der Authentifizierung mit Active Directory auftreten, wird durch diese Verzögerungen (bei der die gesamte Netzwerkkommunikation blockiert ist) auch clustertaktische Takte blockiert, und die Überwachung der Clusterintegrität führt dazu, dass Knoten als ausgefallen erkannt werden, wenn sie nicht innerhalb des Schwellenwerts von 5 Sekunden reagieren.

  8. Alte oder veraltete Netzwerk-Karte Treiber und/oder Firmware. Manchmal kann auch eine einfache Fehlkonfiguration des Netzwerk-Karte oder Switchs zu Einem Verlust von Takten führen.

  9. Bei modernen Netzwerkkarten und virtuellen Netzwerkkarten kann es zu Paketverlusten kommen. Dies kann nachverfolgt werden, indem Sie Leistungsmonitor öffnen und den Zähler "Netzwerkschnittstelle\Empfangene Pakete verworfen" hinzufügen. Dieser Leistungsindikator ist kumulativ und erhöht sich nur, bis der Server neu gestartet wird. Das Anzeigen einer großen Anzahl von Paketen, die hier verworfen werden, könnte ein Zeichen dafür sein, dass die Empfangspuffer im Netzwerk Karte zu niedrig festgelegt sind oder dass der Server langsam arbeitet und den eingehenden Datenverkehr nicht verarbeiten kann. Jedes Netzwerk Karte Hersteller wählt aus, ob diese Einstellungen in den Eigenschaften des Netzwerks Karte verfügbar gemacht werden sollen. Daher müssen Sie auf der Website des Herstellers erfahren, wie Sie diese Werte erhöhen und die empfohlenen Werte verwenden sollten. Wenn Sie auf VMware ausführen, wird im folgenden Blog etwas ausführlicher darüber gesprochen, einschließlich der Informationen, ob dies das Problem ist, und Sie werden auf den VMware-Artikel zu den zu ändernden Einstellungen verweist.

    Knoten, die aus der Failoverclustermitgliedschaft in VMware ESX entfernt werden

Dies sind die häufigsten Gründe für die Protokollierung dieser Ereignisse, aber es kann auch andere Gründe geben. In diesem Blog ging es darum, Ihnen einen Einblick in den Prozess zu geben und auch Ideen zu geben, wonach Sie suchen müssen. Einige erhöhen die folgenden Werte auf ihre Maximalwerte, um zu versuchen, dieses Problem zu beenden.

Parameter Standard Bereich
SameSubnetDelay 1000 Millisekunden 250-2000 Millisekunden
CrossSubnetDelay 1000 Millisekunden 250-4000 Millisekunden
SameSubnetThreshold 5 3-10
CrossSubnetThreshold 5 3-10

Wenn Sie diese Werte auf ihr Maximum erhöhen, können das Ereignis und das Entfernen des Knotens entfernt werden. Das Problem wird lediglich maskiert. Es wird nichts behoben. Am besten ermitteln Sie die Grundursache der Taktfehler, und lassen Sie sie beheben. Die einzige wirkliche Notwendigkeit, diese Werte zu erhöhen, besteht in einem Szenario mit mehreren Standorten, in dem sich Knoten an verschiedenen Standorten befinden und die Netzwerklatenz nicht überwunden werden kann.