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 des 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 rétablie, le maître marquera à nouveau le membre comme vivant.

• Arrêtez l’hôte et demandez au maître d’oublier le nœud membre à l’aide de la commandexe host-forget CLI. Une fois que le membre a été oublié, toutes les machines virtuelles qui y étaient exécutées seront marquées comme hors ligne et peuvent être redémarrées sur d’autres hôtes. Notez qu’il est très important de s’assurer que l’ hôte est réellement hors ligne, sinon une corruption de données de machine virtuelle pourrait se produire. Veillez à ne pas diviser votre pool en plusieurs pools d’un seul hôte en utilisantxe host-forget, car cela pourrait entraîner tous les mapper le même stockage partagé et endommager les données de VM.

Avertissement :

• Si vous souhaitez réutiliser l’hôte oublié comme hôte actif, effectuez une nouvelle installation du logiciel.
• N’utilisez pasxe host-forget la commande si HA est activée sur le pool. Désactivez d’abord HA, puis oubliez l’hôte, puis réactivez HA.

En cas de défaillance d’un hôte membre, il se peut que des machines virtuelles soient toujours enregistrées à l’état d’ exécution . Si vous êtes sûr que l’ hôte membre est définitivement hors service, utilisez la commandexe vm-reset-powerstate CLI pour définir l’état d’alimentation des machines virtuelles surhalted . 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 cela est absolument nécessaire.

Avant de pouvoir démarrer des machines virtuelles sur un autre hôte, vous devez également libérer les verrous sur le stockage de machines virtuelles. Chaque disque d’un SR ne peut être utilisé que par un hôte à la fois. Il est donc essentiel de rendre le disque accessible aux autres hôtes 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 hôte_UUID SR_UUID maître

Il vous suffit de fournir la troisième chaîne (« master ») si l’hôte défaillant était le maître de pool MDASH maître SR ou l’ hôte utilisant MDASH de stockage local au moment du plantage.

Avertissement :

Assurez-vous absolument 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 essayez de démarrer une machine virtuelle sur un autre hôte avant d’exécuter le script ci-dessus, le message d’erreur suivant s’affiche :VDI <UUID> already attached RW.

Échecs principaux

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é, chaque membre attend que le maître revienne.

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 vraiment mort, choisissez l’un des membres et exécutez la commandexe pool-emergency-transition-to-master dessus. Une fois qu’il est devenu le maître, exécutez la commandexe pool-recover-slaves et les membres pointent maintenant vers le nouveau maître.

Si vous réparez ou remplacez le serveur qui était le maître d’origine, vous pouvez simplement le faire apparaître, installer le logiciel hôte et l’ajouter au pool. Puisque les hôtes du pool sont forcés pour être homogènes, il n’est pas vraiment nécessaire de faire du serveur remplacé le maître.

Lorsqu’un hôte membre est transféré à un maître, vous devez également vérifier que le référentiel de stockage de pool par défaut est défini sur une valeur appropriée. Cela peut être fait à l’aide de laxe pool-param-list commande et vérifier que ledefault-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 échouerait, vous devrez recréer la base de données du pool à partir de zéro. Veillez à sauvegarder régulièrement vos métadonnées pool-pool à l’aide de la commandexe pool-dump-database CLI (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 laxe pool-restore-database commande (voir pool-restore-database ).

3. Connectez-vous à l’hôte maître à l’aide et assurez-vous que tous vos stockages et machines virtuelles 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 répertoriée ci-dessous pour récupérer.

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é seront toujours marquées commeRunningdans la base de données. Ceci est pour la 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 àHalted :

  xe vm-reset-powerstate vm = vm_uuid — force Les machines virtuelles peuvent ensuite être redémarrées à l'aide de l'interface de ligne de commande  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éussira que si la machine cible dispose d’un nombre approprié de cartes réseau nommées de manière appropriée.

2. Si la machine cible a une vue différente du stockage (par exemple, un miroir de bloc avec une adresse IP différente) de la machine d’origine, modifiez la configuration de stockage à l’aide de lapbd-destroy commande, puis de lapbd-create commande pour recréer les configurations de stockage. Voir les commandes pbdpour la documentation de ces commandes.

3. Si vous avez créé une nouvelle configuration de stockage, utilisezpbd-plug ou Stockage > Réparer le référentiel de stockage dans 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 = métadonnées de sauvegarde = 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.