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 défaillances matérielles de l’hôte et des interruptions réseau surviennent, le pool XenServer réagit en redémarrant les machines virtuelles affectées sur des hôtes stables du pool. Cette fonctionnalité vous permet de maintenir vos machines virtuelles en fonctionnement jusqu’à ce que vous puissiez corriger les problèmes matériels.

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

• Utilisation d’un battement de cœur 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étection de la défaillance d’un hôte.
• Détection de l’inaccessibilité d’un ou plusieurs hôtes.
• Mise en quarantaine (fencing) des hôtes qui ne peuvent pas communiquer avec la plus grande partition d’hôtes du pool. Un hôte mis en quarantaine redémarre immédiatement, ce qui entraîne l’arrêt de toutes les machines virtuelles qui y sont exécutées. Une fois redémarré, il tente 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 une corruption de données.
• Marquage d’un hôte défaillant, mis en quarantaine ou inaccessible comme ne faisant plus partie de l’ensemble d’hôtes actifs du pool.
• Marquage de toutes les machines virtuelles qui s’exécutaient sur cet hôte comme arrêtées.
• Si l’hôte défaillant, mis en quarantaine ou inaccessible est le coordinateur du pool, réaffectation du 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 toute modification de la configuration du pool pour vérifier que le plan de basculement configuré peut être mis en œuvre.

É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 (défaillant ou inaccessible) de la machine virtuelle n’exécute plus la machine virtuelle. Deux instances de la même machine virtuelle s’exécutant simultanément peuvent entraîner une corruption des données de la machine virtuelle. Pour éviter cette possibilité, les hôtes XenServer d’un pool activé pour la HA sont proactifs en matière d’auto-quarantaine s’ils se trouvent dans des situations susceptibles d’entraîner 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 constatez qu’un événement HA s’est produit, enquêtez et résolvez la défaillance sous-jacente pour ramener votre pool à sa pleine capacité.

Cet article décrit les concepts, les exigences et les comportements attendus de la 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 le pool 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 pulsation fonctionne efficacement, nous recommandons que le pool dispose d’au moins 3 hôtes.
  • Assurez-vous que tous les hôtes du pool sont en ligne avant d’activer la HA.

• Stockage partagé pour tous les hôtes du pool : Pour permettre à toute machine virtuelle du pool d’être redémarrée sur n’importe quel hôte du pool après une défaillance, tous les hôtes du pool doivent avoir accès au SR où sont stockés les disques des machines virtuelles.

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

  • Le SR de pulsation doit se trouver sur un LUN iSCSI, NFS ou Fibre Channel. Le stockage attaché via SMB ou iSCSI authentifié par CHAP ne peut pas être utilisé comme SR de pulsation. Nous recommandons que ce SR soit hautement fiable et à faible latence.

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

    Les informations stockées sur le SR de pulsation 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 de pulsation : 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 vous assurer que le trafic de stockage est fiable. Pour les SR iSCSI et Fibre Channel, configurez le multipathing. Pour les SR NFS, utilisez un réseau agrégé résilient comme réseau de stockage.

• Adresses IP statiques pour tous les hôtes : La HA considère un changement d’adresse IP d’hôte comme une perte de connexion de l’hôte et suppose que le réseau de l’hôte a échoué. Par conséquent, l’hôte peut être mis en quarantaine (fence). Évitez cela en utilisant uniquement des adresses IP statiques dans votre pool.

• Une interface agrégé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 : La pulsation réseau vérifie que les hôtes du pool sont actifs et peuvent communiquer entre eux.

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

• Stockez les disques de la machine virtuelle sur un stockage partagé disponible pour tous les hôtes du pool.
• Configurez 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, consultez Exigences de compatibilité de migration.
• Ne connectez pas la machine virtuelle à un lecteur de DVD local.

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

Une machine virtuelle qui utilise NVIDIA vGPU ou le passthrough GPU ne peut pas être protégée par la HA. Cependant, le mécanisme de HA peut tenter de redémarrer cette machine virtuelle au mieux de ses capacités.

Exigences pour les pools en cluster GFS2

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

Plan de basculement HA

Le mécanisme HA calcule un plan de basculement à l’échelle du pool basé sur les critères suivants :

• Exigences de récupération de VM : Chaque machine virtuelle 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.
• Nombre de pannes d’hôte à tolérer : Après avoir activé la haute disponibilité dans votre pool, XenServer peut calculer le nombre maximal d’hôtes qui peuvent tomber en panne dans le pool avant que les machines virtuelles protégées ne puissent plus être redémarrées. Vous pouvez définir le nombre de pannes d’hôte à tolérer à 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 surchargé. Si les machines virtuelles protégées ne peuvent pas être redémarrées dans le pool, XenServer déclenche une alerte système. Cette alerte est également affichée dans le panneau Notifications de XenCenter®.

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ée : Si la machine virtuelle ou son hôte se déconnecte de manière inattendue, la haute disponibilité redémarre la machine virtuelle sur un autre hôte. Ce redémarrage est garanti, à condition que le pool ne soit pas surchargé et que la machine virtuelle soit agile. Si le redémarrage de la machine virtuelle échoue, la haute disponibilité tente de démarrer la machine virtuelle lorsqu’il y a une capacité supplémentaire dans le pool. Cette valeur est restart sur l’interface de ligne de commande xe et Redémarrer dans XenCenter.
• Meilleur effort : Si l’hôte exécutant la machine virtuelle se déconnecte de manière inattendue, la haute disponibilité tente de redémarrer la machine virtuelle sur un autre hôte. Elle ne fait cette tentative qu’après que toutes les machines virtuelles protégées ont été redémarrées avec succès. La haute disponibilité ne fait qu’une seule tentative pour redémarrer une machine virtuelle en mode meilleur effort. Si cette tentative échoue, la haute disponibilité ne fait pas d’autres tentatives pour redémarrer la machine virtuelle. Cette valeur est best-effort sur l’interface de ligne de commande xe et Redémarrer si possible dans XenCenter.
• Non protégée : Si la machine virtuelle ou son hôte se déconnecte de manière inattendue, la haute disponibilité ne tente pas de redémarrer la machine virtuelle. C’est le paramètre par défaut. Cette valeur est une chaîne vide sur l’interface de ligne de commande xe et Ne pas redémarrer dans XenCenter.

La haute disponibilité n’arrête ni ne migre jamais 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.

Ordre de démarrage

L’ordre de démarrage est l’ordre dans lequel la haute disponibilité de XenServer tente de redémarrer les machines virtuelles protégées en cas de panne. 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 tardivement dans la séquence.

Comportement du pool

Après avoir activé la haute disponibilité dans votre pool XenServer, le pool présente les comportements suivants.

Comportement pendant la configuration

Lorsque vous activez la haute disponibilité (HA) dans un pool, le coordinateur de pool effectue la configuration suivante :

• Calcule le plan de basculement initial.
• Configure la base de données pour écrire les mises à jour sur le SR de pulsation. Ce paramètre garantit que les modifications de configuration des machines virtuelles 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 de pulsation.

Tous les membres du pool :

• S’envoient mutuellement des pulsations réseau. En conséquence, il y a une légère augmentation du trafic réseau de gestion car les hôtes du pool vérifient qu’ils peuvent communiquer entre eux. Ce trafic réseau se poursuit tant que la haute disponibilité (HA) est activée.

Comportement en fonctionnement normal

En fonctionnement normal, le coordinateur de pool d’un pool HA effectue 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 d’un pool tombe en panne à un moment donné. Ce plan prend en compte le nombre maximal de défaillances d’hôtes pouvant être tolérées et garantit que toutes les machines virtuelles protégées peuvent être redémarrées. Le plan est recalculé dynamiquement en fonction des opérations et des mouvements du cycle de vie des machines virtuelles. 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 défaillances d’hôtes, un plan ne peut pas être calculé et le pool est surchargé. Lorsque le pool devient surchargé, XenServer déclenche une alerte via XenCenter, e-mail, trap SNMP ou alerte NRPE.

En fonctionnement normal, chaque membre d’un pool HA effectue les actions suivantes (en plus de ses fonctions habituelles) :

• Vérifie que le coordinateur de pool est actif. L’hôte le fait en tentant d’acquérir un « verrou maître » sur le stockage partagé. Si un coordinateur de pool existe déjà, cette tentative échoue.
• Envoie une pulsation réseau. Cette pulsation réseau est envoyée via UDP sur le port 694 du réseau de gestion à tous les autres hôtes du pool.
• Maintient un enregistrement de l’ensemble des hôtes actifs dans le pool. L’ensemble des hôtes actifs, selon chaque hôte individuel, est l’ensemble des autres hôtes qu’il considère comme actifs. 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 l’ensemble des hôtes actifs 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. Elle permet également aux hôtes de communiquer leur état les uns aux autres (en plus de la communication par pulsation réseau).
• Met à jour la base de données sur le SR de pulsation. 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 la haute disponibilité est activée. 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 un sur-engagement du pool.
• Arrêt d’un hôte dans le pool. Bloqué si cette action peut entraîner un sur-engagement du pool.
• Modification du réseau de gestion.
• Modification du SR attaché au pool.
• Activation du clustering. Certains comportements et exigences de haute disponibilité sont différents pour les pools en cluster. Pour plus d’informations, consultez 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 d’une VM depuis XenCenter ou l’interface de ligne de commande xe. Le mécanisme HA ne considère pas que cette VM a échoué et ne tente pas de la redémarrer. Pour plus d’informations sur cette action, consultez Arrêter une VM protégée par la haute disponibilité
• Plantages de VM ou arrêt propre depuis le système d’exploitation invité, si la HA a été configurée pour ne pas redémarrer automatiquement les VM lors d’un arrêt interne. Dans ce cas, le mécanisme HA ne considère pas que la VM a échoué et ne tente pas de la redémarrer. Pour plus d’informations sur ce paramètre, consultez Configurer le comportement de redémarrage des VM arrêtées en interne
• Arrêt propre d’un hôte depuis XenCenter ou l’interface de ligne de commande xe. Le mécanisme HA ne considère pas que cet hôte a échoué et ne tente pas de redémarrer les VM qui y étaient hébergées. Cependant, si cette action entraîne un sur-engagement du pool, elle est bloquée par XenServer. Pour plus d’informations sur cette action, consultez Arrêter un hôte lorsque la haute disponibilité est activée

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

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

XenServer HA détecte et gère les types de défaillance 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 signaux de pulsation 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 signaux de pulsation réseau d’un ou plusieurs autres hôtes dans le délai défini et démarre un gestionnaire de pannes. Ce processus de gestionnaire de pannes communique via le fichier d’état et le signal de pulsation réseau fonctionnel, 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 constituent le liveset et survivent. S’il y a 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.
• Connexion de stockage échouée : 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 réseau pour vérifier si d’autres hôtes ont perdu l’accès au stockage :
  • Si tous les hôtes ont perdu le stockage, mais pas le réseau, cela est considéré comme une perte temporaire de stockage et les hôtes restent actifs pour attendre le retour du stockage. Toute défaillance supplémentaire et tous les hôtes du pool se mettent en quarantaine. Cette règle empêche le stockage d’être 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 un accès 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 se met en quarantaine. La mise en quarantaine est un comportement attendu conçu comme une mesure de protection pour les données des VM. Elle garantit qu’une VM ne s’exécute pas à deux endroits à la fois. Un hôte utilise les critères suivants pour décider qu’il doit se mettre en quarantaine :

• Si le toolstack de l’hôte ne fonctionne pas et ne peut pas être redémarré, l’hôte se met en quarantaine.
• Si l’hôte a perdu les signaux de pulsation réseau et de stockage, l’hôte se considère comme inaccessible et se met en quarantaine.
• Si l’hôte a perdu le signal de pulsation de stockage, mais reçoit toujours des signaux de pulsation réseau :
  • Si l’hôte peut toujours contacter tous les autres membres du pool et que tous ces membres ont également perdu le signal de pulsation de stockage, l’hôte reste actif. Ce cas empêche le stockage d’agir comme un point de défaillance unique et de mettre en quarantaine l’ensemble du pool.
  • Si l’hôte ne peut pas contacter un ou plusieurs autres hôtes du pool, il se met en quarantaine.
• Si l’hôte a perdu des signaux de pulsation réseau, mais a toujours le signal de 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 se met en quarantaine.
• Il est possible 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 se met en quarantaine.

Lorsqu’une action de mise en quarantaine est effectuée, l’hôte redémarre immédiatement et brusquement, ce qui entraîne l’arrêt de toutes les VM qui y sont exécutées. L’hôte mis en quarantaine entre dans une séquence de redémarrage, et une fois redémarré, il tente de rejoindre le pool de ressources.

Comportement lors de la récupération

Si le coordinateur de pool est l’hôte qui a échoué, a été mis en quarantaine ou est devenu inaccessible, d’autres hôtes tentent d’obtenir le verrou maître. L’hôte qui réussit devient le nouveau coordinateur.

Les hôtes qui se sont mis en quarantaine 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émarrer 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 les ressources deviennent disponibles (par exemple, si des hôtes précédemment mis en quarantaine rejoignent le pool), puis tente de démarrer les machines virtuelles protégées.
• Une fois que toutes les machines virtuelles protégées ont été démarrées avec succès, le coordinateur de pool tente une fois de redémarrer chaque machine virtuelle en mode « meilleur effort ».