Haute disponibilité

Important :

La mise à jour cumulative 1 de Citrix Hypervisor 8.2 prend fin le 25 juin 2025. Planifiez votre mise à niveau vers XenServer 8 dès maintenant pour assurer une transition en douceur et un support continu. Pour plus d’informations, consultez Mise à niveau.

Si vous utilisez vos fichiers de licence Citrix Virtual Apps and Desktops pour obtenir une licence pour vos hôtes Citrix Hypervisor 8.2 Cumulative Update 1, ces fichiers de licence ne sont pas compatibles avec XenServer 8. Avant la mise à niveau, vous devez acquérir les fichiers de licence socket XenServer Premium Edition à utiliser avec XenServer 8. Ces fichiers de licence de socket sont disponibles en tant que droits des abonnements Citrix pour le cloud privé, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP et Citrix Platform License pour l’exécution de vos charges de travail Citrix. Les clients Citrix qui n’ont pas encore migré vers ces nouveaux abonnements peuvent demander à participer à une promotion gratuite pour 10 000 licences de sockets XenServer Premium Edition. Pour plus d’informations, consultez XenServer.

Si vous n’obtenez pas de licence compatible pour XenServer 8 avant la mise à niveau, lorsque vous mettez à niveau vos hôtes, ils reviennent à l’édition d’essai de 90 jours. L’édition d’essai offre les mêmes fonctionnalités que l’édition Premium, avec quelques limitations. Pour plus d’informations, consultez Présentation des licences XenServer 8.

La haute disponibilité est un ensemble de fonctionnalités automatiques conçues pour planifier et récupérer en toute sécurité des problèmes qui mettent hors service les serveurs Citrix Hypervisor ou les rendent inaccessibles. Par exemple, en cas de perturbation physique du réseau ou de panne matérielle de l’hôte.

Vue d’ensemble

La haute disponibilité garantit que si un hôte devient inaccessible ou instable, les machines virtuelles exécutées sur cet hôte sont redémarrées automatiquement en toute sécurité sur un autre hôte. Cela élimine la nécessité de redémarrer manuellement les machines virtuelles, ce qui réduit les temps d’arrêt des machines virtuelles.

Lorsque le pool master devient inaccessible ou instable, la haute disponibilité peut également récupérer le contrôle administratif d’un pool. La haute disponibilité garantit que le contrôle administratif est restauré automatiquement sans aucune intervention manuelle.

En option, la haute disponibilité peut également automatiser le processus de redémarrage des machines virtuelles sur des hôtes dont on sait qu’ils sont en bon état sans intervention manuelle. Ces machines virtuelles peuvent être planifiées pour redémarrer en groupes afin de laisser le temps de démarrer les services. Il permet de démarrer les machines virtuelles d’infrastructure avant leurs machines virtuelles dépendantes (par exemple, un serveur DHCP avant son serveur SQL dépendant).

Avertissements :

Utilisez la haute disponibilité avec le stockage multichemin et la mise en réseau liée. Configurez le stockage multichemin et la mise en réseau liée avant de tenter de configurer la haute disponibilité. Les clients qui ne configurent pas de stockage multichemin et de réseau lié peuvent constater un comportement de redémarrage inattendu de l’hôte (auto-clôture) en cas d’instabilité de l’infrastructure.

Toutes les solutions graphiques (NVIDIA vGPU, AMD MxGPU (obsolète) et vGPU pass-through) peuvent être utilisées dans un environnement utilisant une haute disponibilité. Toutefois, les machines virtuelles qui utilisent ces solutions graphiques ne peuvent pas être protégées par une haute disponibilité. Ces machines virtuelles peuvent être redémarrées dans la mesure du possible tant qu’il existe des hôtes disposant des ressources libres appropriées.

Surengagement

Un pool est surchargé lorsque les machines virtuelles en cours d’exécution ne peuvent pas être redémarrées ailleurs après un nombre de pannes d’hôte défini par l’utilisateur. Un engagement excessif peut se produire s’il n’y a pas suffisamment de mémoire libre dans le pool pour exécuter ces machines virtuelles après une panne. Cependant, il existe également des changements plus subtils qui peuvent rendre la haute disponibilité non durable : les modifications apportées aux périphériques de blocs virtuels (VBD) et aux réseaux peuvent affecter les machines virtuelles qui peuvent être redémarrées sur quels hôtes. Citrix Hypervisor ne peut pas vérifier toutes les actions potentielles et déterminer si elles entraînent une violation des exigences de haute disponibilité. Cependant, une notification asynchrone est envoyée si la haute disponibilité devient insoutenable.

Citrix Hypervisor gère de manière dynamique un plan de basculement qui détaille la marche à suivre lorsqu’un ensemble d’hôtes d’un pool échoue à un moment donné. Un concept important à comprendre est le Défaillances de l’hôte à tolérer value, qui est définie dans le cadre de la configuration de haute disponibilité. La valeur de pannes d'hôte à tolérer détermine le nombre de pannes d’hôte autorisées tout en étant capable de redémarrer toutes les machines virtuelles protégées. Par exemple, considérons un pool de ressources composé de 64 hôtes et pannes d'hôte à tolérer, étant défini sur 3. Dans ce cas, le pool calcule un plan de basculement qui permet à trois hôtes de tomber en panne, puis redémarre les machines virtuelles sur d’autres hôtes. Si aucun plan ne peut être trouvé, le pool est alors considéré comme surchargé. 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) entraînent une surcharge du pool, des alertes sont envoyées via XenCenter ou par e-mail.

Avertissement de surengagement

Si des tentatives de démarrage ou de reprise d’une machine virtuelle entraînent une surcharge du pool, une alerte d’avertissement s’affiche dans XenCenter. Vous pouvez alors choisir d’annuler l’opération ou de continuer quand même. La procédure entraîne une surcharge du pool et un message est envoyé à toutes les adresses e-mail configurées. Ceci est également disponible sous forme d’instance de message via l’API de gestion. La quantité de mémoire utilisée par les machines virtuelles de différentes priorités est affichée au niveau du pool et de l’hôte.

Clôture d’accueil

Parfois, un serveur peut tomber en panne en raison d’une perte de connectivité réseau ou lorsqu’un problème avec la pile de contrôle est rencontré. Dans de tels cas, le serveur Citrix Hypervisor s’auto-barrière pour garantir que les machines virtuelles ne s’exécutent pas sur deux serveurs simultanément. Lorsqu’une action de clôture est effectuée, le serveur redémarre immédiatement et brusquement, provoquant l’arrêt de toutes les machines virtuelles exécutées dessus. Les autres serveurs détectent que les machines virtuelles ne fonctionnent plus et les machines virtuelles sont alors redémarrées en fonction des priorités de redémarrage qui leur sont attribuées. Le serveur clôturé entre dans une séquence de redémarrage et, une fois redémarré, il tente de rejoindre le pool de ressources.

Remarque :

Les hôtes des pools en cluster peuvent également s’auto-isoler lorsqu’ils ne peuvent pas communiquer avec plus de la moitié des autres hôtes du pool de ressources. Pour plus d’informations, voir Pools en cluster.

Configuration requise

Pour utiliser la fonctionnalité de haute disponibilité, vous avez besoin de :

• Pool Citrix Hypervisor (cette fonctionnalité offre une haute disponibilité au niveau du serveur au sein d’un pool de ressources unique).

  Remarque :

  Nous vous recommandons d’activer la haute disponibilité uniquement dans les pools contenant au moins 3 serveurs Citrix Hypervisor. Pour plus d’informations, voir CTX129721 - Comportement de haute disponibilité lorsque le battement de cœur est perdu dans un pool.

• Stockage partagé, comprenant au moins un LUN iSCSI, NFS ou Fibre Channel d’une taille de 356 Mo ou plus - le SR de pulsation **. Le mécanisme de haute disponibilité crée deux volumes sur le SR heartbeat :

  • Volume de pulsation de 4 Mo : utilisé pour fournir une pulsation.
  • Volume de métadonnées de 256 Mo : pour stocker les métadonnées principales du pool à utiliser en cas de basculement principal.

  Remarque :

  Auparavant, nous vous recommandions d’utiliser un référentiel de stockage NFS ou iSCSI dédié comme disque de pulsation haute disponibilité. Cependant, cela n’est bénéfique que si le référentiel de stockage ne partage pas de ressources sur le dispositif de stockage sous-jacent, sinon cela augmente simplement la complexité et l’utilisation des ressources dans le domaine de contrôle (dom0) de l’hôte.

  Si votre pool est un pool en cluster, votre SR de pulsation doit être un SR GFS2.

  Le stockage connecté via SMB ou iSCSI lors de l’authentification via CHAP ne peut pas être utilisé comme SR de pulsation.

• Adresses IP statiques pour tous les hôtes.

  Avertissement :

  Si l’adresse IP d’un serveur change alors que la haute disponibilité est activée, la haute disponibilité suppose que le réseau de l’hôte est en panne. Le changement d’adresse IP peut clôturer l’hôte et le laisser dans un état inamorçable. Pour remédier à cette situation, désactivez la haute disponibilité à l’aide de la commande host-emergency-ha-disable , réinitialisez le pool master à l’aide de pool-emergency-reset-master, puis réactivez la haute disponibilité.

• Pour une fiabilité maximale, nous vous recommandons d’utiliser une interface liée dédiée comme réseau de gestion haute disponibilité.

• Le réseau de gestion doit autoriser le trafic UDP de pulsation du réseau sur le port 694.

Pour qu’une VM soit protégée par une haute disponibilité, elle doit être agile. Cela signifie que la machine virtuelle :

• Doit avoir ses disques virtuels sur un stockage partagé. Vous pouvez utiliser n’importe quel type de stockage partagé. iSCSI, NFS ou Fibre Channel LUN n’est requis que pour le battement de cœur de stockage et peut être utilisé pour le stockage sur disque virtuel.

• Peut utiliser la migration en direct.

• Ne dispose pas d’une connexion à un lecteur de DVD local configuré.

• Possède ses interfaces réseau virtuelles sur des réseaux à l’échelle du pool.

Remarque :

Lorsque la haute disponibilité est activée, nous vous recommandons fortement d’utiliser une interface de gestion liée sur les serveurs du pool et un stockage multichemin pour le SR de pulsation.

Si vous créez des VLAN et des interfaces liées à partir de l’interface de ligne de commande, il se peut qu’ils ne soient pas branchés et actifs malgré leur création. Dans cette situation, une machine virtuelle peut sembler peu agile et n’est pas protégée par une haute disponibilité. Vous pouvez utiliser la commande CLI pif-plug pour activer le VLAN et lier les PIF afin que la VM puisse devenir agile. Vous pouvez également déterminer précisément pourquoi une machine virtuelle n’est pas agile en utilisant la commande CLI xe diagnostic-vm-status . Cette commande analyse ses contraintes de placement et vous pouvez prendre des mesures correctives si nécessaire.

Redémarrer les paramètres de configuration

Les machines virtuelles peuvent être considérées comme protégées, de niveau optimal ou non protégées par une haute disponibilité. La valeur de ha-restart-priority définit si une machine virtuelle est traitée comme protégée, au mieux ou non protégée. Le comportement de redémarrage des machines virtuelles de chacune de ces catégories est différent.

Protégé

La haute disponibilité garantit le redémarrage d’une machine virtuelle protégée qui se déconnecte ou dont l’hôte se déconnecte, à condition que le pool ne soit pas surchargé et que la machine virtuelle soit agile.

Si une machine virtuelle protégée ne peut pas être redémarrée en cas de défaillance d’un serveur, la haute disponibilité tente de démarrer la machine virtuelle lorsqu’il y a une capacité supplémentaire dans un pool. Les tentatives de démarrage de la machine virtuelle lorsqu’il y a une capacité supplémentaire peuvent désormais réussir.

ha-restart-priority Valeur : redémarrer

Meilleur effort

Si l’hôte d’une machine virtuelle de premier ordre est hors ligne, la haute disponibilité tente de redémarrer la machine virtuelle de premier ordre 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.

ha-restart-priority Valeur : meilleur-effort

Non protégé

Si une machine virtuelle non protégée ou l’hôte sur lequel elle s’exécute est arrêté, la haute disponibilité ne tente pas de redémarrer la machine virtuelle.

ha-restart-priority Valeur : la valeur est une chaîne vide

Remarque :

La haute disponibilité n’arrête jamais ni ne migre une machine virtuelle en cours d’exécution pour libérer des ressources afin qu’une machine virtuelle protégée ou de meilleur effort soit redémarrée.

Si le pool subit des pannes de serveur et que le nombre de pannes tolérables tombe à zéro, le redémarrage des machines virtuelles protégées n’est pas garanti. Dans de tels cas, une alerte système est générée. Si une autre panne se produit, toutes les machines virtuelles dont la priorité de redémarrage est définie se comportent conformément au comportement de meilleur effort.

Commencer la commande

L’ordre de démarrage est l’ordre dans lequel la haute disponibilité de Citrix Hypervisor tente de redémarrer les machines virtuelles protégées lorsqu’une panne se produit. Les valeurs de la propriété d’ordre `` pour chacune des machines virtuelles protégées déterminent l’ordre de démarrage.

La propriété d’ordre `` d’une VM est utilisée par la haute disponibilité et également par d’autres fonctionnalités qui démarrent et arrêtent les VM. N’importe quelle machine virtuelle peut avoir la propriété de l'ordre définie, pas seulement les machines virtuelles marquées comme protégées pour une haute disponibilité. Cependant, la haute disponibilité utilise la propriété ordre pour les machines virtuelles protégées uniquement.

La valeur de la propriété order est un entier. 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 0 sont redémarrées en premier par la haute disponibilité. Plus la valeur de la propriété ordre est élevée, plus tard dans la séquence la VM est redémarrée.

Vous pouvez définir la valeur de la propriété order d’une VM en utilisant l’interface de ligne de commande :

  xe vm-param-set uuid=<vm uuid> order=<int>
<!--NeedCopy-->

Ou dans XenCenter, dans le panneau Options de démarrage pour une VM, définissez Ordre de démarrage sur la valeur requise.

Activer la haute disponibilité sur votre pool Citrix Hypervisor

Vous pouvez activer la haute disponibilité sur un pool en utilisant XenCenter ou l’interface de ligne de commande (CLI). Dans les deux cas, vous spécifiez un ensemble de priorités qui déterminent les machines virtuelles auxquelles est attribuée la priorité de redémarrage la plus élevée lorsqu’un pool est surchargé.

Avertissements :

• Lorsque vous activez la haute disponibilité, certaines opérations qui compromettent le plan de redémarrage des machines virtuelles (comme la suppression d’un serveur d’un pool) peuvent être désactivées. Vous pouvez désactiver temporairement la haute disponibilité pour effectuer de telles opérations ou, alternativement, rendre les machines virtuelles protégées par la haute disponibilité non protégées.

• Si la haute disponibilité est activée, vous ne pouvez pas activer le clustering sur votre pool. Désactivez temporairement la haute disponibilité pour activer le clustering. Vous pouvez activer la haute disponibilité sur votre pool en cluster. Certains comportements de haute disponibilité, tels que l’auto-clôture, sont différents pour les pools en cluster. Pour plus d’informations, voir Pools en cluster.

Activer la haute disponibilité en utilisant la CLI

1. Vérifiez que vous disposez d’un référentiel de stockage (SR) compatible attaché à votre pool. Les SR iSCSI, NFS ou Fibre Channel sont compatibles. Pour plus d’informations sur la configuration d’un tel référentiel de stockage à l’aide de la CLI, consultez Gérer les référentiels de stockage.

2. Pour chaque machine virtuelle que vous souhaitez protéger, définissez une priorité de redémarrage et un ordre de démarrage. Vous pouvez définir la priorité de redémarrage comme suit :

     xe vm-param-set uuid=<vm uuid> ha-restart-priority=restart order=1
   <!--NeedCopy-->
   

3. Activez la haute disponibilité sur le pool et, éventuellement, spécifiez un délai d’expiration :

     xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
   <!--NeedCopy-->
   

   Vous pouvez également définir un délai d’expiration par défaut pour votre pool. Pour plus d’informations sur la façon de définir un délai d’expiration, voir Configurer le délai d’expiration de haute disponibilité.

4. Exécutez la commande pool-ha-compute-max-host-failures-to-tolerate. Cette commande renvoie le nombre maximal d’hôtes pouvant échouer avant que les ressources ne soient insuffisantes pour exécuter toutes les machines virtuelles protégées du pool.

     xe pool-ha-compute-max-host-failures-to-tolerate
   <!--NeedCopy-->
   

   Le nombre d’échecs à tolérer détermine le moment où une alerte est envoyée. Le système recalcule un plan de basculement à mesure que l’état du pool change. Il utilise ce calcul pour identifier la capacité du pool et le nombre de pannes supplémentaires possibles sans perte de la garantie de vivacité pour les machines virtuelles protégées. Une alerte système est générée lorsque cette valeur calculée tombe en dessous de la valeur spécifiée pour ha-host-failures-to-tolerate.

5. Spécifiez le paramètre ha-host-failures-to-tolerate . La valeur doit être inférieure ou égale à la valeur calculée :

     xe pool-param-set ha-host-failures-to-tolerate=2 uuid=<pool uuid>
   <!--NeedCopy-->
   

Configurer le délai d’expiration de la haute disponibilité

Le délai d’expiration de haute disponibilité est la période pendant laquelle le réseau ou le stockage n’est pas accessible par les hôtes de votre pool. Si un serveur Citrix Hypervisor ne parvient pas à accéder au réseau ou au stockage dans le délai d’expiration, il peut s’auto-isoler et redémarrer. Le délai d’expiration par défaut est de 60 secondes. Cependant, vous pouvez modifier cette valeur en utilisant la commande suivante.

Définissez un délai d’expiration de haute disponibilité par défaut pour votre pool :

  xe pool-param-set uuid=<pool uuid> other-config:default_ha_timeout=<timeout in seconds>
<!--NeedCopy-->

Si vous activez la haute disponibilité en utilisant XenCenter au lieu de la CLI xe, cette valeur par défaut s’applique toujours.

Vous pouvez également définir un délai d’expiration lorsque vous activez la haute disponibilité :

  xe pool-ha-enable heartbeat-sr-uuids=<sr uuid> ha-config:timeout=<timeout in seconds>
<!--NeedCopy-->

Notez que si vous définissez un délai d’expiration lors de l’activation de la haute disponibilité, cela s’applique uniquement à cette activation spécifique. Par conséquent, si vous désactivez puis réactivez la haute disponibilité ultérieurement, la fonctionnalité de haute disponibilité revient à l’utilisation du délai d’expiration par défaut.

Supprimer la protection haute disponibilité d’une machine virtuelle à l’aide de la CLI

Pour désactiver les fonctionnalités de haute disponibilité pour une machine virtuelle, utilisez la commande xe vm-param-set pour définir le paramètre ha-restart-priority comme une chaîne vide. La définition du paramètre ha-restart-priority n’efface pas les paramètres d’ordre de démarrage. Vous pouvez réactiver la haute disponibilité pour une machine virtuelle en définissant le paramètre ha-restart-priority sur restart ou best-effort selon le cas.

Récupérer un hôte inaccessible

Si, pour une raison quelconque, un hôte ne peut pas accéder au fichier d’état de haute disponibilité, il est possible qu’un hôte devienne inaccessible. Pour récupérer votre installation Citrix Hypervisor, vous devrez peut-être désactiver la haute disponibilité à l’aide de la commande host-emergency-ha-disable:

  xe host-emergency-ha-disable --force
<!--NeedCopy-->

Si l’hôte était le maître du pool, il démarre normalement avec la haute disponibilité désactivée. Les membres du pool se reconnectent et désactivent automatiquement la haute disponibilité. Si l’hôte était membre du pool et ne peut pas contacter le maître, vous devrez peut-être effectuer l’une des actions suivantes :

• Forcer l’hôte à redémarrer en tant que pool master (xe pool-emergency-transition-to-master)

     xe pool-emergency-transition-to-master uuid=<host uuid>
   <!--NeedCopy-->
  

• Indiquez à l’hôte où se trouve le nouveau maître (xe pool-emergency-reset-master):

     xe pool-emergency-reset-master master-address=<new master hostname>
   <!--NeedCopy-->
  

Une fois tous les hôtes redémarrés avec succès, réactivez la haute disponibilité :

  xe pool-ha-enable heartbeat-sr-uuid=<sr uuid>
<!--NeedCopy-->

Arrêt d’un hôte lorsque la haute disponibilité est activée

Soyez particulièrement prudent lors de l’arrêt ou du redémarrage d’un hôte pour éviter que le mécanisme de haute disponibilité ne suppose que l’hôte est en panne. Pour arrêter proprement un hôte lorsque la haute disponibilité est activée, désactivez l’hôte, évacuez l’hôte et enfin arrêtez l’hôte à l’aide de XenCenter ou de la CLI. Pour arrêter un hôte dans un environnement où la haute disponibilité est activée, exécutez ces commandes :

  xe host-disable host=<host name>
  xe host-evacuate uuid=<host uuid>
  xe host-shutdown host=<host name>
<!--NeedCopy-->

Arrêter une VM protégée par une haute disponibilité

Lorsqu’une machine virtuelle est protégée par un plan de haute disponibilité et configurée pour redémarrer automatiquement, elle ne peut pas être arrêtée tant que cette protection est active. Pour arrêter une machine virtuelle, désactivez d’abord sa protection haute disponibilité, puis exécutez la commande CLI. XenCenter vous propose une boîte de dialogue pour automatiser la désactivation de la protection lorsque vous sélectionnez le bouton Arrêter d’une VM protégée.

Remarque :

Si vous arrêtez une machine virtuelle depuis l’invité et que la machine virtuelle est protégée, elle est automatiquement redémarrée dans des conditions d’échec de haute disponibilité. Le redémarrage automatique permet de garantir qu’une erreur de l’opérateur n’entraîne pas l’arrêt accidentel d’une machine virtuelle protégée. Si vous souhaitez arrêter cette machine virtuelle, désactivez d’abord sa protection haute disponibilité.