Présentation du quorum de cluster et de pool

S’applique à : Azure Stack HCI, versions 22H2 et 21H2 ; Windows Server 2022, Windows Server

Le clustering de basculement Windows Server offre une haute disponibilité pour les charges de travail s’exécutant sur des clusters Azure Stack HCI et Windows Server. Ces ressources sont considérées comme hautement disponibles si les nœuds qui hébergent des ressources sont en cours de fonctionnement ; toutefois, le cluster nécessite généralement plus de la moitié des nœuds en fonctionnement, ce qu’on appelle quorum.

Le quorum est conçu pour empêcher les scénarios de cerveau divisé qui peuvent se produire lorsqu’il existe une partition dans le réseau et où les sous-ensembles de nœuds ne peuvent pas communiquer entre eux. Cela peut entraîner la tentative des deux sous-ensembles de nœuds de posséder la charge de travail et d’écrire sur le même disque, ce qui peut entraîner de nombreux problèmes. Cependant, cela est empêché par le concept de quorum du clustering de basculement, qui oblige l’un de ces groupes de nœuds à continuer à fonctionner, de sorte qu’un seul de ces groupes reste en ligne.

Le quorum détermine le nombre d’échecs que le cluster peut tolérer tout en restant en ligne. Le 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, afin 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 force le service de cluster à s’arrêter dans l’un des sous-ensembles de nœuds pour s’assurer qu’il n’existe qu’un seul véritable propriétaire d’un groupe de ressources particulier. Les nœuds qui ont été arrêtés peuvent à nouveau communiquer avec le groupe principal de nœuds et rejoignent automatiquement le cluster et démarrent leur service de cluster.

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

• Quorum de cluster : cela s'applique au niveau du cluster (c'est-à-dire que vous pouvez perdre des nœuds et que le cluster continue de fonctionner)
• Quorum du pool : cela fonctionne au niveau du pool (c’est-à-dire que vous pouvez perdre des nœuds et des disques et que le pool reste opérationnel). Les pools de stockage ont été conçus pour être utilisés dans les scénarios cluster et non cluster, ce qui explique pourquoi ils ont un mécanisme de quorum différent.

Vue d’ensemble du quorum de cluster

Le tableau ci-dessous fournit une vue d’ensemble des résultats du quorum de cluster par scénario :

Nœuds de serveur	Peut survivre à l’échec d’un nœud de serveur	Peut survivre à l’échec d’un nœud de serveur, puis d’un autre	Peut survivre à deux échecs de nœuds de serveur simultanés
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 plus	Oui	Oui	Oui

Recommandations relatives au quorum de cluster

• Si vous avez deux nœuds, un témoin est requis.
• Si vous avez trois ou quatre nœuds, le témoin est fortement recommandé.
• Si vous avez cinq nœuds ou plus, un témoin n’est pas nécessaire et ne fournit pas de résilience supplémentaire.
• Si vous avez accès à Internet, utilisez un témoin cloud.
• Si vous êtes dans un environnement informatique qui comprend d’autres machines et partages de fichiers, utilisez un témoin de partage de fichiers.

Fonctionnement du quorum de cluster

Lorsque les nœuds échouent ou quand 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 à rester en ligne. S’ils ne peuvent pas vérifier cela, ils seront hors connexion.

Mais le concept de majorité fonctionne uniquement correctement lorsque le nombre total de nœuds dans le cluster est impair (par exemple, trois nœuds dans un cluster à cinq nœuds). Qu’en est-il des clusters avec un nombre pair de nœuds (par exemple, un cluster à quatre nœuds) ?

Il existe deux façons par lesquelles le cluster peut rendre le nombre total de votes impair :

1. Il peut d’abord augmenter d’un cran en ajoutant un témoin avec une voix supplémentaire. Cela nécessite la configuration de l’utilisateur.
2. Ou il peut diminuer d’un cran en annulant la voix d’un nœud malchanceux (ce processus se déclenche automatiquement si nécessaire).

Chaque fois que les nœuds survivants vérifient qu’ils sont la majorité, la définition de la majorité est mise à jour pour être parmi les seuls survivants. Cela permet au cluster de perdre un nœud, puis un autre, puis un autre, etc. Ce concept du nombre total de votes qui s'adapte suite à des échecs successifs est appelé quorum dynamique.

Témoin dynamique

Le témoin dynamique ajuste le vote du témoin afin de garantir que le nombre total de votes soit 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 à cause d'une défaillance du témoin. Le cluster détermine s’il faut utiliser le vote témoin en fonction du nombre de nœuds de vote disponibles dans le cluster.

Le quorum dynamique fonctionne avec un témoin dynamique de la façon 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 zéro. Par exemple, seulement 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 témoin, le témoin vote, donc le total est impair.
• Si vous avez un nombre impair de nœuds plus témoin, le témoin ne vote pas.

Le quorum dynamique permet d’attribuer dynamiquement un vote à un nœud afin d’éviter de perdre la majorité des votes et de permettre au cluster de fonctionner avec un seul nœud (appelé le dernier survivant). Prenons un cluster à quatre nœuds comme exemple. Supposons que le quorum nécessite 3 votes.

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

Toutefois, le quorum dynamique empêche ce problème. Le nombre total de votes requis pour le quorum est maintenant déterminé en fonction du nombre de nœuds disponibles. Par conséquent, avec le quorum dynamique, le cluster reste à jour même si vous perdez trois nœuds.

Le scénario ci-dessus s’applique à un cluster général qui n’a pas d’espaces de stockage direct activés. Toutefois, lorsque les espaces de stockage direct sont activés, le cluster ne peut prendre en charge que deux échecs de nœud. Cela est expliqué plus dans la section quorum du pool.

Exemples

Deux nœuds sans témoin

Le vote d’un nœud est nul, donc le vote majoritaire est déterminé sur un total de 1 vote. Si le nœud sans droit de 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 mis hors tension correctement, le vote est transféré à l’autre nœud et le cluster continue de fonctionner. C’est pourquoi il est essentiel de configurer un témoin.

• Peut survivre à un échec de serveur : cinquante pour cent de chances.
• Peut survivre à une défaillance du serveur, puis une autre : Non.
• Peut survivre à deux échecs de serveur à la fois : Non.

Deux nœuds avec un témoin

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

• Peut survivre à une défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Non.
• Peut survivre à deux échecs de serveur à la fois : Non.

Trois nœuds sans témoin

Tous les nœuds votent, donc la majorité est déterminée sur un total de 3 votes. Si un nœud tombe en panne, deux tiers des nœuds survivent 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 défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Cinquante pour cent de chances.
• Peut survivre à deux échecs de serveur à la fois : Non.

Trois nœuds avec un témoin

Tous les nœuds votent, de sorte que le témoin ne vote pas initialement. La majorité est déterminée sur un total de 3 voix. Après une défaillance, 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 défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Oui.
• Peut survivre à deux échecs de serveur à la fois : Non.

Quatre nœuds sans témoin

Le vote d’un nœud est nul. La majorité est donc déterminée sur un total de 3 voix. Après un échec, le cluster devient trois nœuds et vous êtes dans le scénario 3.

• Peut survivre à une défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Oui.
• Peut survivre à deux échecs de serveur à la fois : cinquante pour cent de chances.

Quatre nœuds avec un témoin

Tous les nœuds votent, ainsi que les témoins, de sorte que la majorité est 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 défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Oui.
• Peut survivre à deux échecs de serveur à la fois : Oui.

Cinq nœuds et au-delà

Tous les nœuds votent, ou tous sauf un, selon ce qui donne un nombre impair. Les espaces de stockage direct ne peuvent pas gérer plus de deux nœuds de toute façon. À ce stade, aucun témoin n’est nécessaire ou utile.

• Peut survivre à une défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Oui.
• Peut survivre à deux échecs de serveur à la fois : Oui.

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

Types de témoins de quorum

Le clustering de basculement prend en charge trois types de témoins de quorum :

• [https://blogs.technet.microsoft.com/askperf/2008/11/18/disabling-unnecessary-services-a-word-to-the-wise/]() Témoin cloud – Stockage Blob dans Azure accessible par tous les nœuds du cluster. Il conserve les informations de clustering dans un fichier witness.log, mais ne stocke pas de copie de la base de données de clusters.
• Témoin de partage de fichiers – Un partage de fichiers SMB configuré sur un serveur de fichiers exécutant Windows Server. Il conserve les informations de clustering dans un fichier witness.log, mais ne stocke pas de copie de la base de données de clusters.
• Disque témoin : 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 la fonctionnalité espaces de stockage direct.

Vue d’ensemble du quorum du pool

Nous venons de parler du quorum de cluster, qui fonctionne au niveau du cluster. À présent, examinons le quorum du pool, qui fonctionne au niveau du pool (c’est-à-dire que vous pouvez perdre des nœuds et des lecteurs et maintenir le pool en place). Les pools de stockage ont été conçus pour être utilisés dans les scénarios cluster et non cluster, ce qui explique pourquoi ils ont un mécanisme de quorum différent.

Le tableau ci-dessous fournit une vue d’ensemble des résultats de quorum du pool par scénario :

Nœuds de serveur	Peut survivre à l’échec d’un nœud de serveur	Peut survivre à l’échec d’un nœud de serveur, puis d’un autre	Peut survivre à deux échecs de nœuds de serveur simultanés
2	Oui	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 plus	Oui	Oui	Oui

Fonctionnement du quorum du pool

Lorsque les lecteurs échouent ou lorsque certains sous-ensembles de lecteurs perdent contact avec un autre sous-ensemble, les lecteurs survivants hébergeant des métadonnées doivent vérifier qu’ils constituent la majorité du pool à rester en ligne. S’ils ne peuvent pas vérifier cela, ils seront hors connexion. Le pool est l’entité qui est hors connexion ou reste en ligne selon qu’il dispose de suffisamment de disques pour le quorum (50% + 1). La base de données du cluster peut être le +1 tant que le cluster lui-même est à quorum.

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

• Le pool sélectionne un sous-ensemble de lecteurs par nœud pour héberger les métadonnées
• Le pool utilise la base de données de cluster pour rompre les liens
• Le pool n’a pas de quorum dynamique
• Le pool n’implémente pas sa propre version de la 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 il s’agit du 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 restant dispose de 8 disques et du propriétaire de la ressource de pool, soit 9 voix sur 16. Donc, la piscine survive.

• Peut survivre à une défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Oui.
• Peut survivre à deux échecs de serveur à la fois : Oui.

Quatre nœuds avec une disposition symétrique et une défaillance de disque

Chacun des 16 lecteurs a un vote et le nœud 2 a également un vote (car il s’agit du 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 tombe en panne. Si les nœuds trois et quatre tombent en panne, le sous-ensemble restant dispose de 7 disques et du propriétaire de la ressource de pool, soit 8 voix sur 16. Le pool ne dispose donc pas de la majorité et se met hors service.

• Peut survivre à une défaillance du serveur : Oui.
• Peut survivre à une défaillance du serveur, puis une autre : Non.
• Peut survivre à deux échecs de serveur à la fois : Non.

Recommandations relatives au quorum du pool

• Vérifiez que chaque nœud de votre cluster est symétrique (chaque nœud a le même nombre de lecteurs)
• Activez la parité double ou miroir à trois voies pour que vous puissiez tolérer deux défaillances de nœud et maintenir les disques virtuels en ligne.
• Si plus de deux nœuds sont arrêtés, 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 sont donc mis hors connexion et ne sont pas disponibles. Il est recommandé de ramener les serveurs ou de remplacer rapidement les disques pour garantir la résilience la plus élevée pour toutes les données du volume.

Étapes suivantes

• Configurer et gérer un quorum
• Configurer un témoin de cluster