Problema con i nodi rimossi dall'appartenenza al cluster di failover attivo

Questo articolo illustra come risolvere in modo casuale i problemi in cui i nodi vengono rimossi dall'appartenenza al cluster di failover attivo.

Sintomi

Quando si verifica il problema, vengono visualizzati eventi come questo evento registrato nel registro eventi di sistema:

Questo evento viene registrato su tutti i nodi del cluster, ad eccezione del nodo rimosso. Il motivo di questo evento è dovuto al fatto che uno dei nodi nel cluster ha contrassegnato il nodo come inattivo. Notifica quindi tutti gli altri nodi dell'evento. Quando i nodi ricevono una notifica, interrompono e disattivino le connessioni heartbeat al nodo inattivo.

Cosa ha causato l'arresto del nodo

Tutti i nodi di un cluster di failover di Windows 2008 o 2008 R2 comunicano tra loro tramite le reti impostate per consentire la comunicazione di rete del cluster in questa rete. I nodi inviano pacchetti heartbeat attraverso queste reti a tutti gli altri nodi. Questi pacchetti devono essere ricevuti dagli altri nodi e quindi viene inviata una risposta. Ogni nodo nel cluster ha i propri heartbeat che verrà monitorati per garantire che la rete sia in funzione e che gli altri nodi siano in attività. L'esempio seguente consente di chiarire questo comportamento:

Se uno di questi pacchetti non viene restituito, l'heartbeat specifico viene considerato non riuscito. Ad esempio, W2K8-R2-NODE2 invia una richiesta e riceve una risposta da W2K8-R2-NODE1 a un pacchetto heartbeat in modo da determinare la rete e il nodo è attivo. Se W2K8-R2-NODE1 invia una richiesta a W2K8-R2-NODE2 e W2K8-R2-NODE1 non ottiene la risposta, viene considerato un heartbeat perso e W2K8-R2-NODE1 ne tiene traccia. Questa risposta persa può far in modo che W2K8-R2-NODE1 mostri la rete come inattiva fino a quando non viene ricevuta un'altra richiesta di heartbeat.

Per impostazione predefinita, i nodi cluster hanno un limite di cinque errori in 5 secondi prima che la connessione venga contrassegnata come inattiva. Pertanto, se W2K8-R2-NODE1 non riceve la risposta cinque volte nel periodo di tempo, considera inattiva la route specifica per W2K8-R2-NODE2. Se altre route sono ancora considerate attive, W2K8-R2-NODE2 rimarrà un membro attivo.

Se tutte le route sono contrassegnate per W2K8-R2-NODE2, vengono rimosse dall'appartenenza al cluster di failover attivo e viene registrato l'evento 1135 visualizzato nella prima sezione. In W2K8-R2-NODE2 il servizio cluster viene terminato e quindi riavviato in modo che possa provare a tornare nuovamente al cluster.

Per altre informazioni su come gestire route specifiche che si discendono con tre o più nodi, vedere il blog "Partitioned" Cluster Networks scritto da Jeff Hughes.

Ora che sappiamo come funziona il processo heartbeat, quali sono alcune delle cause note per il fallimento del processo

1. Errori hardware di rete effettivi. Se il pacchetto viene perso sul cavo da qualche parte tra i nodi, gli heartbeat hanno esito negativo. Una traccia di rete da entrambi i nodi coinvolti rivelerà questo aspetto.

2. È possibile che il profilo per le connessioni di rete rimbalzi da Dominio a Pubblico e di nuovo a Dominio. Durante la transizione di queste modifiche, l'I/O di rete può essere bloccato. È possibile verificare se questo è il caso esaminando il log operativo del profilo di rete. È possibile trovare questo log aprendo il Visualizzatore eventi e passando a Registri applicazioni e servizi\Microsoft\Windows\NetworkProfile\Operational. Esaminare gli eventi in questo log nel nodo indicato nell'ID evento 1135 e verificare se il profilo stava cambiando in questo momento. In tal caso, vedere Il profilo del percorso di rete passa da "Dominio" a "Pubblico" in Windows 7 o in Windows Server 2008 R2.

3. IPv6 è abilitato nei server, ma le due regole seguenti sono disabilitate per in ingresso e in uscita in Windows Firewall:

   • Rete di base - Annuncio di individuazione adiacente
   • Rete di base - Richiesta di individuazione adiacente

4. Il software antivirus potrebbe interferire anche con questo processo. In caso di sospetto, eseguire il test disabilitando o disinstallando il software. Eseguire questa operazione a proprio rischio perché a questo punto non si è protetti da virus.

5. La latenza sulla 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.

6. IPv6 è il protocollo predefinito che verrà usato dal clustering di failover per i relativi heartbeat. L'heartbeat stesso è un pacchetto di rete unicast UDP che comunica sulla porta 3343. Se sono presenti commutatori, firewall o router non configurati correttamente per consentire il traffico, è possibile riscontrare problemi come questo.

7. Anche gli aggiornamenti dei criteri di sicurezza IPsec possono causare questo problema. Il problema specifico è che durante un aggiornamento dei criteri di gruppo IPSec tutte le associazioni di sicurezza IPsec vengono eliminate da Windows Firewall con sicurezza avanzata (WFAS). In questo caso, tutta la connettività di rete è bloccata. Quando si rinegoziano le associazioni di sicurezza in caso di ritardi nell'esecuzione dell'autenticazione con Active Directory, questi ritardi (in cui tutte le comunicazioni di rete sono bloccate) impediranno anche il passaggio degli heartbeat del cluster e causeranno il monitoraggio dell'integrità del cluster per rilevare i nodi come inattivi se non rispondono entro la soglia di 5 secondi.

8. Driver e/o firmware di schede di rete obsoleti o obsoleti. A volte, una semplice configurazione errata della scheda di rete o del commutatore può anche causare la perdita di heartbeat.

9. Le schede di rete moderne e le schede di rete virtuale potrebbero riscontrare la perdita di pacchetti. Questa operazione può essere rilevata aprendo Monitor prestazioni e aggiungendo il contatore "Network Interface\Packets Received Discarded". Questo contatore è cumulativo e aumenta solo fino al riavvio del server. La visualizzazione di un numero elevato di pacchetti eliminati potrebbe essere un segno che i buffer di ricezione nella scheda di rete sono troppo bassi o che il server sta eseguendo lentamente e non è in grado di gestire il traffico in ingresso. Ogni produttore di schede di rete sceglie se esporre queste impostazioni nelle proprietà della scheda di rete, quindi è necessario fare riferimento al sito Web del produttore per imparare ad aumentare questi valori e i valori consigliati devono essere usati. Se si esegue su VMware, il blog seguente illustra questo problema in modo più dettagliato, tra cui come stabilire se questo è il problema, nonché indica l'articolo VMware sulle impostazioni da modificare.

   Nodi rimossi dall'appartenenza al cluster di failover in VMware ESX

Questi sono i motivi più comuni per cui questi eventi vengono registrati, ma potrebbero esserci anche altri motivi. Il punto di questo blog è stato quello di darvi alcune informazioni sul processo e anche dare idee su cosa cercare. Alcuni genereranno i valori seguenti ai valori massimi per tentare di arrestare il problema.

Parametro	Predefinita	Intervallo
SameSubnetDelay	1000 millisecondi	250-2000 millisecondi
CrossSubnetDelay	1000 millisecondi	250-4000 millisecondi
SameSubnetThreshold	5	3-10
CrossSubnetThreshold	5	3-10

L'aumento di questi valori al massimo potrebbe far sparire l'evento e la rimozione del nodo, mascherando semplicemente il problema. Non risolve nulla. La cosa migliore da fare è scoprire la causa radice degli errori di heartbeat e fissarla. L'unica reale necessità di aumentare questi valori è in uno scenario multisito in cui i nodi risiedono in posizioni diverse e la latenza di rete non può essere superata.