Como resolvo um erro “ExecutorLostFailure: Slave lost” no Spark do Amazon EMR?

Resolução

Quando uma tarefa do Spark falha porque um nó é encerrado ou fica indisponível, você pode receber o seguinte erro:

“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”

A seguir estão alguns dos motivos pelos quais você pode receber esse erro.

Alta utilização do disco devido a um nó não íntegro

No Apache Hadoop, o NodeManager verifica periodicamente os volumes do Amazon Elastic Block Store (Amazon EBS) que estão conectados aos nós do cluster. Se a utilização do disco em um nó com um volume for maior do que a propriedade YARN yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage, o NodeManager considerará o nó não íntegro. Em seguida, o ResourceManager desliga todos os contêineres desse nó e não agenda novos contêineres. Para obter mais informações, consulte NodeManager no site do Apache Hadoop.

Depois que o ResourceManager desliga vários executores devido a nós não íntegros, a aplicação falha com um erro ExecutorLostFailure: Slave lost. Para confirmar que um nó não está íntegro, revise os logs do NodeManager ou os logs do controlador da instância. A variável YARN_LOG_DIR em yarn-env.sh define a localização dos logs do NodeManager. Os logs do controlador de instância são armazenados em /emr/instance-controller/log/instance-controller.log no nó primário. Os logs do controlador de instância fornecem uma visão agregada de todos os nós do cluster.

Um nó não íntegro mostra uma entrada de log semelhante à seguinte:

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 esse problema, aumente o tamanho dos volumes do EBS que estão conectados aos nós centrais e de tarefas. Ou exclua dados não utilizados do Sistema de Arquivos Distribuído do Hadoop (HDFS).

Instâncias spot

Se você usar instâncias spot do Amazon Elastic Compute Cloud (EC2) para nós de cluster do Amazon EMR e uma das instâncias for encerrada, você poderá receber um erro ExecutorLostFailure: Slave lost. Instâncias spot podem ser encerradas pelos seguintes motivos:

• O preço da instância spot é maior que seu preço máximo.
• Suas instâncias EC2 disponíveis não atendem à demanda por instâncias spot.

Para mais informações, consulte Interrupções de instâncias spot.

Para resolver esse problema, use Instâncias sob demanda. Ou, se você usar a versão 5.11.0 ou anterior do Amazon EMR, atualize para a versão mais recente.

Políticas do Amazon EC2 Auto Scaling

Durante eventos frequentes de ajuste de escala automático, um novo nó pode receber um endereço IP usado por um nó anterior. Se uma aplicação Spark for executada durante um evento de redução da escala horizontalmente, o Spark adicionará o nó desativado à lista de negações para que um executor não seja iniciado nesse nó. Se outro evento de aumento da escala horizontalmente ocorrer e o novo nó obtiver o mesmo endereço IP do nó desativado, o YARN considerará o novo nó válido. O YARN tenta agendar executores no novo nó. Como o nó permanece na lista de negações do Spark, as inicializações do executor falham. Quando você atinge o número máximo de falhas, a aplicação Spark falha com um erro ExecutorLostFailure: Slave lost.

Para resolver esse problema, execute as seguintes ações:

• Use regras menos agressivas em suas políticas de escalabilidade. Para mais informações, consulte Entender regras de ajuste de escalabilidade automática.
• Aumente os endereços IP disponíveis na sub-rede. Para obter mais informações, consulte Blocos CIDR de sub-rede.

Para remover um nó da lista de negações do Spark, diminua as propriedades de tempo limite do Spark e do YARN. Conclua as etapas a seguir:

1. Adicione o seguinte parâmetro ao arquivo /etc/spark/conf/spark-defaults.conf:

   spark.blacklist.decommissioning.timeout 600s

   Observação: Isso reduz a quantidade de tempo que um nó no estado de descomissionamento permanece na lista de negações. O padrão é uma hora. Para mais informações, consulte Configurar o comportamento de descomissionamento de nós.
2. Modifique a seguinte propriedade YARN em /etc/hadoop/conf/yarn-site.xml:

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

   Observação: essa propriedade especifica o tempo de espera para a execução dos contêineres e aplicações em execução antes que um nó de descomissionamento faça a transição para o estado descomissionado. O padrão é 3,600 segundos.

Para mais informações, consulte Aprimoramentos do Spark para elasticidade e resiliência no Amazon EMR.

Informações relacionadas

Configuração dos tipos de instâncias de cluster do Amazon EMR e das práticas recomendadas para instâncias spot

Como posso solucionar falhas de estágio em trabalhos do Spark no Amazon EMR?