Adicionar nó ao cluster de failover com falha na comunicação por 3343

Adicionar nó ao cluster de failover com falha na comunicação por 3343

Temos um cluster de 2 nós do Windows 2012 existente com testemunha de arquivo, mas estamos substituindo-os por servidores 2019. Portanto, podemos simplesmente reutilizar o objeto de cluster existente, estamos adicionando os servidores de 2019 ao cluster e descartando os de 2012 assim que os bancos de dados em cluster forem sincronizados. O teste de validação revela apenas alguns avisos, incluindo o aviso "apenas um par de interfaces de rede" em Validar comunicação de rede, o aviso "A senha não atende aos requisitos da política de senha" em Validar configurações de CSV, os novos servidores não estão na mesma UO como os servidores antigos (eles são agrupados por Server OS versão 2012 vs. 2019), "A propriedade do cluster" ClusterLogSize "está definida com um valor menor que o valor padrão de 1536" e o óbvio "diferente, mas compatível, operacional versões do sistema" aviso. Portanto, nada que nos impeça de adicionar os nós ao cluster.

O processo Adicionar nó falha na etapa "Aguardando notificação de que o nó...é um membro totalmente funcional do cluster". Os logs de eventos do sistema revelam os erros 1653 e 5398, o que indica um problema de comunicação. O serviço de cluster se comunica pelo 3343, portanto, a solução de problemas se concentrou nisso. Desativei completamente o firewall e o AV, mas o problema ainda persistia.

A única coisa que noto que é diferente entre os novos servidores e os servidores antigos é que durante o Assistente para Adicionar Nó, quando o Serviço de Cluster é ativado no novo servidor, o servidor não está escutando no UDP 3343. Vi isso executando o TCPView em tanto os servidores de 2012 atualmente no cluster quanto os servidores de 2019 que estou tentando adicionar ao cluster. Os servidores de 2012 mostrarão escuta em 3343 em TCP e UDP, mas os servidores de 2019 mostrarão apenas escuta e envio de informações em TCP 3343. Haverá 4 comunicações de espera de tempo em TCP 3343 para os dois servidores de 2012, mas eventualmente atingirão o tempo limite, fazendo com que o processo Adicionar nó falhe com um erro de tempo limite. Não tenho certeza se não escutar no UDP 3343 neste ponto do processo é um comportamento normal antes de um nó ser totalmente adicionado ou é indicativo de que o serviço não está escutando corretamente no TCP e no UDP 3343 nos novos servidores.

Nada parece estar bloqueando ativamente a comunicação; parece que os novos servidores não estão ouvindo adequadamente a comunicação dos outros nós. Ou estou apenas latindo para a árvore errada?

Responder1

Embora o Relatório de Validação não diga isso, é fisicamente impossível adicionar um nó de 2019 a um cluster de 2012.

informação relacionada