Windows Server 2016-Gäste im WSFC-Cluster werden aufgrund verlorener Heartbeat-Routen zufällig unter Quarantäne gestellt

Question

Ich hatte gerade das gleiche Problem mit einem Windows Server 2019-Failovercluster (für Hyper-V 2019). Normalerweise deaktiviere ich auch IPv6 auf meinen Servern und das hat die Probleme verursacht. Der Cluster hat viele kritische Fehler ausgegeben und manchmal ein hartes Failover durchgeführt, obwohl auch ein File Share Witness vorhanden und funktionsfähig war(?!).

Die folgenden Fehler und Warnungen habe ich im Ereignisprotokoll beobachtet:

FailoverClustering-Ereignis-IDs:

1135 (Clusterknoten „…“ wurde aus der aktiven Failovercluster-Mitgliedschaft entfernt)
1146 (Der Cluster Resource Hosting Subsystem (RHS)-Prozess wurde beendet und wird neu gestartet)
1673 (Clusterknoten „…“ hat den isolierten Zustand erreicht.)
1681 (Virtuelle Maschinen auf Knoten „…“ sind in einen nicht überwachten Zustand gewechselt.)

Service Control Manager-Ereignis-IDs:

7024 (Es war kein Quorum an Clusterknoten vorhanden, um einen Cluster zu bilden.)
7031 (Der Clusterdienst wurde unerwartet beendet.)

FailoverClustering-Client

81 (Erweiterte RPC-Fehlerinformationen)

Dank Ihrer Recherche habe ich einen wichtigen Hinweis erhalten: Der versteckte Adapter verwendet immer noch IPv6. Da in dem von Ihnen verlinkten Artikel stand, dass es weder empfohlen noch gängige Praxis sei, IPv6 auf dem versteckten Adapter zu deaktivieren, die Deaktivierung auf allen anderen Adaptern jedoch unterstützt und getestet wurde, habe ich mich gefragt, warum er nicht funktioniert.

Mit dem folgenden Befehl habe ich die Cluster-Protokolle abgerufen (danke auch für den Hinweis! Ich kannte diesen nützlichen Befehl nicht):

# -Destination (Folder) in my case changed to be not on the "C:\" SATADOM (this thing is slow and has few write cycles)
# -TimeSpan (in minutes) limited to one of the Failovers because these logs get HUGE otherwise.
Get-ClusterLog -Destination "E:\" -TimeSpan 5

Leider hatte ich die gleichen Protokolleinträge, die Sie bereits gepostet haben.

Ich habe IPv6 auf allen Adaptern wieder aktiviert und meine tunnelbezogenen Adapter/Konfigurationen mit Folgendem zurückgesetzt:

Set-Net6to4Configuration -State Default
Set-NetTeredoConfiguration -Type Default
Set-NetIsatapConfiguration -State Default

Das hat aber nicht geholfen... Bei näherem Hinsehen fiel mir auf, dass ich auch immer „diese nicht benötigten“ IPv6-bezogenen Firewall-Regeln deaktiviere... Und das schien die wirklich wichtige Änderung zu sein! Diese Regeln scheinen auch den unsichtbaren Adapter zu betreffen.

Der Punkt scheint zu sein: IPv6 verwendet kein ARP, um die MAC-Adressen seiner Kommunikationspartner zu finden. Es verwendet das Neighbor Discovery Protocol. Und dieses Protokoll funktioniert nicht, wenn Sie die zugehörigen Firewall-Regeln deaktivieren. Sie können die ARP-Einträge von IPv4 jedoch mit folgendem überprüfen:

arp -a

Hier werden Ihnen die MAC-Adressen für IPv6-Adressen nicht angezeigt. Für diese können Sie Folgendes verwenden:

netsh interface ipv6 show neighbors level=verbose

Wenn Sie möchten, können Sie die Ausgabe auf Ihre IPv6-Adapteradressen wie folgt filtern:

netsh interface ipv6 show neighbors level=verbose | sls ".*fe80::1337:1337:1234:4321.*" -Context 4 |%{$_.Line,$_.Context.PostContext,""}

Dabei stellte ich fest, dass diese Einträge anscheinend nur von kurzer Dauer waren. Der Status des Eintrags für die lokale Linkadresse des Microsoft "Failover Cluster Virtual Adapter" des Clusterpartners wechselte immer zwischen "Erreichbar" und "Probe". Den Moment, in dem er "Nicht erreichbar" war, habe ich allerdings nicht mitbekommen, aber nach erneuter Aktivierung der IPv6-Regeln war das Problem behoben:

Get-NetFirewallRule -ID "CoreNet-ICMP6-*" | Enable-NetFirewallRule

Irgendwie scheint diese MAC-Adresse auf andere Weise zwischen den Clusterpartnern ausgetauscht zu werden (wahrscheinlich, weil es sich um die „virtuelle Remote“-Adresse und nicht um eine echte handelt?). Sie taucht also immer wieder auf, was zu diesen wilden Failover-/Quarantäne-/Isolierungszuständen führt.

Wahrscheinlich hätte es auch geholfen, IPv6 auf dem unsichtbaren Adapter zu deaktivieren, aber da dies nicht empfohlen wird, habe ich mich nun dazu entschlossen, IPv6-bezogene Dinge überhaupt nicht mehr zu deaktivieren. Das ist sowieso die Zukunft :-)

Hoffe, dies hilft einem anderen IPv6-Deaktivierer!

Answer 1