Haute disponibilité

La fonctionnalité de haute disponibilité (HA) de XenServer garantit que vos machines virtuelles continuent de fonctionner avec un temps d’arrêt minimal et aucune corruption de données. Lorsque des problèmes tels que des pannes matérielles de l’hôte et des interruptions de réseau se produisent, le pool XenServer répond en redémarrant les machines virtuelles affectées sur les hôtes stables du pool. Cette fonctionnalité vous permet de maintenir vos machines virtuelles en fonctionnement jusqu’à ce que vous soyez en mesure de corriger les problèmes matériels.

XenServer garantit la haute disponibilité des machines virtuelles par les moyens suivants :

• Utilisation d’un signal de pulsation réseau pour vérifier la connectivité entre les hôtes du pool.
• Utilisation d’un battement de cœur de stockage pour vérifier la connectivité entre les hôtes et le stockage partagé.
• Détecter si un hôte est en panne.
• Détecter si un ou plusieurs hôtes sont devenus inaccessibles.
• Clôture des hôtes qui ne peuvent pas communiquer avec la plus grande partition d’hôtes du pool. Un hôte clôturé redémarre immédiatement, ce qui entraîne l’arrêt de toutes les machines virtuelles exécutées dessus. Une fois redémarré, il essaie de rejoindre le pool de ressources. Cette précaution empêche les machines virtuelles de s’exécuter sur deux hôtes à la fois et de risquer la corruption des données.
• Marquage d’un hôte défaillant, clôturé ou inaccessible comme ne faisant plus partie de l’ensemble d’hôtes actifs du pool.
• Marquage de toutes les machines virtuelles en cours d’exécution sur cet hôte comme arrêtées.
• Si l’hôte défaillant, clôturé ou inaccessible est le coordinateur du pool, réaffectez le rôle de coordinateur à un autre hôte du pool.
• Redémarrage de toutes les machines virtuelles arrêtées conformément au plan de basculement que vous avez configuré.
• Surveillance de toutes les modifications apportées à la configuration du pool pour vérifier que le plan de basculement configuré peut être appliqué.

Étant donné que la fonctionnalité HA redémarre automatiquement les machines virtuelles sur d’autres hôtes du pool, XenServer doit s’assurer que l’hôte d’origine (en panne ou inaccessible) de la machine virtuelle n’exécute plus la machine virtuelle. Deux instances de la même machine virtuelle exécutées en même temps peuvent entraîner une corruption des données de la machine virtuelle. Pour se prémunir contre cette possibilité, les hôtes XenServer dans un pool compatible HA sont proactifs en matière d’auto-clôture s’ils se trouvent dans des situations pouvant conduire à l’exécution de deux instances de la même machine virtuelle.

La fonctionnalité HA maintient vos machines virtuelles clés en fonctionnement jusqu’à ce que vous puissiez résoudre le problème matériel ou réseau sous-jacent. Lorsque vous réalisez qu’un événement HA s’est produit, examinez et résolvez l’échec sous-jacent pour ramener votre pool à sa pleine capacité.

Cet article décrit les concepts, les exigences et les comportements attendus en matière de haute disponibilité. Pour plus d’informations sur la configuration et la gestion de la haute disponibilité, consultez Configurer la haute disponibilité.

Exigences

Pour utiliser la fonctionnalité de haute disponibilité, vous avez besoin des éléments suivants dans votre environnement :

• Un pool XenServer: La fonctionnalité HA fonctionne au sein d’un seul pool de ressources.

  • Nous recommandons que la piscine soit homogène. Chaque hôte du pool expose le même ensemble de fonctionnalités CPU aux machines virtuelles et facilite le redémarrage des machines virtuelles n’importe où dans le pool.
  • Pour que le mécanisme de battement de cœur fonctionne efficacement, nous recommandons que le pool comporte au moins 3 hôtes.
  • Assurez-vous que tous les hôtes du pool sont en ligne avant d’activer HA.

• Stockage partagé pour tous les hôtes du pool: Pour permettre à n’importe quelle VM du pool d’être redémarrée sur n’importe quel hôte du pool après une panne, tous les hôtes du pool doivent avoir accès au SR où les disques de la VM sont stockés.

• Un SR de battement de cœur: Ce SR peut être le même SR que celui où sont stockés les disques de la VM. Le pool stocke des informations qui lui permettent de coordonner la détection et la récupération des pannes en cas de panne.

  • Le SR de pulsation doit se trouver sur un LUN iSCSI, NFS ou Fibre Channel. Le stockage connecté via SMB ou iSCSI lors de l’authentification via CHAP ne peut pas être utilisé comme SR de pulsation. Nous recommandons que ce SR soit très fiable avec une faible latence.

  • XenServer 8.4 nécessite 4 Go pour le SR heartbeat.

    Les informations stockées sur le Heartbeat SR comprennent :

    • Volume de pulsation de 4 Mo : fournit la pulsation de stockage, qui vérifie que les hôtes du pool ont accès au stockage.
    • Le volume de métadonnées : stocke les métadonnées du coordinateur de pool à utiliser en cas de basculement du coordinateur de pool. Ce volume occupe le reste de l’espace requis.

• Communication de stockage fiable et redondante pour le SR heartbeat: pour que la fonctionnalité HA ait la vue la plus précise des hôtes pouvant accéder au stockage partagé, configurez votre environnement pour garantir que le trafic de stockage est fiable. Pour les SR iSCSI et Fibre Channel, configurez le multivoie. Pour les SR NFS, utilisez un réseau lié résilient comme réseau de stockage.

• Adresses IP statiques pour tous les hôtes: HA traite un changement d’adresse IP de l’hôte comme une perte de connexion de l’hôte et suppose que le réseau de l’hôte est en panne. En conséquence, l’hôte peut se défendre. Évitez cela en utilisant uniquement des adresses IP statiques dans votre pool.

• Une interface liée dédiée sur le réseau de gestion: Pour que la fonctionnalité HA ait la vue la plus précise de l’état du pool, vous avez besoin de communications réseau fiables et redondantes entre les hôtes.

• Le réseau de gestion autorise le trafic UDP de pulsation réseau sur le port 694.: Le pulsation réseau vérifie que les hôtes du pool sont actifs et peuvent se contacter.

Pour protéger une machine virtuelle exécutée dans votre pool de haute disponibilité, configurez votre machine virtuelle avec la configuration suivante :

• Stockez les disques VM sur un stockage partagé disponible pour tous les hôtes du pool.
• Configurer ses interfaces réseau virtuelles sur des réseaux à l’échelle du pool.
• Assurez-vous que la machine virtuelle peut utiliser la migration en direct. Pour plus d’informations, voir Exigences de compatibilité de migration.
• Ne connectez pas la VM à un lecteur de DVD local.

Une VM qui remplit tous ces critères est dite agile.

Une machine virtuelle qui utilise NVIDIA vGPU ou GPU passthrough ne peut pas être protégée par HA. Cependant, le mécanisme HA peut tenter de redémarrer cette machine virtuelle dans la mesure du possible.

Exigences relatives aux pools groupés

Le comportement de haute disponibilité des pools en cluster utilise un mécanisme sous-jacent différent et présente donc des exigences et des comportements différents. Pour plus d’informations, voir Pools en cluster.

Plan de basculement haute disponibilité

Le mécanisme HA calcule un plan de basculement à l’échelle du pool en fonction des critères suivants :

• Exigences de récupération de VM: Chaque VM peut avoir une priorité de redémarrage et un ordre de démarrage définis.
• Ressources de pool disponibles: La principale ressource prise en compte est la mémoire de l’hôte.
• Le nombre de pannes d’hôte à tolérer: après avoir activé HA dans votre pool, XenServer peut calculer le nombre maximal d’hôtes pouvant échouer dans le pool avant que les machines virtuelles protégées ne puissent pas être redémarrées. Vous pouvez définir le nombre de pannes d’hôte à tolérer sur une valeur inférieure ou égale à cette valeur.

Si un plan de basculement répondant à ces critères ne peut pas être calculé, le pool est considéré comme surengagé. Si les machines virtuelles protégées ne peuvent pas être redémarrées dans le pool, XenServer génère une alerte système. Cette alerte s’affiche également dans le XenCenter Notifications panneau.

Pour chaque machine virtuelle de votre pool, vous pouvez définir son comportement de récupération.

Priorité de redémarrage

Vous pouvez attribuer à une machine virtuelle l’une des priorités de redémarrage suivantes :

• Protégé: Si la VM ou son hôte se met hors ligne de manière inattendue, HA redémarre la VM sur un autre hôte. Ce redémarrage est garanti, à condition que le pool ne soit pas surchargé et que la VM soit agile. Si le redémarrage de la machine virtuelle échoue, HA tente de démarrer la machine virtuelle lorsqu’il y a une capacité supplémentaire dans le pool. Cette valeur est redémarrer sur la CLI xe et Redémarrer dans XenCenter.
• Meilleur effort: Si l’hôte exécutant la VM se déconnecte de manière inattendue, HA tente de redémarrer la VM sur un autre hôte. Cette tentative est effectuée uniquement après que toutes les machines virtuelles protégées ont été redémarrées avec succès. La haute disponibilité n’effectue qu’une seule tentative de redémarrage d’une machine virtuelle de premier ordre. Si cette tentative échoue, la haute disponibilité ne fait pas d’autres tentatives de redémarrage de la machine virtuelle. Cette valeur est meilleur effort sur la CLI xe et Redémarrer si possible dans XenCenter.
• Non protégé: Si la VM ou son hôte se met hors ligne de manière inattendue, HA ne tente pas de redémarrer la VM. Il s’agit du paramètre par défaut. Cette valeur est une chaîne vide sur la CLI xe et Ne redémarrez pas dans XenCenter.

La haute disponibilité n’arrête jamais ni ne migre une machine virtuelle en cours d’exécution pour libérer des ressources afin de redémarrer une machine virtuelle avec une priorité de redémarrage plus élevée.

Commencer la commande

L’ordre de démarrage est l’ordre dans lequel la haute disponibilité XenServer tente de redémarrer les machines virtuelles protégées lorsqu’une panne se produit. Cette valeur est utilisée uniquement pour les machines virtuelles protégées. La valeur par défaut est 0, ce qui correspond à la priorité la plus élevée. Les machines virtuelles protégées avec une valeur d’ordre de démarrage de 0 sont redémarrées en premier. Plus la valeur de l’ordre de démarrage est élevée, plus la machine virtuelle est redémarrée tard dans la séquence.

Comportement de la piscine

Une fois que vous avez activé HA dans votre pool XenServer, le pool présente les comportements suivants.

Comportement lors de l’installation

Lorsque vous activez HA dans un pool, le coordinateur du pool effectue la configuration suivante :

• Calcule le plan de basculement initial.
• Configure la base de données pour écrire des mises à jour dans le SR de pulsation. Ce paramètre garantit que les modifications de configuration de la machine virtuelle ne sont pas perdues en cas de défaillance d’un hôte.
• Configure les métadonnées du coordinateur de pool sur le SR heartbeat.

Tous les membres du pool :

• Envoyez-vous des pulsations réseau les uns aux autres. En conséquence, il y a une légère augmentation du trafic du réseau de gestion lorsque les hôtes du pool vérifient qu’ils peuvent communiquer entre eux. Ce trafic réseau continue tant que HA est activé.

Comportement en fonctionnement normal

En fonctionnement normal, le coordinateur de pool d’un pool HA exécute les actions suivantes (en plus de ses fonctions habituelles) :

• Maintient dynamiquement un plan de basculement. Ce plan détaille ce qu’il faut faire lorsqu’un ensemble d’hôtes dans un pool échoue à un moment donné. Ce plan prend en compte le nombre maximal de pannes d’hôte pouvant être tolérées et garantit que toutes les machines virtuelles protégées peuvent être redémarrées. Le plan est recalculé de manière dynamique en fonction des opérations et des mouvements du cycle de vie de la machine virtuelle. Si des modifications (par exemple, l’ajout de nouvelles machines virtuelles au pool) signifient que toutes les machines virtuelles protégées ne peuvent plus être redémarrées après le nombre maximal de pannes d’hôte, un plan ne peut pas être calculé et le pool est surchargé. Lorsque le pool devient surchargé, XenServer génère une alerte via XenCenter, e-mail, interruption SNMP ou alerte NRPE.

En fonctionnement normal, chaque membre d’un pool HA exécute les actions suivantes (en plus de leurs fonctions habituelles) :

• Vérifie que le coordinateur de la piscine est vivant. L’hôte y parvient en tentant d’acquérir un « verrou principal » sur le stockage partagé. Si un coordinateur de pool existe déjà, cette tentative échoue
• Envoyer un battement de cœur réseau. Ce battement de cœur réseau est envoyé via UDP sur le port 694 du réseau de gestion à tous les autres hôtes du pool.
• Maintient un enregistrement de l’ensemble de vie des hôtes dans le pool. L’ensemble de vie des hôtes selon chaque hôte individuel est l’ensemble des autres hôtes qu’il considère comme vivants. Si un hôte n’a pas reçu de pulsation réseau d’un autre hôte dans le délai spécifié par le délai d’expiration HA (par défaut, 60 secondes), il communique avec les autres hôtes du pool pour convenir si le liveset doit être mis à jour.
• Écrit dans le fichier d’état sur le volume de pulsation de stockage. Cette action vérifie que l’hôte a toujours accès au stockage. Il permet également aux hôtes de communiquer leur état entre eux (en plus de la communication avec le heartbeat du réseau).
• Met à jour la base de données sur le SR heartbeat. L’hôte enregistre toutes les modifications apportées aux configurations des machines virtuelles qu’il héberge.

Certaines opérations de pool sont bloquées ou déconseillées lorsque HA est activé. Désactivez temporairement la haute disponibilité pour effectuer ces opérations :

• Ajout d’un hôte au pool.
• Suppression d’un hôte du pool. Bloqué si cette action peut entraîner une surcharge du pool.
• Arrêt d’un hôte dans le pool. Bloqué si cette action peut entraîner une surcharge du pool.
• Changement du réseau de gestion.
• Changement du SR attaché à la piscine.
• Activation du clustering. Certains comportements et exigences de haute disponibilité sont différents pour les pools en cluster. Pour plus d’informations, voir Pools en cluster.

En fonctionnement normal, l’exécution de ces actions dans le pool n’active pas le plan de basculement HA :

• Arrêt propre de la machine virtuelle depuis XenCenter ou la CLI xe. Le mécanisme HA ne considère pas que cette VM est en panne et ne tente pas de la redémarrer. Pour plus d’informations sur cette action, voir Arrêter une VM protégée par une haute disponibilité
• Arrêt propre de l’hôte depuis XenCenter ou la CLI xe. Le mécanisme HA ne considère pas que cet hôte est en panne et ne tente pas de redémarrer les machines virtuelles qui y étaient hébergées. Cependant, si cette action entraîne une surcharge du pool, celui-ci est bloqué par XenServer. Pour plus d’informations sur cette action, voir Arrêter un hôte lorsque la haute disponibilité est activée

Comportement lors de pannes matérielles ou d’instabilité de l’infrastructure

Au cours de cette phase, tous les hôtes du pool sont responsables de la détection de leur propre état de connectivité et de l’acceptation de l’état de connectivité des autres hôtes du pool.

XenServer HA détecte et gère les types de pannes suivants :

• Hôte ou hôtes défaillants : dans cette situation, tous les hôtes restants remarquent très rapidement que l’hôte ou les hôtes défaillants ont cessé de mettre à jour le fichier d’état et n’envoient plus de pulsations réseau. Après un délai approprié, ces hôtes sont supprimés du liveset.
• Partition réseau : dans cette situation, un ou plusieurs hôtes ne peuvent pas communiquer avec un ou plusieurs autres hôtes. Un hôte remarque qu’il n’a pas reçu de pulsations réseau d’un ou de plusieurs autres hôtes dans le délai défini et démarre un gestionnaire d’erreurs. Ce processus de gestion des pannes communique via le fichier d’état et le battement de cœur du réseau de travail, et utilise ces informations pour déterminer quelles partitions réseau (groupes d’hôtes pouvant communiquer entre eux) existent. Les hôtes de la plus grande partition sont les liveset et survivent. S’il existe des partitions de taille égale, les hôtes de la partition contenant l’hôte avec l’UUID d’hôte le plus bas survivent.
• Échec de la connexion de stockage : dans cette situation, un hôte remarque qu’il ne peut pas atteindre le stockage ou d’autres hôtes remarquent que ses mises à jour ne sont pas présentes sur le stockage. Les hôtes communiquent via les communications de pulsation du réseau pour vérifier si d’autres hôtes ont perdu l’accès au stockage :
  • Si tous les hôtes ont perdu du stockage, mais pas du réseau, cela est considéré comme une perte temporaire de stockage et les hôtes restent en attente du retour du stockage. D’autres pannes et tous les hôtes dans la clôture de la piscine. Cette règle empêche le stockage de devenir un point de défaillance unique.
  • Si seuls certains hôtes ont perdu l’accès au stockage, mais que tous les hôtes ont toujours accès au réseau, ces hôtes sont supprimés du liveset.

Si un hôte sait qu’il apparaîtra comme défaillant ou inaccessible à la majorité du pool, cet hôte s’auto-protège. Le fencing est un comportement attendu conçu comme une mesure de protection pour les données des machines virtuelles. Cela garantit qu’une machine virtuelle ne fonctionne pas à deux endroits à la fois. Un hôte utilise les critères suivants pour décider qu’il doit s’auto-isoler :

• Si la pile d’outils de l’hôte n’est pas en cours d’exécution et ne peut pas être redémarrée, l’hôte s’auto-clôture.
• Si l’hôte a perdu à la fois les pulsations du réseau et du stockage, l’hôte se considère comme inaccessible et se protège lui-même.
• Si l’hôte a perdu le battement de cœur de stockage, mais reçoit toujours les battements de cœur du réseau :
  • Si l’hôte peut toujours contacter tous les autres membres du pool et que tous ces membres ont également perdu le battement de cœur de stockage, l’hôte reste en vie. Ce cas empêche le stockage d’agir comme un point de défaillance unique et de clôturer l’ensemble du pool.
  • Si l’hôte ne peut pas contacter un ou plusieurs autres hôtes du pool, il s’auto-clôture.
• Si l’hôte a perdu des pulsations réseau, mais dispose toujours de la pulsation de stockage, il détermine s’il se trouve dans la plus grande partition réseau. Si ce n’est pas le cas, l’hôte s’auto-protège.
• Il existe un risque qu’une défaillance de communication réseau divise le pool en partitions de taille égale. Si, en utilisant les informations du fichier d’état sur le SR de pulsation, un hôte sait qu’il se trouve dans une telle partition réseau :
  • Si la partition contient l’hôte avec l’UUID le plus bas, l’hôte reste actif.
  • Si la partition ne contient pas l’hôte avec l’UUID le plus bas, l’hôte s’auto-clôture.

Lorsqu’une action de clôture est effectuée, l’hôte redémarre immédiatement et brusquement, provoquant l’arrêt de toutes les machines virtuelles exécutées dessus. L’hôte clôturé entre dans une séquence de redémarrage et, une fois redémarré, il tente de rejoindre le pool de ressources.

Comportement pendant la récupération

Si le coordinateur du pool est l’hôte qui a échoué, qui est clôturé ou qui est devenu inaccessible, d’autres hôtes tentent d’obtenir le verrou principal. L’hôte qui succède devient le nouveau coordinateur.

Les hôtes qui se sont auto-clôturés redémarrent et tentent de rejoindre le pool.

Lorsqu’un hôte est marqué comme mort et que ses machines virtuelles sont arrêtées, le coordinateur de pool est responsable des actions de récupération suivantes.

• Redémarrez toutes les machines virtuelles protégées conformément au plan de basculement.
• S’il n’y a pas suffisamment de ressources pour démarrer toutes les machines virtuelles protégées, le coordinateur de pool attend que la ressource soit disponible (par exemple, si des hôtes précédemment clôturés rejoignent le pool), puis tente de démarrer les machines virtuelles protégées.
• Une fois toutes les machines virtuelles protégées démarrées avec succès, le coordinateur de pool tente une fois de redémarrer chaque machine virtuelle la plus performante.