Ciao a tutti!

Recentemente abbiamo affrontato diverse situazioni in cui dei nodi di Failover Cluster con Sistema Operativo Windows Server 2003 perdessero apparentemente la connettività con gli altri nodi su tutte le schede di rete, per poi riottenerla correttamente dopo pochi secondi. Le cause che possono originare il problema sono molteplici, e con questo post le andremo a descrivere nel dettaglio.

Innanzitutto, vale la pena fare una breve panoramica sul funzionamento del processo di Heartbeat del Cluster, cioè come fa il sistema operativo ad accorgersi che ha/non ha connettività con gli altri nodi, e quali sono gli eventi che vengono tracciati nel System log.

Semplicemente, ogni 1.2 secondi (valore di default) il nodo del cluster invia dei pacchetti di “Is-Alive” verso gli altri nodi. I pacchetti viaggiano sulla porta UDP 3343, e vengono inviati da ogni interfaccia di rete ad ogni altra interfaccia di ogni altro nodo. Di conseguenza, il nodo riterrà di aver perso la connessione con gli altri qualora tali pacchetti non vengano ricevuti. By design, il cluster è stato progettato per garantire la massima affidabilità, e quindi sono presenti noti algoritmi di failover per non impattare il servizio del cluster stesso qualora dovessero occorrere problemi di rete (e quindi non vengano ricevuti i pacchetti di Heartbeat). Ovviamente, per ragioni pratiche è necessario settare dei “limiti di attesa” di tali pacchetti.

Event ID 1122 e 1123

Qualora non vengano ricevuti i pacchetti di Is-Alive entro due Heartbeat intervals (corrispondenti quindi ad un intervallo di 2.4 secondi) viene tracciato l’evento:

Event ID: 1123
Source: ClusSvc
Description:
The node lost communication with cluster node <ComputerName> on network <NetworkName>.

Dopodichè se viene ricevuto un Heartbeat dopo i 2.4 secondi (ma entro 4.8 secondi!) viene ripristinata la connessione e tracciato l’evento:

Event ID: 1122
Source: ClusSvc
Description:
The node (re)established communication with cluster node <ComputerName> on network <NetworkName>.

è bene specificare che una coppia di eventi 1122-1123 di per sè non evidenzia un problema al cluster, se viene tracciata in modo occasionale/sporadico, se corrisponde ad un istante temporale in cui un nodo viene spento/riavviato, e se non ci sono concomitanti failure di risorse del cluster. I problemi potrebbero eventualmente sorgere se gli eventi sono sistematici, o se sono seguiti dagli altri che andremo ora a descrivere.

Il Regroup Process

Se non vengono ricevuti Is-Alive da un altro nodo entro 4.8 secondi, il nodo verrà considerato “inactive” . In queste situazioni abbiamo l’evento:

Event ID: 1126
Source: ClusSvc
Description:
The interface for cluster node <ComputerName> on network <NetworkName> is unreachable by at least one other cluster node attached to the network. The cluster was not able to determine the location of the failure. Look for additional entries in the system event log indicating which other nodes have lost communication with node ClusterNode. If the condition persists, check the cable connecting the node to the network. Next, check for hardware or software errors in the node's network adaptor. Finally, check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Quando l’heartbeat è ricevuto entro 6 heartbeat intervals la connessione è ripristinata con:

Event ID: 1125
Source: ClusSvc
Description:
The interface for cluster node <ComputerName> on network <NetworkName> is operational (up). The node can communicate with all other available cluster nodes on the network.

Se invece non verrannò più ricevuti pacchetti dopo tali tempi, si assume che la rete sia definitivamente non disponibile e verrà scatenato il Regroup Process, che consiste semplicemente nel comunicare al Cluster che il nodo è fallito e quindi effettuare il failover di risorse che erano in carico a quel nodo. In queste occasioni saranno loggati quindi gli eventi più gravi:

Event Id: 1127
Source: ClusSvc
Description:
The interface for cluster node <ComputerName> on network <NetworkName> failed. If the condition persists, check the cable connecting the node to the network. Next, check for hardware or software errors in node's network adapter. Finally, check for failures in any network components to which the node is connected such as hubs, switches, or bridges.

e soprattutto:

Event ID: 1135
Source: ClusSvc
Description:
Cluster node <ComputerName> was removed from the active cluster membership. The Clustering Service may have been stopped on the node, the node may have failed, or the node may have lost communication with the other active cluster nodes.

Tornando al nostro problema iniziale, se osserviamo nel log System uno o più degli eventi sopracitati, siamo sicuri di che cosa è successo al nostro cluster: un pacchetto di Is-Alive Heartbeat è stato recapitato ad un altro nodo con un certo ritardo. Le conseguenza sul cluster dipenderanno dall’entità del ritardo stesso, ma la cosa principale su cui bisognerà concentrarsi è capire quindi perchè si è accumulato tale ritardo nella trasmissione all’interno della nostra rete.

Troubleshooting

Come anticipato precedentemente, sono molteplici le motivazioni che possono generare ritardo nella distribuzione del traffico di rete relativo al cluster. Di seguito riporteremo le cause e le procedure applicabili per prevenirle.

1) Problema di configurazione Heartbeat. Deve sempre esistere una rete dedicata al traffico intra-cluster sulla quale quindi non passa altro traffico che non quello di Heartbeat. Per farlo, bisogna selezionare la seguente opzione nelle proprietà della rete sulla consolle di Failover Cluster:

image

2) Binding Order. è necessario che su ogni nodo il binding order delle schede di rete sia configurato con la rete LAN – Public a più alta priorità della Heartbeat. Per modificare questo setting: dallo start menu, selezionare “Run” e digitare “ncpa.cpl” per accedere alla pagina di configurazione delle schede di rete. Dal menu, cliccare Advanced / Advanced Settings /Adapters and Bindings ed eventualmente effettuare la modifica utilizzando le frecce direzionali.

image

3) Scheda Public. Se dovessero venire loggati consistenti eventi solo sulla scheda di rete  “Public”, è consigliato che tale interfaccia di rete venga configurata come dedicata solo al traffico esterno e non in mixed mode. Per farlo, bisogna selezionare la seguente opzione nelle proprietà della rete sulla consolle di Failover Cluster:

clip_image002

4) Drivers schede di rete. è fondamentale che per ogni network i diversi nodi del cluster abbiano le stesse schede di rete aggiornate alla stessa versione dei drivers (possibilmente quelli più recenti). Inoltre è opportuno sottolineare che non è supportato avere schede di rete in Teaming per la rete Heartbeat (KB254101).

5) Configurazione schede di rete. Uno scenario tipico di comparsa del problema è l’utilizzo dell’AutoSense mode sulle schede di rete (KB174812). In questo caso, la NIC non conosce la velocità gestibile su quel tratto di rete (Ethernet 10/100/1000 Full o Half duplex) e procede a negoziarla con lo switch ad intervalli regolari. In questa situazione ovviamente avvengono dei momentanei reset della connessione che possono scatenare gli eventi 1122-1123. Il problema è ovviamente amplificato se la NIC usa una modalità di AutoSense mentre lo switch, ad esempio, una velocità fissa quale 100Mb Full-Duplex. Per risolvere è quindi opportuno configurare manualmente la velocità sulla scheda di rete dalle sue proprietà avanzate:

image

6) Configurazione apparati di rete. In caso di problemi agli switch, potrebbe essere sufficiente cambiare la porta fisica usata dal cluster. In aggiunta, ci sono problemi se STP è abilitato sullo switch per la porta utilizzata, ma la porta non è più in forwarding state. La soluzione è in questo caso disabilitare STP o utilizzare direttamente RSTP qualora sia supportato dallo switch.

7) Multicasting. In cluster a 3 o più nodi viene di default utilizzato il Multicast per distribuire i pacchetti Heartbeat. è consigliato quindi disabilitare il Multicast in caso incontriamo i problemi descritti in questo articolo. Ulteriori dettagli sulla procedura per disabilitare il Multicast sono riportati nella KB307962

8) VLAN. Qualora i nodi del cluster siano in una VLAN, è necessario mappare la connessione fra i nodi su una porta che è sullo stesso switch fisico.

9) Risorse di sistema. Questo punto è il più difficile da capire, ma anche il più affascinante da risolvere. In questo caso il sintomo sono i problemi di rete, ma di fatto la causa non è la rete!

Senza entrare troppo approfonditamente nel dettaglio tecnico del funzionamento di Windows, possiamo definire una DPC come una chiamata effettuata dal sistema operativo per gestire la prioritizzazione delle operazioni da effettuare in base alla loro criticità. Quando il sistema deve processare un pacchetto di rete in entrata/uscita invoca una DPC. Lo stesso meccanismo avviene per la gestione, ad esempio dello storage. Le DPC verranno successivamente gestite, in sequenza, dal sistema e tutti i task verranno sequenzialmente eseguiti in base alla priorità. Problemi di questo tipo sono solitamente accompagnati dagli eventi 2021-2022. Per ulteriori informazioni possiamo fare riferimento alla KB317249.

Un possibile scenario è quindi il seguente: l’alta attività di I/O sui dischi genera un altissimo numero di DPC che devono essere gestite dal sistema operativo. Quando arriverà il turno di inviare il pacchetto di rete che viene utilizzato come cluster heartbeat, la relativa richiesta DPC si va ad accodare a tutte quelle dello storage. Risultato: la richiesta di gestione di un pacchetto di rete deve “aspettare” di aver eseguito tutte quelle che erano già precedentemente in coda (Quelle sui dischi).

Se problemi di questo tipo si verificano in modo consistente, c’è poco da fare a livello Windows, poichè quello che è carente sono lo risorse fisiche del Server. E’ opportuno quindi verificare se il nostro Server sia effettivamente dimensionato per gestire tale carico.

L’unico workaround possibile a livello di Sistema Operativo, per poter ovviare ai problemi che vengono generato ad un livello fisico inferiore, è “rilassare” il timeout del cluster, cioè rendere più tollerante il cluster ad eventuali ritardi. Per farlo esiste una procedura, dettagliata nel paragrafo Configurable cluster heartbeats della KB921181.

  • Controllare che tutti i nodi siano attivi. Per farlo si può eseguire il seguente comando e verificare che lo status di tutti i nodi sia “up”:

cluster <cluster_name> node

  • Applicare la modifica al numero di missed heartbeats eseguendo i seguenti comandi (è importante specificare DWORD!!):

cluster cluster_name /priv HeartBeatLostInterfaceTicks=5:DWORD

cluster cluster_name /priv HeartBeatLostNodeTicks=10:DWORD

  • Stoppare e riavviare il cluster service su tutti i nodi. Per farlo:

net stop clussvc

net start clussvc

Questa modifica ci permetterà quindi di concedere al cluster qualche secondo in più per ricevere i pacchetti di heartbeat, ed evitare qualsiasi potenziale ma inutile azione di failover. La conseguenza sarà però che il cluster, nel caso in cui ci sia veramente un problema e l’altro nodo sia irraggiungibile, ci metterà qualche secondo in più ad accorgersene.

10) Antivirus e Softwares di Terze Parti. Recentemente ci è successo un problema di eventi 1126-1127 ma tutti i punti che abbiamo discusso precedentemente erano stati correttamente configurati. Tuttavia il problema persisteva e in effetti potevamo notare un alto numero di DPC ma non direttamente imputabili all’I/O sul disco. Infatti l’aspetto strano era che avevamo picchi di DPC in diversi momenti della giornata ma solo in alcune occasioni si verificava il problema sul cluster. Dopo accurato troubleshooting, abbiamo potuto verificare che le DPC erano invece causate da un software di terze parti di Network Protection. Disabilitandolo il problema è scomparso.

Come sempre, vi ringraziamo per il tempo che ci avete dedicato nel leggere questo articolo e speriamo che vi sia stato utile!

Ciao e alla prossima :)

Stefano Gagliardi
Support Engineer
Microsoft Enterprise Platform Support