Cluster Service – Il Poison Packet

itentblg — Mon, 27 Jul 2009 02:00:00 GMT

In questo post cerchiamo di capire come si comporta il Cluster Service in caso di problemi di comunicazione tra i nodi e quando utilizza il poison packet.

Per semplicità consideriamo un cluster a 2 nodi, ma lo stesso identico scenario è applicabile anche a configurazioni con un numero di nodi maggiori.

Problema

Lo scenario tipico si ha quando il nodo 2, che non detiene il quorum, è stato rimosso dal cluster e il cluster service è arrestato.
Inoltre, se si tenta di avviare il cluster service manualmente, dopo pochi minuti si arresta automaticamente.
Ovviamente in una configurazione a 2 nodi questo limita l’high availability, in quanto un failover non sarebbe possibile con 1 nodo solo disponibile.

Raccolta e Analisi dei Dati

Il primo punto da verificare sono gli Eventi di sistema in quanto riportano tutti gli eventi generati dal Cluster Service, ClusDisk e ClusNet.

In particolare, eventi tipici sintomatici del problema sono i seguenti:

Warning       ClusSvc   1123   The node lost communication with cluster node 'Node2' on network 'Public'.             Nodo1
Warning       ClusSvc   1123   The node lost communication with cluster node 'Node2' on network 'Private'.            Nodo1
Information   ClusSvc   1122   The node (re)established communication with cluster node 'Node2' on network 'Public'. Nodo1
Information   ClusSvc   1122   The node (re)established communication with cluster node 'Node2' on network 'Private'. Nodo1

Seguito dal seguente evento:

Error ClusNet 1118 Cluster service was terminated as requested by Node 1. Node2

L’ultimo evento indicato permette di capire che i 2 nodi sono riusciti a comunicare: infatti il Nodo 1 richiede esplicitamente al Nodo 2 di arrestare il Cluster Service.

Analizziamo il cluster.log presente in C:\Windows\Cluster del nodo 2, e non negli altri nodi, in quando i file cluster.log contengono gli eventi specifici del nodo e quindi sono diversi gli uni dagli altri.
Notiamo i seguenti eventi in corrispondenza dell’ora indicata calcolata in GTM (fuso orario di Londra):

00001728.0000077c::2009/07/20-14:42:13.623 INFO [CS] Cluster Service started - Cluster Node Version 4.3790

00001728.00000a4c::2009/07/20-14:49:21.406 INFO [ClMsg] Received poison event.
00001728.00000a4c::2009/07/20-14:49:21.406 ERR [RGP] Node 2: REGROUP ERROR: poison packet received from node 1

La prima riga indica l’avvio del Cluster Service: questo avviene indipendentemente dalla volontà del cluster perché è il Service Control Manager del Sistema Operativo a riavviare il servizio ad intervalli regolari in base alle impostazioni.
Dopo soli 7 minuti il tentativo di regroup al cluster fallisce perché il Cluster Message notifica la ricezione del Poison Packet e questo termina ogni attività del Cluster Service istantaneamente.

Soluzione

In questo esempio, la sovrapposizione dei problemi di visibilità tra i due nodi e l’evento del Poison Packet indica evidenti problemi di comunicazione.

Questo comportamento avviene nel momento in cui un nodo del cluster fallisce un aggiornamento tramite GUM, in quel momento il nodo che detiene il Quorum invia il Poison Packet e blocca il nodo finchè l’aggiornamento non è eseguito correttamente.

Il seguente articolo illustra un caso particolare in cui un fallimento della comunicazione RPC genera il Poison Packet:

KB 326330 - The Cluster Service Detects RPC Errors 1726 and 1722

Per quanto riguarda gli errori di comunicazione, possono influire molto nella sincronizzazione dei nodi, e per questo consiglio la lettura di questo articolo:

KB 892422 - Overview of event ID 1123 and event ID 1122 logging in Windows 2000-based and Windows Server 2003-based server clusters

Quando il nodo 1, che ha incarico il quorum, non riceve un aggiornamento dall’altro per più di 6 volte il tempo di hearbeat (1.2 secondi) su tutte le schede di rete, lo considera offline e gli invia il Poison Packet.
Questa procedura serve per tutelare il corretto funzionamento di tutto il cluster, in quanto la parte con meno voti (in questo caso il Nodo 2) non deve interferire con la parte maggioritaria (Nodo 1 + Quorum) e tutti i servizi continuano a essere erogati correttamente.

Daniele Maso
Senior Support Engineer
Microsoft Enterprise Platforms Support

Cluster Service – Evict del nodo e Rimozione del Servizio

itentblg — Mon, 10 Nov 2008 04:00:00 GMT

Di seguito vediamo un caso molto particolare di evict automatico di un nodo da un cluster senza apparentemente alcuna spiegazione.

Lo scenario è formato da 2 nodi collegati tra di loro ad un rete di heartbeat condivisa tra più cluster.

Se gli indirizzi IP delle schede di rete non sono configurate correttamente oppure esiste un altro cluster con lo stesso nome collegato sulla rete, c’è il rischio di incorrere nell’evict automatico del nodo!

Se analizziamo il cluster log di un nodo che ha avuto questo problema, troveremo:

Date-Time WARN [JOIN] Attempting join with sponsor 192.168.222.23.
Date-Time INFO [NMJOIN] Beginning cluster join process.
Date-Time ERR [NMJOIN] Unable to begin join, status 5893.
Date-Time WARN [JOIN] NmJoinCluster failed, status 5893.

L’errore 5893 corrisponde a “ERROR_CLUSTER_INSTANCE_ID_MISMATCH” in cui appunto si fa riferimento al fatto che il nodo che ha provato a fare il join al cluster già esistente aveva un ID diverso e che non corrispondeva a quello condiviso nel quorum.

Gli eventi successivi indicano l’avvio della rimozione completa del nodo:

Date-Time INFO [INIT] Cleaning up failed join attempt.
Date-Time INFO [INIT] Leaving cluster
Date-Time INFO [NM] Interface cleanup starting...
Date-Time INFO [NM] Network interface cleanup complete
Date-Time INFO [NM] Network cleanup starting...
Date-Time INFO [NM] Network cleanup complete
Date-Time INFO [NM] Node cleanup starting...
Date-Time INFO [NM] Node cleanup complete
Date-Time WARN [NM] Shutdown of the Cluster Network driver failed, status 21
Date-Time INFO [INIT] Deregistering RPC endpoints & interfaces.
Date-Time WARN [INIT] This node has been evicted from the cluster when it was unavailable. Initiating cleanup.

Dopo questo evento il servizio cluster è completamente disinstallato dal server e non è più presente nell’elenco dei servizi attivi. La sequenza si conclude con questi eventi:

Date-Time ERR [CS] ClusterInitialize failed 5893
Date-Time WARN [INIT] The cluster service is shutting down.
Date-Time INFO [EVT] EvShutdown
Date-Time WARN [FM] Shutdown: Failover Manager requested to shutdown groups.
Date-Time INFO [FM] FmpCleanupGroups: Entry
Date-Time INFO [FM] FmpCleanupGroups: Exit
Date-Time INFO [Dm] DmShutdown
Date-Time INFO [DM] DmpShutdownFlusher: Entry
Date-Time INFO [DM] DmpShutdownFlusher: Setting event
Date-Time INFO [DM] DmpRegistryFlusher: got 0
Date-Time INFO [DM] DmpRegistryFlusher: exiting
Date-Time WARN [MM] MMLeave is called when rgp=NULL.
Date-Time ERR [CS] Service Stopped. exit code = 5893

Da questo momento in avanti, il nodo è tornato a far parte dei member server e non appartiene più al cluster.

Per poter risolvere il problema è necessario innanzitutto capire la causa del problema e risolverla quanto prima perché questo può causare altri “clean up” dei nodi involontari e ovviamente la perdita di ridondanza dei servizi clusterizzati.

Una volta risolto il problema, si può procedere con il join del nodo al cluster esistente in modo da poter ripristinare la situazione originale.