Cluster Service – Il Poison Packet


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

Comments (0)

Skip to main content