Servidor RPC Indisponível no cluster do Hyper-V ao mover recursos após a falha do adaptador host

Question

Em um cluster do Windows 2008 R2 SP1 executando o Hyper-V, uma conectividade de rede perdida na interface principal do host. A interface foi rapidamente agitando para cima e para baixo, e isso foi mais tarde determinado a ser causado por uma porta de switch com defeito.

Como esse era um servidor em cluster, a interface do host não era tolerante a falhas (já que todo o servidor era tolerante a falhas), portanto a conectividade com o host estava aumentando e diminuindo.

Os convidados do Hyper-V não foram afetados pela interrupção da rede, pois usaram um tronco dedicado no servidor separado da interface do host. Além disso, as interfaces dedicadas para as redes de cluster e migração ao vivo estavam bem.

Para diagnosticar o servidor, tentei mover todos os recursos (convidados do Hyper-V) para outros nós por meio do Gerenciador de Cluster de Failover. Esses movimentos falharam com um erro RPC Server Unavailable .

A única maneira de mover recursos era desligar os convidados, parando o serviço de cluster no Nó A, permitindo que outros nós se apropriassem dos recursos e reiniciando os convidados.

Algumas outras notas:

• Todos os nós possuem o Cliente para Redes MS e Arquivo & Compartilhamento de Impressora ativado nas redes Cluster e LM.
• O nó A era acessível através de redes de cluster e LM de outros nós (são redes privadas, somente de cluster); pingável, CIFs, etc.
• O acesso a \\ NODEA é feito através dos adaptadores Host, como seria de esperar neste caso e é o motivo pelo qual o erro RPC Server Unavailable com esse adaptador está inativo.

Minhas perguntas aqui são -

1. Existe uma maneira de continuar usando o Live Migration em um cenário de falha como este para evitar o desligamento dos convidados do Hyper-V?
2. Como a rede pode ser reconfigurada no futuro para que o serviço de cluster tente usar o cluster e / ou as redes de migração ao vivo para emitir as solicitações de RPC?

Answer 1

Ótima pergunta!

O motivo mais provável para a falha de RPC é que o recurso de nome de cluster (e o endereço IP) provavelmente estava hospedado no servidor cuja conexão de rede principal estava oscilando.

Como a interface estava indo para cima e para baixo, o acesso ao cluster por meio do nome do cluster provavelmente falharia devido às interrupções da rede.

Você deve conseguir executar comandos no cluster a partir da linha de comando (cluster.exe ou o módulo FailoverClusters no PowerShell). O módulo FailOverClusters pode ser usado sobre o controle remoto do PowerShell se a delegação de credenciais apropriada estiver configurada (CredSSP ou Kerberos).

No caso de uma falha da interface de rede que hospeda o nome do cluster, você poderia usar o PowerShell para mover esse grupo de clusters para um dos nós acessíveis ou executar comandos contra o cluster para migrar máquinas, etc. ..

Para garantir que isso não aconteça novamente, você provavelmente precisará tornar a NIC altamente disponível (agrupamento de NICs). Isso depende de onde você está gerenciando o cluster a partir de um dos servidores ou de uma estação de gerenciamento remoto. Se você estiver gerenciando de uma máquina em cluster no mesmo cluster, poderá adicionar um IP na rede do cluster ao nome do cluster, mas deseja certificar-se de que não foi adicionado ao DNS; caso contrário, poderá interromper os clientes de gerenciamento remoto. capaz de se conectar.

Para adicionar um endereço IP ao grupo de clusters por meio do PowerShell -

$Resource = Add-ClusterResource -Name SecondaryIP -ResourceType "IP Address" -Group 'Cluster Group' 
$Resource | Set-ClusterParameter -Name 'Address' -Value 'Your-IP-Here'
$Resource | Set-ClusterParameter -Name 'SubnetMask' -Value 'Your-SubnetMask-Here'

Você precisará desabilitar o registro de DNS dinâmico e criar entradas estáticas se não quiser que os clientes de gerenciamento remoto tentem falar com a rede privada.