Configurer la haute disponibilité

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 prennent des hôtes 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).

Avertissement :

La haute disponibilité peut être utilisée avec le stockage multivoies et la mise en réseau via 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 de réseau et de stockage multichemins peuvent voir un comportement inattendu de redémarrage de l’hôte (auto-clôture) en cas d’instabilité de l’infrastructure.

Note :

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.

En trop d’engagements

Un pool est survalisé lorsque les machines virtuelles en cours d’exécution ne peuvent pas être redémarrées ailleurs après un nombre défini par l’utilisateur d’échecs d’hôte.

Un surengagement peut se produire s’il n’y a pas assez de mémoire libre dans le pool pour exécuter ces machines virtuelles après une défaillance. Cependant, il y a aussi des changements plus subtils qui peuvent rendre les garanties de haute disponibilité non durables : les modifications apportées aux périphériques virtuels (VBD) et aux réseaux peuvent affecter les machines virtuelles qui peuvent être redémarrées sur quels hôtes. ne peut pas vérifier toutes les actions potentielles et déterminer si elles provoquent une violation des demandes de haute disponibilité. Toutefois, une notification asynchrone est envoyée si la haute disponibilité devient insoutenable.

maintient 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 ne peut pas être trouvé, le pool est considéré comme surengagé. 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 dans le pool, provoquent une surutilisation de votre pool, des alertes sont envoyées ( soit par courrier électronique).

Avertissement de surengagement

Si une tentative de démarrage ou de reprise d’une machine virtuelle entraîne une surutilisation du pool, une alerte d’avertissement s’affiche. Cet avertissement apparaît dans et est également disponible en tant qu’instance de message via l’API Xen. 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 engagé. 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.

Clôture 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, l’ hôte s’auto-clôtures 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 s’exécutant sur elle. 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 clôturé entre dans une séquence de redémarrage et, lorsqu’il a redémarré, il essaie de rejoindre le pool de ressources.

Note :

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

Configuration requise

Note :

recommande d’activer la haute disponibilité uniquement dans les pools contenant au moins trois hôtes. Pour plus d’informations, consultez CTX129721 - comportement de haute disponibilité lorsque le rythme cardiaque est perdu dans un pool XenServer.

Pour utiliser la fonction haute disponibilité, vous devez :

• 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, il est recommandé d’utiliser un référentiel de stockage NFS ou iSCSI dédié comme disque de pulsation 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.

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

• 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 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

• 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

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

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 met hors connexion ou dont l’hôte est hors connexion, à condition que le pool ne soit pas surengagé 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

Note :

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.

Démarrer l’ordre

L’ordre de démarrage est l’ordre dans lequel la 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 uuuid = ordre VM_UUID = int

Ou dans , dans le panneau Options de démarrage d’une machine virtuelle, définissez l’ordre de démarrage sur la valeur requise.

Activez la haute disponibilité sur votre piscine

Vous pouvez activer la haute disponibilité sur un pool à l’aide de l’interface de ligne de commande 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 surengagé.

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-us/xenserver/current-release/hosts-pools/clustered-pools.html()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, voir 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 uuuid = vm_uuid ha-restart-priority = ordre de redémarrage = 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 en secondes
   

   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é, utilise le délai d’expiration par défaut de 30 secondes. Si un hôte n’est pas en mesure d’accéder au réseau ou au stockage pendant la période de 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, 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 uuuid = 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-uuuid = 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 un hôte proprement lorsque la haute disponibilité est activée,disable l’hôte, l’hôte et enfinevacuate l’hôte àshutdown l’aide de l’une ou l’autre CLI. 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 uuuid = 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. 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.

Note :

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é.