Faire face aux défaillances des machines
Cette section fournit des détails sur la procédure de reprise après différents scénarios de défaillance. Tous les scénarios de reprise après incident nécessitent l’utilisation d’un ou de plusieurs des types de sauvegarde répertoriés dans Sauvegarde.
Échecs des membres
En l’absence de HA, les nœuds maîtres détectent les défaillances des membres en recevant régulièrement des messages de pulsation. Si aucun battement de cœur n’a été reçu pendant 600 secondes, le maître suppose que le membre est mort. Il existe deux méthodes pour résoudre ce problème :
-
Réparez l’hôte mort (par exemple, en le redémarrant physiquement). Lorsque la connexion au membre est rétablie, le maître marque à nouveau le membre comme étant actif.
-
Arrêtez l’hôte et demandez au maître d’oublier le nœud membre à l’aide de la commande
xe host-forgetCLI. Une fois que le membre a été oublié, toutes les machines virtuelles qui y étaient exécutées sont marquées comme étant hors ligne 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 les données de la machine virtuelle pourraient être corrompues.
Ne divisez pas votre pool en plusieurs pools d’un même 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 la machine virtuelle.
Avertissement :
- Si vous comptez 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-forgetsi 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 tombe en panne, il se peut que certaines machines virtuelles soient encore enregistrées 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. Voir vm-reset-powerstatepour plus de détails.
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. Chaque disque d’une SR ne peut être utilisé que sur un hôte à la fois. Il est essentiel de rendre le disque accessible aux autres serveurs Citrix Hypervisor en cas de défaillance d’un hôte. 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 de fournir la troisième chaîne (« master ») que si l’hôte défaillant était le maître SR au moment du crash. (Le maître SR est le maître du pool ou un serveur Citrix Hypervisor utilisant le stockage local.)
Avertissement :
Assurez-vous que l’hôte est hors service 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.
Pannes du Master
Chaque membre d’un pool de ressources contient toutes les informations nécessaires pour assumer le rôle de maître si nécessaire. En cas de défaillance d’un nœud maître, la séquence d’événements suivante se produit :
-
Si HA est activé, un autre maître est sélectionné automatiquement.
-
Si HA n’est pas activé, chaque membre attend le retour du maître.
Si le maître revient à ce stade, il rétablit la communication avec ses membres et le fonctionnement revient à la normale.
Si le maître est mort, choisissez l’un des membres et lancez 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 qui était le serveur principal d’origine, vous pouvez simplement l’ouvrir, installer le logiciel Citrix Hypervisor et l’ajouter au pool. Étant donné que les serveurs Citrix Hypervisor du pool sont obligés d’être homogènes, il n’est pas vraiment nécessaire de faire du serveur remplacé le serveur maître.
Lorsqu’un serveur Citrix Hypervisor membre passe au statut de 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 commande xe pool-param-list et en vérifiant que le paramètre default-SR pointe vers un référentiel de stockage valide.
Pannes 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 les métadonnées de votre pool à l’aide de la commande xe pool-dump-database CLI (voir pool-dump-database).
Pour restaurer un pool complètement défaillant :
-
Installez un nouvel ensemble d’hôtes. Ne les regroupez pas à ce stade.
-
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). -
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.
-
Effectuez une opération de jonction 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 le logiciel ou la configuration de l’hôte est endommagé :
-
Exécutez la commande suivante pour restaurer le logiciel hôte et la configuration :
xe host-restore host=host file-name=hostbackup <!--NeedCopy--> -
Redémarrez sur le CD d’installation de l’hôte et sélectionnez Restaurer à partir d’une sauvegarde
Panne physique des machines
Si la machine hôte physique est défaillante, suivez la procédure appropriée de la liste suivante pour effectuer la restauration.
Avertissement :
toutes les machines virtuelles exécutées sur un membre précédent (ou l’hôte précédent) qui ont échoué sont toujours marquées comme
Runningdans la base de données. Ce comportement est pour des raisons de sécurité. Le démarrage simultané d’une machine virtuelle sur deux hôtes différents entraînerait une grave corruption 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 surHalted:
xe vm-reset-powerstate vm=vm_uuid --forceles machines 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 :
-
Exécutez les commandes suivantes :
xe pool-emergency-transition-to-master xe pool-recover-slaves <!--NeedCopy--> -
Si les commandes réussissent, redémarrez les machines virtuelles.
La restauration d’un pool avec tous les hôtes a échoué :
-
Exécutez la commande :
xe pool-restore-database file-name=backup <!--NeedCopy-->Avertissement :
Cette commande n’aboutit que si la machine cible possède un nombre approprié de cartes réseau nommées correctement.
-
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 commande
pbd-destroy. Utilisez ensuite la commande pour recréer les configurations de stockagepbd-create. Voir les commandes pbdpour la documentation de ces commandes. -
Si vous avez créé une configuration de stockage, utilisez l’
pbd-plugélément de menu Stockage > Réparer le référentiel de stockage dans XenCenter pour utiliser la nouvelle configuration. -
Redémarrez toutes les machines virtuelles.
Pour restaurer une machine virtuelle lorsque le stockage de la machine virtuelle n’est pas disponible :
-
Exécutez la commande suivante :
xe vm-import filename=backup metadata=true <!--NeedCopy--> -
Si l’importation des métadonnées échoue, exécutez la commande suivante :
xe vm-import filename=backup metadata=true --force <!--NeedCopy-->Cette commande tente de restaurer les métadonnées de la machine virtuelle « au mieux ».
-
Redémarrez toutes les machines virtuelles.