Translate this site using Windows Live Translator:
Le quorum et le cluster - C:\>Windows Internals - L'équipe Française de Support Windows - Site Home - TechNet Blogs

Le quorum et le cluster

Le quorum et le cluster

  • Comments 3
  • Likes

Le rôle du quorum au sein d’un cluster est souvent mal compris et peut mener à la mise en place d’une configuration éronée, surtout avec Windows Server 2008 où un nouveau modèle est disponible.

Tout d’abord, la définition du quorum dans son sens commun (Définition d’un quorum) :

“ En droit, le quorum est le nombre minimum de membres d'un corps délibératif nécessaire à la validité d'une décision. C'est souvent la moitié des membres, mais beaucoup d'entités ont un prérequis plus bas ou plus haut.

Lorsque le quorum n'est pas atteint, le corps délibératif ne peut pas tenir de vote et ne peut pas changer le statu quo. Ainsi, les votants en faveur du statu quo peuvent bloquer une décision en ne se présentant pas au vote. Le vote sera alors automatiquement rejeté et le statu quo conservé.

Dans un corps législatif, le quorum est habituellement la majorité des membres de l'entité y compris les postes vacants. Bien des corps ne prennent pas en compte le quorum à moins qu'une question ait été soumise à l'ordre du jour (par exemple un amendement). “

 

Il faut donc retenir les notions de “votants” et de “majorité” pour bien comprendre le rôle du quorum au sein du cluster.

 

 

Qu’est-ce que le quorum et a quoi sert-il ?

 

 

Il est fréquent de voir appeler “quorum” le disque utilisé pour stocker la configuration du cluster. C’est en partie vrai.

Dans un cluster configuré avec un disque quorum, ce disque joue le rôle d’arbitre.

Dans un cluster sans dique quorum, le quorum au sein d’un cluster représente l’ensemble des votants permettant d’assurer la continuité de fonctionnement du service cluster et la cohérence ce celui-ci. Je développe plus tard cet aspect de continuité de fonctionnement.

Une nuance cependant, avec Windows Server 2008, un modèle de quorum inclut le disque quorum comme votant.

 

 

En ce qui concerne son utilité, le quorum a trois rôles très simples :

  1. Fournir un moyen d’arbitrer l’appartenance au cluster


    Lors du démarrage d’un noeud, celui-ci utilise une copie de la configuration du cluster présent en local pour identifier les autres membres du cluster. Un mécanisme de sponsoring permet alors au noeud en cours de démarrage de se joindre ou non au cluster. Si ce serveur est sponsorisé par un noeud déjà démarré et si le cluster est fonctionnel, alors il récupère une copie récente de la configuration du cluster (on appelle cette action un JOIN).

  2. Aider à maintenir la cohérence du cluster


    C’est le rôle le plus important du quorum. Dans un scenario de split-brain, le quorum est utilisé pour garantir que les ressources partagées ne soient montées que sur un seul noeud. Le quorum est utilisé comme un tie-breaker dans ce scénario. Voir plus bas ce qu’est un split-brain.

  3. Fournir un moyen de stocker la configuration du cluster


    Au sein d’un cluster, chaque noeud doit disposer d’une vue consistante de la configuration du cluster. Cela est rendu possible par la mise à disposition par le quorum de la configuration du cluster stockée dans le quorum log.

 

 

Qu’est-ce que le quorum log ?

 

 

Le quorum log est une base de données contenant la configuration du cluster :

  • Les serveurs faisant parti du cluster
  • Les ressources installées et partagées
  • L’état des ressources partagées

Le quorum log est stocké par défaut dans \MSCS\quolog.log.

 

 

Qu’est-ce qu’un split-brain ?

 

 

Mot à mot, l’expression “split-brain” peut se traduire par “cerveau-scindé”. Hum… pas encore tout à fait clair…

Imaginons que le cluster soit un corps humain et que les membres du cluster (les noeuds) soient les lobes du cerveau.

Imaginons que ces lobes ne communiquent plus. On peut s’attendre à ce que le corps ne réagisse plus vraiment correctement, les ordres venant distinctement des deux lobes qui ne se synchronisent plus, et menant donc à quelque catastrophe…

Dans le cas d’un cluster, un split-brain intervient lorsque les liens réseau entre deux ou plusieurs noeuds subissent une défaillance. Le cluster est alors scindé en une ou plusieurs partitions qui ne peuvent plus communiquer entre elles.

 image

Dans ce cas de figure, la partition détenant le quorum (le noeud 1 dans cet exemple) est seule autorisée à continuer à fonctionner. La seconde partition (le noeud 2) devra s’arrêter.

Le but de ce fonctionnement ? Eviter que plusieurs noeuds ne pouvant plus se “concerter” effectuent des opérations sur les ressources partagées menant à une inconsistence du service en cluster.

Exemple : un cluster Exchange est hébergé dans un cluster 2 noeuds. Le noeud 1 détient le quorum, le noeud 2 détient les ressources Exchange (les bases de données).

  • Si le noeud 2 vient à perdre la communication avec le noeud 1 alors le noeud 2 va tenter de prendre l’ownership sur le quorum. S’il n’y parvient pas, le service cluster sur le noeud 2 va s’arrêter de lui-même car il va se considérer en mauvaise santé et donc incapable d’assurer son rôle.
    Le noeud 1 tentera alors de récupérer les ressources détenues par le noeud 2 et les remettres en service.
  • Si le noeud 2 parvient à prendre l’ownership du quorum, alors c’est que le noeud 1 subit une défaillance. C’est alors le noeud 1 qui, s’il n’est pas déjà arrêté ou hors d’état de fonctionner, qui va arrêter le service cluster.
  • Enfin, si ni le noeud 1 ni le noeud 2 ne parviennent à prendre l’ownership du quorum, alors le cluster est arrêté sur les deux noeuds.

Ces opérations visent à laisser la ressource en cluster sur un seul noeud. On ne peut avoir deux instances du même service fonctionner sur un réseau.

 

 

Vous me direz : mais pourquoi un noeud s’arrête t’il de lui-même si c’est le réseau qui a un problème ? Et bien, le noeud n’en sait rien. Il agit de manière proactive en constatant qu’il ne détient pas le quorum.

Et après tout, un problème réseau peut être causé par une défaillance de la carte réseau, d’un changement de configuration IP, sous Windows Server 2003 le service RPC ne répond plus, …

Bien sûr la réalité est un peu plus compliquée, il y a d’autres mécanismes que je n’ai pas détaillé ici qui entrent en jeu et qui complexifient la donne. Mais le principe est là.

Par exemple le cas où le cluster met en oeuvre plus de 2 noeuds. Dans ce cas, la notion de majorité est encore plus forte. La partition détenant le plus de votants est maintenue.

 

 

Les modèles de quorum

 

 

Disk Only

Dans ce modèle, seul le disque partagé dit “quorum” dispose d’un vote. Je lui attribue plutôt un rôle d’arbitrage.

Le cluster continue de fonctionner si au moins un noeud accède au disque quorum.

Cette configuration n’est généralement pas recommandée sous Windows Server 2008 et si ce modèle est toujours disponible, c’est… pour les nostalgiques !

image

Disk and Node Majority

Ce modèle a été intorduit avec Windows Server 2008. Le cluster dispose de trois votants : les deux noeuds et le disque quorum.

Le cluster continue de fonctionner si au moins deux votants sont fonctionnels.

image

Node Majority

Ce modèle de quorum entre en jeu lorsque le cluster est composé d’au moins trois noeuds et sans stockage partagé.

Pour que le cluster continue de fonctionner, il est nécessaire d’avoir une majorité de votants fonctionnels.

image

Node and File Share Majority

Le dernier modèle de quorum est implémenté lorsque qu’il n’y a pas de stockage partagé.

Il s’appuie sur les votants (les noeuds du cluster) et un témoin (un partage sur un serveur qui n’est pas un noeud).

Le cluster continue de fonctionner si la majorité des votants ET le témoin sont fonctionnels.

 

 

image

 

 

Le cas particulier du quorum sans disque partagé

 

 

Dans les configurations Node Majority et Node and File Share Majority, la configuration du quorum est stockée sur chaque noeud du cluster sur le disque système.

La consistence du réplica (le quorum log) sur tous les noeuds est assurée par le témoin (le File Share Witness) ou pas le cluster lui-même qui détermine qu’une modification est considérée comme permanente dès lors que cette configuration est présente sur la moitié des noeuds.

 

 

Comment choisir le modèle de quorum adéquat

 

 

Deux éléments sont à prendre en compte pour choisir le modèle de quorum :

  • La présence ou non de stockage partagé : SAN ou iSCSI / cluster local ou géographique
  • Le nombre de noeuds défaillants tolérés avant arrêt total du cluster

1ère étape : choix en fonction du stockage et de la répartition des noeuds

 

Disk Only

Disk and Node Majority

Node Majority

Node and File Share Majority

Avec stockage partagé

X

X

 

 
Sans stockage partagé

 

 

X

X

Cluster local

X

X

X

X

Cluster géographique

 

 

X

X

2nde étape : choix en fonction de la tolérance aux défaillances (sans stockage partagé ni File Share Witness)

Nombre de noeuds (N)

Nombre de votants (V)

Tolérance aux défaillances : (V-1)/2

2

2

0

3

3

1

4

4

1

5

5

2

6

6

2

7

7

3

8

8

3

3ème étape : choix en fonction de la tolérance aux défaillances (avec stockage partagé ou File Share Witness)

Nombre de noeuds (N)

Nombre de votants (V)

Tolérance aux défaillances : (V-1)/2

2

3

1

3

4

1

4

5

2

5

6

2

6

7

3

7

8

3

8

9

4

 

 

Le piège a éviter

 

 

Prenons le cas d’un cluster Exchange sept noeuds configuré suivant le modèle Disk and Node Majority.

Sur ce cluster, quatre instances d’Exchange sont actives et trois noeuds sont passifs.

image

Si vous avez bien suivi, et si j’ai été clair, combien de votants peuvent subir une défaillance sans que cela n’impacte :

  1. Les quatre instances actives ?
  2. Le cluster dans son ensemble ?

La réponse à la première question est : les quatre instances Exchange restent fonctionnelles tant qu’un maximum de trois votants subissent une défaillance

La réponse à la seconde est : le cluster dans son ensemble reste fonctionnel tant qu’un maximum de trois votants subissent une défaillance

 image

Jusque là tout va bien… mais en allant un peu plus loin, on peut dire que cette configuration amène un risque.

Pourquoi ? Il suffit qu’un votant supplémentaire subisse une défaillance pour que le cluster dans son ensemble ne fournisse plus le service qu’on attend de lui.

Et en l’occurence le risque vient du disque quorum. Si ce disque vient aussi à subir une défaillance alors la majorité n’est pas atteinte au sein du cluster. Le service cluster sera donc arrêté sur les noeuds fonctionnels afin d’éviter une inconsistance sinon de plus graves dommages au niveau du cluster et surtout de l'application en cluster.

image

Que faut-il tirer de cet exemple ?

Une recommandation très simple : toujours avoir un nombre impair de votants.

 

 

Conclusion

 

 

En définitive, la configuration du quorum dépend d’un certain nombre de facteurs dont le plus important est celui visant à déterminer le nombre de défaillances tolérées.

Dans la pratique, sur des clusters mettant en oeuvre plus de deux noeuds, une stratégie de secours doit être définie pour palier à la loi de Murphy. Cette stratégie s’inclut dans un plan de DRP (Disaster Recovery Plan) et la plupart du temps, implique la présence d’un cluster de secours ou tout au moins de procédures visant à remettre en service l’application en cluster le plus rapidement possible.

 

 

Ressources

 

 

Quelques ressources en anglais (les traductions restent parfois aléatoires) :

Failover Cluster Step-by-Step Guide: Configuring the Quorum in a Failover Cluster

Understanding Quorum Configurations in a Failover Cluster

Details of How Quorum Works in a Failover Cluster

Additional Information About Quorum Modes

Quorum resource

Troubleshooting Quorum Resource Problems

KB309186 - How the Cluster service reserves a disk and brings a disk online

 

 

Guillaume

Windows Core Support Escalation Engineer

Comments
  • C’est toujours un sujet complexe à expliquer. Alors quand la majorité des sources d’informations sont

  • Rien à redire, très bien conçu...

    Michael BERTUIT

  • Après un premier article consacré au cluster sous Windows Server 2008 , l’équipe française de support

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment