Cosa fare quando il cluster Always On perde il quorum?

Stavo rivedendo le procedure di DR della nostra azienda e quando ho cercato online soluzioni per un quorum perdente di Always On Cluster, da confrontare. Avevo tre pagine di risultati su Google prima di trovare il primo post SE sull'argomento Clustering vs. replica transazionale vs. gruppi di disponibilità che tocca solo leggermente l'argomento del quorum perduto.

Mentre tutti concordano sul fatto che il quorum perdente sia negativo e ci sono alcuni suggerimenti per ridurre il potenziale, può ancora accadere. Sto cercando una buona risposta peer review al miglior percorso di recupero da una perdita di quorum del cluster Always On.

Le AG si basano sul clustering di Windows. Si applicano le procedure WSFC per la perdita del quorum.

• Ripristino di emergenza WSFC tramite quorum forzato
• Forzare l'avvio di un cluster WSFC senza un quorum

Una volta che il WSFC è in esecuzione, è possibile forzare AG, se necessario. Eseguire un failover manuale forzato di un gruppo di disponibilità :

Dopo aver forzato il quorum sul cluster WSFC (quorum forzato), è necessario forzare il failover di ciascun gruppo di disponibilità (con possibile perdita di dati). È necessario forzare il failover perché lo stato reale dei valori del cluster WSFC potrebbe essere stato perso. Tuttavia, è possibile evitare la perdita di dati se è possibile forzare il failover sull'istanza del server che ospitava la replica che era la replica primaria prima di forzare il quorum o su una replica secondaria che era sincronizzata prima di forzare il quorum. Per ulteriori informazioni, vedere Modi potenziali per evitare la perdita di dati dopo la forzatura del quorum .

Cosa fare quando il cluster AlwaysOn perde il quorum?

Sono stato in questa situazione soprattutto con il clustering multi-subnet che attraversa diversi paesi (NY-LD-HK).

Come evitare la perdita di quorum in un cluster multi-subnet?

• Modificare l'impostazione predefinita del cluster su uno stato di monitoraggio più rilassato, in particolare le impostazioni di Heartbeat del cluster utilizzando CrossSubnetDelayo la CrossSubnetThresholdproprietà di questo aggiornamento rapido .
• AG utilizza WSFC che inturn utilizza un approccio basato sul quorum per determinare l'integrità del cluster. Assicurati di scegliere correttamente e configurare il quorum . Questo post sul blog approfondisce la configurazione del voto Quorum per AlwaysON

• Le cose cambiano in Windows Server 2016 con l'introduzione di cluster consapevoli del sito e cloud testimone .

  I nodi nei cluster allungati ora possono essere raggruppati in base alla loro posizione fisica (sito). La consapevolezza del sito del cluster migliora le operazioni chiave durante il ciclo di vita del cluster come comportamento di failover, criteri di posizionamento, battito cardiaco tra i nodi e comportamento del quorum.

  Cloud Witness è un nuovo tipo di testimone del quorum del cluster di failover che sfrutta Microsoft Azure come punto di arbitrato. Utilizza l'archiviazione BLOB di Microsoft Azure per leggere / scrivere un file BLOB che viene quindi utilizzato come punto di arbitrato in caso di risoluzione split-brain.

Cosa fare quando si perde il quorum?

• Se il cluster si arresta a causa di un'interruzione / disastro non pianificata, è necessario un intervento manuale. Un amministratore di Windows o un amministratore di cluster deve forzare manualmente il quorum (ricollegandosi alla risposta di @ Remus poiché tratta questo punto) e portare online i nodi sopravvissuti.

Come sempre, per eseguire un'analisi della causa principale (RCA), raccogliere i registri del cluster di Windows, per AlwaysON RCA: utilizzare i registri diagnostici del cluster di failover di SQL Server . Questi file nella directory di SQL Server registro hanno il seguente formato: <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.

Una volta sono stato coinvolto in un'interruzione in cui i nostri server con mirroring hanno perso la connettività. Una delle cose di cui preoccuparsi è assicurarsi che le applicazioni vengano indirizzate a una singola istanza. In un'interruzione di rete è possibile avere tutti i nodi di un cluster Always On attivi ma non in grado di comunicare tra loro. Forzare un failover su un secondario e quindi fino a quando si verifica un'interruzione, è possibile avere due nodi primari poiché il primario originale non sarà a conoscenza del failover forzato.

A seconda delle posizioni dei server delle applicazioni, della loro configurazione e della loro capacità di raggiungere un server SQL, in teoria è possibile avere due nodi che credono che siano primari e che i dati vengano modificati contemporaneamente. Una volta risolti i problemi di rete e i nodi riprendono la connettività, tutti i dati modificati sul primario originale verranno sovrascritti dal nodo in cui è stato forzato il failover. Ciò può comportare la perdita di dati critici.

Ho visto questa situazione una volta con SQL 2005 e il mirroring. E abbiamo deciso di non forzare il failover e lasciarlo irraggiungibile. Il motivo è che nel caso peggiore se dovessimo eseguire il backup e il ripristino per riavviare il mirroring, sarebbe un processo di 2 giorni per noi con i rischi che il registro delle transazioni si riempia e non sia in grado di espandere il disco su cui si trovava.