Comment résoudre les erreurs ExecutorLostFailure "Slave Lost" (Esclave perdu) dans Spark sur Amazon EMR ?

Brève description

Cette erreur indique qu'une tâche Spark a échoué parce qu'un nœud s'est terminé ou est devenu indisponible. Il existe de nombreuses causes possibles de cette erreur. La résolution suivante couvre ces causes racine courantes :

• Utilisation élevée du disque
• Utilisation d'instances Spot pour les nœuds de cluster
• Stratégies Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling agressives

Solution

Utilisation élevée du disque

Dans Hadoop, NodeManager vérifie régulièrement les volumes Amazon Elastic Block Store (Amazon EBS) qui sont attachés aux nœuds du cluster. Si l'utilisation du disque sur un nœud auquel est attaché un volume est supérieure à la propriété YARN yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage (la valeur par défaut est 90 %), le nœud est considéré comme défectueux. Lorsqu'un nœud est défectueux, ResourceManager tue tous les conteneurs exécutés sur ce nœud. ResourceManager ne planifie pas de nouveaux conteneurs sur des nœuds défectueux. Pour plus d'informations, consultez NodeManager dans la documentation Hadoop.

Si ResourceManager tue plusieurs exécuteurs en raison de nœuds malsains, l'application échoue avec une erreur "slave lost". Vérifiez les journaux du NodeManager ou du contrôleur d'instance pour confirmer qu'un nœud est défectueux :

• L'emplacement des journaux du NodeManager est défini dans la variable YARN_LOG_DIR dans yarn-env.sh.
• Les journaux du contrôleur d'instance sont stockés à l'adresse /emr/instance-controller/log/instance-controller.log sur le nœud maître. Les journaux du contrôleur d'instance fournissent une vue agrégée de tous les nœuds du cluster.

Si un nœud est défectueux, les journaux affichent une entrée similaire à ceci :

2019-10-04 11:09:37,163 INFO Poller: InstanceJointStatusMap contains 40 entries (R:40):
  i-006baxxxxxx  1829s R   1817s ig-3B ip-xxx-xx-xx-xxx 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-00979xxxxxx  1828s R   1817s ig-3B ip-xxx-xx-xx-xxx I:    7s Y:R     9s c: 3 am: 2048 H:R  0.0%
  i-016c4xxxxxx  1834s R   1817s ig-3B ip-xxx-xx-xx-xxx I:   13s Y:R    14s c: 3 am: 2048 H:R  0.0%
  i-01be3xxxxxx  1832s R   1817s ig-3B ip-xxx-xx-xx-xxx 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 de tâches. Ou supprimez les données inutilisées de HDFS.

Instances Spot

Si vous utilisez des instances Spot Amazon EC2 pour des nœuds de cluster EMR et que l'une de ces instances est interrompue, vous risquez d'obtenir une erreur "slave lost". Voici les raisons pour lesquelles vos instances Spot sont susceptibles d'être interrompues :

• Le prix de l'instance Spot est supérieur à votre prix maximum.
• Il n'y a pas suffisamment d'instances EC2 inutilisées pour répondre à la demande d'instances Spot.

Pour plus d'informations, consultez Raisons d'interruption.

Pour résoudre ce problème :

• Pensez à passer aux instances à la demande.
• Si vous utilisez Amazon EMR version 5.11.0 ou antérieure, envisagez de procéder à une mise à niveau vers la dernière version.

Stratégies Amazon EC2 Auto Scaling

Lorsqu'une stratégie de mise à l'échelle effectue chronologiquement de nombreux événements de diminution et d'augmentation, un nouveau nœud peut obtenir la même adresse IP qu'un nœud précédent. Si une application Spark est en cours d'exécution lors d'une diminution, Spark ajoute le nœud mis hors service est ajouté à la liste de refus pour empêcher le lancement de ce nœud par un programme d'exécution. Si un événement d'augmentation se produit et que le nouveau nœud obtient la même adresse IP que le nœud précédemment mis hors service, YARN considère que le nouveau nœud est valide et tente de planifier des exécuteurs sur ce dernier. Cependant, comme le nœud est toujours sur la liste de refus Spark, les tentatives de lancement de programmes d'exécution sur ce nœud vont échouer. Lorsque le nombre maximal d'échecs est atteint, l'application Spark échoue avec l'erreur "slave lost".

Pour résoudre ce problème :

• Utilisez des règles moins agressives dans vos stratégies de dimensionnement. Pour plus d'informations, consultez la section Présentation des règles de dimensionnement automatique.
• Augmentez le nombre d'adresses IP disponibles dans le sous-réseau. Pour plus d'informations, consultez Dimensionnement des VPC et des sous-réseaux.

Pour supprimer un nœud de la liste de refus Spark, réduisez les propriétés de délai d'expiration de Spark et YARN, comme illustré dans les exemples suivants :

Ajoutez la propriété suivante dans /etc/spark/conf/spark-defaults.conf. Cette méthode réduit la durée pendant laquelle un nœud dont l'état est hors service reste sur liste de refus. La valeur par défaut est une heure. Pour plus d'informations, consultez Configuration du comportement de mise hors service du nœud.

spark.blacklist.decommissioning.timeout 600s

Modifiez la propriété YARN suivante dans /etc/hadoop/conf/yarn-site.xml. Cette propriété indique la durée d'attente des conteneurs et applications en cours d'exécution avant de passer un nœud de mise hors service à l'état mis hors service. La valeur par défaut est 3 600 secondes.

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

Pour plus d'informations, consultez Spark enhancements for elasticity and resiliency on Amazon EMR (Améliorations Spark pour l'élasticité et la résilience sur Amazon EMR).

---

Informations connexes

Consignes et bonnes pratiques pour la configuration de cluster

Comment résoudre les messages d'erreur dans les tâches Spark sur Amazon EMR ?