Comment configurer des groupes de prise en charge secours à chaud de clusters Windows

Cet article décrit la possibilité de Windows Server 2003 et Windows Server 2008 pour configurer Windows Clustering pour prise en charge secours à chaud.

Avec l'arrivée de plus grandes tailles de cluster (quatre et huit n?uds), les topologies "A + Hs" deviennent importants lorsque le cluster possède un ensemble de «A» n?uds actuellement actifs et un jeu de n?uds "Hs" qui sont actuellement passifs ou en mode veille à chaud. Les clusters de plus grandes améliorent les configurations de prise en charge (actif ou passif), telles que la configuration précédente car les configurations peuvent de réduire le coût d'un ou plusieurs n?uds en attente sur un plus grand ensemble de n?uds actifs.

Par exemple, avec un cluster deux n?uds, le coût d'une configuration actif et/ou passif nécessite deux fois le matériel pour la même capacité, avec huit n?uds exécutant que sept actif et un passif. Le matériel supplémentaire augmente le coût de seulement 15 %.

Clustering Windows ne fait aucune distinction entre les n?uds durant un basculement. Windows Clustering ne modifie pas la stratégie de basculement, qui repose sur la charge ou des programmes qui exécutent (et où ils s'exécutent). Ce comportement peut rendre très difficiles à gérer un n?ud de secours à chaud peut prendre la charge lorsqu'une défaillance se produit. Le seul moyen d'influencer la stratégie de basculement consiste à modifier les listes de n?ud possible. Car ce comportement est effectué en dehors du service de cluster de manière asynchrone à d'autres événements cluster (par exemple, défaillances de n?ud), il n'existe aucune garantie qu'un programme peut correctement s'assurer que le n?ud de rechange peut être choisi dans le cas d'un basculement.

Il existe des programmes où ce comportement est essentiel, par exemple, Microsoft Exchange 2000, où la base de données back-end Exchange peut être partitionnée et réparti sur un nombre de n?uds de cluster. Cependant, Exchange peut placer une telle charge sur le réseau qu'en cas d'une défaillance de n?ud, il est déconseillé pour échouer sur une partition sur un n?ud qui héberge déjà une partition différente de la base de données. L'objectif de cette amélioration est pour vous assurer que le service de cluster peut modifier sa stratégie de basculement pour garantir que s'il existe un n?ud qui n'a pas une partition actuellement hébergée sur celui-ci, le n?ud passif peut être considéré comme avant les n?uds actifs sont héberge déjà une partition. Pour garantir haute disponibilité du service, si aucun spares ou si pour une raison quelconque (par exemple, plusieurs défaillances) n'existe aucun n?ud de rechange, la stratégie de basculement peut restaurer la valeur par défaut. En d'autres termes, la stratégie de basculement n'échoue pas services si il y n'a aucun n?ud de rechange est disponible.

La propriété AntiAffinityClassNames

Le groupe de Clustering Windows possède une propriété publique : AntiAffinityClassNames . Cette propriété peut contenir une chaîne arbitraire de caractères. En cas de basculement, si un groupe qui est en cours a basculé possède une chaîne qui n'est pas vide dans la propriété AntiAffinityClassNames , le Gestionnaire de basculement pouvez vérifier tous les autres n?uds. S'il existe des n?uds (qui sont dans la liste Propriétaires possibles pour la ressource) qui n'hébergent pas un groupe avec la même valeur AntiAffinityClassNames , ces n?uds sont considérés comme une cible par défaut pour le basculement. Cette valeur peut prendre une priorité plus élevée sur la liste Propriétaires favoris.

Les deux scénarios suivants montrent comment utiliser cette propriété :

• Dans un cluster "A + Hs" qui exécute un seul programme. Par exemple, un cluster qui exécute Exchange. Dans ce cas, Exchange doit configurer chaque groupe est prise en charge une partition avec la propriété AntiAffinityClassNames définie à une valeur spécifique à Exchange (la même valeur pour chaque groupe), par exemple, «Exchange». En cas de défaillance, le Gestionnaire de basculement peut tenter de conserver les partitions les uns des autres en sélectionnant des n?uds qui n'hébergent pas de groupes ayant la même valeur AntiAffinityClassNames de «Exchange».
• Dans une consolidation de serveur où il existe plusieurs programmes qui doivent être conservées les uns des autres, si possible. Dans ce cas, les groupes qui sont représentant les divers programmes doivent être modifiés manuellement avec la même valeur dans la propriété AntiAffinityClassNames .

L'affinité de groupe peut être configurée seulement à l'aide de l'outil de ligne de commande cluster.exe. Est un exemple de la syntaxe correcte pour l'exemple qui figure à partir du premier scénario précédent : Cette syntaxe pouvez créer la clé de Registre REG_MULTI_SZ suivante : Remarque Vous pouvez utiliser l'exemple suivant commande cluster.exe pour effacer la valeur AntiAffinityClassNames et avoir recours au comportement par défaut : Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la base de connaissances Microsoft : Ou, recherchez «Cluster Server» dans le fichier d'aide de Windows.