Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Pourquoi un choix aléatoire est-il fait dans un cluster à 2 nœuds + témoin de partage de fichiers quand le partage de fichiers tombe en panne ?

ayi

Dans un WSFC à 2 nœuds avec un témoin de partage de fichiers, chaque nœud a 1 vote, et le témoin a également 1 vote. Total 3 votes.
Étant donné que nous avons les concepts de quorum dynamique et de témoin dynamique ; quand le témoin de partage de fichiers tombe en panne, un nœud perd son vote, nous donnant un cluster à 2 nœuds avec 1 vote chacun. À ce moment, si le nœud 1 tombe également en panne et avait mon service/VM en cours d’exécution, le nœud 2 continuera à fonctionner mais ne pourra pas mettre en ligne le service/VM puisqu’il est le seul votant dans un cluster à 2 nœuds.
En tenant compte de l’ajustement dynamique des votes, ce que je n’arrive pas à comprendre est, comment les Services de Cluster Windows décident-ils quel nœud retire son vote de telle manière que cet ajustement de quorum n’affecte pas mon service/VM ? S’agit-il d’un choix aléatoire ou y a-t-il une logique ?

ayi_2

Le mécanisme de quorum dynamique ne connaît pas votre service ni sur quel nœud il est actif. Il est conçu pour fonctionner avec les rôles Windows Server et les VM Hyper-V. Les VM Hyper-V peuvent s’exécuter sur plusieurs nœuds en même temps ou être déplacées entre les nœuds, donc la décision ne repose pas sur ce qui fonctionne où.
Avec un cluster à 2 nœuds + témoin, quand le témoin tombe en panne, le mécanisme de quorum dynamique retire le vote d’un nœud. Le nœud qui perd son vote est déterministe — ce n’est pas aléatoire. Le cluster utilise un algorithme basé sur l’ID de nœud le plus bas.
Si le nœud 1 (ID le plus bas) perd son vote puis tombe en panne, le nœud 2 survit car il a le seul vote. Si le nœud 2 (ID le plus élevé) perd son vote puis tombe en panne, le nœud 1 survit.
Le point clé est : le quorum dynamique est conçu pour maximiser la disponibilité du cluster, pas la disponibilité d’une charge de travail spécifique. Si cela vous préoccupe, vous devriez utiliser un témoin de partage de fichiers hautement disponible (comme un partage Azure ou un partage sur un serveur de fichiers en cluster).