¿Cómo puedo resolver los errores «Slave lost» de ExecutorLostFailure en Spark en Amazon EMR?

5 minutos de lectura
0

He enviado una aplicación Apache Spark a un clúster de Amazon EMR. La aplicación falla con este error: «Fallo más reciente: Se perdió la tarea 1209.0 en la etapa 4.0 (TID 31219, ip-xxx-xxx-xx-xxx.compute.internal, ejecutor 115): ExecutorLostFailure (el ejecutor 115 salió debido a una de las tareas en ejecución) Motivo: Esclavo perdido"

Descripción corta

Este error indica que se ha producido un error en una tarea de Spark porque un nodo ha terminado o ha dejado de estar disponible. Hay muchas causas posibles de este error. La siguiente resolución aborda estas causas fundamentales comunes:

  • Alta utilización del disco
  • Uso de instancias puntuales para nodos de clúster
  • Políticas agresivas de (Amazon EC2) escalado automático de Amazon Elastic Compute Cloud

Resolución

Alta utilización del disco

En 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 que tiene un volumen adjunto es mayor que la propiedad de llamada YARNyarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage (valor predeterminado 90%), entonces se considera que el nodo está en un estado de salud deficiente. Cuando un nodo no está en buen estado, ResourceManager elimina todos los contenedores que se ejecutan en ese nodo. ResourceManager no programa nuevos contenedores en nodos en mal estado. Para obtener más información, consulte NodeManager en la documentación de Hadoop.

Si ResourceManager elimina varios ejecutores debido a que los nodos no funcionan correctamente, la aplicación fallará con el error «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 ubicación de los registros de NodeManager se define en la variable YARN\ _LOG\ _DIR de yarn-env.sh.
  • Los registros del controlador de instancias se almacenan en /emr/instance-controller/log/instance-controller.log en el nodo maestro. Los registros del controlador de instancias proporcionan una vista agregada de todos los nodos del clúster.

Si un nodo no está en buen estado, los registros muestran una entrada similar a la siguiente:

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

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 de HDFS.

Instancias puntuales

Si utiliza instancias puntuales de Amazon EC2 para nodos de clústeres de EMR y una de esas instancias finaliza, es posible que aparezca el error «esclavo perdido». Las instancias puntuales pueden finalizar por los siguientes motivos:

  • El precio de Spot Instant es superior al precio máximo.
  • No hay suficientes instancias de EC2 sin usar para satisfacer la demanda de instancias puntuales.

Para obtener más información, consulte Motivos de la interrupción.

Para resolver este problema:

  • Considere la posibilidad de cambiar a instancias bajo demanda.
  • Si utiliza la versión 5.11.0 o anterior de Amazon EMR, considere la posibilidad de actualizar a la versión más reciente.

Políticas de escalado automático de Amazon EC2

Cuando una política de escalado realiza muchos eventos de escalado ascendente y descendente en secuencia, un nuevo nodo puede obtener la misma dirección IP que utilizó un nodo anterior. Si una aplicación de Spark se ejecuta durante un evento de escalado, Spark añade el nodo fuera de servicio a la lista de denegación para evitar que se inicie un 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 previamente retirado, YARN considera que el nuevo nodo es válido e intenta programar ejecutores en él. Sin embargo, dado que el nodo sigue en la lista de denegaciones de Spark, fallan los intentos de lanzar ejecutores en ese nodo. Cuando se alcanza el número máximo de errores, la aplicación Spark falla con un error de «esclavo perdido».

Para resolver este problema:

Para eliminar un nodo de la lista de denegaciones de Spark, reduzca las propiedades de tiempo de espera de Spark y YARN, como se muestra en los siguientes ejemplos:

Añada la siguiente propiedad en /etc/spark/conf/spark-defaults.conf. Esto reduce la cantidad de tiempo que un nodo en estado de desmantelamiento permanece en la lista de denegaciones. El valor predeterminado es una hora. Para obtener más información, consulte Configurar el comportamiento de desmantelamiento de nodos.

spark.blacklist.decommissioning.timeout 600s

Modifique la siguiente propiedad YARN en /etc/hadoop/conf/yarn-site.xml. Esta propiedad especifica el tiempo que debe transcurrir 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.

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

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


Información relacionada

Pautas y mejores prácticas de configuración de clústeres

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

OFICIAL DE AWS
OFICIAL DE AWSActualizada hace 2 años