Condividi tramite

Risolvere i problemi del cluster con l'ID evento 1135

  • Articolo

Questo articolo illustra come diagnosticare e risolvere l'ID evento 1135, che può essere registrato durante l'avvio del servizio cluster nell'ambiente Clustering di failover.

Si applica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versioni 21H2 e 20H2

Provare l'agente virtuale: consente di identificare e risolvere rapidamente i problemi comuni di replica di Active Directory.

Pagina iniziale

L'ID evento 1135 indica che uno o più nodi del cluster sono stati rimossi dall'appartenenza al cluster di failover attivo. Può essere accompagnato dai sintomi seguenti:

È consigliabile eseguire una convalida e i test di rete come uno dei passaggi iniziali per la risoluzione dei problemi per assicurarsi che non siano presenti problemi di configurazione che potrebbero causare problemi.

Il servizio cluster è il componente software essenziale che controlla tutti gli aspetti dell'operazione del cluster di failover e gestisce il database di configurazione del cluster. Se viene visualizzato l'ID evento 1135, è consigliabile installare le correzioni menzionate negli articoli seguenti e riavviare tutti i nodi del cluster, quindi osservare se il problema si ripete.

Controllare se il servizio cluster è in esecuzione in tutti i nodi

Seguire il comando seguente in base al sistema operativo Windows per verificare che il servizio cluster sia in esecuzione e disponibile in modo continuo.

Per il cluster Windows Server 2008 R2

Da un prompt dei comandi con privilegi elevati, eseguire cluster.exe node /stat.

Per il cluster Windows Server 2012 e Windows Server 2012 R2

Eseguire il cmdlet di PowerShell seguente: Get-ClusterResource

Il servizio cluster è in esecuzione e disponibile in modo continuo in tutti i nodi?

Diversi scenari di ID evento 1135

Si vuole esaminare più in dettaglio i log eventi di sistema in tutti i nodi del cluster. Esaminare l'ID evento 1135 visualizzato nei nodi e copiare tutte le istanze di questo evento. Ciò consentirà di esaminare e rivedere.

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.

Esistono tre scenari tipici:

Scenario A

Tutti gli eventi e tutti i nodi del cluster indicano che NODE A ha perso la comunicazione.

Diagramma che mostra la comunicazione del nodo A, del nodo B e del nodo C.

Diagramma che mostra che il nodo A ha perso la comunicazione con il nodo B e il nodo C.

Potrebbe essere possibile che, quando si visualizzano i log di sistema nel NODO A, siano presenti eventi per tutti i nodi rimanenti nel cluster.

Soluzione

Ciò suggerisce piuttosto che al momento del problema, a causa della congestione della rete o altrimenti la comunicazione con il NODO A è stata persa.

È consigliabile esaminare e convalidare i problemi di configurazione e comunicazione di rete. Ricordarsi di cercare i problemi relativi al nodo A.

Scenario B

Si stanno esaminando gli eventi nei nodi e si supponga che il cluster sia disperso in due siti. NODE A, NODE B e NODE C nel sito 1 e NODE D & NODE E nel sito 2.

Diagramma che mostra che il sito 1 comunica correttamente con il sito 2 tramite un collegamento WAN.

Nei nodi A, B e C si noterà che gli eventi registrati sono per la connettività ai nodi D & E. Analogamente, quando vengono visualizzati gli eventi nei nodi D & E, gli eventi suggeriscono che si perde la comunicazione con A, B e C.

Diagramma che mostra che Site 1 ha perso la connessione WAN Link con site 2.

Soluzione

Se viene visualizzata un'attività simile, è indicativo che si è verificato un errore di comunicazione, tramite il collegamento che connette questi siti. È consigliabile esaminare la connessione tra i siti, se si tratta di una connessione WAN, è consigliabile verificare con l'ISP sulla connettività.

Scenario C

Si esaminano gli eventi nei nodi e si noterà che i nomi dei nodi non vengono associato a un modello specifico. Si supponga che il cluster sia disperso in due siti. NODO A, NODO B e NODO C nel sito 1 e NODE D & NODE E nel sito 2.

  • Nel nodo A: sono visualizzati gli eventi per i nodi B, D, E.
  • Nel nodo B: sono visualizzati gli eventi per i nodi C, D, E.
  • Nel nodo C: sono visualizzati gli eventi per i nodi A, B, E.
  • Nel nodo D: sono visualizzati eventi per i nodi A, C, E.
  • Nel nodo E: sono visualizzati gli eventi per i nodi B, C, D.
  • O qualsiasi altra combinazione.

Diagramma dello scenario C che mostra che il cluster è disperso in due siti.

Soluzione

Tali eventi sono possibili quando i canali di rete tra i nodi vengono soffocati e i messaggi di comunicazione del cluster non raggiungono in modo tempestivo, rendendo il cluster a sentire che la comunicazione tra i nodi viene persa con conseguente rimozione dei nodi dall'appartenenza al cluster.

Esaminare le reti cluster

È consigliabile esaminare le reti cluster controllando le tre opzioni seguenti una alla volta per continuare questa guida alla risoluzione dei problemi.

Verificare la presenza di esclusione antivirus

Escludere i percorsi del file system seguenti dall'analisi di virus in un server che esegue Servizi cluster:

  • Percorso del server di controllo della condivisione file
  • Cartella %Systemroot%\Cluster

Configurare il componente di analisi in tempo reale all'interno del software antivirus per escludere le directory e i file seguenti:

  • Directory di configurazione della macchina virtuale predefinita (C:\ProgramData\Microsoft\Windows\Hyper-V)

  • Directory di configurazione delle macchine virtuali personalizzate

  • Directory predefinita dell'unità disco rigido virtuale (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)

  • Directory di unità disco rigido virtuale personalizzate

  • Directory dei dati di replica personalizzate, se si usa la replica Hyper-V

  • Directory snapshot

  • mms.exe

    Note

    Questo file può essere configurato come esclusione di processi all'interno del software antivirus.

  • Vmwp.exe

    Note

    Questo file può essere configurato come esclusione di processi all'interno del software antivirus.

Inoltre, quando si usa Live Migration insieme ai volumi condivisi del cluster, escludere il percorso CSV C:\Clusterstorage e tutte le relative sottodirectory. Se si stanno risolvendo problemi di failover o problemi generali con i servizi cluster e il software antivirus è installato, disinstallare temporaneamente il software antivirus o rivolgersi al produttore del software per determinare se il software antivirus funziona con i servizi cluster. La semplice disabilitazione del software antivirus non è sufficiente nella maggior parte dei casi. Anche se si disabilita il software antivirus, il driver di filtro viene ancora caricato quando si riavvia il computer.

Verificare la configurazione delle porte di rete nel firewall

Il Servizio cluster controlla le operazioni del cluster di server e gestisce il database del cluster. Un cluster è un insieme di computer indipendenti che agiscono come un singolo computer. I responsabili, i programmatori e gli utenti vedono il cluster come un singolo sistema. Il software distribuisce i dati tra i nodi del cluster. Se un nodo non funziona, altri nodi forniscono i servizi e i dati precedentemente forniti dal nodo mancante. Quando un nodo viene aggiunto o ripristinato, il software del cluster esegue la migrazione di alcuni dati a tale nodo.

Nome del servizio di sistema: ClusSvc

Applicazione Protocollo Porte
Servizio cluster UDP 3343
Servizio cluster TCP 3343 (questa porta è necessaria durante un'operazione di aggiunta al nodo).
RPC TCP 135
Amministratore del cluster UDP 137
Kerberos UDP/TCP 464*
SMB TCP 445
Porte UDP elevate allocate in modo casuale** UDP Numero di porta casuale compreso tra 1024 e 65535
Numero di porta casuale compreso tra 49152 e 65535*

Note

Inoltre, per la convalida corretta nei cluster di failover Windows in Windows Server 2008 e versioni successive, consentire il traffico in ingresso e in uscita per ICMP4, ICMP6.

Questo è l'intervallo in Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008 e Windows Vista.

Eseguire inoltre il comando seguente per verificare la configurazione delle porte di rete nel firewall. Ad esempio: questo comando consente di determinare la porta 3343 disponibile\aperta usata per il cluster di failover:

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

Eseguire il report Di convalida cluster per eventuali errori o avvisi

Lo strumento di convalida del cluster esegue un gruppo di test per verificare che l'hardware e le impostazioni siano compatibili con il clustering di failover.

Seguire queste istruzioni:

  1. Eseguire il report Convalida cluster per eventuali errori o avvisi. Per altre informazioni, vedere Informazioni sui test di convalida del cluster: Rete

    Screenshot dei risultati dopo l'esecuzione del report Convalida cluster per eventuali errori o avvisi.

  2. Verificare la ricerca di avvisi ed errori per reti. Per altre informazioni, vedere Informazioni sui test di convalida del cluster: rete.

    Screenshot dei risultati per categoria.

    Screenshot di Convalida configurazione di Windows Firewall in Rete.

Controllare l'ordine di associazione di rete elenco

Questo test elenca l'ordine in cui le reti sono associate alle schede in ogni nodo.

Nella scheda Adapters and Bindings (Schede e associazioni) sono elencate le connessioni nell'ordine in cui le connessioni sono accessibili dai servizi di rete. L'ordine di queste connessioni riflette l'ordine in cui le chiamate/pacchetti TCP/IP generici vengono inviate in rete.

Seguire questa procedura per modificare l'ordine di associazione delle schede di rete:

  1. Selezionare Start, selezionare Esegui, digitare ncpa.cpl e quindi selezionare OK. È possibile visualizzare le connessioni disponibili nella sezione LAN e Internet ad alta velocità della finestra Connessioni di rete.
  2. Nel menu Avanzate selezionare Impostazioni avanzate e quindi selezionare la scheda Adapters and Bindings (Adattatori e associazioni).
  3. Nell'area Connessioni selezionare la connessione che si desidera spostare in alto nell'elenco. Usare i pulsanti freccia per spostare la connessione. Come regola generale, la scheda che comunica con la rete (connettività del dominio, routing ad altre reti e così via) deve essere la prima scheda associata (superiore all'elenco).

I nodi del cluster sono sistemi multi-homed. La priorità di rete influisce sul client DNS per la connettività di rete in uscita. Le schede di rete usate per la comunicazione client devono trovarsi nella parte superiore dell'ordine di associazione. Le reti non indirizzate possono essere posizionate con priorità più bassa. In Windows Server 2012 e Windows Server 2012 R2 la scheda Driver di rete cluster (NETFT.SYS) viene posizionata automaticamente nella parte inferiore dell'elenco degli ordini di associazione.

Controllare la convalida delle comunicazioni di rete

La latenza nella rete potrebbe anche causare questo problema. I pacchetti potrebbero non andare persi tra i nodi, ma potrebbero non arrivare ai nodi abbastanza velocemente prima della scadenza del periodo di timeout.

Questo test verifica che i server testati possano comunicare con latenza accettabile in tutte le reti.

Ad esempio: in Convalida comunicazione di rete è possibile che vengano visualizzati i messaggi seguenti per i problemi di latenza di rete:

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

Per il cluster multisito, è possibile aumentare i valori di timeout. Per altre informazioni, vedere Configurare le impostazioni heartbeat e DNS in un cluster di failover multisito.

Verificare con ISP eventuali problemi di connettività WAN.

Verificare se si verifica uno dei problemi seguenti.

Pacchetti di rete persi tra nodi

  1. Controllare la perdita di pacchetti usando le prestazioni

    Se il pacchetto viene perso in transito tra i nodi, gli heartbeat avranno esito negativo. È possibile scoprire facilmente se si tratta di un problema usando Monitor prestazioni per esaminare il contatore "Network Interface\Packets Received Discarded". Dopo aver aggiunto questo contatore, esaminare i numeri Average, Minimum e Maximum e se sono un valore superiore a zero, il buffer di ricezione deve essere regolato per l'adattatore.

    Screenshot della finestra Aggiungi contatori.

    Se si verificano problemi di pacchetti di rete persi nella piattaforma di virtualizzazione VMware, vedere la sezione "Cluster installato nella piattaforma di virtualizzazione VMware".

  2. Aggiornare i driver della scheda di interfaccia di rete

    Questo problema può verificarsi a causa di driver NIC obsoleti\Integration Components (IC)\VmTools o schede di interfaccia di rete non riuscite. Se sono presenti pacchetti di rete persi tra i nodi nei computer fisici, aggiornare il driver della scheda di rete. Driver e/o firmware delle schede di rete precedenti o non aggiornati. A volte, una semplice configurazione errata della scheda di rete o del commutatore può anche causare la perdita di heartbeat.

Cluster installato nella piattaforma di virtualizzazione VMware

Verificare i problemi dell'adapter VMware in caso di ambiente VMware.

Questo problema può verificarsi se i pacchetti vengono eliminati durante picchi di traffico elevati. Assicurarsi che non si verifichi alcun filtro del traffico, ad esempio con un filtro di posta elettronica. Dopo aver eliminato questa possibilità, aumentare gradualmente il numero di buffer nel sistema operativo guest e verificare.

Per ridurre le cadute del traffico burst, seguire questa procedura:

  1. Selezionare Start, selezionare Esegui, digitare devmgmt.msc e premere INVIO.
  2. Espandere Schede di rete, fare clic con il pulsante destro del mouse su vmxnet3 e scegliere Proprietà.
  3. Selezionare la scheda Avanzate.
  4. Selezionare Small Rx Buffers (Buffer Rx piccoli) e aumentare il valore. Il valore predefinito è 512 e il valore massimo è 8192.
  5. Selezionare Rx Ring #1 Size (Anello Rx n. 1 ) e aumentare il valore. Il valore predefinito è 1024 e il valore massimo è 4096.

Controllare gli articoli seguenti per verificare i problemi dell'adapter VMware in caso di ambiente VMware:

Si noti qualsiasi congestione della rete

La congestione della rete può anche causare problemi di connettività di rete.

Verificare che la rete sia configurata in base alle raccomandazioni di MS e fornitore, vedere Configurazione delle reti del cluster di failover Windows.

Controllare la configurazione di rete

Se non funziona ancora, verificare se è stata rilevata una rete partizionata nell'interfaccia utente grafica del cluster o se il gruppo NIC è abilitato nella scheda di interfaccia di rete heartbeat.

Se viene visualizzata la rete partizionata nell'interfaccia utente grafica del cluster, vedere Reti cluster partizionate per risolvere il problema.

Se il gruppo NIC è abilitato nella scheda di interfaccia di rete heartbeat, controllare la funzionalità del software teaming in base alle raccomandazioni del fornitore del teaming.

Aggiornare i driver della scheda di interfaccia di rete

Questo problema può verificarsi a causa di driver NIC obsoleti o schede di interfaccia di rete difettose.

Se sono presenti pacchetti di rete persi tra i nodi nei computer fisici, aggiornare il driver della scheda di rete. Driver e/o firmware delle schede di rete precedenti o non aggiornati.

A volte, una semplice configurazione errata della scheda di rete o del commutatore può anche causare la perdita di heartbeat.

Controllare la configurazione di rete

Se non funziona ancora, verificare se è stata rilevata una rete partizionata nell'interfaccia utente grafica del cluster o se il gruppo NIC è abilitato nella scheda di interfaccia di rete heartbeat.