Complete a 3 Question Survey and Earn a re:Post Badge

Help improve AWS Support Official channel in re:Post and share your experience - complete a quick three-question survey to earn a re:Post badge!

Pourquoi mon instance Linux EC2 est-elle inaccessible et échoue-t-elle à ses vérifications d'état ?

Lecture de 10 minute(s)

Mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) est inaccessible et échoue à ses vérifications d'état.

Brève description

Amazon EC2 utilise trois vérifications d'état pour surveiller l'état des instances EC2 :

Surveillance de l'état du système

La surveillance de l'état du système détecte les problèmes liés au matériel sous-jacent d'une instance. Si le matériel sous-jacent ne répond pas ou est inaccessible en raison de problèmes réseau, matériels ou logiciels, la surveillance de l'état du système échoue.

Surveillance de l'état de l'instance

Un échec de surveillance de l'état de l'instance indique que l'instance est inaccessible. Les problèmes suivants peuvent entraîner l'échec de surveillance de l'état de l'instance :

Échec de démarrage du système d'exploitation.
Impossible de monter correctement les volumes.
Processeur et mémoire épuisés.
Panique du noyau.
Défaillance du réseau.

Avertissement : Certaines des résolutions suivantes nécessitent l'arrêt et le démarrage d'une instance. Avant d'arrêter et de redémarrer votre instance, prenez en compte ces conditions :

Les données stockées dans les volumes de stockage de l'instance sont perdues lorsque l'instance est arrêtée. Avant d'arrêter l'instance, assurez-vous de sauvegarder les données. Contrairement aux volumes basés sur Amazon Elastic Block Store (Amazon EBS), les volumes du stockage d'instances 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 conserver une adresse IPv4 publique qui ne change pas lorsque l'instance est arrêtée, utilisez une adresse IP Elastic.

Pour en savoir plus, consultez la section Arrêter et démarrer des instances Amazon EC2.

Vérifications de l’état d’EBS attaché

Les vérifications de l'état d’EBS attaché permettent de vérifier que les volumes Amazon EBS attachés à une instance sont accessibles et capables d'effectuer des opérations d'I/O. Pour plus d'informations, consultez la section ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html#attached-ebs-status-checks)Vérifications de l’état d’EBS attaché[.

Résolution

Pour déterminer si la surveillance de l'état de l'instance ou du système a échoué, consultez les métriques de surveillance de l’état de l’instance.

Si la surveillance de l'état du système a échoué, consultez la section Pourquoi mon instance Linux EC2 a échoué à la surveillance de l'état du système ?

Si la surveillance de l'état de l'instance a échoué, consultez les journaux système de l'instance pour connaître la cause de l'échec. Puis, utilisez l'une des résolutions suivantes pour résoudre le problème.

Impossible de démarrer le système d'exploitation

Si les journaux du système contiennent des erreurs de démarrage, consultez Comment résoudre les problèmes liés à une instance Linux EC2 dont la vérification de l'état de l'instance a échoué en raison de problèmes liés au système d'exploitation ?

Impossible de monter correctement les volumes

Une défaillance du point de montage peut entraîner l'échec de surveillance de l'état de l'instance. Exemple de commande de défaillance du point de montage :

[FAILED] Failed to mount /
See 'systemctl status mnt-nvme0n1p1.mount' for details.
[DEPEND] Dependency failed for Local File Systems.

Pour plus d'informations, consultez les articles suivants du centre de connaissances AWS :

Erreurs « Échec de dépendance » : Pourquoi mon instance Linux EC2 passe-t-elle en mode d'urgence lorsque j'essaie de la démarrer ?
Erreurs « Échec de montage » ou « Échec de dépendance » : Comment puis-je résoudre les problèmes liés à une instance Linux EC2 qui a échoué à la surveillance de l'état de l'instance en raison de problèmes liés au système d'exploitation ?

Lorsque vous changez le type d'instance d'une instance Xen à une instance basée sur Nitro, le montage du volume peut échouer. Un échec de montage se produit parce que les volumes Amazon EBS sont exposés en tant que périphériques de stockage en mode bloc NVMe sur des instances basées sur Nitro. Par exemple, les noms des périphériques sont /dev/nvme0n1 et /dev/nvme1n1. Les noms de périphériques que vous spécifiez dans un mappage de périphériques de stockage en mode bloc sont renommés en noms de périphériques NVMe (/dev/nvme[0-26]n1).

Remarque : Le pilote de périphérique de stockage en mode bloc peut attribuer les noms des périphériques NVMe dans un ordre différent de celui que vous avez spécifié dans le mappage de périphérique de stockage en mode bloc. Pour éviter l'échec de montage sur les instances basées sur Nitro, il est recommandé d'utiliser une étiquette ou un UUID pour les noms de périphériques. Pour plus d'informations, consultez la section Rendre un volume Amazon EBS accessible à l’utilisation.

Processeur et mémoire épuisés

Taux d'utilisation élevé du processeur

Si la métrique CPUUtilization est égale à ou proche de 100 %, l’instance ne dispose pas d’une capacité de calcul suffisante pour exécuter le noyau.

Pour les instances T2 ou T3, vérifiez les métriques de crédit du processeur Amazon CloudWatch pour déterminer si les crédits UPC sont égaux ou proches de zéro. Si les crédits du processeur sont nuls, la métrique CPUUtilization indique un plateau de saturation par rapport aux performances de base de l'instance. Par exemple, la performance de base peut être de 20 % ou 40 %. Une utilisation de processeur égale ou proche de 100 % indique que la surveillance de l'état a échoué en raison d'une utilisation excessive des ressources. Les instances T2 ou T3 qui ont atteint un plateau de saturation indiquent que la surveillance de l'état a échoué en raison d'une utilisation excessive.

Pour résoudre ce problème, consultez la section Comment puis-je résoudre les problèmes liés à une instance Linux EC2 dont le statut échoue en raison d'une utilisation excessive des ressources ?

Les erreurs de périphériques de stockage en mode bloc, les bogues logiciels ou la panique du noyau peuvent provoquer une augmentation inhabituelle de l'utilisation du processeur. Si l'utilisation du processeur est de 100 %, consultez d’abord les journaux système pour détecter des erreurs de périphérique de stockage en mode bloc ou de mémoire ou toute autre erreur système inhabituelle. Puis, redémarrez ou arrêtez et démarrez l'instance.

Mémoire insuffisante

Une charge de mémoire élevée peut entraîner l'échec de surveillance de l'état de l'instance. Dans l'exemple d'extrait de journal suivant, la mémoire du système d'exploitation est insuffisante et la mise à mort sur mémoire saturée est lancée. Pour résoudre cette erreur, arrêtez le processus qui consomme le plus de mémoire.

[115879.769795] Out of memory: kill process 20273 (httpd) score 1285879 or a child
[115879.769795] Killed process 1917 (php-cgi) vsz:467184kB, anon-rss:101196kB, file-rss:204kB

Par défaut, les métriques de mémoire et de disque de l'instance EC2 ne sont pas envoyées à Amazon CloudWatch. Pour plus d'informations, consultez la section Collecter des métriques, des journaux et des traces avec l'agent CloudWatch.

Pour résoudre le problème de mémoire insuffisante, mettez à niveau l'instance vers un type d'instance plus grand. Vous pouvez également ajouter du stockage de swap à l'instance pour réduire la charge de mémoire. Pour plus d'informations, consultez les articles suivants du centre de connaissances AWS :

Erreurs de saturation du disque

Si les journaux système contiennent des erreurs de saturation du disque, cela signifie que l'instance est en mode d'urgence en raison d'un périphérique racine complet.

Exemple de journal système :

$: sudo service apache2 restart
Error: No space left on device

$: sudo /etc/init.d/mysql restart
[....] Restarting mysql (via systemctl):
mysql.serviceError: No space left on device

$: df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.7G  7.7G     0 100% /

Pour obtenir des instructions détaillées sur le dépannage et la résolution des erreurs de saturation du disque, consultez les articles suivants du centre de connaissances :

Panique du noyau

La panique du noyau se produit lorsque le noyau détecte une erreur fatale interne en cours de fonctionnement. Si l'erreur se produit lors du démarrage du système d'exploitation, cela signifie que le noyau ne s'est pas chargé correctement. Cet échec de chargement du noyau entraîne un échec du démarrage de l'instance.

Exemple de message d'erreur de panique du noyau :

Linux version
2.6.16-xenU (builder@xenbat.amazonsa) (gcc version 4.0.1 20050727 (Red Hat4.0.1-5)) #1 SMP Mon May 28 03:41:49 SAST 2007
Kernel command
line:  root=/dev/sda1 ro 4
Registering block device major 8
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Pour plus d'informations sur le dépannage et la résolution d'une erreur de panique du noyau, consultez les articles suivants du centre de connaissances :

Défaillance du réseau

Votre réseau peut tomber en panne pour les raisons suivantes :

Le package cloud-init n'est pas installé sur l'instance
Le package cloud-init est utilisé pour mettre à jour les configurations réseau au lancement.

Pour corriger cette erreur pour installer le package cloud-init sur votre instance, exécutez la commande suivante :

Pour les systèmes d'exploitation Amazon, Amazon Linux 2, Amazon Linux 2023 ou RedHat :

$ sudo yum install cloud-init -y

Pour les systèmes d'exploitation Ubuntu ou Debian :

$ sudo apt install cloud-init -y

L'adresse MAC est codée en dur dans un fichier de configuration

Les adresses MAC codées en dur se trouvent dans les fichiers de configuration Linux et dans les fichiers de configuration udev. Les fichiers suivants se trouvent aux emplacements suivants :

/etc/udev/rules.d/
/etc/udev/rules.d/70-persistent-net.rules
/etc/udev/rules.d/80-net-name-slot.rules

Pour résoudre les problèmes réseau causés par une adresse MAC codée en dur, supprimez les entrées ou les fichiers de configuration, puis exécutez la commande suivante :

$ sudo mv /etc/udev/rules.d/70-persistent-net.rules /root/

Une fois le fichier de configuration déplacé, redémarrez le service réseau pour vous assurer qu'une nouvelle adresse MAC est reçue.

L'adresse IP est codée en dur dans un fichier de configuration du réseau

Lorsque vous créez une Amazon Machine Image (AMI) à partir d'une instance avec une adresse IP configurée de manière statique, le fichier de configuration contient une adresse IP codée en dur. Pour corriger cette erreur, configurez votre interface réseau pour qu'elle utilise le protocole DHCP.

Remarque : Vous ne pouvez pas mettre à jour les AMI qui existent déjà. Vous devez configurer l'interface réseau pour qu'elle utilise le protocole DHCP avant de créer une nouvelle AMI.

Des pilotes réseau ENA ou Intel améliorés sont manquants

Pour plus d'informations sur les adaptateurs réseau élastique (ENA) ou les pilotes réseau améliorés Intel manquants, consultez la section Mise en réseau améliorée sur les instances Amazon EC2.

**L'interface réseau est automatiquement renommée au démarrage **

Pour désactiver le changement de nom prévisible de l'interface réseau, ajoutez net.ifnames=0 à la ligne de commande du noyau. Pour utiliser l'espace réservé, vous devez activer la mise en réseau améliorée avec l'ENA et recréer ou mettre à jour le fichier de configuration grub.