Convidados do Windows Server 2016 no cluster WSFC colocados em quarentena aleatoriamente devido à queda de rotas de pulsação

Question

Acabei de ter o mesmo problema com um cluster de failover do Windows Server 2019 (para Hyper-V 2019). Normalmente também desabilito o IPv6 em meus servidores e isso causou problemas. O cluster gerou muitos erros críticos e às vezes fazia um failover difícil, embora uma testemunha de compartilhamento de arquivos também estivesse instalada e funcionando (?!).

Erros e avisos que observei no log de eventos foram:

IDs de evento de cluster de failover:

1135 (o nó do cluster '....' foi removido da associação ativa do cluster de failover)
1146 (O processo do Resource Hosting Subsystem (RHS) do cluster foi encerrado e será reiniciado)
1673 (o nó do cluster '....' entrou no estado isolado.)
1681 (As máquinas virtuais no nó '....' entraram em um estado não monitorado.)

IDs de evento do Gerenciador de controle de serviço:

7024 (Um quorum de nós do cluster não estava presente para formar um cluster.)
7031 (O serviço Cluster Service foi encerrado inesperadamente.)

Cliente de Clustering de Failover

81 (informações estendidas de erro de RPC)

Graças à sua pesquisa, recebi uma pista importante: o adaptador oculto ainda usa IPv6. Como o artigo ao qual você vinculou dizia que não era recomendado ou comum desabilitar o IPv6 no adaptador oculto, mas desativá-lo em todos os outros adaptadores foi suportado e testado, fiquei me perguntando o que o impediu de funcionar.

Usando o seguinte comando, extraí os logs do cluster (também obrigado pela dica! Não conhecia este comando útil):

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

Infelizmente, tive as mesmas entradas de log que você já postou.

Reativei o IPv6 em todos os adaptadores e reverti meus adaptadores/configuração relacionados ao túnel com:

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

Isso não funcionou... Olhando mais adiante, notei que eu também sempre desativo "aquelas regras de firewall relacionadas ao IPv6" desnecessárias... E essa parecia ser a mudança realmente importante! Essas regras parecem afetar também o adaptador invisível.

A questão parece ser: o IPv6 não usa ARP para encontrar os endereços MAC de seus parceiros de comunicação. Ele usa o protocolo de descoberta de vizinho. E este protocolo não funciona se você desabilitar as regras de firewall associadas. Embora você possa verificar as entradas ARP IPv4 com:

arp -a

Isso não mostrará os endereços MAC dos endereços IPv6. Para aqueles você pode usar:

netsh interface ipv6 show neighbors level=verbose

Se desejar, você pode filtrar a saída para os endereços do adaptador IPv6 assim:

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

Fazendo isso descobri que essas entradas parecem ter vida muito curta. O estado da entrada do endereço local do link "Failover Cluster Virtual Adapter" da Microsoft do parceiro de cluster estava sempre alternando entre "Acessível" e "Sonda". Não entendi o momento em que estava "Inacessível", mas depois de reativar as regras IPv6, o problema desapareceu:

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

De alguma forma, este endereço MAC parece ser trocado de outra forma entre os parceiros do cluster (provavelmente porque é o endereço "remoto virtual" e não real?). Portanto, ele continua reaparecendo, levando a esses estados selvagens de failover/quarentena/isolado.

Provavelmente desabilitar o IPv6 no adaptador invisível também teria ajudado, mas como isso não é recomendado, decidi parar de desabilitar completamente as coisas relacionadas ao IPv6. De qualquer forma, é o futuro :-)

Espero que isso ajude outro colega desabilitador de IPv6!

Answer 1