Pools en cluster GFS2
Le clustering GFS2 offre des fonctionnalités supplémentaires qui sont 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 de 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 GFS2 ne bénéficie 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 connu sous le nom d’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 pour que le cluster GFS2 atteigne 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é du nombre total d’hôtes dans le cluster GFS2 plus un : (n+1)/2. C’est aussi 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 en cluster GFS2 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 en cluster GFS2 a toujours plus d’hôtes actifs que nécessaire pour le quorum et XenServer ne s’auto-isole jamais. Pour rendre ce scénario plus probable, tenez compte des recommandations suivantes lors de la configuration de votre pool en cluster GFS2 :
-
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 en cluster GFS2
Avant de commencer, assurez-vous que les prérequis suivants sont remplis :
-
Tous les hôtes XenServer du pool en cluster GFS2 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 subir une instabilité réseau. L’instabilité réseau peut causer des problèmes pour un pool en cluster GFS2 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 en cluster GFS2 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 GFS2 activé.
- Nous vous recommandons fortement d’utiliser un réseau agrégé pour votre pool GFS2 en cluster qui n’est pas utilisé pour d’autre trafic.
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 GFS2 en cluster :
-
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 GFS2 en cluster. N’utilisez pas ce réseau pour d’autre trafic.
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 NIC 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
mode, et 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 du 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. Après avoir désactivé le clustering GFS2, le pool continue d’exister, mais n’est plus un cluster 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 en cluster GFS2
Lorsque vous gérez votre pool en cluster GFS2, les pratiques suivantes peuvent réduire le risque que le pool perde son quorum.
Ajouter ou supprimer un hôte sur un pool en cluster GFS2
Lorsque vous ajoutez ou supprimez un hôte sur un pool en cluster 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 en cluster 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 en cluster 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 ne compte pas pour 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 de passer hors ligne. Cet hôte compte pour 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 maintenir 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 la mise en quarantaine 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 fencing 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-fencing 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 comptent toujours pour 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-fencés ou sont hors ligne
Il est important de récupérer les hôtes qui se sont auto-fencés. Tant que ces membres du cluster GFS2 sont hors ligne, ils comptent pour le nombre de quorum du cluster GFS2 et diminuent le nombre de membres du cluster GFS2 qui sont joignables. Cette situation augmente le risque qu’une défaillance ultérieure d’un hôte 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 comptent plus pour 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 du 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 qu’il contient des machines virtuelles en cours d’exécution. Cette action peut entraîner le redémarrage forcé (mise en quarantaine) 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 si nécessaire. Pour résoudre ce problème, corrigez le conflit d’adresses IP.