Comprendre le quorum de cluster et de pool

• 01/18/2019
• 11 minutes à lire
• • a
  • e
  • v
  • C
  • J
  • +3

S’applique à : Windows Server 2019, Windows Server 2016

La mise en cluster de basculement de Windows Server offre une haute disponibilité pour les charges de travail. Ces ressources sont considérées comme hautement disponibles si les nœuds qui hébergent les ressources sont en place; cependant, le cluster nécessite généralement que plus de la moitié des nœuds soient en cours d’exécution, ce qui est connu sous le nom de quorum.

Quorum est conçu pour empêcher les scénarios de cerveau partagé qui peuvent se produire lorsqu’il y a une partition dans le réseau et que des sous-ensembles de nœuds ne peuvent pas communiquer entre eux. Cela peut amener les deux sous-ensembles de nœuds à essayer de s’approprier la charge de travail et à écrire sur le même disque, ce qui peut entraîner de nombreux problèmes. Cependant, cela est évité avec le concept de quorum du Clustering de basculement qui oblige un seul de ces groupes de nœuds à continuer à fonctionner, de sorte qu’un seul de ces groupes restera en ligne.

Le quorum détermine le nombre de défaillances que le cluster peut subir tout en restant en ligne. Quorum est conçu pour gérer le scénario en cas de problème de communication entre des sous-ensembles de nœuds de cluster, de sorte que plusieurs serveurs n’essaient pas d’héberger simultanément un groupe de ressources et d’écrire sur le même disque en même temps. En ayant ce concept de quorum, le cluster forcera le service de cluster à s’arrêter dans l’un des sous-ensembles de nœuds pour s’assurer qu’il n’y a qu’un seul véritable propriétaire d’un groupe de ressources particulier. Une fois que les nœuds qui ont été arrêtés peuvent à nouveau communiquer avec le groupe principal de nœuds, ils rejoindront automatiquement le cluster et démarreront leur service de cluster.

Dans Windows Server 2019 et Windows Server 2016, il existe deux composants du système qui ont leurs propres mécanismes de quorum:

• Quorum du cluster : Cela fonctionne au niveau du cluster (c.-à-d. vous pouvez perdre des nœuds et faire en sorte que le cluster reste actif)
• Quorum de pool : Cela fonctionne au niveau du pool lorsque Storage Spaces Direct est activé (c’est-à-dire que vous pouvez perdre des nœuds et des disques et que le pool reste actif). Les pools de stockage ont été conçus pour être utilisés dans des scénarios clusterisés et non clusterisés, c’est pourquoi ils ont un mécanisme de quorum différent.

Aperçu du quorum des grappes

Le tableau ci-dessous donne un aperçu des résultats du Quorum des grappes par scénario:

Les nœuds de serveur	Peuvent survivre à une défaillance d’un nœud de serveur	Peuvent survivre à une défaillance d’un nœud de serveur, puis un autre	Peut survivre à deux pannes simultanées de nœud de serveur
2	50/50	Non	Non
2 + Témoin	Oui	Non	Non
3	Oui	50/50	Non
3 + Témoin	Oui	Oui	Non
4	Oui	Oui	50/50
4 + Témoin	Oui	Oui	Oui
5 et au-dessus	Oui	Oui	Oui

Recommandations de quorum de cluster

• Si vous avez deux nœuds, un témoin est requis.
• Si vous avez trois ou quatre nœuds, witness est fortement recommandé.
• Si vous avez accès à Internet, utilisez un témoin cloud
• Si vous êtes dans un environnement informatique avec d’autres machines et des partages de fichiers, utilisez un témoin de partage de fichiers

Fonctionnement du quorum du cluster

Lorsque des nœuds échouent ou qu’un sous-ensemble de nœuds perd le contact avec un autre sous-ensemble, les nœuds survivants doivent vérifier qu’ils constituent la majorité du cluster pour rester en ligne. S’ils ne peuvent pas le vérifier, ils se déconnecteront.

Mais le concept de majorité ne fonctionne proprement que lorsque le nombre total de nœuds du cluster est impair (par exemple, trois nœuds dans un cluster à cinq nœuds). Alors, qu’en est-il des clusters avec un nombre pair de nœuds (disons un cluster à quatre nœuds)?

Le cluster peut rendre impair le nombre total de votes:

1. Tout d’abord, il peut en monter un en ajoutant un témoin avec un vote supplémentaire. Cela nécessite une configuration utilisateur.
2. Ou, il peut descendre un en réduisant à zéro le vote d’un nœud malchanceux (se produit automatiquement au besoin).

Chaque fois que les nœuds survivants vérifient avec succès qu’ils sont majoritaires, la définition de majority est mise à jour pour figurer parmi les seuls survivants. Cela permet au cluster de perdre un nœud, puis un autre, puis un autre, et ainsi de suite. Ce concept du nombre total de votes s’adaptant après des échecs successifs est connu sous le nom de quorum dynamique.

Témoin dynamique

Témoin dynamique bascule le vote du témoin pour s’assurer que le nombre total de votes est impair. S’il y a un nombre impair de votes, le témoin n’a pas de vote. S’il y a un nombre pair de votes, le témoin a un vote. Le témoin dynamique réduit considérablement le risque que le cluster tombe en panne en raison de la défaillance du témoin. Le cluster décide d’utiliser ou non le vote témoin en fonction du nombre de nœuds de vote disponibles dans le cluster.

Quorum dynamique fonctionne avec Dynamic witness de la manière décrite ci-dessous.

Comportement de quorum dynamique

• Si vous avez un nombre pair de nœuds et aucun témoin, un nœud obtient son vote mis à zéro. Par exemple, seuls trois des quatre nœuds obtiennent des votes, donc le nombre total de votes est de trois, et deux survivants avec des votes sont considérés comme une majorité.
• Si vous avez un nombre impair de nœuds et aucun témoin, ils obtiennent tous des votes.
• Si vous avez un nombre pair de nœuds plus le témoin, le témoin vote, donc le total est impair.
• Si vous avez un nombre impair de nœuds plus le témoin, le témoin ne vote pas.

Le quorum dynamique permet d’attribuer dynamiquement un vote à un nœud pour éviter de perdre la majorité des votes et pour permettre au cluster de s’exécuter avec un nœud (appelé last-man standing). Prenons un cluster à quatre nœuds comme exemple. Supposons que le quorum nécessite 3 voix.

Dans ce cas, le cluster serait tombé en panne si vous aviez perdu deux nœuds.

Cependant, le quorum dynamique empêche cela de se produire. Le nombre total de votes requis pour le quorum est maintenant déterminé en fonction du nombre de nœuds disponibles. Ainsi, avec le quorum dynamique, le cluster restera actif même si vous perdez trois nœuds.

Le scénario ci-dessus s’applique à un cluster général pour lequel les espaces de stockage Direct ne sont pas activés. Cependant, lorsque Storage Spaces Direct est activé, le cluster ne peut prendre en charge que deux défaillances de nœuds. Ceci est expliqué plus en détail dans la section quorum du pool.

Exemples

Deux nœuds sans témoin.

Le vote d’un nœud est mis à zéro, de sorte que le vote majoritaire est déterminé sur un total de 1 vote. Si le nœud sans vote tombe en panne de manière inattendue, le survivant a 1/1 et le cluster survit. Si le nœud de vote tombe en panne de manière inattendue, le survivant a 0/1 et le cluster tombe en panne. Si le nœud de vote est correctement éteint, le vote est transféré à l’autre nœud et le cluster survit. C’est pourquoi il est essentiel de configurer un témoin.

• Peut survivre à une panne de serveur: Cinquante pour cent de chances.
• Peut survivre à une panne de serveur, puis à une autre : Non.
• Peut survivre à deux pannes de serveur à la fois : Non.

Deux nœuds avec un témoin.

Les deux nœuds votent, plus les votes des témoins, de sorte que la majorité est déterminée sur un total de 3 votes. Si l’un des nœuds tombe en panne, le survivant a 2/3 et le cluster survit.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Non.
• Peut survivre à deux pannes de serveur à la fois : Non.

Trois nœuds sans témoin.

Tous les nœuds votent, la majorité est donc déterminée sur un total de 3 votes. Si un nœud tombe en panne, les survivants sont 2/3 et le cluster survit. Le cluster devient deux nœuds sans témoin – à ce stade, vous êtes dans le scénario 1.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Cinquante pour cent de chances.
• Peut survivre à deux pannes de serveur à la fois : Non.

Trois nœuds avec un témoin.

Tous les nœuds votent, donc le témoin ne vote pas initialement. La majorité est déterminée sur un total de 3 voix. Après un échec, le cluster a deux nœuds avec un témoin – ce qui revient au scénario 2. Donc, maintenant, les deux nœuds et le témoin votent.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Oui.
• Peut survivre à deux pannes de serveur à la fois : Non.

Quatre nœuds sans témoin

Le vote d’un nœud est mis à zéro, de sorte que la majorité est déterminée sur un total de 3 votes. Après un échec, le cluster devient trois nœuds et vous êtes dans le scénario 3.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Oui.
• Peut survivre à deux pannes de serveur à la fois: Cinquante pour cent de chances.

Quatre nœuds avec un témoin.

Tous les votes des nœuds et les votes des témoins, la majorité est donc déterminée sur un total de 5 votes. Après un échec, vous êtes dans le scénario 4. Après deux échecs simultanés, vous passez au scénario 2.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Oui.
• Peut survivre à deux pannes de serveur à la fois : Oui.

Cinq nœuds et au-delà.

Tous les nœuds votent, ou tous sauf un vote, quel que soit le total impair. Les espaces de stockage Direct ne peuvent de toute façon pas gérer plus de deux nœuds, donc à ce stade, aucun témoin n’est nécessaire ou utile.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Oui.
• Peut survivre à deux pannes de serveur à la fois : Oui.

Maintenant que nous comprenons comment fonctionne le quorum, examinons les types de témoins du quorum.

Types de témoins à Quorum

Le regroupement par basculement prend en charge trois types de témoins à Quorum:

• Cloud Witness – Stockage Blob dans Azure accessible par tous les nœuds du cluster. Il maintient les informations de regroupement dans un témoin.fichier journal, mais ne stocke pas une copie de la base de données du cluster.Témoin de partage de fichiers
• – Partage de fichiers SMB configuré sur un serveur de fichiers exécutant Windows Server. Il maintient les informations de regroupement dans un témoin.fichier journal, mais ne stocke pas une copie de la base de données du cluster.
• Témoin de disque – Un petit disque en cluster qui se trouve dans le groupe de stockage disponible du cluster. Ce disque est hautement disponible et peut basculer entre les nœuds. Il contient une copie de la base de données du cluster. Un Témoin de disque n’est pas pris en charge avec des espaces de stockage directs.

Aperçu du quorum du pool

Nous venons de parler du Quorum du cluster, qui fonctionne au niveau du cluster. Maintenant, plongeons dans le Quorum de la piscine, qui fonctionne au niveau de la piscine (c’est-à-dire que vous pouvez perdre des nœuds et des disques et que la piscine reste debout). Les pools de stockage ont été conçus pour être utilisés dans des scénarios clusterisés et non clusterisés, c’est pourquoi ils ont un mécanisme de quorum différent.

Le tableau ci-dessous donne un aperçu des résultats du Quorum du pool par scénario:

Les nœuds de serveur	Peuvent survivre à une défaillance d’un nœud de serveur	Peuvent survivre à une défaillance d’un nœud de serveur, puis un autre	Peut survivre à deux pannes simultanées de nœud de serveur
2	Non	Non	Non
2 + Témoin	Oui	Non	Non
3	Oui	Non	Non
3 + Témoin	Oui	Non	Non
4	Oui	Non	Non
4 + Témoin	Oui	Oui	Oui
5 et au-dessus	Oui	Oui	Oui

Fonctionnement du quorum du pool

Lorsque les lecteurs échouent ou qu’un sous-ensemble de lecteurs perd le contact avec un autre sous-ensemble, les lecteurs survivants doivent vérifier qu’ils constituent la majorité du pool pour rester en ligne. S’ils ne peuvent pas le vérifier, ils se déconnecteront. Le pool est l’entité qui se déconnecte ou reste en ligne selon qu’elle dispose de suffisamment de disques pour le quorum (50% + 1). Le propriétaire de la ressource du pool (nœud de cluster actif) peut être le +1.

Mais le quorum du pool fonctionne différemment du quorum du cluster de la manière suivante:

• le pool utilise un nœud du cluster en tant que témoin en tant que briseur d’égalité pour survivre à la moitié des lecteurs disparus (ce nœud qui est le propriétaire de la ressource du pool)
• le pool n’a PAS de quorum dynamique
• le pool n’implémente PAS sa propre version de suppression d’un vote

Exemples

Quatre nœuds avec une disposition symétrique.

Chacun des 16 lecteurs a un vote et le nœud deux a également un vote (car c’est le propriétaire de la ressource du pool). La majorité est déterminée sur un total de 16 voix. Si les nœuds trois et quatre tombent en panne, le sous-ensemble survivant a 8 lecteurs et le propriétaire de la ressource du pool, soit 9/16 votes. Ainsi, la piscine survit.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Oui.
• Peut survivre à deux pannes de serveur à la fois : Oui.

Quatre nœuds avec une disposition symétrique et une défaillance du lecteur.

Chacun des 16 lecteurs a un vote et le nœud 2 a également un vote (car c’est le propriétaire de la ressource du pool). La majorité est déterminée sur un total de 16 voix. Tout d’abord, le lecteur 7 descend. Si les nœuds trois et quatre tombent en panne, le sous-ensemble survivant a 7 lecteurs et le propriétaire de la ressource du pool, soit 8/16 votes. Donc, la piscine n’a pas la majorité et descend.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : Non.
• Peut survivre à deux pannes de serveur à la fois : Non.

Quatre nœuds avec une disposition non symétrique.

Chacun des 24 lecteurs a un vote et le nœud deux a également un vote (car c’est le propriétaire de la ressource du pool). La majorité est déterminée sur un total de 24 voix. Si les nœuds trois et quatre tombent en panne, le sous-ensemble survivant a 8 lecteurs et le propriétaire de la ressource du pool, soit 9/24 votes. Donc, la piscine n’a pas la majorité et descend.

• Peut survivre à une panne de serveur: Oui.
• Peut survivre à une panne de serveur, puis à une autre : ** Dépend ** (ne peut pas survivre si les nœuds trois et quatre tombent en panne, mais peut survivre à tous les autres scénarios.
• Peut survivre à deux pannes de serveur à la fois: ** Dépend ** (ne peut pas survivre si les deux nœuds trois et quatre tombent en panne, mais peut survivre à tous les autres scénarios.

Recommandations de quorum de pool

• Assurez-vous que chaque nœud de votre cluster est symétrique (chaque nœud a le même nombre de lecteurs)
• Activez le miroir à trois voies ou la parité double afin que vous puissiez tolérer les pannes d’un nœud et garder les disques virtuels en ligne. Consultez notre page d’orientation sur les volumes pour plus de détails.
• Si plus de deux nœuds sont en panne, ou si deux nœuds et un disque sur un autre nœud sont en panne, les volumes peuvent ne pas avoir accès aux trois copies de leurs données, et donc être déconnectés et indisponibles. Il est recommandé de ramener les serveurs ou de remplacer rapidement les disques pour assurer la plus grande résilience de toutes les données du volume.