Wie behebe ich die ExecutorLostFailure-Fehler „Slave lost“ in Spark auf Amazon EMR?

Kurzbeschreibung

Dieser Fehler weist darauf hin, dass eine Spark-Aufgabe fehlgeschlagen ist, weil ein Knoten beendet wurde oder nicht mehr verfügbar war. Es gibt viele mögliche Ursachen für diesen Fehler. Die folgende Lösung behandelt diese häufigen Ursachen:

• Hohe Festplattenauslastung
• Spot-Instances für Clusterknoten verwenden
• Aggressive Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling-Richtlinien

Behebung

Hohe Festplattenauslastung

In Hadoop überprüft NodeManager regelmäßig die Amazon Elastic Block Store (Amazon EBS)-Volumes, die an die Knoten des Clusters angeschlossen sind. Wenn die Festplattenauslastung auf einem Knoten, an den ein Volume angeschlossen ist, größer ist als die YARN-Eigenschaft yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage (Standardwert 90 %), wird der Knoten als fehlerhaft angesehen. Wenn ein Knoten fehlerhaft ist, beendet ResourceManager alle Container, die auf diesem Knoten laufen. ResourceManager plant keine neuen Container auf fehlerhaften Knoten. Weitere Informationen finden Sie unter NodeManager in der Hadoop-Dokumentation.

Wenn ResourceManager mehrere Executoren aufgrund fehlerhafter Knoten tötet, schlägt die Anwendung fehl und es wird der Fehler „Slave Lost“ angezeigt. Um zu überprüfen, ob ein Knoten fehlerhaft ist, überprüfen Sie die NodeManager-Protokolle oder die Instance-Controller-Protokolle:

• Der Speicherort der NodeManager-Protokolle ist in der Variablen YARN_LOG_DIR in yarn-env.sh definiert.
• Die Instance-Controller-Logs werden unter /emr/instance-controller/log/instance-controller.log auf dem Hauptknoten gespeichert. Die Instance-Controller-Protokolle bieten eine aggregierte Ansicht aller Knoten des Clusters.

Wenn ein Knoten fehlerhaft ist, zeigen die Protokolle einen Eintrag, der wie folgt aussieht:

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

Um dieses Problem zu lösen, erhöhen Sie die Größe der EBS-Volumes, die an die Core- und Aufgabenknoten angeschlossen sind. Oder löschen Sie ungenutzte Daten aus HDFS.

Spot-Instances

Wenn Sie Amazon EC2 Spot Instances für EMR-Clusterknoten verwenden und eine dieser Instances beendet wird, erhalten Sie möglicherweise die Fehlermeldung „Slave Lost“. Spot-Instances können aus den folgenden Gründen beendet werden:

• Der Spot Instant-Preis liegt über Ihrem Höchstpreis.
• Es gibt nicht genügend ungenutzte EC2-Instances, um die Nachfrage nach Spot-Instances zu decken.

Weitere Informationen finden Sie unter Gründe für eine Unterbrechung.

Um dieses Problem zu lösen:

• Erwägen Sie den Wechsel zu On-Demand-Instances.
• Wenn Sie Amazon EMR Release-Version 5.11.0 oder früher verwenden, sollten Sie ein Upgrade auf die neueste Version in Betracht ziehen.

Amazon EC2 Auto Scaling-Richtlinien

Wenn eine Skalierungsrichtlinie viele Scale-In- und Scale-Out-Ereignisse nacheinander ausführt, erhält ein neuer Knoten möglicherweise dieselbe IP-Adresse, die ein früherer Knoten verwendet hat. Wenn eine Spark-Anwendung während eines Scale-In-Ereignisses ausgeführt wird, fügt Spark den stillgelegten Knoten zur Deny-Liste hinzu, um zu verhindern, dass ein Executor auf diesem Knoten gestartet wird. Tritt ein weiteres Scale-Out-Ereignis ein und der neue Knoten erhält dieselbe IP-Adresse wie der zuvor stillgelegte Knoten, betrachtet YARN den neuen Knoten als gültig und versucht, Executoren darauf zu planen. Da der Knoten jedoch immer noch auf der Spark-Deny-Liste steht, schlagen Versuche fehl, Executoren auf diesem Knoten zu starten. Wenn Sie die maximale Anzahl von Ausfällen erreichen, schlägt die Spark-Anwendung mit dem Fehler „Slave Lost“ fehl.

Um dieses Problem zu lösen:

• Verwenden Sie weniger aggressive Regeln in Ihren Skalierungsrichtlinien. Weitere Informationen finden Sie unter Grundlegendes zu automatischen Skalierungsregeln.
• Erhöhen Sie die Anzahl der verfügbaren IP-Adressen im Subnetz. Weitere Informationen finden Sie unter VPC- und Subnetzgröße.

Um einen Knoten aus der Spark-Deny-Liste zu entfernen, verringern Sie die Timeout-Eigenschaften Spark und YARN, wie in den folgenden Beispielen gezeigt:

Fügen Sie die folgende Eigenschaft in /etc/spark/conf/spark-defaults.conf hinzu. Dadurch wird die Zeit reduziert, in der ein Knoten im Stilllegungsstatus auf der Ablehnungsliste verbleibt. Die Standardeinstellung ist eine Stunde. Weitere Informationen finden Sie unter Konfiguration des Verhaltens bei der Außerbetriebnahme von Knoten.

spark.blacklist.decommissioning.timeout 600s

Ändern Sie die folgende YARN-Eigenschaft in /etc/hadoop/conf/yarn-site.xml. Diese Eigenschaft gibt an, wie lange gewartet werden muss, bis die Ausführung von Containern und Anwendungen abgeschlossen ist, bevor ein Knoten zur Außerbetriebnahme in den Status Stillgelegt übergeht. Die Standardeinstellung ist 3600 Sekunden.

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

Weitere Informationen finden Sie unter Spark-Verbesserungen für Elastizität und Resilienz in Amazon EMR.

---

Verwandte Informationen

Richtlinien und bewährte Methoden zur Clusterkonfiguration

Wie kann ich Stufenfehler in Spark-Jobs auf Amazon EMR beheben?