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:
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