Pourquoi mon instance Linux EC2 migre-t-elle alors que le service de migration des applications ou la reprise après sinistre ne répond pas aux vérifications de l'état de l'instance ?

Résolution

Remarque : La résolution suivante inclut les raisons les plus courantes des échecs de vérification de l'état des instances. Les serveurs de conversion du service de migration d'applications modifient le chargeur de démarrage, injectent des pilotes d'hyperviseur et installent des outils cloud. Si le type d'instance est correctement dimensionné, les échecs de vérification de l'état de l'instance en cas d'épuisement de la mémoire sont rares. Les systèmes de fichiers endommagés apparaissent généralement sur l'ordinateur source.

Lorsque vous résolvez l'échec de la vérification de l'état de l'instance, gardez à l'esprit le processus de démarrage de Linux lorsque vous vérifiez les points suivants :

• Point de terminaison Amazon Elastic Compute Cloud (Amazon EC2
• Sortie de la console d'instance

L'ordre de démarrage typique est le suivant : Allumer - démarrer l'auto-test (POST) - BIOS/UEFI - Master boot Record/EFI - Boot Loader - Kernel (et initramfs)

La séquence de démarrage peut différer selon les systèmes d'exploitation.

Configuration de démarrage incorrecte

L'instance n'a pas pu atteindre le chargeur de démarrage (GRUB)

L'erreur suivante se produit si l'instance ne parvient pas à atteindre le chargeur de démarrage (GRUB) :

No bootable device. Retrying in 60 seconds.

Booting from hard disk 0...

Pour résoudre l'erreur précédente, vérifiez les points suivants :

• La partition de démarrage a été migrée depuis le serveur source.
  Les étapes d'analyse de la partition de démarrage varient en fonction de votre système d'exploitation. Consultez la documentation de votre système d'exploitation pour plus d'informations.
  Vous pouvez créer une instance de secours pour vérifier la partition. Pour en savoir plus, voir la **Méthode 3 : La correction manuelle des erreurs à l'aide d'une instance de secours ** dansMon instance Linux EC2 a échoué à la vérification de l'état de l'instance en raison de problèmes liés au système d'exploitation. Comment résoudre ce problème ?
• Si le serveur source dispose d'un partitionnement GPT, vérifiez que les modules grub2-pc sont installés.

Une invite GRUB semblable à la suivante peut s'afficher en cas de problème avec un fichier de configuration GRUB (grub.cfg) :

grub>

Une capture d'écran de la console d'instance indiquant que le démarrage est toujours dans le chargeur de démarrage GRUB indique un problème avec le fichier grub.cfg. Le fichier grub.cfg est généralement situé dans /boot/grub2/grub.cfg, /boot/grub/grub.cfg ou /boot/grub/grub.conf.

Noyau incompatible

Problèmes avec le noyau ou les pilotes

Si les erreurs GRUB décrites dans la section précédente ne sont pas détectées, dépannez le noyau et les pilotes.

Plateforme Xen :

Les types d'instances de génération précédente (m4, c4, r4) s'exécutent sur la plateforme Xen. Les systèmes d'exploitation exécutés sur cette plate-forme nécessitent des pilotes xen-blkfront et xen-netfront. Si ces deux pilotes ne sont pas installés, la vérification de l'état de l'instance échoue. Cet échec peut apparaître sous la forme de lecteurs manquants dans la sortie de la console, comme illustré dans l'exemple suivant :

[ ***] dracut-initqueue[679]: Warning: dracut-initqueue timeout - starting timeout scripts

L'échec précédent se produit si le fichier initramfs ne dispose pas des pilotes requis.

En cas d’erreurs liées à initramfs ou au noyau, reconstruisez le fichier initramfs. Pour plus d'informations, voir Je reçois un message d'erreur « Kernel panic » après avoir mis à niveau le noyau ou essayé de redémarrer mon instance Linux EC2

Instances basées sur Nitro :

Les instances basées sur Nitro nécessitent à la fois des pilotes NVME (pour les volumes EBS) et des pilotes ENA (pour les interfaces réseau). L'absence de ces deux pilotes entraîne l'échec de la vérification de l'état de l'instance. Cet échec peut apparaître sous la forme de lecteurs manquants dans la sortie de la console, comme illustré dans l'exemple suivant :

[***   ] A start job is running for dev-disk...e2.device (12min 17s / no limit)

Pour plus d'informations sur la résolution de l'erreur précédente, consultez Pourquoi mon instance Linux ne démarre-t-elle pas après avoir remplacé son type par un type d'instance basé sur Nitro ?

Configuration réseau incorrecte

Il existe de nombreuses configurations réseau pour les serveurs sources. Les responsables en amont des applications utilisées pour gérer ces configurations disposent d'une documentation détaillée sur leur configuration. Si vous soupçonnez un problème de configuration réseau, accédez à l'instance et vérifiez la configuration. Utilisez pour cela l'une des méthodes suivantes décrites dans Pourquoi mon instance Linux EC2 ne démarre-t-elle pas et passe en mode d'urgence:

• Méthode 1 : Utiliser l'EC2 Serial Console
• Méthode 2 : Exécutez le document d'automatisation EC2Rescue d'AWS Support-Execute
• Méthode 3 : Modifiez manuellement le fichier au moyen d'une instance de secours

Les outils de gestion de configuration réseau courants sont les suivants :

• Canonical Netplan sur le site netplan.io.
• openSUSE/Wicked sur le dépôt GitHub d'openSUSE/Wicked.
• Network Manager - Red Hat Enterprise Linux 6 sur le portail client Red Hat.
• Network Manager - Red Hat Enterprise Linux 7 sur le portail client Red Hat.
• Network Manager - Red Hat Enterprise Linux 8 sur le portail client Red Hat.
• Bonnes pratiques en matière de configuration des interfaces réseau

Informations connexes

Mon instance Linux EC2 a échoué à la vérification de l'état de l'instance en raison de problèmes liés au système d'exploitation. Comment résoudre ce problème ?

Contrôles de l'état du système