Comment résoudre les échecs de vérification de l'état d'une instance sur mon instance Amazon Windows EC2 après un basculement vers Application Migration Service ou un lancement de test ?

Brève description

Lorsqu'une vérification de l’état d’un système ou d'une instance échoue, les instances EC2 deviennent inaccessibles. Une fois que vous avez utilisé Application Migration Service pour un basculement ou un lancement de test, les vérifications de l'état des instances peuvent échouer pour l’une ou plusieurs des raisons suivantes :

• Échec de démarrage du système d'exploitation
• Défaillance du réseau
• Processeur et mémoire épuisés
• Problèmes liés au processus de conversion
• Types d'instances qui ne sont pas compatibles avec le système d'exploitation

Remarque : Le premier démarrage des machines Windows peut prendre jusqu'à 45 minutes, délai pendant lequel Windows s'adapte au matériel virtuel AWS.

Résolution

Remarque : Si des erreurs surviennent lorsque vous exécutez des commandes de l'interface de la ligne de commande AWS (AWS CLI), consultez la section Résoudre des erreurs liées à l’AWS CLI. Vérifiez également que vous utilisez bien la version la plus récente de l'AWS CLI.

Vérifiez que la machine source est compatible avec le type d'instance sélectionné dans le modèle de lancement.

Connectez-vous à votre machine source, puis utilisez l'une des méthodes suivantes pour vérifier la version de votre système d'exploitation :

Choisissez Panneau de configuration, puis Paramètres du système. Vérifiez l'édition de Windows et le type de système pour vérifier si le système d'exploitation est 32 bits ou 64 bits.

En tant qu'administrateur, exécutez la commande suivante dans une fenêtre d'invite de commande :

systeminfo

La sortie de commande liste le nom du système d’exploitation et le type de système.

Si votre machine source est 32 bits, vous devez utiliser l'un des types d'instances suivants :

• t2.nano
• t2.micro
• t2.small
• t2.medium
• c3. large
• t1. micro
• m1.small
• m1.medium
• c1.medium

Si votre machine source est en 64 bits et exécute Windows Server 2008 R2 ou une version ultérieure, vous pouvez utiliser n'importe quel type d’instance.

Si votre machine source est en 64 bits et exécute l'une des éditions Windows suivantes, migrez vers un type d'instance XEN :

• Windows Server 2003
• Windows Server 2003 R2
• Windows Server 2008

Pour obtenir la liste complète des types d'instances XEN, exécutez la commande d'interface de ligne de commande AWS describe-instance-types suivante :

aws ec2 describe-instance-types --filters Name=hypervisor,Values=xen --query InstanceTypes[].InstanceType

Désactiver ou supprimer un antivirus tiers sur la machine source

Un logiciel antivirus tiers peut interférer avec le processus de conversion. Désactivez ou supprimez le logiciel antivirus, puis relancez l'instance.

Attacher une interface réseau Elastic secondaire

Un pare-feu tiers peut bloquer la connectivité sur la carte réseau principale de l'instance. Cela entraîne l'échec des vérifications de l'état de l'instance cible. Pour éviter ce problème, attachez une interface réseau Elastic secondaire à l'instance cible, puis connectez-vous à l'instance.

Utiliser différents types d'instances

Les instances XEN utilisent des pilotes paravirtuels (PV), alors que les instances Nitro utilisent les pilotes Elastic Network Adapter (ENA) et AWS NVMe. Pour obtenir la liste des pilotes utilisés par chaque type d'instance, consultez la section Compatibilité pour modifier le type d'instance.

Si votre machine source est compatible à la fois avec XEN et Nitro, lancez une instance XEN et une instance Nitro. Si l'instance cible réussit les vérifications de l’état en tant que type d'instance mais pas en tant qu'autre, redimensionnez l'instance. Vérifiez si l'instance redimensionnée réussit ses vérifications d’état.

Si le problème est lié au pilote, exécutez le dossier d’exploitation d’automatisation AWSSupport-UpgradeWindowsAWSDrivers pour forcer l'installation du pilote.

Consulter les journaux de l'instance

Important : Avant d'arrêter et de démarrer votre instance, effectuez les actions suivantes :

• Créez un instantané de votre volume Amazon Elastic Block Store (Amazon EBS).
  Remarque : Si votre instance est sauvegardée par un stockage d'instances ou si ses volumes de stockage d'instances contiennent des données, Amazon EC2 supprime les données lorsque vous arrêtez l'instance.
• Supprimez temporairement l'instance de son groupe Amazon EC2 Auto Scaling.
  Remarque : Si vous arrêtez une instance qui se trouve dans un groupe Auto Scaling Amazon EC2, vous pouvez la résilier en fonction de vos paramètres de protection de réduction horizontale. Les instances que vous lancez avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe Auto Scaling.
• Définissez le comportement d'arrêt de l'instance** sur **Arrêter pour vous assurer que les instances ne se résilient pas lorsque vous les arrêtez.

Remarque : Lorsque vous arrêtez et démarrez une instance, son adresse IP publique change. Une bonne pratique consiste à utiliser une adresse IP Elastic pour acheminer le trafic externe vers votre instance au lieu d'une adresse IP publique.

Si votre nouvelle instance ne réussit jamais les vérifications d'état, consultez les journaux d'instance suivants pour en déterminer la cause.

• C:\Program Files (x86)\AWS Replication Agent\migrate_script.log
• C:\Program Files (x86)\AWS Replication Agent\migrate_script.log.sent
• C:\Program Files (x86)\AWS Replication Agent\aws_nvme\awsnvme_dism.log
• C:\Program Files (x86)\AWS Replication Agent\ena_2012R2_2016\ena_dism.log
• C:\Program Files (x86)\AWS Replication Agent\PVinstall.log
• C:\Windows\inf\setupapi.dev.log
• C:\Windows\inf\setupapi.offline.log
• C:\Program Files (x86)\AWS Replication Agent\SSMInstall.log

Procédez comme suit pour accéder aux journaux :

1. Arrêtez l'instance cible.
2. Dissociez le volume EBS racine de l'instance arrêtée.
3. Associez le volume racine EBS à une instance à laquelle vous pouvez accéder en tant que lecteur secondaire.
4. Rendez le volume EBS disponible pour une utilisation.
5. Rassemblez les journaux des emplacements précédents, puis examinez-les pour déterminer les causes possibles de l'échec de vérification de l'état de l'instance.
   Remarque : Il se peut que tous les journaux précédents ne soient pas présents sur l'instance cible. Lorsque vous utilisez cette méthode, le mappage des lettres du lecteur peut différer des emplacements des journaux répertoriés car vous utilisez un lecteur secondaire plutôt que C:\.

Si les étapes précédentes de résolution de problèmes ne résolvent pas le problème, créez un dossier de support.

Informations connexes

systeminfo sur le site Web de Microsoft

Résoudre les problèmes liés aux instances Amazon EC2