Comportement de basculement sur des clusters de trois nœuds ou plus

Cet article décrit la logique selon laquelle les groupes échouent d’un nœud à un autre lorsqu’il existe au moins trois membres de nœud de cluster.

S’applique à : Windows Server 2012 R2
Numéro de la base de connaissances d’origine : 299631

Résumé

Le déplacement d’un groupe peut être provoqué par un administrateur qui déplace manuellement un groupe ou par une défaillance de nœud ou de ressource. L’emplacement où le groupe se déplace dépend de la façon dont le déplacement est lancé et si la liste Propriétaire préféré est définie.

Plus d’informations

Des informations sur la liste des propriétaires préférés sont traitées dans le fichier d’aide sous « Clusters de serveurs », notamment des informations sur la planification et l’optimisation des clusters de serveurs. Cet article décrit les quatre scénarios possibles suivants :

  1. Il y a une défaillance de nœud ou de ressource et la liste des propriétaires préférés est définie.
  2. Il y a une défaillance de nœud ou de ressource et la liste des propriétaires préférés n’est pas définie.
  3. L’administrateur déplace manuellement le groupe vers « Meilleur possible » et la liste des propriétaires préférés est définie.
  4. L’administrateur déplace manuellement le groupe vers « Meilleur possible » et la liste des propriétaires préférés n’est pas définie.

Scénario 1

Si un nœud ou une ressource échoue et que la liste des propriétaires préférés a été définie, le service de cluster fait passer le groupe au nœud suivant disponible dans la liste des nœuds. La liste des nœuds est composée de la liste des propriétaires préférés suivie des nœuds restants organisés par leur ID de nœud. L’ID de nœud est défini lorsqu’un nœud est joint à un cluster ou si un nœud est supprimé ou ajouté à nouveau.

Vous pouvez afficher l’ordre des ID de nœud en examinant le Registre sous la clé \HKEY_LOCAL_MACHINE\Cluster\Nodes.

Par exemple, supposons que nous avons un cluster à six nœuds et que les nœuds ont été installés et joints au cluster dans l’ordre suivant : NodeA, NodeB, NodeC, NodeD, NodeE et NodeF. Supposons qu’un groupe a NodeA, NodeC et NodeE répertoriés comme propriétaires préférés.

Avec ces informations, la liste de nœuds pour le groupe serait alors la suivante :

  1. NodeA - Propriétaire préféré numéro un
  2. NodeC - Propriétaire préféré numéro deux
  3. NodeE - Propriétaire préféré numéro trois
  4. NodeB - Deuxième nœud installé
  5. NodeD - Quatrième nœud installé
  6. NodeF - Sixième nœud installé

Dans ce scénario, si une défaillance de nœud ou une défaillance d’une ressource devait se produire et que son seuil de redémarrage était atteint, l’ensemble du groupe échoue au nœud suivant dans la liste des nœuds. Par exemple, si NodeC contenait la ressource qui a échoué, l’ensemble du groupe échoue sur NodeE. Il n’échouerait pas à NodeA, même s’il est répertorié en premier dans la liste des propriétaires préférés. Si NodeE échoue, le groupe bascule vers NodeB et non vers NodeA.

Scénario 2A

Si une ressource échoue et que la liste des propriétaires préférés n’est pas définie, le groupe suit une liste de nœuds comme dans le scénario 1. La liste de nœuds est générée uniquement à partir de l’ID de nœud. En cas de défaillance d’un nœud ou d’une ressource, les ressources suivent un chemin vers le bas qui échoue vers le nœud suivant dans la liste des nœuds. Lorsqu’il atteint le dernier nœud répertorié dans la liste des nœuds, il commence par le premier nœud de la liste des nœuds.

  1. NodeA - Premier nœud installé

  2. NodeC - Deuxième nœud installé

  3. NodeE - Troisième nœud installé

  4. NodeB - Quatrième nœud installé

  5. NodeD - Cinquième nœud installé

  6. NodeF - Sixième nœud installé

Par exemple, cette liste contient l’ordre d’installation des différents nœuds de cluster. En cas d’échec de NodeE, tous les groupes qu’il possédait basculent vers NodeB et non vers NodeF.

Scénario 2B

Si un nœud échoue et que la liste des propriétaires préférés n’est pas définie pour un groupe sur ce nœud, un nœud disponible est sélectionné de manière aléatoire pour le groupe à déplacer. Cela répartit les groupes entre les nœuds disponibles.

Scénario 3

Si un administrateur de cluster choisit manuellement Déplacer le groupe et sélectionne Meilleur possible et que la liste des propriétaires préférés est configurée, le groupe démarre toujours en haut de la liste des nœuds. Comme dans le scénario 1, la liste des nœuds est composée de la liste des propriétaires préférés et de l’ordre d’installation.

  1. NodeA - Propriétaire préféré numéro un
  2. NodeC - Propriétaire préféré numéro deux
  3. NodeE - Propriétaire préféré numéro trois
  4. NodeB - Deuxième nœud installé
  5. NodeD - Quatrième nœud installé
  6. NodeF - Sixième nœud installé

Dans cet exemple, lorsque Le meilleur possible est sélectionné, le groupe tente toujours de se déplacer vers NodeA. Si le groupe est déjà sur NodeA ou si NodeA n’est pas disponible, le groupe tente de passer à NodeC. Si un groupe se trouve sur NodeD et que l’administrateur choisit de le déplacer vers Le meilleur possible, le groupe passe à NodeA. Si NodeA, NodeC ou NodeE ne sont pas actifs, NodeB ou NodeF est choisi de manière aléatoire.

Scénario 4

Si, en tant qu’administrateur de cluster, vous choisissez manuellement Déplacer le groupe et que vous sélectionnez Meilleur possible et que la liste des propriétaires préférés n’est pas configurée, un nœud actif est choisi de manière aléatoire pour héberger le groupe. Sans la liste des propriétaires préférés configurée, il est possible qu’un groupe se déplace vers un nœud qui exécute déjà plusieurs autres groupes.

Nous vous recommandons de configurer la liste Propriétaire préféré sur un cluster de nœuds volumineux si la charge entre les nœuds est sensiblement différente ou si les nœuds ne sont pas homogènes.

Remarque

L’exception au comportement de basculement mentionné ici concerne le groupe par défaut qui contient la ressource quorum nommée Groupe de clusters. Le groupe de clusters ne suit pas le comportement classique de liste de propriétaires préférés. Au lieu de cela, si le propriétaire de la ressource Quorum échoue, le nouveau propriétaire est le groupe précédent qui a réussi à posséder la ressource Quorum.

La propriété publique AntiAffinityClassNames peut également affecter l’emplacement vers lequel un groupe bascule.