Comment résoudre une défaillance du nœud primaire associée à l'erreur « 502 Bad Gateway » ou « 504 Gateway Time-out » dans Amazon EMR ?

Dernière mise à jour : 06/01/2023

Mon nœud primaire Amazon EMR échoue en raison d'une erreur « 502 Bad Gateway » ou « 504 Gateway Time-out ».

Brève description

Un nœud primaire EMR peut échouer avec l'une des erreurs suivantes :

The master failed: Error occurred:<html>?? <head><title>502 Bad Gateway</title></head> <body>?? <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx/1.20.0</center>?? </body>?? </html>??

-ou-

The master failed: Error occurred: <html>??<head><title>504 Gateway Time-out</title></head>??<body>??<center><h1>504 Gateway Time-out</h1></center>??<hr><center>nginx/1.16.1</center>??</body>??</html>??

Les causes courantes de ces erreurs sont les suivantes :

Le démon du contrôleur d'instance est à l'état arrêté ou est hors service sur l'instance du nœud primaire.
Le nœud primaire manque de mémoire ou d'espace disque.
Les vérifications de l'état de l'instance Amazon Elastic Compute Cloud (Amazon EC2) échouent.

Solution

Résoudre les défaillances du démon du contrôleur d'instance du nœud primaire

Le contrôleur d'instance (I/C) du nœud primaire est le démon qui communique avec le plan de contrôle EMR et le reste du cluster. Si le contrôleur d'instance ne peut pas communiquer avec le plan de contrôle EMR, le nœud primaire est considéré comme défectueux et le cluster est arrêté.

Pour résoudre ce problème, analysez les journaux du contrôleur d'instance afin de déterminer pourquoi le processus a échoué. Les journaux du contrôleur d'instance se trouvent dans /emr/instance-controller/log/.

Si la protection contre la terminaison est activée, connectez-vous via SSH au nœud primaire et redémarrez le processus du contrôleur d'instance.

Amazon EMR 5.30.0 et versions ultérieures :

1. Pour vérifier l'état de l'agent SSM, utilisez les commandes suivantes :

sudo systemctl status instance-controller.service

2. Utilisez la commande suivante pour redémarrer l'I/C si l'état est inactif :

sudo systemctl start instance-controller.service

Versions 4.x-2.x d'Amazon EMR :

1. Utilisez la commande suivante pour vérifier l'état du domaine :

sudo /etc/init.d/instance-controller status

2. Utilisez la commande suivante pour redémarrer l'I/C si l'état est inactif :

sudo /etc/init.d/instance-controller start

Analyser les fichiers journaux pour résoudre les problèmes de mémoire et de disque

Si la protection contre la terminaison est activée, utilisez SSH pour vous connecter au nœud primaire. Passez ensuite en revue le fichier journal de l'état de l'instance.
Analysez les indicateurs d'instance tels que la mémoire et le disque répertoriés dans le journal des états instantanés. Vous pouvez analyser ces métriques à l'aide de commandes Linux telles que free -m et df -h.
Utilisez les résultats du fichier journal pour déterminer pourquoi le nœud primaire utilise une grande quantité de disque ou de mémoire.

Résoudre les échecs de vérification de l'état des instances EC2 du nœud primaire

Déterminez si la vérification de l'état de l'instance primaire a échoué en affichant les métriques de vérification de l'état.
Résolvez l'échec de la vérification de l'état de l'instance. Sachez que le démarrage et l'arrêt de votre instance EC2 entraînent la fermeture du cluster EMR.

Résoudre les problèmes liés aux nœuds primaires dont la protection contre la terminaison est désactivée alors que le cluster est déjà arrêté

Activez la protection contre la terminaison lors du lancement d'un nouveau cluster EMR.
Basculez vers un type d'instance plus important. Pour plus d'informations, consultez la section Types d'instances pris en charge dans Amazon EMR.
Activez les alarmes Amazon CloudWatch concernant l'utilisation de la mémoire et du disque sur le nœud primaire EMR

Cet article vous a-t-il été utile?

Envoyer un commentaire

Besoin d'aide pour une question technique ou de facturation ?

Contacter AWS Support