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 de cluster en cours de comparaison. J'avais trois pages dans les résultats de Google avant de trouver le premier message 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.
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 en un état de surveillance plus détendu, en particulier paramètres Cluster Heartbeat en utilisant la propriété
CrossSubnetDelayouCrossSubnetThresholdpar 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 que choisissez et configurez correctement le quorum . Ce billet de blog approfondit Configuration du vote de quorum pour AlwaysON
Les choses changent dans Windows Server 2016 avec l'introduction de clusters sensibles au site et témoin 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 pendant le 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 exploite 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 de split-brain.
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 Journaux de diagnostic du cluster de basculement SQL Server . Ces fichiers dans le répertoire SQL Server Log 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, vous pouvez en théorie 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 primaire d'origine seront écrasées par le 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 l'impossibilité d'étendre le disque sur lequel il se trouvait.