Comment puis-je récupérer une instance Linux EC2 qui ne démarre pas en raison d'erreurs de disque ?

Lecture de 6 minute(s)
0

Mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) lancée depuis une Amazon Machine Image (AMI) personnalisée présente une erreur de disque.

Brève description

Les erreurs de configuration suivantes dans le fichier fstab entraînent des erreurs de disque pour les instances Amazon EC2 créées à partir d'une AMI personnalisée :

  • ID de périphérique incorrect
  • Nom de chemin incorrect
  • UUID incorrect ou dupliqué

Pour corriger ces erreurs, vous devez accéder au système d'exploitation de l'instance. Si votre instance est inaccessible, utilisez l'une des méthodes suivantes pour y accéder :

  • EC2 Serial Console
  • Une instance de secours pour corriger manuellement les erreurs

Résolution

Utilisez EC2 Serial Console

Si vous avez activé EC2 Serial Console pour Linux, vous pouvez l'utiliser pour résoudre les problèmes des types d'instances basés sur Nitro pris en charge et les instances matériel nu. EC2 Serial Console vous aide à résoudre les problèmes de démarrage et de configuration réseau et SSH. Cette console se connecte à votre instance sans avoir besoin d'une connexion réseau active. Pour accéder à EC2 Serial Console, utilisez la console Amazon EC2 ou l'interface de ligne de commande AWS (AWS CLI).

Si vous utilisez EC2 Serial Console pour la première fois, assurez-vous de passer en revue les prérequis et de configurer l'accès avant d'essayer de vous connecter. Si votre instance est inaccessible et que vous n'avez pas configuré l'accès à EC2 Serial Console, suivez les instructions de la section suivante Utiliser une instance de secours pour corriger manuellement les erreurs. Pour en savoir plus sur la configuration d'EC2 Serial Console, reportez-vous à Configurer l'accès à EC2 Serial Console.

Utilisez une instance de secours pour corriger manuellement les erreurs

Avertissement : La procédure suivante nécessite l'arrêt de l'instance. Les données stockées dans les volumes de stockage de l'instance sont perdues lorsque l’instance est arrêtée. Assurez-vous donc de sauvegarder les données avant d'arrêter l'instance. Contrairement aux volumes basés sur Amazon Elastic Block Store (Amazon EBS), les volumes du stockage d'instances sont éphémères et ne prennent pas en charge la persistance des données.

L'adresse IPv4 publique statique qu'Amazon EC2 a attribuée automatiquement à l'instance lors du lancement ou du démarrage change après l'arrêt et le démarrage. Pour retenir une adresse IPv4 publique qui ne change pas lorsque l'instance est arrêtée, utilisez une adresse IP Elastic.

Pour en savoir plus, reportez-vous à Que se passe-t-il lorsque vous arrêtez une instance.

1.    Utilisez la même AMI que l'instance présentant des erreurs de disque pour lancer une nouvelle instance EC2 dans votre cloud privé virtuel (VPC). Lancez la nouvelle instance dans la même zone de disponibilité que l'instance défaillante. La nouvelle instance devient alors votre instance de secours.

Vous pouvez également utiliser une instance existante qui utilise la même AMI et se trouve dans la même zone de disponibilité que votre instance défaillante.

2.    Arrêtez l'instance défaillante.

3.    Désassociez le volume racine Amazon EBS (/dev/xvda ou /dev/sda1) de votre instance défaillante. Notez le nom du périphérique (/dev/xvda ou /dev/sda1) de votre volume racine.

4.    Associez le volume en tant que périphérique secondaire (/dev/sdf) à l'instance de secours.

5.    Utilisez SSH pour vous connecter à votre instance de secours.

6.    Créez un répertoire de point de montage (/rescue) pour le nouveau volume associé à l'instance de secours :

$ sudo mkdir /rescue

7.    Montez le volume dans le répertoire :

$ sudo mount /dev/xvdf1 /rescue

Remarque : Le périphérique (/dev/xvdf1) peut être associé à l'instance de secours avec un nom de périphérique différent. Pour déterminer les noms de périphériques appropriés, utilisez la commande lsblk pour afficher les périphériques de disque disponibles ainsi que leurs points de montage.

7.    Résoudre le problème du volume :

Exécutez la commande suivante pour vérifier l'entrée fstab :

$ cat /rescue/etc/fstab

L'exemple suivant d'entrée fstab comporte deux volumes :

UUID=47834bf7-764e-42f9-9507-11a3e70b99de / xfs defaults,noatime 1 1
UUID=1b75bcf4-ee55-428e-8d68-88dca398da01 /test xfs defaults,nofail 0 2

Dans l'entrée fstab, vérifiez les configurations suivantes :

  • L'entrée ne contient pas d'ID de périphériques. Des ID de périphériques incorrects entraînent des problèmes et des incohérences. Il est recommandé d'utiliser des UUID plutôt que des identifiants de périphériques. Si les ID de périphériques figurent dans le fichier, remplacez-les par l'UUID du volume. Exécutez la commande suivante pour trouver le bon UUID :

    lsblk -f
  • Assurez-vous que le chemin d'accès au point de montage est correct et qu'il existe dans le volume.

  • Vérifiez qu'il n'existe aucun UUID dupliqué. Vérifiez également que les volumes supplémentaires de l'instance défaillante n'utilisent pas les mêmes UUID. Pour vérifier les UUID des volumes supplémentaires, utilisez les étapes précédentes pour les associer à l'instance de secours. S'il existe des UUID dupliqués, vous ne pouvez pas monter de volumes. D'ailleurs, vous recevez un message d'erreur similaire au suivant :

    mount: /rescue: wrong fs type, bad option, bad superblock on /dev/xvdg1, missing codepage or helper program, or other error

    Exécutez la commande suivante pour vérifier l'UUID des volumes associés :

    $ lsblk -f

    S'il existe des UUID dupliqués, exécutez la commande suivante pour modifier les UUID :

    Pour les systèmes de fichiers XFS :

    $ sudo xfs_admin -U <unique UUID> /dev/xvdb1

    Pour les systèmes de fichiers EXT4 :

    $ tune2fs -U random /dev/sdb1

    Ajoutez également l'option nofail à vos entrées fstab, comme dans l'exemple suivant :

    UUID=aebf131c-6957-451e-8d34-ec978d9581ae /data xfs defaults,nofail 0 2

    Remarque : Si vous démarrez votre instance sans que ce volume spécifique soit associé, l'option de montage nofail permet à l'instance de démarrer même en cas d'erreurs de montage. Par exemple, vous pouvez essayer de démarrer l'instance après avoir déplacé le volume vers une autre instance. Les dérivés de Debian (dont les versions d'Ubuntu antérieures à 16.04) doivent également ajouter l'option de montage nobootwait.

8.    Une fois les erreurs corrigées, enregistrez le fichier, puis exécutez la commande umount pour démonter le volume monté.

$ sudo umount /mnt/rescue

9.    Désassociez le volume de l'instance temporaire.

10.    Associez le volume à l'instance d'origine, puis démarrez-la pour vérifier qu'elle démarre correctement.

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 9 mois