Pourquoi mon instance Linux EC2 est-elle inaccessible et pourquoi une ou les deux vérifications de son statut échouent-elles ?

Date de la dernière mise à jour : 07/09/2022

Mon instance Linux Amazon Elastic Compute Cloud (Amazon EC2) est inaccessible et une ou les deux vérifications de son statut échouent.

Brève description

Amazon EC2 surveille l'état de chaque instance EC2 via deux vérifications de statut :

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

La vérification du statut du système détecte les problèmes liés à l'hôte sous-jacent sur lequel votre instance s'exécute. Si l'hôte sous-jacent ne répond pas ou est inaccessible en raison de problèmes réseau, matériels ou logiciels, cette vérification de statut échoue.

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

L'échec de la vérification du statut de l'instance indique un problème lié à l'accessibilité de l'instance. Ce problème se produit en raison d'erreurs au niveau du système d'exploitation, telles que les suivantes :

  • Échec du démarrage du système d'exploitation
  • Échec du montage correct des volumes
  • CPU et mémoire épuisés
  • Alerte du noyau
  • Le réseau n'a pas réussi à s'établir

Avertissement : certaines de ces résolutions nécessitent un arrêt et un redémarrage de l'instance. Avant d'arrêter et de redémarrer votre instance, tenez compte des conditions suivantes :

  • Les données de stockage d'instances sont perdues lorsque vous arrêtez une instance. Les données sont perdues lorsque vous arrêtez l'instance si votre instance est basée sur le stockage d'instances ou dispose de volumes de stockage d'instances contenant des données. Pour plus d'informations, consultez Déterminer le type d'appareil racine de votre instance.
  • L'arrêt de l'instance peut entraîner sa résiliation si celle-ci fait partie d'un groupe Amazon EC2 Auto Scaling. Votre instance peut faire partie d'un groupe AWS Auto Scaling si vous l'avez lancée avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk. Dans ce cas, sa résiliation dépend des paramètres de protection contre la mise à l'échelle horizontale d'instance définis pour votre groupe Auto Scaling. Si votre instance fait partie d'un groupe Auto Scaling, supprimez-la temporairement du groupe avant d'exécuter les étapes de résolution.
  • L'arrêt et le démarrage d'une instance renvoie l'adresse IP publique dans le pool d'adresses IP dynamiques AWS. Une bonne pratique consiste à utiliser une adresse IP Elastic au lieu d'une adresse IP publique lors du routage du trafic externe vers votre instance. Si vous utilisez Amazon Route 53, vous devrez peut-être mettre à jour les enregistrements DNS Route 53 lorsque l'adresse IP publique change.

Pour plus d'informations, consultez la rubrique Stop and start your instance (Arrêt et démarrage de votre instance).

Résolution

1.    Déterminez si la vérification de l'état de l'instance ou de la vérification de l'état du système a échoué en affichant les métriques de vérification de l'état.

2.    Si la vérification du statut du système a échoué, consultez la rubrique Mon instance EC2 Linux a échoué à son contrôle de statut du système. Comment 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. En fonction des données trouvées dans les journaux système, utilisez l'une de ces résolutions :

Échec du démarrage du système d'exploitation

Échec du montage correct des volumes

Une vérification de l'état d'une instance peut échouer en raison d'un point de montage qui ne peut pas être monté correctement, comme l'illustre cet exemple :

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

CPU et mémoire épuisés

Utilisation élevée du CPU

Si la métrique CPUUtilization est égale à 100 % ou en est proche, la capacité de calcul de l'instance peut ne pas être suffisante pour l'exécution du noyau.

Pour les instances T2 ou T3, consultez les métriques relatives aux crédits CPU dans le tableau des métriques Amazon CloudWatch afin de déterminer si les crédits CPU sont égaux à zéro ou en sont proches. Si les crédits de CPU sont à zéro, la métrique CPUUtilization affiche un plateau de saturation aux performances de base de l'instance. Les performances de base peuvent être de 20 %, 40 %, et ainsi de suite, en fonction du type d'instance.

Les métriques CloudWatch indiquant une utilisation du CPU égale ou proche de 100 %, ou sur un plateau de saturation pour les instances T2 ou T3, indiquent que la vérification du statut a échoué en raison d'une sur-utilisation des ressources de l'instance. Pour connaître la procédure permettant de résoudre ce problème, consultez la section La vérification du statut de mon instance EC2 Linux a échoué en raison d'une sur-utilisation de ses ressources. Comment résoudre ce problème ?

Les erreurs de périphérique de stockage en mode bloc, les bogues logiciels ou les paniques du noyau peuvent entraîner un pic d'utilisation inhabituel du CPU. Si la métrique CPUUtilization est à 100 % et que les journaux système contiennent des erreurs liées à des périphériques de stockage en mode bloc, des problèmes de mémoire ou d'autres erreurs système inhabituelles, redémarrez l'instance, ou arrêtez-la et démarrez-la.

Mémoire insuffisante

Une forte sollicitation de la mémoire peut entraîner l'échec de la vérification de l'état de l'instance. Dans cet exemple, la mémoire du système d'exploitation est insuffisante et le système arrête 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

Les métriques de mémoire et de disque EC2 ne sont pas envoyées à CloudWatch par défaut. Toutefois, vous pouvez envoyer des métriques supplémentaires à CloudWatch à des fins de surveillance à l'aide de l'agent CloudWatch.

Pour dépanner et résoudre le problème de mémoire insuffisante, envisagez de mettre à niveau l'instance vers un type d'instance plus grand. Vous pouvez également ajouter du stockage d'échange à l'instance pour réduire la sollicitation de la mémoire. Pour en savoir plus, consultez les rubriques suivantes :

Erreurs de disque plein

Si les journaux système contiennent des erreurs de disque plein, l'instance peut être entrée en mode d'urgence, car le périphérique racine est plein.

$: 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% /

Alerte du noyau

Une erreur de panique du noyau se produit lorsque le noyau détecte une erreur interne irrécupérable pendant le fonctionnement. Si l'erreur se produit pendant le démarrage du système d'exploitation, il se peut que le noyau ne puisse pas se charger correctement. Cela peut entraîner un échec du démarrage du système d'exploitation. Voici un exemple de message d'erreur de type kernel panic (alerte 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)

Le réseau n'a pas réussi à s'établir

Le réseau n'a pas réussi à s'établir pour les raisons suivantes :

Le package « cloud-init » est manquant

Si l'instance ne dispose pas du package cloud-init, l'établissement du réseau peut échouer. Le package cloud-init est utile pour mettre à jour la configuration réseau lors de son lancement.

Pour corriger cette erreur, vous pouvez 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

Si votre adresse MAC est codée en dur dans un fichier de configuration, vous pouvez rencontrer des problèmes qui peuvent entraîner une défaillance de l'établissement de votre réseau.

Les adresses MAC codées en dur se trouvent dans les fichiers de configuration Linux et les fichiers de configuration « udev », tels que 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 de réseau lorsque votre adresse MAC est codée en dur dans votre instance, vous devez supprimer les entrées ou les fichiers de configuration. Par exemple :

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

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

Si votre adresse IP est codée en dur dans un fichier de configuration, vous pouvez rencontrer des problèmes qui peuvent entraîner une défaillance de l'établissement de votre réseau. Cela se produit lorsqu'une Amazon Machine Image (AMI) provient d'une instance avec une adresse IP configurée de manière statique.

Pour corriger cette erreur, configurez votre interface réseau pour qu'elle utilise DHCP.

Remarque : vous ne pouvez pas mettre à jour les AMI existantes. La configuration de l'interface réseau pour utiliser DHCP doit être effectuée sur l'instance avant de créer une AMI.

Les pilotes réseau ENA ou Intel Enhanced sont manquants

Si l'instance ne dispose pas des pilotes réseau Elastic Network Adapter (ENA) ou Intel Enhanced Network Adapter, cela peut entraîner une défaillance de l'établissement du réseau.

Pour en savoir plus, consultez la rubrique Enhanced networking on Linux (Réseaux améliorés sur Linux).

L'interface réseau est renommée lors du démarrage

Si l'interface réseau est renommée au démarrage de l'instance, cela peut entraîner des problèmes de réseau. Pour corriger cette erreur, désactivez les noms d'interface réseau prévisibles en ajoutant net.ifnames=0 à la ligne de commande du noyau. Pour ce faire, vous devez activer l'option enhanced networking with the ENA (mise en réseau améliorée avec l'ENA).

Pour plus d'informations sur les problèmes de réseau, consultez la rubrique Best practices for configuring network interfaces (Bonnes pratiques pour la configuration des interfaces réseau).