Pourquoi mon instance Linux EC2 est-elle inaccessible et échoue-t-elle à l'une de ses vérifications d'état ou aux deux ?

Brève description

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

Vérification de l'état du système

La vérification 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 vérification de l'état du système échoue.

Vérification de l'état de l'instance

Un échec de la vérification de l'état de l'instance indique que l'instance est inaccessible. Les problèmes courants suivants entraînent l'échec de la vérification 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 démarrer votre instance, tenez compte des conditions suivantes :

• 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 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 conserver une adresse IPv4 publique qui ne change pas si l'instance est arrêtée, utilisez une adresse IP élastique.

Pour plus d'informations, consultez la section Conditions préalables à l'arrêt d'une instance.

Résolution

Pour déterminer si le contrôle de l'état de l'instance ou du système a échoué, consultez les mesures de vérification du statut de l'instance.

Si la vérification de l'état du système a échoué, consultez la section Mon instance Linux EC2 a échoué à la vérification de l'état du système. Comment puis-je résoudre ce problème ?

Si la vérification de l'état de l'instance a échoué, consultez les journaux système de l'instance pour déterminer la cause de l'échec. Utilisez ensuite 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 la vérification de l'état de l'instance.

Exemple 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 résoudre les problèmes liés à une instance Linux EC2 qui a échoué à la vérification 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 de Xen à Nitro, le montage du volume peut échouer. L'échec du 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. Les noms des périphériques sont /dev/nvme0n1, /dev/nvme1n1, etc. 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). 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 l'ordre d'origine que vous avez spécifié dans le mappage de périphérique de stockage en mode bloc. Pour éviter l'échec du 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 Rendre un volume Amazon EBS disponible pour une utilisation sous Linux.

Processeur et mémoire épuisés

Taux d'utilisation élevé du processeur

Si la métrique CPUUtilization est égale à ou proche de 100 %, il est possible que la capacité de calcul de l'instance ne soit pas suffisante pour exécuter le noyau.

Pour les instances T2 ou T3, vérifiez les indicateurs 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. Les performances de référence peuvent être de 20 %, 40 %, etc., selon le type d'instance.

L'utilisation du processeur à 100 % ou presque, ou à un plateau de saturation pour les instances T2 ou T3, indique que la vérification d'état a échoué en raison d'une surutilisation des ressources. Pour résoudre ce problème, consultez la section Mon instance Linux EC2 a échoué à la vérification de l'état de l'instance en raison d'une surutilisation de ses ressources. Comment puis-je résoudre ce problème ?

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 le taux d'utilisation du processeur est de 100 %, consultez les journaux du système pour détecter toute erreur de périphérique de stockage en mode bloc ou de mémoire ou toute autre erreur système inhabituelle. Ensuite, 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 la vérification de l'état de l'instance. Dans l'exemple d'entrée de journal suivant, la mémoire du système d'exploitation est insuffisante. 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. Cependant, vous pouvez utiliser l'agent CloudWatch pour collecter et surveiller des métriques supplémentaires.

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 pour qu'elle fonctionne comme espace d'échange sur une instance Amazon EC2 à l'aide d'un fichier d'échange ?
• 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 disque plein

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 :

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

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


root@example:~# 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 AWS :

• Mon instance Linux EC2 a échoué à la vérification de l'état de l'instance en raison d'une utilisation excessive de ses ressources. Comment puis-je résoudre ce problème ?
• Comment 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 pendant le démarrage du système d'exploitation, le noyau risque de ne pas se charger correctement. Cela provoque un échec du démarrage du système d'exploitation.

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 AWS :

• Pourquoi le message d'erreur « Kernel panic » s'affiche-t-il après la mise à niveau du noyau ou le redémarrage de mon instance Linux 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

Les raisons courantes suivantes peuvent provoquer une défaillance de votre réseau.

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, exécutez la commande suivante pour installer le package cloud-init sur votre instance :

$ sudo yum install cloud-init

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. Ces fichiers se trouvent généralement dans les 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. Par exemple, exécutez la commande suivante :

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

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

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 peut contenir 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 existantes. 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 sous Linux.

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

Pour résoudre ce problème, ajoutez net.ifnames=0 à la ligne de commande du noyau afin de désactiver les noms d'interface réseau prévisibles. Pour utiliser la variable, vous devez activer la mise en réseau améliorée avec l'ENA.

Pour plus d'informations sur les problèmes liés au réseau, consultez la section Bonnes pratiques de configuration des interfaces réseau.

Informations connexes

Résoudre les problèmes liés à des instances dont les vérifications d'état ont échoué

Pourquoi mon instance Windows EC2 ne fonctionne-t-elle pas en raison d'un échec de la vérification de l'état du système ou d'une vérification d'état 0/2 ?

Pourquoi mon instance Windows EC2 est-elle en panne en raison d'un échec de la vérification de l'état de l'instance ?

Types de vérifications d'état