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 ?
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 :
- Comment allouer de la mémoire afin qu'elle fonctionne en tant que fichier d'échange dans une instance Amazon EC2 ?
- Comment puis-je allouer de la mémoire sur une partition de mon disque dur pour qu'elle fonctionne comme un espace d'échange sur une instance Amazon EC2 ?
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 :
- Comment résoudre les problèmes liés à une instance Linux EC2 dont le contrôle statut échoue en raison d'une surutilisation des ressources ?
- Comment puis-je augmenter la taille de mon volume EBS si je reçois un message d'erreur indiquant qu'il n'y a plus d'espace libre sur mon système de fichiers ?
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 :
- Comment corriger une erreur « Kernel panic - not syncing » (Panique du noyau - non synchronisation) sur les instances EC2 ?
- Comment puis-je revenir à un noyau stable connu après qu'une mise à jour a empêché mon instance Amazon EC2 de redémarrer correctement ?
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.
Informations connexes
Vidéos associées


Contenus pertinents
- demandé il y a 6 moislg...
- Réponse acceptéedemandé il y a un anlg...
- demandé il y a 2 anslg...
- demandé il y a un anlg...
- demandé il y a 4 moislg...