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 font tomber les hôtes XenServer 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 coordinateur du pool 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 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 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. XenServer 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.

XenServer 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 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 hôte 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, l’hôte XenServer s’auto-barrière pour garantir que les machines virtuelles ne s’exécutent pas sur deux hôtes simultanément. Lorsqu’une action de clôture est effectuée, l’hôte redémarre immédiatement et brusquement, provoquant l’arrêt de toutes les machines virtuelles exécutées dessus. Les autres hôtes détectent que les machines virtuelles ne fonctionnent plus, puis les machines virtuelles sont redémarrées en fonction des priorités de redémarrage qui leur sont attribuées. L’hôte 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 XenServer (cette fonctionnalité offre une haute disponibilité au niveau de l’hôte au sein d’un seul pool de ressources).

  Remarque :

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

• Stockage partagé, y compris au moins un LUN iSCSI, NFS ou Fibre Channel d’une taille de 4 Go ou plus : battement de cœur SR. 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 3,7 Go : pour stocker les métadonnées du coordinateur de pool à utiliser en cas de basculement du coordinateur de pool.

  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 hôte 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 coordinateur de pool à 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 hôtes 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 hôte, 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 d’hôte 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é XenServer 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>
 

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

Activez la haute disponibilité sur votre pool XenServer

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 hôte 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 ensuite 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
    

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>
    

   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
    

   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>
    

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

Le délai d’attente 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 hôte XenServer ne parvient pas à accéder au réseau ou au stockage dans le délai imparti, 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>
 

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>
 

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 XenServer, vous devrez peut-être désactiver la haute disponibilité à l’aide de la commande host-emergency-ha-disable:

  xe host-emergency-ha-disable --force
 

Si l’hôte était le coordinateur 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 coordinateur du pool, vous devrez peut-être effectuer l’une des actions suivantes :

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

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

• Dites à l’hôte où se trouve le nouveau coordinateur de pool (xe pool-emergency-reset-master) :

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

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>
 

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>
 

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