Pools en cluster

Le clustering fournit des fonctionnalités supplémentaires requises pour les pools de ressources qui utilisent des SR GFS2. Pour plus d’informations sur GFS2, voir Configurer le stockage.

Un cluster est un pool contenant jusqu’à 16 hôtes XenServer qui sont plus étroitement connectés et coordonnés que les hôtes des pools non groupés. Les hôtes du cluster maintiennent une communication constante entre eux sur un réseau sélectionné. Tous les hôtes du cluster connaissent l’état de chaque hôte du cluster. Cette coordination de l’hôte permet au cluster de contrôler l’accès au contenu du GFS2 SR.

Remarque :

La fonctionnalité de clustering ne profite qu’aux pools qui contiennent un SR GFS2. Si votre pool ne contient pas de SR GFS2, n’activez pas le clustering dans votre pool.

Quorum

Chaque hôte d’un cluster doit toujours être en communication avec la majorité des hôtes du cluster (y compris lui-même). Cet état est connu sous le nom d’hôte ayant le quorum. Si un hôte n’a pas le quorum, cet hôte s’auto-escrime.

Le nombre d’hôtes qui doivent être en communication pour atteindre le quorum peut être différent du nombre d’hôtes dont un cluster a besoin pour maintenir le quorum.

Le tableau suivant récapitule ce comportement. La valeur de n est le nombre total d’hôtes dans le pool en cluster.

Pour un pool en cluster, vous pouvez vérifier si le pool a le quorum en interrogeant le paramètre is-quorate du cluster :

  xe cluster-list params=is-quorate uuid=<cluster_id>

Pour voir combien d’hôtes du cluster sont actifs, exécutez la commande suivante :

  xe cluster-list params=live-hosts uuid=<cluster_id>

Pour voir combien d’hôtes actifs sont nécessaires pour que le cluster atteigne le quorum, exécutez la commande suivante :

  xe cluster-list params=quorum uuid=<cluster_id>

Lors de la création du cluster, le nombre d’hôtes actifs doit être supérieur ou égal à cette valeur. Pour conserver le quorum, le nombre d’hôtes requis peut être différent de la valeur renvoyée par cette commande selon que le cluster contient un nombre impair ou pair d’hôtes.

Poules impaires

Pour atteindre la valeur de quorum pour un pool impair, vous avez besoin de la moitié d’un de plus que le nombre total d’hôtes dans le cluster : (n+1)/2. Il s’agit également du nombre minimum d’hôtes qui doivent rester joignables pour que le pool reste quorum.

Par exemple, dans un pool en cluster de 5 hôtes, 3 hôtes doivent être joignables pour que le cluster devienne actif et reste quorum [(5+1)/2 = 3].

Dans la mesure du possible, il est recommandé d’utiliser un nombre impair d’hôtes dans un pool en cluster, car cela garantit que les hôtes sont toujours en mesure de déterminer s’ils ont un quorum défini.

Poules paires

Lorsqu’un pool cluster pair est mis sous tension à partir d’un démarrage à froid, les hôtes (n/2)+1 doivent être disponibles avant que les hôtes n’aient le quorum. Une fois que les hôtes ont atteint le quorum, le cluster devient actif.

Toutefois, un pool pair actif peut rester quorum si le nombre d’hôtes contactables est au moins n/2. Par conséquent, il est possible qu’un cluster en cours d’exécution avec un nombre pair d’hôtes soit divisé exactement en deux. Le cluster en cours d’exécution décide quelle moitié du cluster s’auto-clôture et quelle moitié du cluster a le quorum. La moitié du cluster qui contient le nœud avec l’ID le plus bas qui était considéré comme actif avant la scission du cluster reste active et l’autre moitié du cluster s’auto-escrime.

Par exemple, dans un pool en cluster à 4 hôtes, 3 hôtes doivent être joignables pour que le cluster devienne actif [4/2 + 1 = 3]. Une fois que le cluster est actif, pour maintenir le quorum, seuls 2 hôtes doivent être joignables [4/2 = 2] et cet ensemble d’hôtes doit inclure l’hôte avec l’ID de nœud le plus bas connu pour être actif.

Clôture automatique

Si un hôte détecte qu’il n’a pas le quorum, il s’auto-clôture en quelques secondes. Lorsqu’un hôte s’auto-clôture, il redémarre immédiatement. Toutes les machines virtuelles exécutées sur l’hôte sont immédiatement arrêtées, car l’hôte effectue un arrêt dur. Dans un pool en cluster qui utilise la haute disponibilité, XenServer redémarre les machines virtuelles en fonction de leur configuration de redémarrage sur les autres membres du pool. L’hôte qui s’est auto-clôturé redémarre et tente de rejoindre le cluster.

Si le nombre d’hôtes actifs dans le cluster devient inférieur à la valeur de quorum, tous les hôtes restants perdent le quorum.

Dans un scénario idéal, votre pool en cluster dispose toujours de plus d’hôtes actifs que nécessaire pour le quorum et XenServer ne clôture jamais. Pour rendre ce scénario plus probable, tenez compte des recommandations suivantes lors de la configuration de votre pool en cluster :

• Assurez-vous que vous disposez d’une bonne redondance matérielle.

• Utilisez un réseau lié dédié pour le réseau de cluster. Assurez-vous que les cartes réseau liées se trouvent sur le même segment L2. Pour plus d’informations, voir Réseau.

• Configurez le multipathing de stockage entre le pool et le SR GFS2. Pour plus d’informations, consultez Multipathing de stockage.

Créer un pool en cluster

Avant de commencer, assurez-vous que les conditions préalables suivantes sont remplies :

• Tous les hôtes XenServer du pool en cluster doivent disposer d’au moins 2 Gio de mémoire de domaine de contrôle.

  Selon votre environnement, vos hôtes peuvent nécessiter plus de mémoire de domaine de contrôle que cela. Si vous ne disposez pas d’une mémoire de domaine de contrôle suffisante sur vos hôtes, votre pool peut rencontrer une instabilité du réseau. L’instabilité du réseau peut entraîner des problèmes pour un pool en cluster avec des SR GFS2. Pour plus d’informations sur la modification de la quantité de mémoire du domaine de contrôle et la surveillance du comportement de la mémoire, consultez Utilisation de la mémoire.

• Tous les hôtes du cluster doivent utiliser des adresses IP statiques pour le réseau du cluster.

• Nous vous recommandons d’utiliser le clustering uniquement dans les pools contenant au moins trois hôtes, car les pools de deux hôtes sont sensibles à l’auto-séparation de l’ensemble du pool.

• Les pools en cluster ne prennent en charge que 16 hôtes par pool.

• Si vous disposez d’un pare-feu entre les hôtes de votre pool, assurez-vous que les hôtes peuvent communiquer sur le réseau du cluster à l’aide des ports suivants :
  • TCP : 8892, 8896, 21064
  • UDP : 5404, 5405

  Pour plus d’informations, consultez Ports de communication utilisés par XenServer.

• Si vous mettez en cluster un pool existant, assurez-vous que la haute disponibilité est désactivée. Vous pouvez réactiver la haute disponibilité une fois le clustering activé.

• Nous vous recommandons fortement d’utiliser un réseau lié pour votre pool en cluster qui n’est utilisé pour aucun autre trafic.

Si vous préférez, vous pouvez configurer le clustering sur votre pool en utilisant XenCenter. Pour plus d’informations, consultez la documentation du produit XenCenter.

Pour utiliser l’interface de ligne de commande xe afin de créer un pool en cluster :

1. Créez un réseau lié à utiliser comme réseau de clustering.

   Remarque :

   Nous vous recommandons fortement d’utiliser un réseau lié dédié pour votre pool en cluster. N’utilisez pas ce réseau pour tout autre trafic.

   Sur l’hôte XenServer que vous souhaitez définir comme coordinateur de pool, procédez comme suit :

   1. Ouvrez une console sur l’hôte XenServer.

   2. Créez un réseau à utiliser avec la carte réseau liée à l’aide de la commande suivante :

        xe network-create name-label=bond0
      <!--NeedCopy-->
      

      L’UUID du nouveau réseau est renvoyé.

   3. Recherchez les UUID des PIF à utiliser dans la liaison à l’aide de la commande suivante :

        xe pif-list
      <!--NeedCopy-->
      

   4. Créez votre réseau lié en mode actif-actif, en mode actif-passif ou en mode liaison LACP. Selon le mode de liaison que vous souhaitez utiliser, effectuez l’une des actions suivantes :

      • Pour configurer la liaison en mode actif-actif (par défaut), utilisez la commande bond-create pour créer la liaison. En utilisant des virgules pour séparer les paramètres, spécifiez l’UUID du réseau nouvellement créé et les UUID des PIF à lier :

           xe bond-create network-uuid=<network_uuid> /
                pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4>
         <!--NeedCopy-->
        

        Tapez deux UUID lorsque vous liez deux cartes réseau et quatre UUID lorsque vous liez quatre cartes réseau. L’UUID de la liaison est renvoyé après l’exécution de la commande.

      • Pour configurer la liaison en mode liaison actif-passif ou LACP, utilisez la même syntaxe, ajoutez le paramètre facultatif mode et spécifiez lacp ou active-backup:

           xe bond-create network-uuid=<network_uuid> pif-uuids=<pif_uuid_1>, /
                <pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> /
                mode=balance-slb | active-backup | lacp
         <!--NeedCopy-->
        

   Une fois que vous avez créé votre réseau lié sur le coordinateur de pool, lorsque vous joignez d’autres hôtes XenServer au pool, les informations sur le réseau et la liaison sont automatiquement répliquées sur le serveur de jonction.

   Pour plus d’informations, consultez Réseautage.

2. Créez un pool de ressources d’au moins trois hôtes XenServer.

   Répétez les étapes suivantes sur chaque hôte XenServer qui est un membre du pool (non maître) :

   1. Ouvrez une console sur l’hôte XenServer.

   2. Joignez l’hôte XenServer au pool sur le coordinateur de pool à l’aide de la commande suivante :

        xe pool-join master-address=master_address master-username=administrators_username master-password=password
      <!--NeedCopy-->
      

      La valeur de la adresse-maître doit être défini sur le nom de domaine complet de l’hôte XenServer qui est le coordinateur du pool. Le mot de passe Il doit s’agir du mot de passe administrateur défini lors de l’installation du coordinateur de pool.

   Pour plus d’informations, consultez Hôtes et pools de ressources.

3. Pour chaque PIF appartenant à ce réseau, définissez disallow-unplug=vrai.

   1. Recherchez les UUID des PIF qui appartiennent au réseau à l’aide de la commande suivante :

        xe pif-list
      <!--NeedCopy-->
      

   2. Exécutez la commande suivante sur un hôte XenServer de votre pool de ressources :

        xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
      <!--NeedCopy-->
      

4. Activez le clustering sur votre pool. Exécutez la commande suivante sur un hôte XenServer de votre pool de ressources :

     xe cluster-pool-create network-uuid=<network_uuid>
   <!--NeedCopy-->
   

   Indiquez l’UUID du réseau lié que vous avez créé à l’étape précédente.

Destruction d’un pool en cluster

Vous pouvez détruire un pool en cluster. Une fois que vous avez détruit un pool en cluster, celui-ci continue d’exister, mais n’est plus en cluster et ne peut plus utiliser les SR GFS2.

Pour détruire un pool en cluster, exécutez la commande suivante :

  xe cluster-pool-destroy cluster-uuid=<uuid>

Gérer votre pool en cluster

Lors de la gestion de votre pool clusterisé, les pratiques suivantes peuvent réduire le risque de perte de quorum du pool.

Ajouter ou supprimer un hôte sur un pool en cluster

Lors de l’ajout ou de la suppression d’un hôte sur un pool en cluster, assurez-vous que tous les hôtes du cluster sont en ligne.

Vous pouvez ajouter ou supprimer un hôte sur un pool en cluster à l’aide de XenCenter. Pour plus d’informations, consultez Ajouter un serveur à un pool et Suppression d’un serveur d’un pool.

Vous pouvez également ajouter ou supprimer un hôte sur un pool en cluster à l’aide de l’interface de ligne de commande xe. Pour plus d’informations, voir Ajouter un hôte à un pool à l’aide de la CLI xe et Supprimer des hôtes XenServer d’un pool de ressources.

Assurez-vous que les hôtes sont arrêtés proprement

Lorsqu’un hôte est arrêté proprement, il est temporairement supprimé du cluster jusqu’à ce qu’il soit redémarré. Lorsque l’hôte est arrêté, il ne compte pas dans le quorum du cluster. L’absence de l’hôte n’entraîne pas la perte du quorum pour les autres hôtes. Pour plus d’informations, voir Arrêter un hôte XenServer.

Toutefois, si un hôte est arrêté de force ou de manière inattendue, il n’est pas supprimé du cluster avant d’être mis hors connexion. Cet hôte est pris en compte dans la valeur de quorum du cluster. Son arrêt peut faire perdre le quorum à d’autres hôtes.

S’il est nécessaire d’arrêter de force un hôte, vérifiez d’abord combien d’hôtes actifs se trouvent dans le cluster. Vous pouvez le faire avec la commande corosync-quorumtool. Dans la sortie de la commande, le nombre d’hôtes en direct est la valeur de Total des votes : et le nombre d’hôtes en direct requis pour conserver le quorum est la valeur de Quorum:.

• Si le nombre d’hôtes en direct est le même que le nombre d’hôtes nécessaires pour maintenir le quorum, ne forcez pas l’arrêt de l’hôte. Cela provoque la clôture de l’ensemble du groupe.

  Au lieu de cela, essayez de récupérer d’autres hôtes et d’augmenter le nombre d’hôtes en direct avant de forcer l’arrêt de l’hôte.

• Si le nombre d’hôtes en direct est proche du nombre d’hôtes nécessaires pour maintenir le quorum, vous pouvez forcer l’arrêt de l’hôte. Toutefois, cela rend le cluster plus vulnérable à la séparation complète si d’autres hôtes du pool rencontrent des problèmes.

Essayez toujours de redémarrer l’hôte arrêté dès que possible pour augmenter la résilience de votre cluster.

Utiliser le mode maintenance

Avant de faire quelque chose sur un hôte qui pourrait faire perdre le quorum à cet hôte, mettez l’hôte en mode maintenance. Lorsqu’un hôte est en mode maintenance, les machines virtuelles en cours d’exécution sont migrées vers un autre hôte du pool. De plus, si cet hôte était le coordinateur du pool, ce rôle est transmis à un autre hôte du pool. Si vos actions entraînent l’auto-clôture d’un hôte en mode maintenance, vous ne perdez aucune machine virtuelle ni votre connexion XenCenter au pool.

Les hôtes en mode maintenance sont toujours pris en compte dans la valeur de quorum du cluster.

Vous ne pouvez modifier l’adresse IP d’un hôte qui fait partie d’un pool en cluster que lorsque cet hôte est en mode de maintenance. La modification de l’adresse IP d’un hôte entraîne la sortie de celui-ci du cluster. Lorsque l’adresse IP a été modifiée avec succès, l’hôte rejoint le cluster. Une fois que l’hôte a rejoint le cluster, vous pouvez le sortir du mode de maintenance.

Récupérer les hôtes qui se sont auto-clôturés ou qui sont hors ligne

Il est important de récupérer les hôtes qui se sont auto-clôturés. Lorsque ces membres du cluster sont hors connexion, ils sont comptabilisés dans le nombre de quorum du cluster et diminuent le nombre de membres du cluster pouvant être contactés. Cette situation augmente le risque qu’une défaillance ultérieure de l’hôte entraîne la perte du quorum et l’arrêt complet du cluster.

La présence d’hôtes hors ligne dans votre cluster vous empêche également d’effectuer certaines actions. Dans un pool clusterisé, chaque membre du pool doit accepter chaque modification de l’appartenance au pool pour que la modification puisse réussir. Si un membre du cluster n’est pas joignable, XenServer empêche les opérations qui modifient l’appartenance au cluster (telles que l’ajout ou la suppression d’un hôte).

Marquer les hôtes comme irrécupérables

Si un ou plusieurs hôtes hors ligne ne peuvent pas être récupérés, vous pouvez demander au pool en cluster de les oublier. Ces hôtes sont définitivement supprimés du pool. Une fois les hôtes supprimés du pool en cluster, ils ne sont plus pris en compte dans la valeur du quorum.

Pour marquer un hôte comme irrécupérable, utilisez la commande suivante :

  xe host-forget uuid=<host_uuid>

Récupérer un hôte oublié

Une fois qu’un pool en cluster a reçu l’ordre d’oublier un hôte, celui-ci ne peut pas être rajouté au pool.

Pour rejoindre à nouveau le pool en cluster, vous devez réinstaller XenServer sur l’hôte afin qu’il apparaisse comme un nouvel hôte dans le pool. Vous pouvez ensuite joindre l’hôte au pool en cluster de la manière habituelle.

Résoudre les problèmes liés à votre pool en cluster

Si vous rencontrez des problèmes avec votre pool en cluster, consultez Résoudre les problèmes des pools en cluster.

Contraintes

• Les pools en cluster ne prennent en charge que 16 hôtes par pool.
• Pour activer HA sur votre pool en cluster, le SR de pulsation doit être un SR GFS2.
• Pour le trafic de cluster, nous vous recommandons vivement d’utiliser un réseau lié qui utilise au moins deux commutateurs réseau différents. N’utilisez pas ce réseau à d’autres fins.
• La modification de l’adresse IP du réseau de cluster à l’aide de XenCenter nécessite la désactivation temporaire du clustering et de GFS2.
• Ne modifiez pas la liaison de votre réseau de clustering lorsque le cluster est en ligne et que des machines virtuelles sont en cours d’exécution. Cette action peut entraîner un redémarrage dur des hôtes du cluster (clôture).
• Si vous avez un conflit d’adresses IP (plusieurs hôtes ayant la même adresse IP) sur votre réseau de clustering impliquant au moins un hôte pour lequel le clustering est activé, le cluster ne se forme pas correctement et les hôtes ne peuvent pas se clôturer lorsque cela est nécessaire. Pour résoudre ce problème, résolvez le conflit d’adresse IP.