Faire face aux défaillances de la machine

Cette section fournit des détails sur la procédure de récupération à partir de divers scénarios de défaillance. Tous les scénarios de récupération d’échec nécessitent l’utilisation d’un ou de plusieurs types de sauvegarde répertoriés dans Sauvegarde.

Échecs de membres

En l’absence d’HA, les nœuds maîtres détectent les défaillances des membres en recevant des messages de rythme cardiaque réguliers. Si aucun battement cardiaque n’a été reçu pendant 600 secondes, le maître suppose que le membre est mort. Il existe deux façons de récupérer de ce problème :

  • Réparer l’hôte mort (par exemple, en le redémarrant physiquement). Lorsque la connexion au membre est restaurée, le maître repère le membre comme vivant.

  • Arrêtez l’hôte et demandez au maître d’oublier le nœud membre à l’aide de la commande xe host-forget CLI. Une fois que le membre a été oublié, toutes les machines virtuelles qui s’y exécutaient sont marquées comme étant hors connexion et peuvent être redémarrées sur d’autres serveurs Citrix Hypervisor.

    Il est important de s’assurer que le serveur Citrix Hypervisor est réellement hors ligne, sinon la corruption des données de la machine virtuelle pourrait se produire.

    Ne pas diviser votre pool en plusieurs pools d’un seul hôte en utilisant xe host-forget. Cette action peut entraîner le mappage du même stockage partagé et la corruption des données de machine virtuelle.

Avertissement :

  • Si vous allez utiliser à nouveau l’hôte oublié en tant qu’hôte actif, effectuez une nouvelle installation du logiciel Citrix Hypervisor.
  • N’utilisez pas la commande xe host-forget si HA est activée sur le pool. Désactivez d’abord HA, puis oubliez l’hôte, puis réactivez HA.

Lorsqu’un serveur Citrix Hypervisor membre échoue, il se peut que des machines virtuelles soient toujours enregistrées à l’état en cours d’exécution. Si vous êtes sûr que le serveur Citrix Hypervisor membre est définitivement en panne, utilisez la commande xe vm-reset-powerstate CLI pour définir l’état d’alimentation des machines virtuelles sur halted. Pour plus d’informations, veuillez consulter la section vm-reset-powerstate.

Avertissement :

Une utilisation incorrecte de cette commande peut entraîner une corruption des données. N’utilisez cette commande que si nécessaire.

Avant de pouvoir démarrer des machines virtuelles sur un autre serveur Citrix Hypervisor, vous devez également libérer les verrous sur le stockage des machines virtuelles. Seul l’hôte à la fois peut utiliser chaque disque dans un SR. Il est essentiel de rendre le disque accessible aux autres serveurs Citrix Hypervisor une fois qu’un hôte a échoué. Pour ce faire, exécutez le script suivant sur le maître de pool pour chaque SR contenant des disques de toutes les machines virtuelles concernées :/opt/xensource/sm/resetvdis.py host_UUID SR_UUID master

Vous n’avez besoin que de fournir la troisième chaîne (« master ») si l’hôte défaillant était le maître SR au moment du crash. (Le maître SR est le maître de pool ou un serveur Citrix Hypervisor utilisant le stockage local.)

Avertissement :

Assurez-vous que l’hôte est en panne avant d’exécuter cette commande. Une utilisation incorrecte de cette commande peut entraîner une corruption des données.

Si vous tentez de démarrer une machine virtuelle sur un autre serveur Citrix Hypervisor avant d’exécuter le resetvdis.py script, le message d’erreur suivant s’affiche : VDI <UUID> already attached RW.

Échecs du maître

Chaque membre d’un pool de ressources contient toutes les informations nécessaires pour prendre en charge le rôle de maître si nécessaire. Lorsqu’un nœud maître échoue, la séquence d’événements suivante se produit :

  1. Si HA est activée, un autre maître est choisi automatiquement.

  2. Si HA n’est pas activée, chaque membre attend le retour du maître.

Si le maître revient à ce stade, il rétablit la communication avec ses membres et l’opération revient à la normale.

Si le maître est mort, choisissez l’un des membres et exécutez la commande xe pool-emergency-transition-to-master dessus. Une fois qu’il est devenu le maître, exécutez la commande xe pool-recover-slaves et les membres pointent maintenant vers le nouveau maître.

Si vous réparez ou remplacez le serveur principal d’origine, vous pouvez simplement le faire apparaître, installer le logiciel Citrix Hypervisor et l’ajouter au pool. Étant donné que les serveurs Citrix Hypervisor dans le pool sont appliqués pour être homogènes, il n’est pas vraiment nécessaire de faire du serveur remplacé le maître.

Lorsqu’un serveur Citrix Hypervisor membre est transféré en tant que serveur maître, vérifiez que le référentiel de stockage de pool par défaut est défini sur une valeur appropriée. Cette vérification peut être effectuée à l’aide de la xe pool-param-list commande et en vérifiant que le default-SR paramètre pointe vers un référentiel de stockage valide.

Échecs de pool

Dans le cas malheureux où l’ensemble de votre pool de ressources échoue, vous devez recréer la base de données de pool à partir de zéro. Veillez à sauvegarder régulièrement vos métadonnées de pool à l’aide de la commande CLI xe pool-dump-database (voir pool-dump-database).

Pour restaurer un pool complètement défaillant :

  1. Installez un nouvel ensemble d’hôtes. Ne les remontez pas à ce stade.

  2. Pour l’hôte désigné comme maître, restaurez la base de données du pool à partir de votre sauvegarde à l’aide de la commande xe pool-restore-database (voir pool-restore-database).

  3. Connectez-vous à l’hôte maître à l’aide de XenCenter et assurez-vous que tous vos ordinateurs virtuels et de stockage partagés sont à nouveau disponibles.

  4. Effectuez une opération de jointure de pool sur les hôtes membres fraîchement installés restants et démarrez vos machines virtuelles sur les hôtes appropriés.

Faire face aux défaillances dues à des erreurs de configuration

Si la machine hôte physique est opérationnelle mais que la configuration du logiciel ou de l’hôte est endommagée :

  1. Exécutez la commande suivante pour restaurer le logiciel hôte et la configuration :

    xe host-restore host=host file-name=hostbackup
    
  2. Redémarrez sur le CD d’installation de l’hôte et sélectionnez Restaurer à partir de la sauvegarde.

Défaillance physique de la machine

Si la machine hôte physique a échoué, utilisez la procédure appropriée de la liste suivante pour restaurer.

Avertissement :

toutes les machines virtuelles exécutées sur un membre précédent (ou sur l’hôte précédent) qui ont échoué sont toujours marquées comme Running dans la base de données. Ce comportement est pour la sécurité. Le démarrage simultané d’une machine virtuelle sur deux hôtes différents entraînerait une corruption grave du disque. Si vous êtes sûr que les machines (et les machines virtuelles) sont hors connexion, vous pouvez réinitialiser l’état d’alimentation de la machine virtuelle sur Halted : les machines

xe vm-reset-powerstate vm=vm_uuid --force

virtuelles peuvent ensuite être redémarrées à l’aide de XenCenter ou de l’interface de ligne de commande.

Pour remplacer un maître défaillant par un membre toujours en cours d’exécution :

  1. Exécutez les commandes suivantes :

    xe pool-emergency-transition-to-master
    xe pool-recover-slaves
    
  2. Si les commandes réussissent, redémarrez les machines virtuelles.

Pour restaurer un pool avec tous les hôtes a échoué :

  1. Exécutez la commande :

    xe pool-restore-database file-name=backup
    

    Avertissement :

    Cette commande ne réussit que si la machine cible dispose d’un nombre approprié de cartes réseau nommées correctement.

  2. Si la machine cible a une vue du stockage différente de celle de la machine d’origine, modifiez la configuration du stockage à l’aide de la pbd-destroy commande. Utilisez ensuite la pbd-create commande pour recréer les configurations de stockage. Reportez-vous à commandes pbd pour la documentation de ces commandes.

  3. Si vous avez créé une configuration de stockage, utilisez pbd-plug ou Stockage > Réparer le référentiel de stockage dans XenCenter pour utiliser la nouvelle configuration.

  4. Redémarrez toutes les machines virtuelles.

Pour restaurer une machine virtuelle lorsque le stockage de machine virtuelle n’est pas disponible :

  1. Exécutez la commande suivante :

    xe vm-import filename=backup metadata=true
    
  2. Si l’importation des métadonnées échoue, exécutez la commande :

    xe vm-import filename=backup metadata=true --force
    

    Cette commande tente de restaurer les métadonnées de la machine virtuelle sur la base du « meilleur effort ».

  3. Redémarrez toutes les machines virtuelles.