layout: doc description: Create, manage, or destroy a clustered pool of XenServer hosts. Understand the constraints and requirements associated with setting up a clustered pool.—
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 de 16 hôtes XenServer plus étroitement connectés et coordonnés que les hôtes des pools non clusterisé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 contenant un GFS2 SR. Si votre pool ne contient pas de SR GFS2, n’activez pas le clustering dans votre pool.
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 quorum. Si un hôte n’a pas le quorum, cet hôte se limite à lui-même.
Le nombre d’hôtes qui doivent être en communication pour atteindre initialement 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 du pool clusterisé.
| Nombre d’hôtes requis pour atteindre le quorum | Nombre d’hôtes requis pour respecter le quorum | |
|---|---|---|
| Nombre impair d’hôtes dans le pool | (n+1)/2 | (n+1)/2 |
| Nombre pair d’hôtes dans le pool | (n/2)+1 | n/2 |
Pour atteindre la valeur de quorum d’un pool impair, vous avez besoin de la moitié d’un de plus que le nombre total d’hôtes du cluster : (n+1) /2. Il s’agit également du nombre minimum d’hôtes qui doivent rester joignables pour que le pool soit maintenu en quorum.
Par exemple, dans un pool clusterisé à 5 hôtes, 3 hôtes doivent être joignables pour que le cluster soit à la fois actif et reste quoré [(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 quorate défini.
Lorsqu’un pool en cluster pair se met sous tension à la suite d’un démarrage à froid, (n/2) +1 hôtes doivent être disponibles pour que les hôtes atteignent le quorum. Une fois que les hôtes ont atteint le quorum, le cluster devient actif.
Toutefois, un pool pair actif peut rester en quorum si le nombre d’hôtes joignables est au moins égal à n/2. Par conséquent, il est possible qu’un cluster en cours d’exécution avec un nombre pair d’hôtes se divise exactement en deux. Le cluster en cours d’exécution décide quelle moitié du cluster est auto-clôturée et quelle moitié du cluster possède le quorum. La moitié du cluster qui contient le nœud dont l’ID est le plus bas et qui était considéré comme actif avant la division du cluster reste active et l’autre moitié du cluster se limite automatiquement.
Par exemple, dans un pool clusterisé à 4 hôtes, 3 hôtes doivent être joignables pour que le cluster devienne actif [4/2 + 1 = 3]. Une fois le cluster actif, pour que le quorum soit maintenu, seuls 2 hôtes doivent être joignables [4/2 = 2] et cet ensemble d’hôtes doit inclure l’hôte dont l’ID de nœud est le plus bas connu pour être actif.
Si un hôte détecte qu’il n’a pas le quorum, il se bloque automatiquement en quelques secondes. Lorsqu’un hôte se bloque, il redémarre immédiatement. Toutes les machines virtuelles exécutées sur l’hôte sont immédiatement arrêtées en raison d’un arrêt brutal de l’hôte. 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 du quorum, tous les hôtes restants perdent le quorum.
Dans un scénario idéal, votre pool en cluster possède toujours plus d’hôtes actifs que ce qui est requis 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 de disposer d’une bonne redondance matérielle.
Utilisez un réseau lié dédié pour le réseau de clusters. Assurez-vous que les cartes réseau liées se trouvent sur le même segment L2. Pour plus d’informations, reportez-vous à la section Mise en réseau.
Configurez le multiacheminement du stockage entre le pool et le GFS2 SR. Pour plus d’informations, voir Multiacheminement de stockage.
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 Go de mémoire de domaine de contrôle.
En fonction de votre environnement, vos hôtes peuvent avoir besoin d’une quantité de mémoire de domaine de contrôle supérieure à celle-ci. Si la mémoire du domaine de contrôle de vos hôtes est insuffisante, votre pool peut connaître une instabilité 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, voir 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 de n’utiliser le clustering que dans les pools contenant au moins trois hôtes, car les pools de deux hôtes sont susceptibles d’isoler automatiquement l’ensemble du pool.
Les pools en cluster ne prennent en charge que 16 hôtes par pool.
Pour plus d’informations, consultez la section 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é.
Si vous préférez, vous pouvez configurer le clustering sur votre pool à l’aide de XenCenter. Pour plus d’informations, consultez la documentation du produit XenCenter.
Pour utiliser l’interface de ligne de commande xe pour créer un pool en cluster :
Créez un réseau lié à utiliser comme réseau de clustering.
Remarque :
Nous vous recommandons vivement d’utiliser un réseau lié dédié pour votre pool en cluster. N’utilisez pas ce réseau pour d’autres trafics.
Sur l’hôte XenServer que vous souhaitez utiliser comme coordinateur du pool, effectuez les étapes suivantes :
Ouvrez une console sur l’hôte XenServer.
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é.
Recherchez les UUID des PIF à utiliser dans la liaison à l’aide de la commande suivante :
xe pif-list
<!--NeedCopy-->
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. À l’aide de virgules pour séparer les paramètres, spécifiez l’UUID 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-->
Saisissez 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 de liaison actif-passif ou LACP, utilisez la même syntaxe, ajoutez le paramètre mode facultatif 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 du pool, lorsque vous joignez d’autres hôtes XenServer au pool, les informations relatives au réseau et aux liaisons sont automatiquement répliquées sur le serveur de jonction.
Pour plus d’informations, reportez-vous à la section Mise en réseau.
Créez un pool de ressources d’au moins trois hôtes XenServer.
Répétez les étapes suivantes sur chaque hôte XenServer membre (non maître) du pool :
Joignez l’hôte XenServer au pool sur le coordinateur du pool à l’aide de la commande suivante :
xe pool-join master-address=master_address master-username=administrators_username master-password=password
<!--NeedCopy-->
La valeur du master-address paramètre doit être définie sur le nom de domaine complet de l’hôte XenServer qui est le coordinateur du pool. password doit être le mot de passe administrateur défini lors de l’installation du coordinateur du pool.
Pour plus d’informations, consultez Hôtes et pools de ressources.
Pour chaque PIF appartenant à ce réseau, définissez disallow-unplug=true.
Recherchez les UUID des PIF appartenant au réseau à l’aide de la commande suivante :
xe pif-list
<!--NeedCopy-->
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-->
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-->
Fournissez l’UUID du réseau lié que vous avez créé lors d’une étape précédente.
Vous pouvez détruire un pool en cluster. Une fois que vous avez détruit un pool en cluster, le pool continue d’exister, mais n’est plus mis 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>
Lors de la gestion de votre pool en cluster, les pratiques suivantes peuvent réduire le risque que le pool perde le quorum.
Lorsque vous ajoutez ou supprimez un hôte dans un pool en cluster, assurez-vous que tous les hôtes du cluster sont en ligne.
Vous pouvez ajouter ou supprimer un hôte dans un pool en cluster à l’aide de XenCenter. Pour plus d’informations, voir Ajouter un serveur à un pool et Supprimer un serveur d’un pool.
Vous pouvez également ajouter ou supprimer un hôte dans un pool en cluster à l’aide de l’interface de ligne de commande xe. Pour plus d’informations, consultez Ajouter un hôte à un pool à l’aide de l’interface de ligne de commande xe et Supprimer des hôtes XenServer d’un pool de ressources.
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 n’est pas pris en compte dans la valeur de quorum du cluster. L’absence de l’hôte n’entraîne pas la perte du quorum des autres hôtes.
Toutefois, si un hôte est arrêté de manière forcée ou inattendue, il n’est pas supprimé du cluster avant d’être mis hors ligne. Cet hôte est pris en compte dans la valeur de quorum du cluster. Son arrêt peut entraîner la perte du quorum d’autres hôtes.
S’il est nécessaire d’arrêter un hôte de force, vérifiez d’abord combien d’hôtes actifs se trouvent dans le cluster. Vous pouvez le faire à l’aide de la commande corosync-quorumtool. Dans la sortie de la commande, le nombre d’hôtes actifs est la valeur de Total votes: et le nombre d’hôtes actifs requis pour conserver le quorum est la valeur de Quorum:.
Si le nombre d’hôtes actifs est identique au nombre d’hôtes nécessaires pour maintenir le quorum, n’arrêtez pas l’hôte de force. Cela entraîne la clôture de l’ensemble du cluster.
Essayez plutôt de récupérer d’autres hôtes et d’augmenter le nombre d’hôtes actifs avant d’arrêter de force l’hôte.
Si le nombre d’hôtes actifs est proche du nombre d’hôtes nécessaires pour maintenir le quorum, vous pouvez arrêter l’hôte de force. Toutefois, cela rend le cluster plus vulnérable à une clôture 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 afin d’augmenter la résilience de votre cluster.
Avant de faire quelque chose sur un hôte qui pourrait entraîner la perte de quorum de 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 hors de celui-ci 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 du 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 maintenance. La modification de l’adresse IP d’un hôte entraîne la sortie de l’hôte 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.
Il est important de récupérer les hôtes qui se sont auto-clôturés. Lorsque ces membres du cluster sont hors ligne, ils sont pris en compte dans le quorum du cluster et diminuent le nombre de membres du cluster joignables. Cette situation augmente le risque d’une défaillance ultérieure de l’hôte entraînant 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 en cluster, chaque membre du pool doit accepter chaque changement d’adhésion au pool pour que le changement puisse être effectué. 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’hôtes).
Si un ou plusieurs hôtes hors ligne ne peuvent pas être restauré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 retirés du pool en cluster, ils ne sont plus pris en compte dans la valeur de quorum.
Pour marquer un hôte comme irrécupérable, utilisez la commande suivante :
xe host-forget uuid=<host_uuid>
Lorsqu’un pool clusterisé reçoit l’ordre d’oublier un hôte, celui-ci ne peut pas être réintégré au pool.
Pour rejoindre le pool en cluster, vous devez réinstaller XenServer sur l’hôte afin qu’il apparaisse comme un nouvel hôte du pool. Vous pouvez ensuite joindre l’hôte au pool en cluster de la manière habituelle.
Si vous rencontrez des problèmes avec votre pool en cluster, voir Résoudre les problèmes liés aux pools en cluster.