Partilhar via

Solucionar problemas de cluster com a ID de evento 1135

  • Artigo

Este artigo ajuda a diagnosticar e resolver a ID 1135 de Evento, que pode ocorrer durante a inicialização do Serviço cluster no ambiente de Clustering de failover.

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versões 21H2 e 20H2

Experimente nosso Agente virtual. Ele pode ajudar a identificar e corrigir rapidamente os problemas comuns de replicação do Active Directory.

Página inicial

A ID 1135 de Evento indica que um ou mais nós de cluster foram removidos da associação ativa do Cluster de failover. O evento pode apresentar os seguintes sintomas:

Para assegurar que a causa dos problemas não é a configuração, recomenda-se primeiro validar a configuração e testar a rede.

O Serviço de cluster é o componente de software essencial que controla todos os aspectos da operação do cluster de failover e gerencia o banco de dados de configuração do cluster. Se você vir a ID de evento 1135, recomendamos que você instale as correções mencionadas nos artigos a seguir e reinicialize todos os nós do cluster e, em seguida, observe se o problema ocorre novamente.

Verificar se o serviço de cluster está em execução em todos os nós

Acompanhe o comando a seguir (de acordo com seu sistema de operações do Windows) para validar se o serviço de cluster está disponível e executando sem interrupções.

Para cluster do Windows Server 2008 R2

Em um prompt de comandos com privilégios elevados, execute cluster.exe node /stat.

Para cluster do Windows Server 2012 e Windows Server 2012 R2

Execute o seguinte cmdlet do PowerShell: Get-ClusterResource

O serviço de cluster está disponível e executando sem interrupções em todos os nós?

Vários cenários da ID 1135 de Evento

Queremos que você examine melhor os logs de eventos do sistema em todos os nós do cluster. Examine a ID do evento 1135 que você está vendo nos nós e copie todas as instâncias desse evento. Isso facilitará sua análise.

Event ID 1135
Cluster node ' **NODE A** ' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. 
This could also be due to the node having lost communication with other active nodes in the failover cluster. 
Run the Validate a Configuration wizard to check your network configuration. 
If the condition persists, check for hardware or software errors related to the network adapters on this node. 
Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Há três cenários comuns:

Cenário A

Você está olhando para todos os eventos e todos os nós no cluster estão indicando que o NÓ A perdeu a comunicação.

Diagrama mostrando o Nó A, o Nó B e o Nó C se comunicando com êxito.

Diagrama mostrando que o Nó A perdeu a comunicação com o Nó B e o Nó C.

Pode ser possível que, quando você estiver vendo os logs do sistema no NÓ A, ele tenha eventos para todos os nós restantes no cluster.

Solução

Isso é um forte indício de que no momento do problema, seja pelo congestionamento da rede ou não, a comunicação com o NÓ A foi perdida.

Você deve examinar e validar a configuração da rede e os problemas de comunicação. Lembre-se de procurar problemas relacionados ao Nó A.

Cenário B

Você está olhando para os eventos nos nós e digamos que seu cluster esteja disperso em dois sites. NÓ A, NÓ B e NÓ C no local 1 e NÓ D E NÓ E no local 2.

Diagrama mostrando que o Site 1 está se comunicando com êxito com o Site 2 por meio de um Link de WAN.

Nos nós A, B e C, você vê que os eventos registrados são para conectividade com os nós D e E. Da mesma forma, quando você vê os eventos nos nós D e E, os eventos sugerem que perdemos a comunicação com A, B e C.

Diagrama que mostra que o Site 1 perdeu a ligação WAN com o Site 2.

Solução

Se você vir uma atividade semelhante, é um indicativo de que houve uma falha de comunicação por meio do link que conecta esses sites. Recomendamos que você examine a conexão entre os sites. Se usar uma conexão WAN, sugerimos que você verifique a conectividade com seu ISP.

Cenário C

Você está olhando para os Eventos nos nós e vê que os nomes dos nós não correspondem a nenhum padrão específico. Digamos que seu cluster esteja distribuído em dois sites. NÓ A, NÓ B e NÓ C no local 1 e NÓ D E NÓ E no local 2.

  • No Nó A: você vê eventos dos Nós B, D, E.
  • No Nó B: você vê eventos dos Nós C, D, E.
  • No Nó C: você vê eventos dos Nós A, B, E.
  • No Nó D: você vê eventos dos Nós A, C, E.
  • No Nó E: você vê eventos dos Nós B, C, D.
  • Ou qualquer outra combinação.

Diagrama do Cenário C mostrando que seu cluster está disperso em dois sites.

Solução

Esses eventos ocorrem quando os canais de rede entre os nós estão bloqueados e as mensagens de comunicação do cluster não chegam em tempo hábil, fazendo com que o cluster ache que a comunicação entre os nós foi perdida, resultando na remoção de nós da associação do cluster.

Analisar Redes de cluster

Recomendamos que você examine as Redes de Cluster verificando as três opções a seguir, uma a uma, para prosseguir neste guia de solução de problemas.

Verificar a exclusão de antivírus

Exclua da verificação de vírus, os seguintes locais do sistema de arquivos no servidor que está executando os Serviços de Cluster:

  • O caminho da Testemunha de compartilhamento de arquivos
  • A pasta %Systemroot%\Cluster

Configure o componente de verificação em tempo real no software antivírus para excluir os diretórios e arquivos:

  • Diretório de configuração da máquina virtual padrão (C:\ProgramData\Microsoft\Windows\Hyper-V)

  • Diretórios de configuração da máquina virtual personalizada

  • Diretório padrão da unidade de disco rígido virtual (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)

  • Diretórios personalizados da unidade do disco rígido virtual

  • Diretórios de dados de replicação personalizados, se você estiver usando a Réplica do Hyper-V

  • Diretórios de instantâneos

  • mms.exe

    Observação

    Pode ser que esse arquivo tenha que ser configurado como uma exclusão de processo dentro do software antivírus.

  • Vmwp.exe

    Observação

    Pode ser que esse arquivo tenha que ser configurado como uma exclusão de processo dentro do software antivírus.

Além disso, ao usar a Migração ao Vivo junto com os Volumes Compartilhados Clusterizados, exclua o caminho C:\Clusterstorage do CSV e todos os subdiretórios. Se você estiver solucionando problemas de failover ou problemas gerais com os serviços de cluster e o software antivírus estiver instalado, desinstale temporariamente o software antivírus ou verifique com o fabricante do software para determinar se o software antivírus funciona com os serviços de cluster. Na maioria dos casos, não basta apenas desabilitar o antivírus. Mesmo que você desabilite o antivírus, o driver de filtro será carregado quando você reiniciar o computador.

Verifique a configuração da porta de rede no firewall

O Serviço de cluster controla as operações do cluster de servidores e gerencia o banco de dados do cluster. Um cluster é uma coleção de computadores independentes que atuam como um único computador. Gerentes, programadores e usuários veem o cluster como um único sistema. O software distribui os dados entre os nós do cluster. Se um nó falhar, os outros nós fornecerão os serviços e os dados que eram fornecidos anteriormente pelo nó ausente. Quando o nó é adicionado ou consertado, o software do cluster migra alguns dados para esse nó.

Nome do serviço do sistema: ClusSvc

Aplicativo Protocolo Portas
Serviço de Cluster UDP 3343
Serviço de Cluster TCP 3343 (essa porta é obrigatória durante uma operação de junção de nó)
RPC TCP 135
Administrador do cluster UDP 137
Kerberos UDP/TCP 464*
SMB TCP 445
Portas UDP altas alocadas aleatoriamente** UDP Número de porta aleatório entre 1024 e 65535
Número de porta aleatório entre 49152 e 65535***

Observação

Além disso, para uma validação bem-sucedida em Clusters de Failover do Windows no Windows Server 2008 e superiores, permita o tráfego de entrada e saída para ICMP4, ICMP6.

Este é o intervalo no Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008 e Windows Vista.

Além disso, execute o seguinte comando para verificar a configuração da porta de rede no firewall. Por exemplo, este comando ajuda a determinar a porta 3343 disponível\aberta, usada para o Cluster de Failover:

netsh advfirewall firewall show rule name="Failover Clusters (UDP-In)" verbose

Executar relatório de Validação de cluster para encontrar erros ou avisos

A ferramenta de validação de cluster executa um conjunto de testes para verificar se o hardware e as configurações são compatíveis com os clusters de failover.

Siga estas instruções:

  1. Execute o relatório de Validação de cluster para encontrar erros ou avisos. Para obter mais informações, veja Conceitos sobre testes de validação de cluster: rede

    Captura de tela dos resultados após a execução do relatório de validação de cluster para quaisquer erros ou avisos.

  2. Verifique se há avisos e erros nas Redes. Para obter mais informações, veja Conceitos sobre testes de validação de cluster: rede.

    Captura de tela dos resultados por categoria.

    Captura de tela de Validar configuração do firewall do Windows em Rede.

Verificar o recurso Listar Ordem de Associações de Rede

Esse teste lista a ordem em que as redes estão associadas aos adaptadores em cada nó.

A guia Adaptadores e Ligações lista as conexões na ordem em que as conexões são acessadas pelos serviços de rede. A ordem das conexões reflete a ordem na qual chamadas/pacotes TCP/IP genéricos são enviados pela rede.

Siga as etapas abaixo para alterar a ordem de associação dos adaptadores de rede:

  1. Selecione Iniciar, selecione Executar, digite ncpa.cpl e selecione OK. Para ver as conexões disponíveis, acesse a seção LAN e Internet de alta velocidade na janela Conexões de Rede.
  2. No menu Avançado, selecione Configurações Avançadas e, em seguida, selecione a guia Adaptadores e Associações.
  3. Na área Conexões, escolha a conexão que você quer mover para a parte superior da lista. Use os botões de setas para mover a conexão. Como regra geral, a placa que se comunica com a rede (conectividade de domínio, roteamento para outras redes, etc. deve ser a primeira placa vinculada (topo da lista)).

Os nós de cluster são sistemas multi-homed. A prioridade de rede afeta a conectividade de rede de saída do Cliente DNS. Os adaptadores de rede usados na comunicação do cliente devem estar no topo da ordem de associações. Redes não roteadas podem ter prioridade mais baixa. No Windows Server 2012 e no Windows Server 2012 R2, o adaptador do Driver de Rede de Cluster (NETFT.SYS) é colocado automaticamente na parte inferior da lista de ordem de associação.

Verificar o recurso Validar Comunicação de Rede

A latência na rede também pode causar problemas. Os pacotes não são perdidos entre os nós, mas não chegam aos nós com rapidez suficiente antes que o tempo limite expire.

Esse teste valida se os servidores testados estão se comunicando com latência aceitável em todas as redes.

Por exemplo: em Validar Comunicação de Rede, pode aparecer as seguintes mensagens de problemas de latência de rede:

Succeeded in pinging network interface node003.contoso.com IP Address 192.168.0.2 from network interface node004.contoso.com IP Address 192.168.0.3 with maximum delay 500 after 1 attempt(s).
Either address 10.0.0.96 is not reachable from 192.168.0.2 or **the ping latency is greater than the maximum allowed 2000 ms** 
This may be expected, since network interfaces node003.contoso.com - Heartbeat Network and node004.contoso.com - Production Network are on different cluster networks
Either address 192.168.0.2 is not reachable from 10.0.0.96 or **the ping latency is greater than the maximum allowed 2000 ms** 
This may be expected, since network interfaces node004.contoso.com - Production Network and node003.contoso.com - Heartbeat Network for MSCS are on different cluster networks

Para clusters multissites, você pode aumentar o valor do tempo limite. Para obter mais informações, veja Definir configurações de heartbeat e DNS em um cluster multissite de failover.

Use o ISP para verificar se há problemas de conectividade de WAN.

Verifique se você encontrou algum dos problemas a seguir.

Pacotes de rede perdidos entre os nós

  1. Verificar a perda de pacotes usando o Desempenho

    Se o pacote for perdido na rede, em algum lugar entre os nós, os heartbeats falharão. Para descobrir de forma fácil se esse problema ocorre, use o Monitor de Desempenho e analise o contador "Interface de Rede\Pacotes Recebidos Descartados". Depois de adicionar esse contador, examine os números de Média, Mínimo e Máximo e, se contiverem um valor maior do que zero, o buffer de recebimento do adaptador precisará ser ajustado para cima.

    Captura de tela da janela Adicionar contadores.

    Se você estiver enfrentando a perda de pacotes de rede na plataforma de virtualização VMware, consulte a seção "Cluster instalado na plataforma de virtualização VMware".

  2. Atualizar drivers NIC

    Esse problema pode ocorrer devido a drivers\Componentes de Integração (IC)\VmTools NIC desatualizados ou adaptadores NIC defeituosos. Se houver pacotes de rede perdidos entre os nós em computadores físicos, atualize o driver do adaptador de rede. Drivers de placa de rede e/ou firmware antigos ou desatualizados. Às vezes, uma simples configuração incorreta da placa de rede ou do switch também pode causar perda de heartbeats.

Cluster instalado na plataforma de virtualização do VMware

Em ambientes VMware, verifique os problemas do adaptador VMware.

Esse problema poderá ocorrer se os pacotes forem descartados durante tráfego alto intermitente. Verifique se o tráfego está sendo filtrado (por exemplo, uso de filtro de email). Depois de eliminar essa possibilidade, aumente gradualmente o número de buffers no sistema operacional convidado e monitore.

Para reduzir as quedas em tráfego intermitente, siga estas etapas:

  1. Selecione Iniciar, selecione Executar, digite devmgmt.msc e pressione Enter.
  2. Expanda Adaptadores de rede, clique com o botão direito do mouse em vmxnet3 e selecione Propriedades.
  3. Selecione a guia Avançado.
  4. Selecione Buffers Rx pequenos e aumente o valor. O valor padrão é 512 e o máximo é 8192.
  5. Selecione Rx Ring #1 Size e aumente o valor. O valor padrão é 1024 e o máximo é 4096.

Verifique os seguintes artigos para verificar os problemas do adaptador VMware no caso do ambiente VMware:

Constatar congestionamentos de rede

Congestionamentos de rede também podem causar problemas de conectividade de rede.

Verifique se a rede está configurada de acordo com as recomendações da MS e do fornecedor. Confira Configuração de redes de Cluster de failover do Windows.

Verificar a configuração de rede

Se ainda não funcionar, verifique se você viu a rede particionada na GUI do cluster ou se o agrupamento NIC está habilitado na NIC de pulsação.

Se houver rede particionada na GUI do cluster, confira Redes de Cluster "particionadas" para solucionar o problema.

Se o NIC Teaming estiver habilitado no heartbeat do NIC, verifique a funcionalidade do software Teaming de acordo com as recomendações do fornecedor.

Atualizar drivers NIC

Esse problema pode ocorrer devido a drivers NIC desatualizados ou adaptadores NIC defeituosos.

Se ocorrer perda de pacotes de rede entre os nós em computadores físicos, atualize o driver do adaptador de rede. Drivers de placa de rede e/ou firmware antigos ou desatualizados.

Às vezes, uma simples configuração incorreta da placa de rede ou do switch também pode causar perda de heartbeats.

Verificar a configuração de rede

Se ainda não funcionar, verifique se você viu a rede particionada na GUI do cluster ou se o agrupamento NIC está habilitado na NIC de pulsação.