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

4. Priorités pour le basculement

Lorsque vous n'avez que 2 noeuds (serveurs) dans un cluster, le rôle mis en cluster basculera évidemment sur l'autre serveur lorsque le serveur hébergeant ce rôle tombe en panne.
Mais, lorsque vous possédez au moins 3 serveurs, il peut être intéressant de gérer les priorités de basculement, ainsi que de pouvoir restaurer automatiquement ou non les différents rôles sur tel ou tel serveur
Raison pour laquelle nous venons d'ajouter un 3ème serveur à notre cluster.

Faites un clic droit "Propriétés" sur un rôle mis en cluster.
Dans notre cas, le rôle "iw-file-server" de type "Serveur de fichiers".

Comme vous pouvez le voir, vous pouvez choisir un ou plusieurs propriétaires favoris pour un rôle mis en cluster.

Si vous choisissez un propriétaire favori, le rôle sera hébergé par défaut sur ce serveur.
Ensuite, en cas de panne, puis de remise en ligne de ce serveur, ce rôle sera restauré automatiquement sur ce serveur (si la restauration automatique est activée dans l'onglet "Basculement" de ce rôle).

Si vous choisissez plusieurs propriétaires favoris, vous pourrez gérer la priorité entre ceux-ci en les cochant, puis en changeant l'ordre de priorité grâce aux boutons "Monter" et "Descendre".

Notez que le changement de l'ordre pour les serveurs qui ne sont pas cochés dans cette liste n'aura aucun effet.
En effet, lorsque vous fermerez cette fenêtre et que vous la rouvrirez, l'ordre des serveurs non cochés sera redevenu celui par défaut.

Vous pourrez également spécifier une priorité pour ce rôle et plus précisément une priorité de démarrage.
Autrement dit, il sera possible d'indiquer à un cluster que tel ou tel rôle est plus important et qu'il devra donc être démarré en priorité par rapport à d'autres rôles moins importants.

Note : cette priorité est liée au rôle et non au serveur sélectionné dans la liste ci-dessus. Ce sont 2 options complètement différentes.

Dans l'onglet "Basculement", vous pourrez définir le nombre d'échecs maximal pour une période donnée.
Au-delà de ce nombre d'échecs, le rôle ne démarrera plus sur le serveur concerné.

Vous pourrez également activer ou désactiver la restauration automatique du rôle sur un des serveurs définis en tant que propriétaires favoris.

La restauration automatique permet de restaurer le rôle sur un serveur favori pour qu'il soit hébergé sur le serveur que vous considérez comme plus fiable et/ou plus performant pour le rôle concerné.
Néanmoins, si vous autorisez la restauration automatique de façon immédiate, cela peut provoquer 2 coupures du service hébergé au lieu d'une.

Si tous les serveurs de votre cluster sont identiques (ce qui devrait normalement être le cas), vous pouvez interdire la restauration automatique.
Ainsi, il n'y aura une coupure de service uniquement lorsque le serveur hébergeant ce service tombera en panne.

Si vous souhaitez vraiment restaurer le rôle sur un serveur favori (pour une raison x ou y), nous vous recommandons de planifier cette restauration automatique à une heure qui se situe en dehors des heures de boulot (en général : pendant la nuit).
Ainsi, le rôle fonctionnera principalement sur le serveur favori de votre cluster et la 2ème coupure ne dérangera personne.

5. Tests de basculement

5.1. Configuration de base

Pour tester le basculement de notre rôle, nous allons autoriser la restauration automatique immédiate.
Néanmoins, nous vous déconseillons d'utiliser cette option en production pour les raisons expliquées précédemment.

Précédemment, nous avions défini notre serveur "clust-s2" comme serveur propriétaire favori.
Pour éviter de partir sur de mauvaises bases, nous allons donc déplacer le rôle sur ce noeud.

Pour cela, sélectionnez le rôle à déplacer et faites un clic droit "Déplacer -> Sélectionnez un noeud" sur celui-ci.

Sélectionnez le serveur "clust-s2".

Le rôle est maintenant hébergé par notre serveur "clust-s2".

5.2. Serveur propriétaire en panne

Nous arrêtons le serveur "clust-s2" qui héberge actuellement notre rôle "Serveur de fichiers" pour simuler une panne de celui-ci.

Comme vous pouvez le voir dans le gestionnaire du cluster de basculement, le statut du rôle est actuellement en attente.

Quelques secondes plus tard, le rôle a été migré sur le 2ème serveur propriétaire favori défini précédemment : clust-s1.

5.3. Restauration du rôle sur le propriétaire favori

Comme indiqué précédemment, nous avions sélectionné 2 propriétaires favoris pour notre rôle "Serveur de fichiers".
Le serveur "clust-s2" avait été indiqué comme prioritaire par rapport à "clust-s1".

En admettant que nous venions de réparer notre serveur 2, nous le redémarrons et le gestionnaire du cluster de basculement finira par le détecter.
A ce moment-là, vous verrez que l'état du serveur 2 sera "Jonction en cours".

Etant donné que la restauration automatique immédiate (que nous vous déconseillons en production) est activée, le rôle sera restauré automatiquement sur le serveur clust-s2 (dans notre cas).
Cela confirme ce que nous vous avions expliqué précédemment. Et notamment le fait que cela provoque 2 coupures de services au lieu d'une (une lorsque le serveur tombe en panne et une autre lorsque le serveur est remis en service).

Maintenant, notre rôle fonctionne à nouveau sur le propriétaire favori le plus prioritaire : clust-s2.