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 les hébergent sont actifs. Toutefois, le cluster nécessite généralement plus de la moitié des nœuds en cours d’exécution. C’est ce que l’on appelle disposer d’un quorum.

Le quorum est conçu pour empêcher les scénarios de fractionnement de cerveau qui peuvent se produire lorsqu’il existe 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 posséder la charge de travail et d’écrire sur le même disque, ce qui peut entraîner de nombreux problèmes. Toutefois, cela est évité avec le concept de quorum du clustering de basculement, qui force un seul de ces groupes de nœuds à continuer à s’exécuter, de sorte qu’un seul de ces groupes reste en ligne.

Le quorum détermine le nombre d’échecs que le cluster peut supporter 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 force 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. Les nœuds qui ont été arrêtés peuvent à nouveau communiquer avec le groupe de nœuds main et rejoignent automatiquement le cluster et démarrent leur service de cluster.

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

• Quorum de cluster : celui-ci fonctionne au niveau du cluster (par exemple, vous pouvez perdre des nœuds sans pour autant que le cluster devienne indisponible).
• Quorum de pool : celui-ci opère au niveau du pool (c’est-à-dire que vous pouvez perdre des nœuds et des lecteurs sans pour autant que le cluster devienne indisponible). Les pools de stockage ont été conçus pour être utilisés dans des scénarios cluster et non cluster, ce qui explique pourquoi ils disposent d’un mécanisme de quorum différent.

Présentation du quorum de cluster

Le tableau ci-dessous donne une vue d’ensemble des résultats du quorum de cluster pour chaque 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, il est obligatoire de disposer d’un témoin.
• Si vous disposez de 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 de 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 lorsque certains sous-ensembles de nœuds perdent leur 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 seront mis hors connexion.

Toutefois, le concept de majorité ne fonctionne correctement que si 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 qui ont un nombre pair de nœuds (par exemple, un cluster à quatre nœuds) ?

Il existe deux façons pour le cluster de rendre le nombre total de votes impair :

1. Tout d’abord, il peut augmenter ce nombre en ajoutant un témoin avec un vote supplémentaire. Cela nécessite une configuration de la part de l’utilisateur.
2. Il peut également diminuer ce nombre en annulant le vote d’un nœud (cela se produit automatiquement lorsque c’est nécessaire).

Chaque fois que les nœuds survivants vérifient correctement qu’ils sont majoritaires, la définition de la majorité est mise à jour pour ne figurer que parmi les survivants. Cela permet au cluster de perdre un nœud, puis un autre, puis un autre, et ainsi de suite. Ce concept de nombre total de votes qui s’adapte après des échecs successifs est appelé quorum dynamique.

Témoin dynamique

Le témoin dynamique modifie le vote du témoin pour faire en sorte que le nombre total de votes soit impair. Si le nombre de votes est impair, le témoin ne dispose pas d’un 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 de défaillance du cluster en raison d’une défaillance du témoin. Le cluster décide s’il faut utiliser le vote du témoin en fonction du nombre de nœuds votants disponibles dans le cluster.

Le quorum dynamique fonctionne avec un témoin dynamique, comme décrit ci-dessous.

Comportement du quorum dynamique

• Si vous avez un nombre de nœuds pair et aucun témoin, un des nœuds voit son vote annulé. Par exemple, seuls trois des quatre nœuds disposent d’un vote. Par conséquent, le nombre total de votes est de trois, et les deux survivants disposant d’un vote sont considérés comme formant une majorité.
• Si vous avez un nombre de nœuds impair et aucun témoin, tous les nœuds disposent d’un vote.
• Si vous disposez d’un nombre de nœuds pair et d’un témoin, le témoin dispose d’un vote et le nombre total devient impair.
• Si vous disposez d’un nombre de nœuds impair et d’un témoin, le témoin ne disposera pas d’un vote.

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 s’exécuter avec un seul nœud (on appelle ce nœud « last-man standing » ou « dernier homme debout »). Prenons comme exemple un cluster à quatre nœuds. Supposons que le quorum nécessite 3 votes.

Dans ce cas, le cluster s’arrêterait si vous perdiez deux nœuds.

Le quorum dynamique empêche ce problème de se produire. Le nombre total de votes nécessaires pour le quorum est désormais déterminé en fonction du nombre de nœuds disponibles. Ainsi, avec le quorum dynamique, le cluster reste en place même si vous perdez trois nœuds.

Le scénario ci-dessus s’applique à un cluster général où les espaces de stockage direct ne sont pas activés. Toutefois, lorsque les espaces de stockage direct sont activés, le cluster peut uniquement prendre en charge deux échecs de nœuds. Pour plus d’informations, consultez la section concernant le quorum de pool.

Exemples

Deux nœuds sans témoin

Le vote d’un nœud est annulé. La majorité est donc déterminée sur un total de 1 vote. Si le nœud qui ne vote pas devient indisponible de façon inattendue, le survivant a un ratio de 1/1 et le cluster survit. Si le nœud qui vote devient indisponible de façon inattendue, le survivant a un ratio de 0/1 et le cluster devient lui aussi indisponible. Si le nœud qui vote est mis hors connexion normalement, le vote est transféré vers l’autre nœud, ce qui permet au cluster de survivre. C’est pourquoi il est essentiel de configurer un témoin.

• Peut survivre à un échec de serveur : 50 % de chance.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Non.
• Peut survivre à deux échecs de serveur simultanés : Non.

Deux nœuds avec un témoin

Les deux nœuds votent, ainsi que le témoin. La majorité est déterminée par rapport à un total de 3 votes. Si l’un des nœuds devient indisponible, le survivant a un ratio de 2/3 et le cluster survit.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Non.
• Peut survivre à deux échecs de serveur simultanés : Non.

Trois nœuds sans témoin

Tous les nœuds votent. La majorité est donc déterminée par rapport à un total de 3 votes. Si l’un des nœuds devient indisponible, les survivants ont un ratio de 2/3 et le cluster survit. Le cluster comprend alors deux nœuds et pas de témoin : cela correspond au scénario 1.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : 50 % de chance.
• Peut survivre à deux échecs de serveur simultanés : Non.

Trois nœuds avec un témoin

Tous les nœuds votent, donc le témoin ne dispose pas encore d’un vote. La majorité est donc déterminée par rapport à un total de 3 votes. Après un échec, le cluster comprend deux nœuds et un témoin : nous sommes revenus au scénario 2. À présent, les deux nœuds et le témoin votent.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Oui.
• Peut survivre à deux échecs de serveur simultanés : Non.

Quatre nœuds sans témoin.

Le vote d’un nœud est annulé. La majorité est donc déterminée sur un total de 3 votes. Après un échec, le cluster comprend trois nœuds : il s’agit du scénario 3.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Oui.
• Peut survivre à deux échecs de serveur simultanés : 50 % de chance.

Quatre nœuds avec un témoin

Tous les nœuds votent, ainsi que le témoin. La majorité est donc déterminée par rapport à un total de 5 votes. Après un échec, vous vous retrouvez dans le scénario 4. Après deux échecs simultanés, vous passez au scénario 2.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Oui.
• Peut survivre à deux échecs de serveur simultanés : Oui.

Cinq nœuds et plus

Tous les nœuds votent, ou tous sauf un, du moment que le total est impair. espaces de stockage direct ne pouvez de toute façon pas gérer plus de deux nœuds vers le bas. À ce stade, aucun témoin n’est nécessaire ou utile.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Oui.
• Peut survivre à deux échecs de serveur simultanés : Oui.

Maintenant que nous savons comment fonctionne un quorum, intéressons-nous aux différents 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 :

• Témoin cloud : stockage Blob dans Azure accessible à 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 : 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.
• Témoin de disque : petit disque en cluster qui se trouve dans le groupe 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 de cluster. Un témoin de disque n’est pas pris en charge avec la fonctionnalité espaces de stockage direct.

Présentation du quorum de pool

Nous venons de parler du quorum de cluster, qui opère au niveau du cluster. Maintenant, nous allons voir le quorum de pool qui opère au niveau du pool (par exemple, vous pouvez perdre des nœuds et des lecteurs sans que le cluster devienne indisponible). Les pools de stockage ont été conçus pour être utilisés dans des scénarios cluster et non cluster, ce qui explique pourquoi ils disposent d’un mécanisme de quorum différent.

Le tableau ci-dessous donne une vue d’ensemble des résultats du quorum de pool pour chaque 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 de pool

En cas d’échec des lecteurs ou lorsqu’un sous-ensemble de lecteurs perd le 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 pour rester en ligne. S’ils ne peuvent pas le vérifier, ils seront mis hors connexion. Le pool est l’entité qui passe hors connexion ou qui reste en ligne selon qu’elle dispose de suffisamment de disques pour le quorum (50 % + 1). La base de données de cluster peut être le +1 tant que le cluster lui-même est quorate.

Toutefois, le quorum de pool fonctionne différemment du quorum de cluster :

• 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 suppression d’un vote

Exemples

Quatre nœuds avec un layout symétrique

Chacun des 16 lecteurs a un vote, et le nœud 2 a également un vote (puisqu’il s’agit du propriétaire de la ressource du pool). La majorité est donc déterminée par rapport à un total de 16 votes. Si les nœuds 3 et 4 échouent, le sous-ensemble survivant comprendra 8 lecteurs, ainsi que le propriétaire de la ressource du pool, soit 9 votes sur 16. Par conséquent, le pool survit.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Oui.
• Peut survivre à deux échecs de serveur simultanés : Oui.

Quatre nœuds avec un layout symétrique et une défaillance de lecteur

Chacun des 16 lecteurs a un vote, et le nœud 2 a également un vote (puisqu’il s’agit du propriétaire de la ressource du pool). La majorité est donc déterminée par rapport à un total de 16 votes. D’abord, le lecteur 7 connaît un échec. Si les nœuds 3 et 4 échouent, le sous-ensemble survivant comprendra 7 lecteurs, ainsi que le propriétaire de la ressource du pool, soit 8 votes sur 16. Par conséquent, le pool n’a pas la majorité et devient indisponible.

• Peut survivre à un échec de serveur : Oui.
• Peut survivre à l’échec d’un serveur, puis d’un autre : Non.
• Peut survivre à deux échecs de serveur simultanés : Non.

Recommandations relatives au quorum de pool

• Vérifiez que chaque nœud de votre cluster est symétrique (c’est-à-dire que chaque nœud a le même nombre de lecteurs)
• Activez la miroir triple ou la parité double pour pouvoir tolérer deux défaillances de nœud et maintenir les disques virtuels en ligne.
• Si plus de deux nœuds échouent, ou si deux nœuds et un disque d’un autre nœud échouent, les volumes peuvent ne pas avoir accès aux trois copies de leurs données, et donc être mis hors connexion et devenir indisponibles. Il est recommandé de ramener rapidement les serveurs ou de remplacer les disques pour garantir la plus grande résilience pour toutes les données du volume.

Étapes suivantes

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