Come posso risolvere gli errori ExecutorLostFailure "Slave lost" in Spark su Amazon EMR?

Breve descrizione

Questo errore indica che un'operazione Spark non è riuscita perché un nodo è stato terminato o non è più disponibile. Le possibili cause di questo errore sono molteplici. La risoluzione seguente copre queste cause principali comuni:

• Elevato utilizzo del disco
• Utilizzo di istanze spot per i nodi del cluster
• Policy aggressive di dimensionamento automatico di Amazon Elastic Compute Cloud (Amazon EC2)

Risoluzione

Elevato utilizzo del disco

In Hadoop, NodeManager controlla periodicamente i volumi Amazon Elastic Block Store (Amazon EBS) collegati ai nodi del cluster. Se l'utilizzo del disco su un nodo a cui è collegato un volume è maggiore della proprietà YARN yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage (valore predefinito 90%), il nodo è considerato non integro. Quando un nodo non è integro, ResourceManager elimina tutti i container in esecuzione su quel nodo. ResourceManager non pianifica nuovi container su nodi non integri. Per ulteriori informazioni, consulta NodeManager nella documentazione di Hadoop.

Se ResourceManager uccide più esecutori a causa di nodi non integri, l'applicazione non riesce con un errore "slave lost". Per confermare che un nodo non è integro, esamina i log di NodeManager o i log del controller di istanza:

• La posizione dei log NodeManager è definita nella variabile YARN_LOG_DIR in yarn-env.sh.
• I log del controller di istanza sono archiviati in /emr/instance-controller/log/instance-controller.log nel nodo master. I log del controller di istanza forniscono una vista aggregata di tutti i nodi del cluster.

Se un nodo non è integro, i log mostrano una voce simile a questa:

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

Per risolvere questo problema, aumenta le dimensioni dei volumi EBS collegati ai nodi core e attività. Oppure, elimina i dati non utilizzati da HDFS.

Istanze spot

Se utilizzi istanze spot di Amazon EC2 per i nodi del cluster EMR e una di queste istanze termina, potresti ricevere un errore "slave lost". Le istanze spot potrebbero terminare per i seguenti motivi:

• Il prezzo di Spot Instant è superiore al prezzo massimo.
• Non ci sono abbastanza istanze EC2 inutilizzate per soddisfare la domanda di istanze spot.

Per ulteriori informazioni, consulta Motivi dell'interruzione.

Per risolvere questo problema:

• Valuta la possibilità di passare alle istanze on-demand.
• Se utilizzi la versione 5.11.0 o precedente di Amazon EMR, valuta la possibilità di effettuare l'aggiornamento alla versione più recente.

Politiche di dimensionamento automatico Amazon EC2

Quando una policy di dimensionamento esegue molti eventi di dimensionamento in entrata e in uscita in sequenza, un nuovo nodo potrebbe ottenere lo stesso indirizzo IP utilizzato da un nodo precedente. Se un'applicazione Spark è in esecuzione durante un evento di dimensionamento, Spark aggiunge il nodo disattivato all'elenco dei negati per impedire l'avvio di un esecutore su quel nodo. Se si verifica un altro evento di dimensionamento orizzontale e il nuovo nodo ottiene lo stesso indirizzo IP del nodo precedentemente disattivato, YARN considera valido il nuovo nodo e tenta di pianificare gli esecutori su di esso. Tuttavia, poiché il nodo è ancora nell'elenco di utenti negati di Spark, i tentativi di avviare gli esecutori su quel nodo non riescono. Quando raggiungi il numero massimo di errori, l'applicazione Spark non riesce con un errore "slave lost".

Per risolvere questo problema:

• Usa regole meno aggressive nelle tue politiche di dimensionamento. Per ulteriori informazioni, consulta Understanding automatic scaling rules.
• Aumenta il numero di indirizzi IP disponibili nella sottorete. For more information, see VPC and subnet sizing.

Per rimuovere un nodo dall'elenco Spark negato, riduci le proprietà di timeout Spark e YARN, come mostrato negli esempi seguenti:

Aggiungi la seguente proprietà in /etc/spark/conf/spark-defaults.conf. In questo modo si riduce il periodo di tempo in cui un nodo in stato di disattivazione rimane nell'elenco degli oggetti negati. L'impostazione predefinita è un'ora. Per ulteriori informazioni, consulta Configurazione del comportamento di disattivazione dei nodi.

spark.blacklist.decommissioning.timeout 600s

Modifica la seguente proprietà YARN in /etc/hadoop/conf/yarn-site.xml. Questa proprietà specifica il tempo di attesa per il completamento dei container e delle applicazioni in esecuzione prima che un nodo di disattivazione passi allo stato disattivato. L'impostazione predefinita è 3600 secondi.

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

Per ulteriori informazioni, consulta Miglioramenti di Spark per l'elasticità e la resilienza su Amazon EMR.

---

Informazioni correlate

Cluster configuration guidelines and best practices

How can I troubleshoot stage failures in Spark jobs on Amazon EMR?