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 sans corruption de données. Lorsque des problèmes tels que des pannes matérielles d’hôte et des interruptions de 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 résoudre 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 si un ou plusieurs hôtes sont devenus inaccessibles.
• Isoler les hôtes qui ne peuvent pas communiquer avec la plus grande partition d’hôtes du pool. Un hôte isolé 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.
• Marquer un hôte défaillant, isolé ou inaccessible comme ne faisant plus partie de l’ensemble d’hôtes actifs du pool.
• Marquer toutes les machines virtuelles qui s’exécutaient sur cet hôte comme arrêtées.
• Si l’hôte défaillant, isolé ou inaccessible est le coordinateur du pool, réaffecter le rôle de coordinateur à un autre hôte du pool.
• Redémarrer toutes les machines virtuelles arrêtées conformément au plan de basculement que vous avez configuré.
• Surveiller 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 se prémunir contre cette possibilité, les hôtes XenServer d’un pool activé pour la HA sont proactifs en matière d’auto-isolement 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ù les disques des machines virtuelles sont stockés.

• Un SR de pulsation : Ce SR peut être le même que celui où les disques des machines virtuelles sont stockés. 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 garantir 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 haute disponibilité (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.

• Connectivité de proximité étroite entre tous les hôtes du pool : Tous les hôtes du pool doivent être connectés avec une latence aller-retour inférieure à 5 ms et un débit réseau d’au moins 10 Gbit/s. Les hôtes répartis sur plusieurs centres de données ne peuvent partager un pool que si ces centres de données répondent à la définition de proximité étroite. Une latence élevée entre les hôtes augmente le risque de mise en quarantaine (fencing) intempestive causée par des pulsations manquées.

Remarque :

La HA n’a pas conscience des limites des centres de données. Lors du redémarrage des machines virtuelles après une défaillance d’hôte, la HA les place sur n’importe quel hôte disponible dans le pool en fonction de la mémoire disponible, sans notion d’affinité ou de préférence de centre de données. Si vous répartissez un pool sur deux centres de données de proximité étroite et qu’un centre de données entier tombe en panne, la HA tentera de redémarrer les machines virtuelles affectées sur les hôtes survivants — mais le résultat dépendra de la capacité disponible et de la question de savoir si le stockage partagé reste accessible depuis ces hôtes. Cela ne constitue pas un basculement contrôlé au niveau du centre de données. Pour la résilience contre une défaillance complète d’un centre de données, utilisez la récupération d’urgence.

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 de la machine virtuelle sur un stockage partagé accessible à 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 les 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 pass-through 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 les 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 des machines virtuelles : 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ôtes à tolérer : Après avoir activé la haute disponibilité dans votre pool, XenServer peut calculer le nombre maximal d’hôtes pouvant 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ôtes à 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 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 tardivement dans la séquence.

Comportement du pool

Une fois que vous avez activé la haute disponibilité (HA) 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 pendant le fonctionnement normal

Pendant le 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 de cycle de vie et de déplacement 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.

Pendant le 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 en utilisant UDP sur le port 694 sur le 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 battement de cœur réseau d’un autre hôte dans la période spécifiée 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 battement de cœur 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 battement de cœur réseau).
• Met à jour la base de données sur le SR de battement de cœur. 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 HA 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 surengagement du pool.
• Arrêt d’un hôte dans le pool. Bloqué si cette action peut entraîner un surengagement 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.

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

• Arrêt propre d’une machine virtuelle depuis XenCenter ou la CLI xe. Le mécanisme HA ne considère pas que cette machine virtuelle a échoué et ne tente pas de la redémarrer. Pour plus d’informations sur cette action, consultez Arrêter une machine virtuelle protégée par la haute disponibilité
• Plantages de machines virtuelles 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 machines virtuelles lors d’un arrêt interne. Dans ce cas, le mécanisme HA ne considère pas que la machine virtuelle 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 machines virtuelles arrêtées en interne
• 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 a échoué et ne tente pas de redémarrer les machines virtuelles qui y étaient hébergées. Cependant, si cette action entraîne un surengagement 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 défaillance matérielle 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 retiré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 qui peuvent communiquer entre eux) existent. Les hôtes de la plus grande partition constituent le 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.
• Connexion de stockage défaillante : 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 que le stockage revienne. Toute défaillance supplémentaire entraîne le fencing de tous les hôtes du pool. 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 retiré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 auto-fencing. Le fencing est un comportement attendu conçu comme une mesure de protection pour les données des VM. Il 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 auto-fencing :

• Si le toolstack de l’hôte ne fonctionne pas et ne peut pas être redémarré, l’hôte se met en auto-fencing.
• Si l’hôte a perdu les pulsations réseau et de stockage, il se considère comme inaccessible et se met en auto-fencing.
• Si l’hôte a perdu la pulsation de stockage, mais reçoit toujours des pulsations réseau :
  • Si l’hôte peut toujours contacter tous les autres membres du pool et que tous ces membres ont également perdu la 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 provoquer le fencing de l’ensemble du pool.
  • Si l’hôte ne peut pas contacter un ou plusieurs autres hôtes du pool, il se met en auto-fencing.
• Si l’hôte a perdu des pulsations réseau, mais a toujours 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 se met en auto-fencing.
• 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 le plus petit UUID, l’hôte reste actif.
  • Si la partition ne contient pas l’hôte avec le plus petit UUID, l’hôte s’auto-isole.

Lorsqu’une action d’isolement est effectuée, l’hôte redémarre immédiatement et brusquement, ce qui entraîne l’arrêt de toutes les machines virtuelles qui y sont exécutées. L’hôte isolé 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 de pool est l’hôte qui a échoué, s’est isolé ou est devenu inaccessible, les autres hôtes tentent d’obtenir le verrou maître. L’hôte qui y parvient devient le nouveau coordinateur.

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

Lorsqu’un hôte est marqué comme inactif 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 soient disponibles (par exemple, si des hôtes précédemment isolés 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 ».