Solucionar problemas de cluster com a ID do evento 1135

Este artigo ajuda você a diagnosticar e resolve ID do evento 1135, que pode ser registrada 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

Página inicial

A ID do evento 1135 indica que um ou mais nós de cluster foram removidos da associação de cluster de failover ativo. Pode ser acompanhado pelos seguintes sintomas:

• O failover de cluster\nodes que estão sendo removidos da associação de cluster de failover ativo:

  Ter um problema com nós sendo removidos da associação ativa do Cluster de Failover

• ID do evento 1069:

  ID do evento 1069 – Disponibilidade de aplicativo ou serviço clusterizado

• ID do evento 1177 para perda de Quorum:

  ID do evento 1177 – Quorum e conectividade necessários para Quorum

• A ID do evento 1006 para o serviço cluster foi interrompida:

  ID do evento 1006 – Inicialização do Serviço de Cluster

Uma validação e os testes de rede seriam recomendados como uma das etapas iniciais de solução de problemas para garantir que não haja problemas de configuração que possam ser uma causa de problemas.

Verificar se foram instaladas as correções quentes recomendadas

O serviço 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 de cluster. Se você vir a ID do evento 1135, recomendamos instalar as correções mencionadas nos artigos a seguir e reiniciar todos os nós do cluster e observar se o problema ocorrer novamente.

• Hotfixes e atualizações recomendados para clusters de failover baseados no Windows Server 2012 R2
• Hotfixes e atualizações recomendados para clusters de failover baseados no Windows Server 2012
• Hotfixes e atualizações recomendados para clusters de failover do Windows Server 2008 R2 SP1

Verifique se o serviço de cluster em execução em todos os nós

Siga o comando a seguir de acordo com seu sistema de operações do Windows para validar que o serviço de cluster está em execução e disponível continuamente.

Para o cluster do Windows Server 2008 R2

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

Para Windows Server 2012 e Windows Server 2012 cluster R2

Execute o seguinte cmdlet do PowerShell: Get-ClusterResource

O serviço de cluster está continuamente em execução e disponível em todos os nós?

Vários cenários da ID de Evento 1135

Queremos que você examine mais de perto 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 deste evento. Isso tornará conveniente para você olhar para eles e examinar.

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 típicos:

Cenário A

Você está olhando para todos os Eventos e todos os nós no cluster estão indicando que o NODE A havia perdido a comunicação.

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

Solução

Isso sugere que, no momento do problema, devido ao congestionamento da rede ou caso contrário, a comunicação com o NODE A foi perdida.

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

Cenário B

Você está olhando para os Eventos nos nós e vamos dizer que seu cluster está disperso em dois sites. NODE A, NODE B e NODE C no Site 1 e NODE D & NODE E no Site 2.

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

Solução

Se você vir 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 isso for por meio de uma conexão WAN, sugerimos que você verifique com seu ISP sobre a conectividade.

Cenário C

Você está olhando para os Eventos nos nós e vê que os nomes dos nós não estão em contagem com nenhum padrão específico. Digamos que seu cluster está disperso em dois sites. NODE A, NODE B e NODE C no Site 1 e NODE D & NODE E no Site 2.

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

Solução

Tais eventos são possíveis quando os canais de rede entre os nós são sufocados e as mensagens de comunicação do cluster não são acessadas em tempo hábil, fazendo com que o cluster sinta que a comunicação entre os nós é perdida, resultando na remoção de nós da associação de cluster.

Examinar redes de cluster

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

Verificar a exclusão de antivírus

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

• O caminho da Testemunha fileshare
• A pasta %Systemroot%\Cluster

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

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

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

• Diretório de disco rígido virtual padrão (C:\Users\Public\Documents\Hyper-V\Discos Rígidos Virtuais)

• Diretórios personalizados de disco rígido virtual

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

• Diretórios instantâneos

• mms.exe

  Observação

  Esse arquivo pode ter que ser configurado como uma exclusão de processo no software antivírus.

• Vmwp.exe

  Observação

  Esse arquivo pode ter que ser configurado como uma exclusão de processo no software antivírus.

Além disso, quando você usa a Migração Dinâmica junto com Volumes Compartilhados de Cluster, exclua o caminho CSV C:\Clusterstorage e todos os seus subdiretórios. Se você estiver solucionando problemas de failover ou problemas gerais com serviços de cluster e software antivírus estiver instalado, desinstale temporariamente o software antivírus ou marcar com o fabricante do software para determinar se o software antivírus funciona com serviços de Cluster. Apenas desabilitar o software antivírus é insuficiente na maioria dos casos. Mesmo que você desabilite o software antivírus, o driver de filtro ainda será carregado quando você reinicia o computador.

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

O serviço de Cluster controla as operações de cluster de servidor e gerencia o banco de dados de cluster. Um cluster é uma coleção de computadores independentes que atuam como um único computador. Gerenciadores, programadores e usuários vêem o cluster como um único sistema. O software distribui dados entre os nós do cluster. Se um nó falhar, outros nós fornecem os serviços e dados que eram fornecidos anteriormente pelo nó que está faltando. Quando um nó é adicionado ou reparado, o software do cluster migra alguns dados para aquele nó.

Nome de serviço do sistema: ClusSvc

• Para obter mais informações, confira Criando um cluster de failover Windows Server 2012 falha com 0xc000005e de erro.
• Para obter mais informações sobre como personalizar essas portas, consulte a seção "Referências" na visão geral do serviço e nos requisitos da porta de rede para Windows.

Esse é o intervalo em Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008 e Windows Vista.

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

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

Execute o relatório de validação de cluster para quaisquer 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 o failover clustering.

Siga estas instruções:

1. Execute o relatório de validação de cluster para quaisquer erros ou avisos. Para obter mais informações, confira Noções básicas sobre testes de validação de cluster: Rede

   

2. Verifique se há avisos e erros para Redes. Para obter mais informações, consulte Noções básicas sobre testes de validação de cluster: rede.

   

   

Verificar a ordem de associação de rede de lista

Este teste lista a ordem na qual as redes estão associadas aos adaptadores em cada nó.

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

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

1. Selecione Iniciar, selecione Executar, digite ncpa.cple selecione OK. Você pode ver as conexões disponíveis na seção LAN e High-Speed Internet da janela Connections de rede.
2. No menu Avançado , selecione Configurações Avançadas e selecione a guia Adaptadores e Associações .
3. Na área Connections, selecione a conexão que você deseja mover mais alto na lista. Use os botões de seta para mover a conexão. Como regra geral, o cartão que fala com a rede (conectividade de domínio, roteamento para outras redes etc. deve ser o primeiro limite (topo da lista) cartão).

Os nós de cluster são sistemas multilocatários. A prioridade de rede afeta o cliente DNS para conectividade de rede de saída. Os adaptadores de rede usados para comunicação do cliente devem estar na parte superior da ordem de associação. Redes não roteadas podem ser colocadas em menor prioridade. Em Windows Server 2012 e Windows Server 2012 R2, o adaptador do Driver de Rede de Cluster (NETFT.SYS) é colocado automaticamente na parte inferior da lista de pedidos de associação.

Verificar a Comunicação de Rede validada

A latência em sua rede também pode fazer com que isso aconteça. Os pacotes podem não ser perdidos entre os nós, mas podem não chegar aos nós rapidamente o suficiente antes que o período de tempo limite expire.

Esse teste valida que os servidores testados podem se comunicar com latência aceitável em todas as redes.

Por exemplo: em Validar Comunicação de Rede, você pode ver as seguintes mensagens para 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 cluster de vários sites, você pode aumentar os valores de tempo limite. Para obter mais informações, consulte Configurar configurações de pulsação e DNS em um cluster de failover de vários sites.

Verifique com o ISP se há problemas de conectividade de WAN.

Verifique se você encontra algum dos seguintes problemas.

Pacotes de rede perdidos entre nós

1. Verificar a perda de pacote usando Desempenho

   Se o pacote for perdido no fio em algum lugar entre os nós, os batimentos cardíacos falharão. Podemos descobrir facilmente se esse é um problema usando Monitor de Desempenho para examinar o contador "Interface de Rede\Pacotes Descartados Recebidos". Depois de adicionar esse contador, examine os números Médio, Mínimo e Máximo e, se eles forem qualquer valor maior que zero, o buffer de recebimento precisará ser ajustado para o adaptador.

   

   Se você estiver experimentando o pacote de rede perdido na plataforma de virtualização do VMware, consulte a seção "Cluster instalado na plataforma de virtualização do VMware".

2. Atualizar os drivers nic

   Esse problema pode ocorrer devido a drivers nic desatualizados\Componentes de Integração (IC)\VmTools ou adaptadores NIC defeituosos. Se houver pacotes de rede perdidos entre nós em computadores físicos, tenha as atualizações do driver do adaptador de rede. A rede antiga ou desatualizada cartão drivers e/ou firmware. Às vezes, uma simples configuração incorreta da rede cartão ou comutador também pode causar perda de pulsações.

Cluster instalado na plataforma de virtualização do VMware

Verifique os problemas do adaptador do VMware no caso do ambiente VMware.

Esse problema poderá ocorrer se os pacotes forem descartados durante grandes intermitências de tráfego. Verifique se não há nenhuma filtragem de tráfego ocorrendo (por exemplo, com um filtro de email). Depois de eliminar essa possibilidade, aumente gradualmente o número de buffers no sistema operacional convidado e verifique.

Para reduzir as quedas de tráfego de intermitência, 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 de Rx Pequeno e aumente o valor. O valor padrão é 512 e o máximo é 8192.
5. Selecione Rx Ring #1 Tamanho e aumente o valor. O valor padrão é 1024 e o máximo é 4096.

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

• Nós sendo removidos da associação do Cluster de Failover no VMware ESX?.
• Grande perda de pacote no nível do sistema operacional convidado no VMXNET3 vNIC no ESXi

Observe qualquer congestionamento de rede

O congestionamento de rede também pode causar problemas de conectividade de rede.

Verifique se sua rede está configurada de acordo com as recomendações de MS e fornecedor, consulte Configurando redes de cluster de failover do Windows.

Verificar a configuração de rede

Se ainda não funcionar, marcar se você tiver visto a rede particionada no GUI do cluster ou tiver a equipe nic habilitada na NIC de pulsação.

Se você vir a rede particionada no GUI do cluster, consulte Redes de Cluster "Particionadas" para solucionar o problema.

Se você tiver a equipe nic habilitada na NIC de pulsação, marcar funcionalidade de software de teaming de acordo com a recomendação do fornecedor de equipe.

Atualizar os drivers nic

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

Se houver pacotes de rede perdidos entre nós em computadores físicos, tenha as atualizações do driver do adaptador de rede. A rede antiga ou desatualizada cartão drivers e/ou firmware.

Às vezes, uma simples configuração incorreta da rede cartão ou comutador também pode causar perda de pulsações.

Verificar a configuração de rede

Se ainda não funcionar, marcar se você viu a rede particionada no GUI do cluster ou se você tem a equipe nic habilitada na NIC de pulsação.