Windows Server 2003 - Disconnessioni intermittenti delle schede di rete su un Failover Cluster

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:

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.

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:

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:

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

Comments

• Anonymous
  January 01, 2003
  Ciao Emanuele, grazie per il commento! Per quanto riguarda la domanda, anche se utilizzare un singolo switch è un single point of failure, il servizio cluster può eseguire l’heartbeat sulle altre interfacce di rete disponibili: Public, CSV, live migration, etc in modo automatico. In questo modo si eliminano possibili problemi di comunicazione di rete tra i 2 nodi e comunque l’ambiente è ridondato. Stefano

• Anonymous
  January 01, 2003
  Ciao Emanuele, L’obiezione è legittima, sono d’accordo con te che lo switch in una configurazione ideale di alta affidabilità deve essere ridondato. È vero che nello scenario che mi descrivi in caso di problema dello switch che gestisce le schede pubbliche il cluster diventerebbe irraggiungibile, ma forse abbiamo dato per sottointeso il fatto che le due schede public dei due nodi dovrebbero essere collegate a diversi switch. Il documento che citi riassume le condizioni necessarie minime per il funzionamento del cluster (requirements obbligatori), non le modalità per garantire la massima affidabilità. Il Teaming è una ottima soluzione per garantire un ulteriore livello di affidabilità, ma essendo prodotti di terze parti e non Microsoft, non erano stati certificati per la supportabilità su Windows 2003 per insufficienza di tests. Negli anni successivi Microsoft ha lavorato con i produttori e risolto il problema per 2008/2008 R2 (miglioramenti tra l’altro in continuo sviluppo anche per la prossima versione di Windows). Il punto 8 semplicemente riporta il fatto che nella nostra esperienza abbiamo verificato che gli eventi 1122 e 1123 possono essere generati quando i nodi sono parte di una VLAN che utilizza porte su differenti switch fisici con una trunk link configuration tra i due switch. Stefano

• Anonymous
  August 02, 2011
  Ciao, sono anni che lavoro con MScluster e non conoscevo metà delle info sull'heartbeat che ci hai spiegato, grazie 1000 della bella spiega! Una cosa però non mi è chiara: al punto 8 dici che in caso l'intracluster sia su VLAN è necessario utilizzare lo stesso switch per entrambi i nodi e non ne comprendo il motivo. Per esempio lo scenario è quello di un'infrastruttura blade a 2 switch e 2 interfacce per lama; come produrre ridondanza all'erogato se uno dei 2 switch è dedicato alla rete privata e supponendo che l'altro switch si guasti? Ancora grazie 1000 e cia:)

• Anonymous
  October 06, 2011
  Ciao Stefano e grazie per la risposta. Quello che dici è certamente corretto, ma non risolve lo scenario proposto: dati 2 switch e 2 interfacce fisiche per macchina, attestando l'interfaccia privata di ciascuno dei 2 nodi su di un solo switch e le pubbliche sull'altro se l'eventuale fault riguardasse lo switch su cui sono attestate le private, il cluster funzionerebbe regolarmente, ma se si guastasse lo switch su cui sono attestate le interfacce pubbliche, l'erogato verrebbe per forza di cose a mancare. Per il cluster 2k3, che non supporta l'aggregazione delle interfacce private (cfrsupport.microsoft.com/.../en-us - si potrebbero creare interfacce virtuali sulla fisica utilizzata per la rete privata, ma ammesso che abbia senso, personalmente non ho mai visto software che raggiungano un livello di astrazione tale da permettere il teaming tra interfacce virtuali e fisiche) quello che mi sembra significativo sottolineare sta nel fatto che i requirement per avere piena ridondanza includono almeno 3 interfacce fisiche -2 in team per la public, mixed nella conf del cluster, e una privata - distribuite su almeno 2 switch - uno switch che ospita la privata di entrambe e il primo ramo del team public e l'altro switch che ospita il secondo ramo del team public -. Articoli come technet.microsoft.com/.../cc783193(WS.10).aspx, nonostante siano "politicamente" e formalmente corretti, contribuiscono a far credere che siano sufficienti almeno 2 interfacce fisiche (come nello scenario proposto) per nodo a fornire ridondanza, mentre invece non mi sembra che sia così.. Forse non considero qualche aspetto e sbaglio qualcosa? Per il Cluster 2k8 il discorso è diverso visto che è possibile costruire un team delle 2 fisiche (per nodo) attestate ciascuna su di uno switch diverso e creare le 2 interfacce virtuali e ridondate che servono. E.. perdonami, ma il punto 8 non mi è ancora chiaro :) Scusami se sono stato un po' prolisso anche se ho cercato di limitarmi :) Grazie 1000 e cia:)