Share via

Hotfix di Windows consigliato per i gruppi di disponibilità del database che eseguono Windows Server 2008 R2

  • Article

Articolo originale pubblicato domenica 20 nov. 2011

Nei primi giorni di agosto di quest'anno, il team di Windows SE ha rilasciato il seguente articolo della Knowledge Base (KB) e il relativo hotfix per software hotfix riguardante un problema dei cluster di failover di in Windows Server 2008 R2:

KB2550886 - Un errore di comunicazione temporaneo provoca un cluster di failover Windows Server 2008 R2 smettere di funzionare

Questo hotfix è vivamente consigliato per tutti i gruppi di disponibilità del database (DAG) estesi tra più centri dati. Questo hotfix può essere utile anche per i DAG non estesi tra più centri dati. L'articolo descrive una race condition e un problema di deadlock del database cluster che possono verificarsi quando un cluster di failover di Windows va incontro a un errore di comunicazione temporaneo. Esiste una race condition all'interno della logica di riconnessione dei nodi del cluster che si manifesta quando il cluster presenta errori di comunicazione. Quando ciò si verifica, il database cluster smette di funzionare, con conseguente perdita di quorum loss nel cluster di failover.

Come descritto in TechNet, un gruppo di disponibilità del database si basa su funzionalità di cluster specifiche, quali il database cluster. Perché un DAG possa funzionare e fornire una disponibilità elevata, anche il cluster e il database cluster devono presentare un funzionamento corretto.

Microsoft ha riscontrato scenari in cui si verifica un errore di comunicazione temporaneo (un malfunzionamento delle comunicazioni di rete di circa 60 secondi), che ha come conseguenza un deadlock dell'intero cluster e l'interruzione della disponibilità di tutti i database all'interno del DAG. Dal momento che non è molto semplice stabilire quale nodo del cluster è effettivamente colpito dal deadlock, se un cluster di failover si blocca a causa del race della logica di failover, l'unica possibilità per intervenire è riavviare tutti i membri all'interno dell'intero cluster per risolvere la condizione di deadlock.

Il problema di norma si manifesta sotto forma di perdita di quorum del cluster a causa di un errore di comunicazione asimmetrica (due nodi non possono comunicare tra di loro ma possono ancora comunicare con altri nodi). Se si verificano ritardi tra gli altri nodi nella ricezione di messaggi del nuovo raggruppamento del cluster provenienti da Gestione aggiornamenti globali, è possibile che i messaggi del nuovo raggruppamento vengano ricevuti secondo un ordine imprevisto. Quando ciò si verifica, il cluster perde quorum invece di invocare il comportamento previsto, che consiste nella rimozione di uno dei nodi che ha subito l'errore di comunicazione iniziale dal cluster.

Questo bug si manifesta in genere in caso di latenza asimmetrica (ad esempio, se la metà dei membri del DAG presenta una latenza di 1 ms, mentre l'altra metà ha una latenza di 30 ms) per due nodi del cluster che rilevano una connessione interrotta tra i due elementi della coppia. Se il primo nodo rileva una perdita di connessione prima del secondo nodo, può verificarsi una race condition:

  • Il primo nodo avvia una riconnessione del flusso tra i due nodi. A causa di ciò il secondo nodo aggiungerà il nuovo flusso ai propri dati.
  • L'aggiunta del nuovo flusso demolisce quello esistente e istruisce la relativa gestione degli errori a ignorare l'evento. Nel caso dell'errore, il flusso precedente è il flusso interrotto che non è stato ancora rilevato.
  • Quando l'interruzione della connessione viene rilevata sul secondo nodo, questo avvia una propria sequenza di riconnessione. Se l'interruzione della connessione viene rilevata nella finestra di race corretta, il gestore degli errori del flusso su cui è stato rilevato l'errore verrà istruito a ignorare l'evento e il processo di riconnessione non avvierà una riconnessione. Determinerà invece una pausa per la coda di invio, che interromperà l'invio di messaggi tra i due nodi. L'interruzione dell'invio dei messaggi impedisce alla gestione degli aggiornamenti globali di funzionare correttamente forza un riavvio del cluster.

Se si verifica questo problema, le conseguenze per i DAG sono molto negative. Per tale motivo si consiglia di distribuire questo hotfix a tutti i server Cassette postali in uso che sono membri di un DAG, soprattutto se il DAG è esteso a più centri dati. Questo hotfix può essere utile anche per gli ambienti che eseguono cluster a copia singola di Exchange 2007 e per gli ambienti con replica continua cluster.

Oltre a risolvere il problema descritto sopra, l'articolo KB2550886 include inoltre importanti hotfix per Windows Server 2008 R2 consigliati anche per i DAG:

Questo è un post di blog localizzato. Consultate l'articolo originale: Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2