Haute disponibilité

La haute disponibilité est un ensemble de fonctionnalités automatiques conçues pour planifier et récupérer en toute sécurité les problèmes qui font tomber les serveurs Citrix Hypervisor ou les rendent inaccessibles. Par exemple, lors d’une interruption physique du réseau ou d’une défaillance matérielle de l’hôte.

Synthèse

La haute disponibilité garantit que lorsqu’un hôte devient inaccessible ou instable, les machines virtuelles exécutées sur cet hôte sont arrêtées et redémarrées sur un autre hôte. L’arrêt et le redémarrage des machines virtuelles sur un autre hôte évitent que les machines virtuelles soient démarrées (manuellement ou automatiquement) sur un nouvel hôte. À un moment donné, l’hôte d’origine est récupéré. Ce scénario peut conduire deux instances de la même machine virtuelle s’exécutant sur des hôtes différents, et une forte probabilité correspondante de corruption de disque de machine virtuelle et de perte de données.

Lorsque le maître de pool devient inaccessible ou instable, la haute disponibilité peut également récupérer le contrôle administratif d’un pool. La haute disponibilité garantit une restauration automatique du contrôle administratif sans intervention manuelle.

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

Avertissements :

Utilisez la haute disponibilité ainsi que le stockage multivoies et la mise en réseau sous liaison. 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 le stockage multichemin et le réseau lié peuvent voir un comportement inattendu de redémarrage de l’hôte (Self Fencing) en cas d’instabilité de l’infrastructure.

Toutes les solutions graphiques (nVidia vGPU, Intel GVT-D, Intel GVT-G, AMD MxGPU et vGPU pass-through) peuvent être utilisées dans un environnement qui utilise la haute disponibilité. Toutefois, les machines virtuelles qui utilisent ces solutions graphiques ne peuvent pas être protégées avec une haute disponibilité. Ces machines virtuelles peuvent être redémarrées au mieux alors qu’il existe des hôtes avec les ressources libres appropriées.

Surcharge

Un pool est surchargé lorsque les machines virtuelles qui sont en cours d’exécution ne peuvent pas être redémarrées ailleurs à la suite d’un nombre d’échecs d’hôte défini par l’utilisateur.

Une surcharge peut se produire s’il n’y a pas assez de mémoire libre dans le pool pour exécuter ces machines virtuelles à la suite d’un échec. Cependant, il y a aussi des changements plus subtils qui peuvent rendre les garanties de haute disponibilité non durables : les modifications apportées aux VBD (Virtual Block Devices) 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 provoquent une violation des exigences de haute disponibilité. Toutefois, une notification asynchrone est envoyée si la haute disponibilité devient insoutenable.

Citrix Hypervisor gère dynamiquement un plan de basculement qui détaille ce qu’il faut faire lorsqu’un ensemble d’hôtes d’un pool échoue à un moment donné. Un concept important à comprendre est les échecs de tolérance de valeur de l’hôte , qui est défini dans le cadre de la configuration haute disponibilité. La valeur des échecs d’hôte à tolérer détermine le nombre de défaillances autorisées sans perte de service. Par exemple, considérez un pool de ressources composé de 64 hôtes et les échecs tolérés sont définis sur 3. Dans ce cas, le pool calcule un plan de basculement qui permet à trois hôtes d’échouer et de redémarrer les machines virtuelles sur d’autres hôtes. Si un plan est introuvable, le pool est considéré comme étant trop engagé. 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, provoquent une surallocation de votre pool, des alertes sont envoyées (via XenCenter ou par e-mail).

Avertissement de surallocation

Si une tentative de démarrage ou de reprise d’une machine virtuelle entraîne une surallocation du pool, une alerte d’avertissement s’affiche. Cet avertissement apparaît dans XenCenter et est également disponible en tant qu’instance de message via l’API de gestion. Si vous avez configuré une adresse e-mail, un message peut également être envoyé à l’adresse e-mail. Vous pouvez alors annuler l’opération, ou continuer quand même. En procédant, le pool devient trop chargé. La quantité de mémoire utilisée par les machines virtuelles de priorités différentes s’affiche au niveau du pool et de l’hôte.

Isolation d’hôte

Parfois, un serveur peut échouer en raison de la 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-isole pour s’assurer que les machines virtuelles ne s’exécutent pas simultanément sur deux serveurs. 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 qui s’exécutent dessus. Les autres serveurs détectent que les machines virtuelles ne sont plus en cours d’exécution et que les machines virtuelles sont redémarrées en fonction des priorités de redémarrage qui leur sont assignées. Le serveur isolé entre dans une séquence de redémarrage et, lorsqu’il a 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 de plus amples informations, consultez la section Pools en cluster.

Configuration requise

Pour utiliser la fonction haute disponibilité, vous devez :

  • 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 trois serveurs Citrix Hypervisor. Pour de plus amples informations, consultez la section CTX129721 - Comportement de haute disponibilité lorsque le rythme cardiaque est perdu dans un pool.

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

    Volume de battements cardiaques de 4 Mo : Utilisé pour les battements cardiaques.

    Volume de métadonnées de 256 Mo : pour stocker les métadonnées maîtresses de pool à utiliser en cas de basculement principal.

    Remarques :

    • Pour une fiabilité maximale, nous vous recommandons d’utiliser un référentiel de stockage NFS ou iSCSI dédié comme disque de fréquence cardiaque haute disponibilité. N’utilisez pas ce référentiel de stockage à d’autres fins.
    • Si votre pool est un pool en cluster, votre SR de pulsation doit être un SR GFS2.
    • Le stockage connecté à l’aide de SMB ou iSCSI lorsqu’il est authentifié à l’aide de CHAP ne peut pas être utilisé comme SR de pulsation.
    • Lorsque vous utilisez NetApp ou EqualLogic SR, provisionnez manuellement un LUN NFS ou iSCSI sur la baie pour l’utiliser 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 a échoué. Le changement d’adresse IP peut clôturer l’hôte et le laisser dans un état non amorçable. Pour remédier à cette situation, désactivez la haute disponibilité à l’aide de lahost-emergency-ha-disable commande, réinitialisez le maître de pool à l’aidepool-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é.

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

  • Doit avoir ses disques virtuels sur le stockage partagé. Vous pouvez utiliser n’importe quel type de stockage partagé. La LUN iSCSI, NFS ou Fibre Channel est uniquement requise pour le rythme cardiaque de stockage et peut être utilisée pour le stockage sur disque virtuel.

  • Peut utiliser la migration en direct

  • Aucune connexion à un lecteur de DVD local n’est configurée

  • A ses interfaces réseau virtuelles sur les 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 la SR heartbeat.

Si vous créez des VLAN et des interfaces liées à partir de l’interface de ligne de commande, ils peuvent ne pas être branchés et actifs malgré leur création. Dans ce cas, une machine virtuelle peut sembler ne pas être agile et elle n’est pas protégée par une haute disponibilité. Vous pouvez utiliser lapif-plug commande CLI pour afficher le VLAN et les PIF de liaison afin que la machine virtuelle devienne agile. Vous pouvez également déterminer précisément pourquoi une machine virtuelle n’est pas agile à l’aide de la commandexe diagnostic-vm-status CLI. 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, au meilleur effort ou non protégées par la haute disponibilité. La valeur deha-restart-priority définit si une machine virtuelle est traitée comme protégée, best effort 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 survalidé et que la machine virtuelle soit agile.

Si une machine virtuelle protégée ne peut pas être redémarrée lorsqu’un serveur tombe en panne, 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 maintenant réussir.

ha-restart-priority Valeur :restart

Meilleur effort

Si l’hôte d’une machine virtuelle du meilleur effort est mis hors ligne, la haute disponibilité tente de redémarrer la machine virtuelle la plus performante sur un autre hôte. Il effectue cette tentative seulement 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 de redémarrage d’une machine virtuelle au meilleur effort. Si cette tentative échoue, la haute disponibilité ne tente pas de redémarrer la machine virtuelle.

ha-restart-priority Valeur :best-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ée, la haute disponibilité ne tente pas de redémarrer la machine virtuelle.

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

Remarque :

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

Si le pool rencontre des défaillances de serveur et que le nombre de défaillances tolérables tombe à zéro, les machines virtuelles protégées ne sont pas garanties de redémarrage. Dans de tels cas, une alerte système est générée. Si une autre défaillance se produit, toutes les machines virtuelles dont la priorité de redémarrage est définie se comportent en fonction du comportement le plus efficace.

Commencer la commande

L’ordre de démarrage est l’ordre dans lequel Citrix Hypervisor haute disponibilité tente de redémarrer les machines virtuelles protégées en cas d’échec. Les valeurs de laorder propriété pour chacune des machines virtuelles protégées déterminent l’ordre de début.

Laorder propriété d’une machine virtuelle est utilisée par la haute disponibilité et aussi par d’autres fonctionnalités qui démarrent et arrêtent les machines virtuelles. N’importe quelle machine virtuelle peut avoir le jeu deorder propriétés, pas seulement les machines virtuelles marquées comme protégées pour une haute disponibilité. Toutefois, la haute disponibilité utilise laorder propriété uniquement pour les machines virtuelles protégées.

La valeur de laorder propriété est un entier. La valeur par défaut est 0, qui est la priorité la plus élevée. Les machines virtuelles protégées dontorder la valeur est 0 sont redémarrées en premier par haute disponibilité. Plus la valeur de laorder propriété est élevée, plus tard dans la séquence, la machine virtuelle est redémarrée.

Vous pouvez définir la valeur de laorder propriété d’une machine virtuelle à l’aide de l’interface de ligne de commande :

xe vm-param-set uuid=VM_UUID order=int

Ou dans XenCenter, dans le panneau Options de démarrage d’une machine virtuelle, définissez l’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 à l’aide de XenCenter ou de l’interface de ligne de commande. Dans les deux cas, vous spécifiez un ensemble de priorités qui déterminent les machines virtuelles qui reçoivent la priorité de redémarrage la plus élevée lorsqu’un pool est survalidé.

Avertissements :

  • Lorsque vous activez la haute disponibilité, certaines opérations qui compromettent le plan de redémarrage des machines virtuelles, telles que la suppression d’un serveur d’un pool, peuvent être désactivées. Vous pouvez temporairement désactiver 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ésactiver 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é à l’aide de l’interface de ligne de commande

  1. Vérifiez qu’un référentiel de stockage (SR) compatible est connecté à 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 l’interface de ligne de commande, reportez-vous à la sectionGé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
    
  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
    

    Le délai d’expiration est la période pendant laquelle la mise en réseau ou le stockage n’est pas accessible par les hôtes de votre pool. Si vous ne spécifiez pas de délai d’expiration lorsque vous activez la haute disponibilité, Citrix Hypervisor utilise le délai d’expiration par défaut de 30 secondes. Si un serveur Citrix Hypervisor n’est pas en mesure d’accéder à la mise en réseau ou au stockage pendant le délai d’expiration, il peut s’auto-clôturer et redémarrer.

  4. Exécutez la commandepool-ha-compute-max-host-failures-to-tolerate. Cette commande renvoie le nombre maximal d’hôtes pouvant échouer avant qu’il n’y ait suffisamment de ressources pour exécuter toutes les machines virtuelles protégées dans le pool.

    xe pool-ha-compute-max-host-failures-to-tolerate
    

    Le nombre d’échecs à tolérer détermine quand une alerte est envoyée. Le système recalcule un plan de basculement lorsque l’état du pool change. Il utilise ce calcul pour identifier la capacité du pool et combien de défaillances supplémentaires sont possibles sans perte de la garantie de réactivité 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 pourha-host-failures-to-tolerate.

  5. Spécifiez le nombre d’échecs à tolérer le paramètre. 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
    

Supprimez la protection haute disponibilité d’une machine virtuelle à l’aide de l’interface de ligne de commande

Pour désactiver les fonctionnalités de haute disponibilité pour une machine virtuelle, utilisez laxe vm-param-set commande pour définir leha-restart-priority paramètre comme une chaîne vide. La définition duha-restart-priority paramètre n’efface pas les paramètres de l’ordre de départ. Vous pouvez réactiver la haute disponibilité pour une machine virtuelle en définissant leha-restart-priority paramètre surrestart oubest-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 haute disponibilité, il est possible qu’un hôte devienne inaccessible. Pour récupérer votre installation de Citrix Hypervisor, vous devrez peut-être désactiver la haute disponibilité à l’aide de lahost-emergency-ha-disable commande :

xe host-emergency-ha-disable --force

Si l’hôte était le maître de 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 maître de pool (xe pool-emergency-transition-to-master)

     xe pool-emergency-transition-to-master uuid=host_uuid
    
  • 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
    

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

xe pool-ha-enable heartbeat-sr-uuid=sr_uuid

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

Faites particulièrement attention lors de l’arrêt ou du redémarrage d’un hôte pour empêcher le mécanisme de haute disponibilité de supposer que l’hôte a échoué. Pour arrêter proprement un hôte lorsque la haute disponibilité est activée,disable l’hôte, l’hôte et enfinevacuate l’hôte àshutdown l’aide de XenCenter ou de l’interface de ligne de commande. Pour arrêter un hôte dans un environnement où la haute disponibilité est activée, exécutez les commandes suivantes :

    xe host-disable host=host_name
    xe host-evacuate uuid=host_uuid
    xe host-shutdown host=host_name

Arrêter une machine virtuelle protégée par la haute disponibilité

Lorsqu’une machine virtuelle est protégée dans le cadre d’un plan de haute disponibilité et qu’elle est définie 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 machine virtuelle protégée.

Remarque :

Si vous arrêtez une machine virtuelle à partir de l’invité et que la machine virtuelle est protégée, elle est automatiquement redémarrée dans les conditions d’échec de haute disponibilité. Le redémarrage automatique permet de s’assurer que l’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é.