Comment résoudre une erreur « ExecutorLostFailure » : Esclave perdu » dans Spark sur Amazon EMR ?

Résolution

Lorsqu'une tâche Spark échoue parce qu'un nœud se termine ou devient indisponible, le message d'erreur suivant peut s'afficher :

« Most recent failure: Lost task 1209.0 in stage 4.0 (TID 31219, ip-###-###-##-###.compute.internal, executor 115): ExecutorLostFailure (executor 115 exited caused by one of the running tasks) Reason: Slave lost » (Ma défaillance la plus récente : Tâche perdue 1209.0 dans l’étape 4.0 (TID 31219, ip-###-###-##-###.compute.internal, executor 115): ExecutorLostFailure (fermeture du programme d’exécution 115 causée par l’une des tâches en cours d’exécution) Raison : Esclave perdu)

Voici quelques-unes des raisons pour lesquelles vous pourriez recevoir cette erreur.

Utilisation élevée du disque en raison d'un nœud défectueux

Dans Apache Hadoop, NodeManager vérifie régulièrement les volumes Amazon Elastic Block Store (Amazon EBS) attachés aux nœuds du cluster. Si l'utilisation du disque sur un nœud comportant un volume est supérieure à la propriété yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage, NodeManager considère que le nœud est défectueux. Puis, ResourceManager arrête tous les conteneurs de ce nœud et ne planifie pas de nouveaux conteneurs. Pour plus d'informations, consultez NodeManager sur le site Web d'Apache Hadoop.

Une fois que ResourceManager a arrêté plusieurs programmes d’exécution en raison de nœuds défectueux, l'application échoue avec une erreur ExecutorLostFailure: Esclave perdu. Pour vérifier qu'un nœud est défectueux, consultez les journaux NodeManager ou ceux du contrôleur d'instance. La variable YARN_LOG_DIR de yarn-env.sh définit l'emplacement des journaux NodeManager. Les journaux du contrôleur d'instance sont stockés dans le fichier /emr/instance-controller/log/instance-controller.log sur le nœud primaire. Les journaux du contrôleur d'instance fournissent une vue agrégée de tous les nœuds du cluster.

Un nœud défectueux affiche une entrée de journal qui ressemble à la suivante :

2019-10-04 11:09:37,163 INFO Poller: InstanceJointStatusMap contains 40 entries (R:40):  i-006ba######  1829s R   1817s ig-3B ip-###-##-##-### I:    7s Y:U    11s c: 0 am:    0 H:R  0.0%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers
  i-00979######  1828s R   1817s ig-3B ip-###-##-##-### I:    7s Y:R     9s c: 3 am: 2048 H:R  0.0%
  i-016c4######  1834s R   1817s ig-3B ip-###-##-##-### I:   13s Y:R    14s c: 3 am: 2048 H:R  0.0%
  i-01be3######  1832s R   1817s ig-3B ip-###-##-##-### I:   10s Y:U    12s c: 0 am:    0 H:R  0.0%Yarn unhealthy Reason : 1/1 local-dirs are bad: /mnt/yarn; 1/1 log-dirs are bad: /var/log/hadoop-yarn/containers

Pour résoudre ce problème, augmentez la taille des volumes EBS attachés aux nœuds principaux et aux nœuds de tâches. Vous pouvez également supprimer les données inutilisées du système de fichiers distribué Hadoop (HDFS).

Instances ponctuelles

Si vous utilisez des instances ponctuelles Amazon Elastic Compute Cloud (EC2) pour les nœuds de cluster Amazon EMR et que l'une des instances se termine, vous risquez de recevoir une erreur ExecutorLostFailure: Esclave perdu. Les instances Spot peuvent être interrompues pour les raisons suivantes :

• Le prix de l'instance Spot est supérieur à votre prix maximum.
• Vos instances EC2 disponibles ne répondent pas à la demande d'instances Spot.

Pour plus d'informations, consultez la section Interruptions des instances Spot.

Pour résoudre ce problème, utilisez des instances à la demande. Ou, si vous utilisez la version 5.11.0 ou antérieure d'Amazon EMR, effectuez une mise à niveau vers la dernière version.

Politiques d'Amazon EC2 Auto Scaling

Lors d'événements Auto Scaling fréquents, un nouveau nœud peut recevoir une adresse IP utilisée par un nœud précédent. Si une application Spark s'exécute pendant un événement de mise à l'échelle horizontale descendante, Spark ajoute le nœud mis hors service à la liste de refus afin qu'aucun programme d’exécution ne soit lancé sur ce nœud. Si un autre événement de mise à l'échelle horizontale ascendante se produit et que le nouveau nœud obtient la même adresse IP que le nœud mis hors service, YARN considère que le nouveau nœud est valide. YARN tente de planifier des programmes d’exécution sur le nouveau nœud. Comme le nœud reste sur la liste de refus de Spark, le lancement du programme d’exécution échoue. Lorsque vous atteignez le nombre maximum d'échecs, l'application Spark échoue avec une erreur ExecutorLostFailure : Esclave perdu.

Pour résoudre ce problème, prenez les mesures suivantes :

• Utilisez des règles moins agressives dans vos politiques de mise à l’échelle. Pour plus d'informations, consultez la section Comprendre les règles de mise à l’échelle automatique.
• Augmentez les adresses IP disponibles dans le sous-réseau. Pour plus d'informations, consultez la section Blocs d'adresses CIDR de sous-réseau.

Pour supprimer un nœud de la liste de refus de Spark, diminuez les propriétés de délai d’expiration de Spark et YARN. Procédez comme suit :

1. Ajoutez le paramètre suivant au fichier /etc/spark/conf/spark-defaults.conf :

   spark.blacklist.decommissioning.timeout 600s

   Remarque : Cela réduit la durée pendant laquelle un nœud en état de mise hors service reste sur la liste de refus. La valeur par défaut est d'une heure. Pour plus d'informations, consultez la section Configuration du comportement de mise hors service des nœuds.
2. Modifiez la propriété YARN suivante dans /etc/hadoop/conf/yarn-site.xml :

   yarn.resourcemanager.nodemanager-graceful-decommission-timeout-secs 600

   Remarque : Cette propriété spécifie le temps d'attente pour que les conteneurs et les applications en cours d'exécution se terminent avant qu'un nœud en cours de mise hors service ne passe à l'état mis hors service. La valeur par défaut est de 3 600 secondes.

Pour plus d'informations, consultez la section Améliorations Spark apportées à l'élasticité et à la résilience sur Amazon EMR.

Informations connexes

Configuration des types d'instances de cluster Amazon EMR et des bonnes pratiques pour les instances Spot

Comment puis-je résoudre les échecs d’étape dans les tâches Spark sur Amazon EMR ?