Los invitados de Windows Server 2016 en el clúster WSFC se ponen en cuarentena aleatoriamente debido a la caída de rutas de latidos

Question

Acabo de tener el mismo problema con un clúster de conmutación por error de Windows Server 2019 (para Hyper-V 2019). Normalmente también desactivo IPv6 en mis servidores y eso causó los problemas. El clúster arrojó muchos errores críticos y, en ocasiones, realizó una conmutación por error completa, a pesar de que también había un testigo de recurso compartido de archivos instalado y funcionando (?!).

Los errores y advertencias que observé en el registro de eventos fueron:

ID de eventos de conmutación por error:

1135 (El nodo del clúster '....' se eliminó de la membresía activa del clúster de conmutación por error)
1146 (El proceso del subsistema de alojamiento de recursos (RHS) del clúster finalizó y se reiniciará)
1673 (El nodo del clúster '....' ha entrado en estado aislado).
1681 (Las máquinas virtuales en el nodo '....' han entrado en un estado no supervisado).

ID de eventos del Administrador de control de servicios:

7024 (No había quórum de nodos del clúster para formar un clúster).
7031 (El servicio de Cluster Service finalizó inesperadamente).

Cliente de clustering de conmutación por error

81 (información de error de RPC extendida)

Gracias a tu investigación obtuve una pista importante: el adaptador oculto todavía usa IPv6. Dado que el artículo al que usted se vinculó decía que no era recomendado ni convencional deshabilitar IPv6 en el adaptador oculto, pero que se admitía y probaba deshabilitarlo en todos los demás adaptadores, me preguntaba qué le impedía funcionar.

Usando el siguiente comando, extraje los registros del clúster (¡también gracias por la pista! No conocía este útil comando):

# -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

Desafortunadamente, tuve las mismas entradas de registro que usted ya publicó.

Volví a habilitar IPv6 en todos los adaptadores y revertí mis adaptadores/configuraciones relacionados con el túnel con:

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

Eso no funcionó... Mirando más allá, noté que también siempre desactivo "esas innecesarias" reglas de firewall relacionadas con IPv6... ¡Y ese parecía ser el cambio realmente importante! Esas reglas parecen afectar también al adaptador invisible.

La cuestión parece ser la siguiente: IPv6 no utiliza ARP para encontrar las direcciones MAC de sus socios de comunicación. Utiliza el protocolo de descubrimiento de vecinos. Y este protocolo no funciona si desactiva las reglas de firewall asociadas. Si bien puedes verificar las entradas ARP de IPv4 con:

arp -a

Esto no le mostrará las direcciones MAC para las direcciones IPv6. Para aquellos puedes usar:

netsh interface ipv6 show neighbors level=verbose

Si lo desea, puede filtrar la salida a las direcciones de su adaptador IPv6 de esta manera:

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

Al hacerlo, descubrí que esas entradas parecen durar muy poco. El estado de la entrada para la dirección local del enlace "Adaptador virtual de clúster de conmutación por error" de Microsoft del socio del clúster siempre alternaba entre "Alcanzable" y "Sonda". Sin embargo, no entendí el momento en el que era "Inalcanzable", pero después de volver a habilitar las reglas de IPv6, el problema desapareció:

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

De alguna manera, esta dirección MAC parece intercambiarse de otra manera entre los socios del clúster (¿probablemente porque es la dirección "remota virtual" y no una real?). Por lo tanto, sigue reapareciendo, lo que lleva a esos estados salvajes de conmutación por error, cuarentena o aislamiento.

Probablemente deshabilitar IPv6 en el adaptador invisible también habría ayudado, pero como esto no es recomendado, he decidido dejar de deshabilitar por completo las cosas relacionadas con IPv6. Es el futuro de todos modos :-)

¡Espero que esto ayude a otro compañero desactivador de IPv6!

Answer 1