Pourquoi mon instance Linux Amazon EC2 ne démarre-t-elle pas après l'avoir remplacée par une instance basée sur Nitro ?

Brève description

Il est possible qu'une instance EC2 Linux ne démarre pas lorsque vous l'avez remplacée par une instance basée sur Nitro pour les raisons suivantes :

• Vous n'avez pas activé l'attribut de mise en réseau améliorée enaSupport sur l'instance.
• Vous n'avez pas installé le pilote Adaptateur réseau élastique (ENA) sur l'instance.
• Vous n'avez pas installé le pilote NVMe sur l'instance. Ou bien vous n'avez pas chargé le module NVMe dans l'image initramfs de l'instance.
• Vous avez utilisé un nom de périphérique pour monter les systèmes de fichiers dans le fichier /etc/fstab au démarrage à la place d'un UUID.<br id=hardline_break/> Remarque : les volumes Amazon Elastic Block Store (Amazon EBS) apparaissent sous la forme de périphériques NVMe pour les instances basées sur Nitro. Cette configuration modifie les noms des périphériques.

Pour résoudre les problèmes de démarrage, redéfinissez le type d'instance en instance Xen. Puis, utilisez le dossier d'exploitation AWSSupport-MigrateXentonitroLinux pour préparer automatiquement votre instance à la migration. Vous pouvez également vérifier et corriger manuellement les prérequis manquants. Enfin, définissez le type d'instance sur une instance Nitro.

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.

Remplacer le type d'instance par Xen

Important : pour modifier les types d'instances, vous devez arrêter et démarrer l'instance.

Configurer votre instance pour un arrêt et un démarrage

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 vous utilisez Amazon Route 53, vous devrez peut-être mettre à jour les enregistrements DNS Route 53 lorsque l'adresse IP publique change.

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

• Si votre instance utilise un stockage d'instances, enregistrez les données de volume du stockage d'instances dans un stockage persistant. Par exemple, vous pouvez enregistrer les données dans des volumes Amazon EBS ou des compartiments Amazon Simple Storage Service (Amazon S3).<br id=hardline_break/> Important : Amazon EC2 supprime les données du stockage d'instances lorsque vous arrêtez l'instance.
• Créez un instantané de votre volume EBS. Si vous rencontrez des problèmes, vous pouvez utiliser l’instantané pour restaurer votre instance.
• Supprimez temporairement l'instance de son groupe Amazon EC2 Auto Scaling afin de ne pas résilier accidentellement l'instance lorsque vous l'arrêtez.<br id=hardline_break/> Remarque : EC2 Auto Scaling peut résilier les instances arrêtées dans un groupe Auto Scaling en fonction de vos paramètres de protection évolutive. 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.

Modifier le type d'instance

Redéfinissez l'instance sur le type d'instance Xen pour vous assurer qu'elle peut démarrer.

Préparer automatiquement votre instance pour la migration

Pour mettre à jour automatiquement votre instance afin qu'elle réponde aux prérequis pour migrer vers Nitro, exécutez le dossier d'exploitation AWSSupport-MigrateXenToNitroLinux.

Vérifier les prérequis avant de procéder à la migration

Exécutez le script nitro_check_script.sh pour vérifier les prérequis avant de changer le type d'instance à Nitro. Pour accéder au script, consultez la page nitro_check_script.sh sur le site Web de GitHub. Pour plus d'informations sur les éléments vérifiés par le script, consultez la page NitroInstanceChecks sur le site Web de GitHub.

Pour télécharger le script nitro_check_script.sh, exécutez la commande suivante :

sudo wget https://raw.githubusercontent.com/awslabs/aws-support-tools/refs/heads/master/EC2/NitroInstanceChecks/nitro_check_script.sh -O /tmp/nitro_check_script.sh

Pour autoriser votre environnement à exécuter le script, exécutez la commande suivante :

sudo chmod +x /tmp/nitro_check_script.sh

Pour exécuter le script avec les autorisations racine, exécutez la commande suivante :

sudo bash /tmp/nitro_check_script.sh

Remarque : vous devez exécuter le script en tant qu'utilisateur racine ou avec sudo. Sinon, le message d'erreur « This script must be run as root » s'affiche.

Sur la base de la sortie du script, effectuez les actions suivantes.

Vérifier que vous avez activé la mise en réseau améliorée et que vous avez installé le pilote ENA

Vérifiez si vous avez activé la mise en réseau améliorée sur votre instance. Si la mise en réseau améliorée n'est pas activée, activez-la.

Pour vérifier si vous avez installé le pilote ENA, exécutez la commande suivante :

sudo modinfo ena |grep -i '^version:' || echo "ENA module not available, try modprobe ena"

Si vous n'avez pas installé le pilote ENA, installez le pilote le plus récent. Pour obtenir des instructions, consultez la page Pilote du noyau Linux pour la famille d’adaptateurs réseau élastiques (ENA) sur le site Web de GitHub.

Installer le pilote NVMe

Pour accéder aux volumes NVMe, vous devez installer les pilotes NVMe.

Vérifier si vous avez utilisé un nom d’appareil pour les points de montage dans le fichier /etc/fstab

Procédez comme suit :

1. Pour vérifier si vous avez utilisé un UUID, exécutez la commande suivante :

   cat /etc/fstab |grep -iP 'uuid|dev/'

   Exemple de sortie :

   /dev/nvme0n1p1 / xfs defaults,noatime 1 1

   Remarque : l'exemple de sortie utilise un nom de périphérique à la place d'un UUID.

2. Si vous n'avez pas utilisé d'UUID, exécutez la commande suivante pour récupérer l'UUID correspondant au nom de l'appareil :

   lsblk -f device_name |tail -n 1 |awk '{print $4}'

   Remarque : remplacez device_name par le nom de votre périphérique.

3. (Facultatif) Avant de modifier le fichier /etc/fstab, il est recommandé d'exécuter la commande suivante pour créer une copie du fichier :

   sudo cp /etc/fstab /etc/fstab-`date +%d%m%Y`

4. Exécutez la commande suivante pour ouvrir le fichier /etc/fstab :

   cat /etc/fstab

5. Dans le fichier, remplacez le nom du périphérique par l'UUID.<br id=hardline_break/> Exemple de fichier :

   /dev/nvme0n1p1 / xfs defaults,noatime 1 1

   Remarque : remplacez /dev/nvme0n1p1 par l'UUID. Assurez-vous de remplacer tous les noms de périphériques du fichier /etc/fstab par l'UUID.

6. Pour vérifier que vous avez correctement mis à jour le fichier, réexécutez la commande suivante :

   cat /etc/fstab

   Dans la sortie, vérifiez si l'UUID affiche l'UUID.<br id=hardline_break/> Exemple de sortie :

   UUID=123456-1234-1234-acbd-1234abc1234 / xfs defaults,noatime 1 1

Redéfinir le type d'instance sur Nitro

Modifiez l'instance à une instance basée sur Nitro.

Remarque : si vous effectuez une mise à niveau vers la dernière instance de Nitro et que vous utilisez un noyau ou un pilote obsolète, la vérification de statut de l'instance peut échouer. Par conséquent, des échecs de démarrage et des erreurs de type « kernel panic » se produisent, ou votre instance devient inaccessible. Pour résoudre ce problème, consultez la section Comment résoudre l'erreur « Kernel panic - not sync » dans mon instance EC2 ?