Pools en cluster GFS2
Le clustering GFS2 offre des fonctionnalités supplémentaires requises pour les pools de ressources qui utilisent des SR GFS2. Pour plus d’informations sur GFS2, consultez Configurer le stockage.
Un cluster GFS2 est un pool pouvant contenir jusqu’à 16 hôtes XenServer® qui sont plus étroitement connectés et coordonnés que les hôtes des pools non-clusterisés. Les hôtes du cluster GFS2 maintiennent une communication constante entre eux sur un réseau sélectionné. Tous les hôtes du cluster GFS2 sont conscients de l’état de chaque hôte du cluster GFS2. Cette coordination des hôtes permet au cluster GFS2 de contrôler l’accès au contenu du SR GFS2.
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 GFS2 dans votre pool.
Quorum
Chaque hôte d’un cluster GFS2 doit toujours être en communication avec la majorité des hôtes du cluster GFS2 (y compris lui-même). Cet état est appelé un hôte ayant le quorum. Si un hôte n’a pas le quorum, cet hôte s’auto-isole.
Le nombre d’hôtes qui doivent être en communication pour atteindre initialement le quorum peut être différent du nombre d’hôtes qu’un cluster GFS2 requiert pour maintenir le quorum.
Le tableau suivant résume ce comportement. La valeur de n est le nombre total d’hôtes dans le pool en cluster GFS2.
| Nombre d’hôtes requis pour atteindre le quorum | Nombre d’hôtes requis pour rester en 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 un pool en cluster GFS2, vous pouvez vérifier si le pool a le quorum en interrogeant le paramètre is-quorate du cluster GFS2 :
xe cluster-list params=is-quorate uuid=<cluster_id>
Pour voir combien d’hôtes du cluster GFS2 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 au cluster GFS2 pour atteindre le quorum, exécutez la commande suivante :
xe cluster-list params=quorum uuid=<cluster_id>
Lorsque le cluster GFS2 est créé, 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 GFS2 contient un nombre impair ou pair d’hôtes.
Pools à nombre impair d’hôtes
Pour atteindre la valeur de quorum pour un pool à nombre impair d’hôtes, vous avez besoin de la moitié de un de plus que le nombre total d’hôtes dans le cluster GFS2 : (n+1)/2. C’est également le nombre minimum d’hôtes qui doivent rester joignables pour que le pool reste en quorum.
Par exemple, dans un pool en cluster GFS2 de 5 hôtes, 3 hôtes doivent être joignables pour que le cluster GFS2 devienne actif et reste en 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 GFS2, car cela garantit que les hôtes sont toujours en mesure de déterminer s’ils disposent d’un ensemble en quorum.
Pools à nombre pair d’hôtes
Lorsqu’un pool en cluster GFS2 à nombre pair d’hôtes démarre à froid, (n/2)+1 hôtes doivent être disponibles avant que les hôtes n’aient le quorum. Une fois que les hôtes ont le quorum, le cluster GFS2 devient actif.
Cependant, un pool actif à nombre pair d’hôtes peut rester en quorum si le nombre d’hôtes joignables est au moins n/2. Par conséquent, il est possible qu’un cluster GFS2 en cours d’exécution avec un nombre pair d’hôtes se divise exactement en deux. Le cluster GFS2 en cours d’exécution décide quelle moitié du cluster GFS2 s’auto-isole et quelle moitié du cluster GFS2 a le quorum. La moitié du cluster GFS2 qui contient le nœud avec l’ID le plus bas qui était considéré comme actif avant la division du cluster GFS2 reste active et l’autre moitié du cluster GFS2 s’auto-isole.
Par exemple, dans un pool en cluster GFS2 de 4 hôtes, 3 hôtes doivent être joignables pour que le cluster GFS2 devienne actif [4/2 + 1 = 3]. Une fois le cluster GFS2 actif, pour rester en 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.
Auto-isolement
Si un hôte détecte qu’il n’a pas de quorum, il s’auto-isole en quelques secondes. Lorsqu’un hôte s’auto-isole, 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 brutal. Dans un pool GFS2 en cluster qui utilise la haute disponibilité, XenServer redémarre les machines virtuelles conformément à leur configuration de redémarrage sur d’autres membres du pool. L’hôte qui s’est auto-isolé redémarre et tente de rejoindre le cluster GFS2.
Si le nombre d’hôtes actifs dans le cluster GFS2 devient inférieur à la valeur de quorum, tous les hôtes restants perdent le quorum.
Dans un scénario idéal, votre pool GFS2 en cluster dispose toujours de plus d’hôtes actifs que nécessaire pour le quorum et XenServer ne s’isole jamais. Pour rendre ce scénario plus probable, prenez en compte les recommandations suivantes lors de la configuration de votre pool GFS2 en cluster :
-
Assurez-vous de disposer d’une bonne redondance matérielle.
-
Utilisez un réseau agrégé dédié pour le réseau de cluster GFS2. Assurez-vous que les cartes réseau agrégées se trouvent sur le même segment L2. Pour plus d’informations, consultez Mise en 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 GFS2 en cluster
Avant de commencer, assurez-vous que les prérequis suivants sont remplis :
-
Tous les hôtes XenServer du pool GFS2 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 la mémoire de domaine de contrôle de vos hôtes est insuffisante, votre pool peut rencontrer une instabilité réseau. L’instabilité réseau peut causer des problèmes pour un pool GFS2 en cluster avec des SR GFS2. Pour plus d’informations sur la modification de la quantité de mémoire de 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 GFS2 doivent utiliser des adresses IP statiques pour le réseau de cluster GFS2.
-
Nous vous recommandons d’utiliser le clustering GFS2 uniquement dans les pools contenant au moins trois hôtes, car les pools de deux hôtes sont sensibles à l’auto-isolement de l’ensemble du pool.
-
Les pools GFS2 en cluster ne prennent en charge que jusqu’à 16 hôtes par pool.
- Si vous avez un pare-feu entre les hôtes de votre pool, assurez-vous que les hôtes peuvent communiquer sur le réseau de cluster GFS2 en utilisant les ports suivants :
- TCP : 8892, 8896, 21064
- UDP: 5404, 5405
Pour plus d’informations, consultez Ports de communication utilisés par XenServer.
-
Si vous ajoutez le clustering GFS2 à 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 agrégé pour votre pool en cluster GFS2, qui ne doit pas être utilisé pour d’autres trafics.
Si vous préférez, vous pouvez configurer le clustering GFS2 sur votre pool à l’aide de XenCenter. Pour plus d’informations, consultez la documentation produit XenCenter.
Pour utiliser l’interface de ligne de commande xe afin de créer un pool en cluster GFS2 :
-
Créez un réseau agrégé à utiliser comme réseau de cluster GFS2.
Remarque :
Nous vous recommandons fortement d’utiliser un réseau agrégé dédié pour votre pool en cluster GFS2. N’utilisez pas ce réseau pour d’autres trafics.
Sur l’hôte XenServer que vous souhaitez désigner comme coordinateur de pool, suivez les étapes suivantes :
-
Ouvrez une console sur l’hôte XenServer.
-
Créez un réseau à utiliser avec la carte réseau agrégé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 l’agrégation à l’aide de la commande suivante :
xe pif-list <!--NeedCopy--> -
Créez votre réseau agrégé en mode actif-actif, en mode actif-passif ou en mode d’agrégation LACP. Selon le mode d’agrégation que vous souhaitez utiliser, effectuez l’une des actions suivantes :
-
Pour configurer l’agrégation en mode actif-actif (par défaut), utilisez la commande
bond-createpour créer l’agrégation. En utilisant des virgules pour séparer les paramètres, spécifiez l’UUID du réseau nouvellement créé et les UUID des PIF à agréger :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 agrégez deux cartes réseau et quatre UUID lorsque vous agrégez quatre cartes réseau. L’UUID de l’agrégation est renvoyé après l’exécution de la commande.
-
Pour configurer l’agrégation en mode actif-passif ou LACP, utilisez la même syntaxe, ajoutez le paramètre facultatif
modeet spécifiezlacpouactive-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-->
-
Après avoir créé votre réseau agrégé sur le coordinateur de pool, lorsque vous joignez d’autres hôtes XenServer au pool, les informations de réseau et d’agrégation sont automatiquement répliquées sur le serveur rejoignant.
Pour plus d’informations, consultez 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 qui est un membre de pool (non-maître) :
- Ouvrez une console sur l’hôte XenServer.
-
Joignez l’hôte XenServer au pool sur le coordinateur de pool en utilisant la commande suivante :
xe pool-join master-address=master_address master-username=administrators_username master-password=password <!--NeedCopy-->La valeur du paramètre
master-addressdoit être définie sur le nom de domaine complet de l’hôte XenServer qui est le coordinateur de pool. Lepassworddoit être le 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.
-
Pour chaque PIF appartenant à ce réseau, définissez
disallow-unplug=true.-
Recherchez les UUID des PIF appartenant au réseau en utilisant 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 GFS2 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 agrégé que vous avez créé à une étape précédente.
Désactiver le clustering GFS2
Vous pouvez désactiver le clustering GFS2. Une fois le clustering GFS2 désactivé, le pool continue d’exister, mais il n’est plus clusterisé GFS2 et ne peut plus utiliser les SR GFS2.
Pour désactiver le clustering GFS2, exécutez la commande suivante :
xe cluster-pool-destroy cluster-uuid=<uuid>
Gérer votre pool clusterisé GFS2
Lorsque vous gérez votre pool clusterisé GFS2, les pratiques suivantes peuvent réduire le risque que le pool perde son quorum.
Ajouter ou supprimer un hôte sur un pool clusterisé GFS2
Lorsque vous ajoutez ou supprimez un hôte sur un pool clusterisé GFS2, assurez-vous que tous les hôtes du cluster GFS2 sont en ligne.
Vous pouvez ajouter ou supprimer un hôte sur un pool clusterisé GFS2 à l’aide de XenCenter. Pour plus d’informations, consultez Ajouter un serveur à un pool et Supprimer un serveur d’un pool.
Vous pouvez également ajouter ou supprimer un hôte sur un pool clusterisé GFS2 à 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.
Assurez-vous que les hôtes sont arrêtés proprement
Lorsqu’un hôte est arrêté proprement, il est temporairement retiré du cluster GFS2 jusqu’à ce qu’il soit redémarré. Pendant que l’hôte est arrêté, il n’est pas pris en compte dans le quorum du cluster GFS2. L’absence de l’hôte n’entraîne pas la perte de quorum des autres hôtes. Pour plus d’informations, consultez Arrêter un hôte XenServer.
Cependant, si un hôte est arrêté de force ou de manière inattendue, il n’est pas retiré du cluster GFS2 avant d’être mis hors ligne. Cet hôte est pris en compte dans la valeur de quorum du cluster GFS2. Son arrêt peut entraîner la perte de quorum des autres hôtes.
S’il est nécessaire d’arrêter un hôte de force, vérifiez d’abord le nombre d’hôtes actifs dans le cluster GFS2. Vous pouvez le faire avec 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 le même que le nombre d’hôtes nécessaires pour rester en quorum, n’arrêtez pas l’hôte de force. Cela entraînerait le fencing de l’ensemble du cluster GFS2.
Au lieu de cela, tentez de récupérer d’autres hôtes et d’augmenter le nombre d’hôtes actifs avant d’arrêter l’hôte de force.
-
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. Cependant, cela rend le cluster GFS2 plus vulnérable à un isolement complet 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 GFS2.
Utiliser le mode maintenance
Avant d’effectuer une action sur un hôte qui pourrait lui faire perdre le quorum, 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 transféré à un autre hôte du pool. Si vos actions entraînent l’auto-isolement 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 GFS2.
Vous ne pouvez modifier l’adresse IP d’un hôte faisant partie d’un pool en cluster GFS2 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 GFS2. Une fois l’adresse IP modifiée avec succès, l’hôte rejoint le cluster GFS2. Après que l’hôte ait rejoint le cluster GFS2, vous pouvez le sortir du mode maintenance.
Récupérer les hôtes qui se sont auto-isolés ou sont hors ligne
Il est important de récupérer les hôtes qui se sont auto-isolés. Tant que ces membres du cluster GFS2 sont hors ligne, ils sont pris en compte dans le nombre de quorum du cluster GFS2 et diminuent le nombre de membres du cluster GFS2 joignables. Cette situation augmente le risque qu’une défaillance d’hôte ultérieure entraîne la perte de quorum du cluster GFS2 et son arrêt complet.
Avoir des hôtes hors ligne dans votre cluster GFS2 vous empêche également d’effectuer certaines actions. Dans un pool en cluster GFS2, chaque membre du pool doit approuver chaque modification de l’appartenance au pool avant que la modification ne puisse être réussie. Si un membre du cluster GFS2 n’est pas joignable, XenServer empêche les opérations qui modifient l’appartenance au cluster GFS2 (telles que l’ajout ou la suppression d’hôtes).
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 GFS2 de les oublier. Ces hôtes sont définitivement supprimés du pool. Une fois les hôtes supprimés du pool en cluster GFS2, 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>
Récupérer un hôte oublié
Une fois qu’un pool en cluster GFS2 a été invité à oublier un hôte, l’hôte ne peut plus être ajouté au pool.
Pour rejoindre le pool en cluster GFS2, vous devez réinstaller XenServer sur l’hôte afin qu’il apparaisse comme un nouvel hôte pour le pool. Vous pouvez ensuite joindre l’hôte au pool en cluster GFS2 de la manière habituelle.
Dépanner votre pool en cluster GFS2
Si vous rencontrez des problèmes avec votre pool en cluster GFS2, consultez Dépanner les pools en cluster GFS2.
Contraintes
- Les pools en cluster GFS2 ne prennent en charge que jusqu’à 16 hôtes par pool.
- Pour activer la haute disponibilité (HA) sur votre pool en cluster GFS2, le SR de pulsation doit être un SR GFS2.
- Pour le trafic de cluster GFS2, nous vous recommandons fortement d’utiliser un réseau agrégé 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 GFS2 à l’aide de XenCenter nécessite la désactivation temporaire du clustering GFS2 et de tous les SR GFS2.
- Ne modifiez pas l’agrégation de votre réseau de cluster GFS2 tant que le cluster GFS2 est actif et contient des machines virtuelles en cours d’exécution. Cette action peut entraîner le redémarrage forcé (fencing) des hôtes du cluster GFS2.
- Si vous avez un conflit d’adresses IP (plusieurs hôtes ayant la même adresse IP) sur votre réseau de cluster GFS2 impliquant au moins un hôte avec le clustering GFS2 activé, le cluster GFS2 ne se forme pas correctement et les hôtes ne peuvent pas être mis en quarantaine (fence) si nécessaire. Pour résoudre ce problème, corrigez le conflit d’adresses IP.