Choisir et configurer le quorum d'un cluster de basculement sous Windows Server 2012 / 2012 R2

5.4. Quorum non atteint

Vous vous rappelez de la configuration de quorum ? Cela défini qui de vos noeuds et de vos disques/partages témoin ont un droit de vote et donc dans quel cas votre cluster pourra continuer de fonctionner ou non.

5.4.1. Quorum dynamique (depuis WS 2012)

Depuis Windows Server 2012, Microsoft a créé une fonctionnalité appelée le Quorum dynamique (qui est activée par défaut).
Vous allez voir dans cet exemple, ce que cela change.

Comme nous possédons un nombre impair de noeuds dans notre cluster, nous utilisons le mode de quorum "Noeud majoritaire".
Ce qui implique qu'il faut qu'une majorité de votants (de noeuds dans ce cas-ci) soit en ligne pour que le cluster puisse continuer à fonctionner.
En résumé, il faut donc que nous ayons au moins 2 noeuds sur 3 de disponibles pour que notre cluster puisse continuer de fonctionner sans problème.

La perte d'un serveur ne pose donc pas de problème pour le moment.

De plus, le service est toujours hébergé sur notre 2ème serveur.

Admettons que ce 2ème serveur tombe en panne, cela provoque ... la migration du rôle sur le dernier serveur du cluster.

Bizarrement, notre cluster continue de fonctionner alors que nous devrions avoir 1 vote sur 3. Ce qui voudrait dire que notre cluster aurait dû s'arrêter.
Pourtant, celui-ci fonctionne toujours.

Et bien, c'est dû à la fonctionnalité "Quorum dynamique" apparue avec Windows Server 2012 et qui est activée par défaut.
En effet, grâce à cette fonctionnalité, chaque noeud qui tombe en panne perd son droit de vote.
Actuellement, nous avons donc un quorum de 1 sur 1. Raison pour laquelle notre cluster continue de fonctionner sans problème.

Bien évidemment, si le dernier noeud tombe en panne, cela provoquerait l'arrêt du cluster.

5.4.2. Quorum classique (non dynamique)

Si vous voulez tester ce qu'aurait du donner l'utilisation de votre quorum sans le quorum dynamique, sachez que cette fonctionnalité peut être désactivée avec une simple commande powershell :

PowerShell

(Get-Cluster "Nom du cluster").DynamicQuorum = 0

Ce qui donne dans notre cas :

PowerShell

(Get-Cluster "iw-cluster").DynamicQuorum = 0

Nous avons remis nos 3 serveurs en ligne.

Le rôle est en cours d'exécution sur le serveur 1.

L'arrêt d'un serveur ne change rien étant donné que nous avons toujours 2 votes sur 3 (noeuds).

Le cluster continue de fonctionner correctement sur le serveur 1.

Par contre, lorsque le serveur 2 tombe en panne, nous nous retrouvons avec 2 votes sur 3.
Nous n'avons donc plus la majorité et le gestionnaire de cluster n'arrive plus à obtenir les informations concernant ce serveur.

Un peu plus tard, on voit que le cluster a fini par disparaitre, car le gestionnaire du cluster de basculement n'arrive plus à se connecter à votre serveur.
Bien qu'il reste un serveur disponible. Mais pas assez de votes pour obtenir la majorité.

Comme vous pouvez le voir, seul le serveur 1 est disponible, mais les autres serveurs du cluster, ainsi que le cluster en lui-même ne sont plus accessibles.

5.4.3. Restauration du cluster

Pour restaurer votre cluster, redémarrez tous les serveurs du cluster, puis cliquez sur "Se connecter au cluster" (si besoin).

Le nom du dernier cluster auquel vous étiez connecté devrait apparaitre dans la case "Nom du cluster".
Cliquez sur OK.

Comme vous pouvez le voir, il y a un événement critique dans les événements de cluster récents.

Lors de l'arrêt automatique du cluster (dû à la perte du quorum), cet événement a été enregistré :

Plain Text

Le service de cluster a rencontré un problème inattendu et doit être arrêté. Code d'erreur : "5008".
ID : 1556

Les 3 noeuds sont maintenant en service.

Pour enlever l'événement, cliquez sur : Réinitialiser les événements.