Passer au contenu

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

Lecture de 3 minute(s)
0

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

Brève description

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

« The master failed: Error occurred:<html>?? <head><meta http-equiv="Content-Type" content="text/html; charset=UTF-16"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><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><meta http-equiv="Content-Type" content="text/html; charset=UTF-16"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><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>?? »

Ces erreurs peuvent s'afficher pour l'une des raisons suivantes :

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

Résolution

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

Le contrôleur d'instance situé sur le nœud primaire communique avec le plan de contrôle Amazon EMR et le reste du cluster. Si le contrôleur d'instance ne parvient pas à communiquer avec le plan de contrôle Amazon EMR, Amazon EMR classe le nœud primaire comme étant non sain. Si la protection contre la terminaison est activée, utilisez SSH pour vous connecter au nœud primaire, puis redémarrez le processus du contrôleur d'instance.

Amazon EMR version 5.30.0 et versions ultérieures :

  1. Pour vérifier le statut du contrôleur d'instance, exécutez la commande suivante :

    sudo systemctl status instance-controller.service
  2. Si le statut du contrôleur d'instance n'est pas activé, exécutez la commande suivante pour redémarrer le contrôleur d'instance :

    sudo systemctl start instance-controller.service

Amazon EMR versions 2 à 4 :

  1. Pour vérifier le statut du contrôleur d'instance, exécutez la commande suivante :

    sudo /etc/init.d/instance-controller status
  2. Si le statut du contrôleur d'instance n'est pas activé, exécutez la commande suivante pour redémarrer le contrôleur d'instance :

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

Résoudre les problèmes de mémoire et de disque

Procédez comme suit :

  1. Si la protection contre la résiliation est activée, utilisez SSH pour vous connecter au nœud primaire.
  2. Consultez le fichier journal d'état de l'instance.
  3. Analysez les métriques de l'instance, telles que la mémoire et le disque, répertoriées dans le journal d'état de l’instantané. Vous pouvez utiliser des commandes Linux telles que free -m et df -h pour analyser ces métriques.
  4. 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 du statut de l'instance EC2 du nœud primaire

Examinez les métriques de vérification du statut de l'instance pour déterminer si la vérification du statut de l'instance primaire échoue. Si la vérification du statut de l'instance échoue, résolvez le problème d'échec de vérification du statut de l'instance.

Remarque : lorsque vous démarrez et arrêtez votre instance EC2, votre cluster Amazon EMR s'arrête.

Résoudre les problèmes liés aux nœuds primaires pour lesquels la protection contre la résiliation est désactivée alors que le cluster est déjà résilié

Effectuez les opérations suivantes :

AWS OFFICIELA mis à jour il y a 6 mois