Cómo resuelvo un error «ExecutorLostFailure: «esclavo perdido» en Spark en Amazon EMR?

Resolución

Cuando una tarea de Spark falla porque un nodo termina o deja de estar disponible, es posible que se muestre el siguiente error:

«Fallo más reciente: Tarea perdida 1209.0 en la etapa 4.0 (TID 31219, ip-###-###-##-###.compute.internal, ejecutor 115): ExecutorLostFailure (el ejecutor 115 salió debido a una de las tareas en ejecución) Motivo: Esclavo perdido"

Las siguientes son algunas de las razones por las que se puede mostrar este error.

Uso elevado del disco debido a un nodo en mal estado

En Apache Hadoop, NodeManager comprueba periódicamente los volúmenes de Amazon Elastic Block Store (Amazon EBS) que están conectados a los nodos del clúster. Si la utilización del disco en un nodo con un volumen es superior a la propiedad YARN yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage, NodeManager considera que el nodo no está en buen estado. A continuación, ResourceManager cierra todos los contenedores de ese nodo y no programa nuevos contenedores. Para obtener más información, consulte NodeManager en el sitio web de Apache Hadoop.

Después de que ResourceManager cierre varios ejecutores debido a nodos en mal estado, la aplicación produce el error ExecutorLostFailure: esclavo perdido. Para confirmar que un nodo no está en buen estado, revise los registros de NodeManager o los registros del controlador de instancias. La variable YARN_LOG_DIR en yarn-env.sh define la ubicación de los registro de NodeManager. Los registros del controlador de instancias se almacenan en /emr/instance-controller/log/instance-controller.log en el nodo principal. Los registros del controlador de instancias proporcionan una vista agregada de todos los nodos del clúster.

Un nodo en mal estado muestra una entrada de registro similar a la siguiente:

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

Para resolver este problema, aumente el tamaño de los volúmenes de EBS que están conectados al núcleo y a los nodos de tareas. O bien, elimine los datos no utilizados del Sistema de archivos distribuido de Hadoop (HDFS).

Instancias de spot

Si utiliza instancias de spot de Amazon Elastic Compute Cloud (EC2) para los nodos del clúster de Amazon EMR y una de las instancias finaliza, es posible que se muestre un error ExecutorLostFailure: esclavo perdido. Las instancias de spot pueden finalizar por los siguientes motivos:

• El precio de la instancia de spot es superior al precio máximo.
• Las instancias de EC2 disponibles no satisfacen la demanda de instancias de spot.

Para obtener más información, consulte Interrupciones de las instancias de spot.

Para resolver este problema, utilice instancias bajo demanda. O bien, si usa la versión 5.11.0 o anterior de Amazon EMR, actualice a la versión más reciente.

Políticas de Amazon EC2 Auto Scaling

Durante los eventos frecuentes de Auto Scaling, un nodo nuevo puede recibir una dirección IP que utilizó un nodo anterior. Si una aplicación de Spark se ejecuta durante un evento de desescalamiento horizontal, Spark agrega el nodo desmantelado a la lista de denegados para que no se inicie ningún ejecutor en ese nodo. Si se produce otro evento de escalamiento horizontal y el nuevo nodo obtiene la misma dirección IP que el nodo desmantelado, YARN considera que el nuevo nodo es válido. YARN intenta programar ejecutores en el nuevo nodo. Como el nodo permanece en la lista de denegados de Spark, los inicios del ejecutor fallan. Cuando se alcanza el número máximo de errores, la aplicación Spark falla con un error ExecutorLostFailure: esclavo perdido.

Para solucionar este problema, tome las siguientes medidas:

• Utilice reglas menos agresivas en sus políticas de escalamiento. Para obtener más información, consulte Descripción de las reglas de escalamiento automático.
• Aumente las direcciones IP disponibles en la subred. Para obtener más información, consulte Bloques de CIDR de subred.

Para eliminar un nodo de la lista de denegados de Spark, reduzca las propiedades de tiempo de espera de Spark y YARN. Siga estos pasos:

1. Agregue el siguiente parámetro al archivo /etc/spark/conf/spark-defaults.conf:

   spark.blacklist.decommissioning.timeout 600s

   Nota: Esto reduce el tiempo que un nodo en estado de desmantelamiento permanece en la lista de denegados. El valor predeterminado es una hora. Para obtener más información, consulte Configuración del comportamiento de desmantelamiento de nodos.
2. Modifique la siguiente propiedad YARN en /etc/hadoop/conf/yarn-site.xml:

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

   Nota: Esta propiedad especifica el tiempo de espera hasta que se complete la ejecución de los contenedores y las aplicaciones antes de que un nodo en desmantelamiento pase al estado desmantelado. El valor predeterminado es 3600 segundos.

Para obtener más información, consulte las mejoras de elasticidad y resiliencia de Spark en Amazon EMR.

Información relacionada

Configuración de los tipos de instancias de clúster de Amazon EMR y las prácticas recomendadas para las instancias de spot

¿Cómo puedo solucionar los errores de fase de los trabajos de Spark en Amazon EMR?