Présentation du quorum de cluster et de pool
S’applique à : Azure Stack HCI, versions 22H2 et 21H2 ; Windows Server 2022, Windows Server
Important
Azure Stack HCI fait désormais partie d’Azure Local. Le changement de nom de la documentation produit est en cours. Toutefois, les versions antérieures d’Azure Stack HCI, par exemple 22H2, continueront de référencer Azure Stack HCI et ne reflèteront pas la modification du nom. Plus d’informations
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 fractionnés qui peuvent se produire lorsqu’il existe une partition dans le réseau et 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. Toutefois, cela n’est pas possible avec le concept de quorum du clustering de basculement, qui force l’un 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. 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, 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 | No | 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 :
- 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.
- 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 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, 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 que le cluster tombe en panne en raison d’une défaillance de 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. 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 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 peut pas gérer plus de deux nœuds de toute façon, donc à 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 : 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 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 | No | Non |
| 2 + témoin | Oui | No | Non |
| 3 | Oui | No | Non |
| 3 + témoin | Oui | No | Non |
| 4 | Oui | No | Non |
| 4 + témoin | Oui | Oui | Oui |
| 5 et plus | Oui | Oui | Oui |
Fonctionnement du quorum de 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 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 du cluster peut être la +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 la 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 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 é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 les serveurs ou de remplacer rapidement les disques pour garantir la résilience la plus élevée pour toutes les données du volume.