Como posso resolver erros ExecutorLostFailure de "perda de escravo" do Spark no Amazon EMR?

Descrição breve

Esse erro indica que uma tarefa do Spark falhou porque um nó foi encerrado ou ficou indisponível. Existem muitas causas possíveis desse erro. A resolução a seguir aborda essas causas básicas comuns:

• Alta utilização do disco
• Usar instâncias spot para nós de cluster
• Políticas agressivas do Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling

Resolução

Alta utilização do disco

No 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 conectado for maior que a propriedade YARN yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage (valor padrão 90%), o nó será considerado não íntegro. Quando um nó não está íntegro, o ResourceManager elimina todos os contêineres em execução nesse nó. O ResourceManager não agenda novos contêineres em nós não íntegros. Para mais informações, consulte NodeManager na documentação do Hadoop.

Se o ResourceManager eliminar vários executores devido a nós não íntegros, a aplicação falhará com um erro de “escravo perdido”. Para confirmar que um nó não está íntegro, revise os logs do NodeManager ou os logs do controlador da instância:

• A localização dos logs do NodeManager é definida na variável YARN_LOG_DIR em yarn-env.sh.
• Os logs do controlador de instância são armazenados em /emr/instance-controller/log/instance-controller.log no nó principal. Os logs do controlador de instância fornecem uma visão agregada de todos os nós do cluster.

Se um nó não estiver íntegro, os logs mostrarão uma entrada semelhante a esta:

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

Instâncias spot

Se você estiver usando instâncias Spot do Amazon EC2 para nós de cluster do EMR (e uma dessas instâncias for encerrada), poderá receber um erro de “escravo perdido”. Instâncias spot podem ser encerradas pelos seguintes motivos:

• O preço da instância spot é maior que seu preço máximo.
• Não há instâncias do EC2 não utilizadas suficientes para atender à demanda por instâncias spot.

Para mais informações, consulte Motivos da interrupção.

Para resolver esse problema:

• Considere mudar para instâncias sob demanda.
• Se você estiver usando a versão 5.11.0 ou anterior do Amazon EMR, considere atualizar para a versão mais recente.

Políticas do Amazon EC2 Auto Scaling

Quando uma política de escalabilidade executa vários eventos de expansão e redução em sequência, um novo nó pode obter o mesmo endereço IP usado por um nó anterior. Se uma aplicação Spark estiver em execução durante um evento de expansão, o Spark adicionará o nó desativado à lista de negação para impedir que um executor seja iniciado nesse nó. Se outro evento de expansão ocorrer e o novo nó obtiver o mesmo endereço IP do nó anteriormente desativado, o YARN considerará o novo nó válido e tentará agendar executores nele. No entanto, como o nó ainda está na lista de negação do Spark, as tentativas de iniciar executores nesse nó falham. Quando você atinge o número máximo de falhas, a aplicação Spark falha com um erro de “escravo perdido”.

Para resolver esse problema:

• Use regras menos agressivas em suas políticas de ajuste de escala. Para mais informações, consulte Entender regras de ajuste de escala automático.
• Aumente o número de endereços IP disponíveis na sub-rede. Para mais informações, consulte Dimensionamento de VPC e sub-rede.

Para remover um nó da lista de negações do Spark, diminua as propriedades de tempo limite do Spark e do YARN, conforme mostrado nos exemplos a seguir:

Adicione a seguinte propriedade em /etc/spark/conf/spark-defaults.conf. 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.

spark.blacklist.decommissioning.timeout 600s

Modifique a seguinte propriedade YARN em /etc/hadoop/conf/yarn-site.xml. Essa propriedade especifica o tempo de espera pela conclusã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 é 3600 segundos.

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

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

---

Informações relacionadas

Diretrizes e práticas recomendadas de configuração de cluster

Como posso solucionar falhas de etapa dos trabalhos do Spark no Amazon EMR?