Que faire lorsque votre cluster Always On perd le quorum?

Je passais en revue les procédures de reprise après sinistre de notre entreprise et lorsque j'ai cherché en ligne des solutions à un quorum perdant Always On Cluster, à comparer. J'avais trois pages dans les résultats de Google avant de trouver le premier post SE sur le sujet Clustering vs réplication transactionnelle vs groupes de disponibilité qui ne touche que légèrement le sujet du quorum perdu.

Bien que tout le monde convienne que le quorum perdant est mauvais et qu'il existe des suggestions pour réduire le potentiel, cela peut toujours se produire. Je recherche une bonne réponse évaluée par les pairs pour le meilleur chemin de récupération après une perte de quorum de cluster Always On.

Les AG sont basés sur le clustering Windows. Les procédures WSFC pour la perte de quorum s'appliquent.

• Récupération après sinistre WSFC via le quorum forcé
• Forcer un cluster WSFC à démarrer sans quorum

Une fois le WSFC en cours d'exécution, vous pouvez alors forcer AG, si nécessaire. Effectuer un basculement manuel forcé d'un groupe de disponibilité :

Après avoir forcé le quorum sur le cluster WSFC (quorum forcé), vous devez forcer le basculement de chaque groupe de disponibilité (avec une perte de données possible). Forcer le basculement est nécessaire car l'état réel des valeurs du cluster WSFC peut avoir été perdu. Cependant, vous pouvez éviter la perte de données si vous êtes en mesure de forcer le basculement sur l'instance de serveur qui hébergeait la réplique qui était la réplique principale avant de forcer le quorum ou sur une réplique secondaire qui a été synchronisée avant de forcer le quorum. Pour plus d'informations, consultez Moyens potentiels pour éviter la perte de données une fois le quorum forcé .

Que faire lorsque votre cluster AlwaysOn perd le quorum?

J'ai été dans cette situation en particulier avec le clustering multi-sous-réseaux couvrant différents pays (NY-LD-HK).

Comment éviter la perte de quorum dans un cluster multi-sous-réseau?

• Modifiez le paramètre par défaut du cluster à un état de surveillance plus détendu, en particulier les paramètres Cluster Heartbeat utilisant CrossSubnetDelayou la CrossSubnetThresholdpropriété de ce correctif .
• AG utilise WSFC qui utilise à son tour une approche basée sur le quorum pour déterminer la santé du cluster. Assurez-vous de bien choisir et configurer le quorum . Ce billet de blog approfondit la configuration du vote de quorum pour AlwaysON

• Les choses changent dans Windows Server 2016 avec l'introduction de clusters sensibles au site et de témoins cloud .

  Les nœuds des clusters étirés peuvent désormais être regroupés en fonction de leur emplacement physique (site). La reconnaissance du site du cluster améliore les opérations clés au cours du cycle de vie du cluster, telles que le comportement de basculement, les stratégies de placement, les pulsations entre les nœuds et le comportement de quorum.

  Cloud Witness est un nouveau type de témoin de quorum de cluster de basculement qui utilise Microsoft Azure comme point d'arbitrage. Il utilise Microsoft Azure Blob Storage pour lire / écrire un fichier blob qui est ensuite utilisé comme point d'arbitrage en cas de résolution partagée.

Que faire lorsque le quorum est perdu?

• Si le cluster tombe en panne en raison d'une panne / catastrophe imprévue, une intervention manuelle est requise. Un administrateur Windows ou un administrateur de cluster doit forcer manuellement le quorum (lien vers la réponse de @ Remus car cela couvre ce point) et mettre en ligne les nœuds survivants.

Comme toujours, pour effectuer une analyse des causes profondes (RCA), rassemblez vos journaux de cluster Windows, pour AlwaysON RCA - utilisez les journaux de diagnostic du cluster de basculement SQL Server . Ces fichiers dans le répertoire Log SQL Server ont le format suivant: <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel.

Une fois que j'ai été impliqué dans une panne où nos serveurs en miroir ont perdu la connectivité. L'une des choses dont vous devez vous soucier est de vous assurer que vos applications sont dirigées vers une seule instance. Lors d'une panne de réseau, vous pouvez avoir tous les nœuds d'un cluster Always On activés mais incapables de communiquer entre eux. Vous forcez un basculement vers un secondaire, puis tant qu'il y a une panne, vous pouvez avoir deux nœuds principaux car le primaire d'origine ne connaîtra pas le basculement forcé.

Selon l'emplacement de vos serveurs d'applications, leur configuration et leur capacité à atteindre un serveur SQL, en théorie, vous pouvez avoir deux nœuds croyant qu'ils sont principaux et que les données sont modifiées en même temps. Une fois que vous avez résolu vos problèmes de réseau et que les nœuds reprennent la connectivité, toutes les données modifiées sur le serveur principal d'origine seront écrasées à partir du nœud où le basculement a été forcé. Cela peut entraîner la perte de données critiques.

J'ai déjà vu cette situation avec SQL 2005 et la mise en miroir. Et nous avons décidé de ne pas forcer le basculement et de le laisser inaccessible. La raison étant que dans le pire des cas, si nous devions sauvegarder et restaurer pour redémarrer la mise en miroir, ce serait un processus de 2 jours pour nous avec des risques de saturation du journal des transactions et de ne pas pouvoir étendre le disque sur lequel il se trouvait.