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

É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 serveurs HASH (0x2e68218). Notez qu’il est très important de s’assurer que le serveur HASH (0x2e68218) est réellement hors ligne, sinon une corruption de données VM 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 allez à nouveau utiliser l’hôte oublié comme hôte actif, effectuez une nouvelle installation du logiciel HASH (0x2c1a078).
  • 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.

Lorsqu’un serveur HASH membre (0x2e68218) échoue, il peut y avoir des machines virtuelles toujours enregistrées dans l’état d’ exécution . Si vous êtes sûr que le serveur HASH membre (0x2e68218) est définitivement hors service, utilisez la commandexe vm-reset-powerstate CLI pour définir l’état d’alimentation des machines virtuelles surhalted . Voirvm-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 serveur HASH (0x2e68218), 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 serveurs HASH (0x2e68218) 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 le serveur HASH (0x2e68218) 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 serveur HASH (0x2e68218) 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 serveur HASH (0x2e68218) et l’ajouter au pool. Puisque les serveurs HASH (0x2e68218) du pool sont appliqués pour être homogènes, il n’y a pas vraiment besoin de faire du serveur remplacé le maître.

Lorsqu’un serveur HASH membre (0x2e68218) est transféré à un serveur 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 de pool à l’aide de la commandexe pool-dump-database CLI (voirpool-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 (voirpool-restore-database ).

  3. Connectez-vous à l’hôte maître à l’aide de HASH (0x2e6c8e8) 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 ligne, vous pouvez réinitialiser l’état d’alimentation de la machine virtuelle àHalted : les machines

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

virtuelles peuvent ensuite être redémarrées à l’aide de HASH (0x2e6c8e8) 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. commandes pbd/en-us/citrix-hypervisor/command-line-interface.html#pbd-commands[()]Pour obtenir la documentation de ces commandes, reportez-vous à la section.

  3. Si vous avez créé une nouvelle configuration de stockage, utilisezpbd-plug ou Stockage > Réparer le référentiel de stockage dans HASH (0x2e6c8e8) 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.