Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Problembehandlung bei Amazon EMR-Clustern
Ein EMR-Cluster läuft in einem komplexen Ökosystem, das Open-Source-Software, benutzerdefinierten Anwendungscode und umfasst. AWS-Services Wenn bei einem dieser Teile ein Problem auftritt, schlägt der Cluster möglicherweise fehl oder es dauert länger als erwartet, bis er abgeschlossen ist. Die folgenden Themen können Ihnen bei der Identifizierung von Cluster-Problemen und deren Behebung helfen.
**Topics**
+ [Welche Tools sind für die Fehlerbehebung bei einem Amazon EMR-Cluster verfügbar?](emr-troubleshoot-tools.md)
+ [Anzeigen und Neustarten von Amazon-EMR- und Anwendungsprozessen (Daemons)](emr-process-restart-stop-view.md)
+ [Sammlungen häufiger Fehler in Amazon EMR](emr-troubleshoot-errors.md)
+ [Fehlerbehebung bei einem Amazon EMR-Cluster, der mit einem Fehlercode ausgefallen ist](emr-troubleshoot-failed.md)
+ [Fehlerbehebung bei einem langsamen Amazon EMR-Cluster](emr-troubleshoot-slow.md)
+ [Behebung häufiger Probleme bei der Verwendung von Amazon EMR mit AWS Lake Formation](emr-troubleshoot-lf.md)
Anleitung zur Fehlerbehebung bei [Spark-Anwendungen auf EMR.](https://aws.github.io/aws-emr-best-practices/docs/bestpractices/Applications/Spark/troubleshooting/)
Wenn Sie eine neue Hadoop-Anwendung entwickeln, empfehlen wir Ihnen, das Debugging zu aktivieren und eine kleine, aber repräsentative Teilmenge Ihrer Daten zu verarbeiten, um die Anwendung zu testen. Möglicherweise möchten Sie die Anwendung auch ausführen, step-by-step um jeden Schritt separat zu testen. Weitere Informationen erhalten Sie unter [Amazon EMR-Cluster-Protokollierung und Debugging konfigurieren](emr-plan-debugging.md) und [Schritt 5: Testen Sie den Amazon EMR-Cluster Schritt für Schritt](emr-troubleshoot-failed-5-test-steps.md).
# Welche Tools sind für die Fehlerbehebung bei einem Amazon EMR-Cluster verfügbar?
Um Clusterfehler zu identifizieren und zu beheben, können Sie die auf dieser Seite beschriebenen Tools verwenden. Möglicherweise müssen Sie einige der Tools initialisieren, wenn Sie den Cluster starten. Andere Tools sind standardmäßig für jeden Cluster verfügbar.
**Topics**
+ [Anzeigen von EMR Cluster-Details](#emr-troubleshoot-tools-details)
+ [EMR-Cluster-Fehlerdetails anzeigen](#emr-troubleshoot-errordetail)
+ [Skripts ausführen und Amazon-EMR-Prozesse konfigurieren](#emr-troubleshoot-tools-commands)
+ [Anzeige von -Protokolldateien](#emr-troubleshoot-tools-logs)
+ [Überwachen Sie die Leistung des EMR-Clusters](#emr-troubleshoot-tools-performance)
## Anzeigen von EMR Cluster-Details
Sie können die AWS-Managementkonsole, oder EMR-API verwenden AWS CLI, um detaillierte Informationen über einen EMR-Cluster und die Jobausführung abzurufen. Weitere Hinweise zur Verwendung von AWS-Managementkonsole und finden Sie AWS CLI unter. [Status und Details des Amazon EMR-Clusters anzeigen](emr-manage-view-clusters.md)
### Detailbereich der Amazon-EMR-Konsole
In der Liste **Cluster** in der Amazon-EMR-Konsole werden allgemeine Informationen über den Status der einzelnen Cluster in Ihrem Konto und Ihrer AWS-Region angezeigt. Die Liste zeigt alle aktiven und beendeten Cluster an, die Sie in den vergangenen zwei Monaten gestartet haben. Sie können in der Liste **Clusters (Cluster)** den **Name (Namen)** eines Clusters auswählen, um Details zu diesem anzuzeigen. Diese Informationen sind in verschiedene Kategorien unterteilt, um das Navigieren zu vereinfachen.
Die auf der Cluster-Detailseite verfügbaren **Anwendungsbenutzeroberflächen** können bei der Fehlerbehebung bei Clustern hilfreich sein. Sie zeigt den Status von YARN-Anwendungen. Bei einigen Anwendungen wie z. B. Spark-Anwendungen können Sie verschiedene Metriken und Facets wie Aufträge, Phasen und Ausführende anzeigen. Weitere Informationen finden Sie unter [Amazon EMR-Anwendungsverlauf anzeigen](emr-cluster-application-history.md). Dieses Feature ist nur mit Amazon-EMR-Versionen 5.8.0 und höher verfügbar.
### Amazon-EMR;-Befehlszeilenschnittstelle
Einzelheiten zu einem Cluster finden Sie in dem AWS CLI mit dem `--describe` Argument.
### Amazon-EMR-API
Sie können die Details eines Cluster in der API mit der Aktion `DescribeJobFlows` abrufen.
## EMR-Cluster-Fehlerdetails anzeigen
Wenn ein EMR-Cluster mit einem Fehler beendet wird, werden ein Fehlercode und eine Fehlermeldung `ListClusters` APIs zurückgegeben. `DescribeCluster` Bei ausgewählten Clusterfehlern kann Ihnen das `ErrorDetail`-Datenarray bei der Behebung des Fehlers helfen.
Eine Liste der Fehlercodes, die `ErrorDetail` Daten enthalten, finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md).
**Anmerkung**
Wir verfeinern unsere Fehlermeldungen kontinuierlich, damit Sie die aktuellsten und relevantesten Informationen erhalten. Es wird nicht empfohlen, den Text von `ErrorMessage` zu analysieren, da sich dieser Text ändern kann.
## Skripts ausführen und Amazon-EMR-Prozesse konfigurieren
Im Rahmen Ihrer Problembehandlung kann es hilfreich sein, benutzerdefinierte Skripts auf Ihrem Cluster auszuführen oder Clusterprozesse anzuzeigen und zu konfigurieren.
### Anwendungsprozesse anzeigen und neu starten
Es kann hilfreich sein, sich die laufenden Prozesse auf Ihrem Cluster anzusehen, um potenzielle Probleme zu diagnostizieren. Sie können Clusterprozesse beenden und neu starten, indem Sie eine Verbindung zum Hauptknoten Ihres Clusters herstellen. Weitere Informationen finden Sie unter [Anzeigen und Neustarten von Amazon-EMR- und Anwendungsprozessen (Daemons)](emr-process-restart-stop-view.md).
### Führen Sie Befehle und Skripts ohne SSH-Verbindung aus
Um als Schritt einen Befehl oder ein Skript auf Ihrem Cluster auszuführen, können Sie die Tools `command-runner.jar` oder `script-runner.jar` verwenden, ohne eine SSH-Verbindung zum Hauptknoten herzustellen. Weitere Informationen finden Sie unter [Befehle und Skripts auf einem Amazon-EMR-Cluster ausführen](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-commandrunner.html).
## Anzeige von -Protokolldateien
Amazon EMR und Hadoop generieren beide Protokolldateien, während der Cluster ausgeführt wird. Sie können auf diese Protokolldateien mit mehreren Tools zugreifen, abhängig von der Konfiguration, die Sie beim Starten des Clusters angegeben haben. Weitere Informationen finden Sie unter [Amazon EMR-Cluster-Protokollierung und Debugging konfigurieren](emr-plan-debugging.md).
### Protokolldateien auf dem Hauptknoten
Jeder Cluster veröffentlicht Protokolldateien im Verzeichnis/mnt/var/log/auf dem Master-Knoten. Diese Protokolldateien sind nur verfügbar, während der Cluster ausgeführt wird.
### So archivieren Sie Protokolldateien in Amazon S3
Wenn Sie den Cluster starten und einen Amazon S3-Protokollpfad angeben, kopiert der Cluster die in/mnt/var/log/auf dem Master-Knoten gespeicherten Protokolldateien in 5-Minuten-Intervallen nach Amazon S3. So wird sichergestellt, dass Sie Zugriff auf die Protokolldateien auch nach Beendigung des Clusters haben. Da die Dateien in 5-Minuten-Intervallen archiviert werden, stehen die letzten Minuten eines unvermittelt beendeten Clusters ggf. nicht zur Verfügung.
## Überwachen Sie die Leistung des EMR-Clusters
Amazon EMR bietet mehrere Tools zur Überwachung der Leistung Ihres Clusters.
### Hadoop-Webschnittstellen
Jeder Cluster veröffentlicht eine Reihe von Webschnittstellen auf dem Master-Knoten, die Informationen über den Cluster enthalten. Sie können auf diese Webseiten über einen SSH-Tunnel zugreifen, um sie auf dem Master-Knoten zu verbinden. Weitere Informationen finden Sie unter [Anzeigen von auf Amazon-EMR-Clustern gehosteten Webschnittstellen](emr-web-interfaces.md).
### CloudWatch Metriken
Jeder Cluster meldet Metriken an CloudWatch. CloudWatch ist ein Webservice, der Metriken verfolgt und mit dem Sie Alarme für diese Metriken einrichten können. Weitere Informationen finden Sie unter [Überwachung von Amazon EMR-Metriken mit CloudWatch](UsingEMR_ViewingMetrics.md).
# Anzeigen und Neustarten von Amazon-EMR- und Anwendungsprozessen (Daemons)
Wenn Sie in einem Cluster Fehler beheben, möchten Sie möglicherweise laufende Prozesse auflisten. Möglicherweise möchten Sie Prozesse auch beenden oder neu starten. Sie können beispielsweise einen Prozess neu starten, nachdem Sie eine Konfiguration geändert haben, oder ein Problem mit einem bestimmten Prozess feststellen, nachdem Sie Protokolldateien und Fehlermeldungen analysiert haben.
Es gibt zwei Arten von Prozessen, die auf einem Cluster ausgeführt werden: Amazon EMR-Prozesse (z. B. Instance-Controller und Log Pusher) und Prozesse, die mit den auf dem Cluster installierten Anwendungen verknüpft sind (z. B., hadoop-hdfs-namenode und). hadoop-yarn-resourcemanager
Um mit Prozessen direkt auf einem Cluster zu arbeiten, stellen Sie eine Verbindung mit dem Hauptknoten her. Weitere Informationen finden Sie unter [Eine Verbindung zu einem Amazon-EMR-Cluster herstellen](emr-connect-master-node.md).
## Anzeigen von ausgeführten Prozessen
Die Methode, mit der Sie laufende Prozesse in einem Cluster anzeigen, unterscheidet sich je nach der von Ihnen verwendeten Amazon-EMR-Version.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : Listet alle laufenden Prozesse auf**
Im folgenden Beispiel wird `systemctl` verwendet und `--type` angegeben, um alle Prozesse anzuzeigen.
```
systemctl --type=service
```
**Example : Listet bestimmte Prozesse auf**
Im folgenden Beispiel werden alle Prozesse aufgeführt, deren Namen `hadoop` enthalten.
```
systemctl --type=service | grep -i hadoop
```
Beispielausgabe:
```
hadoop-hdfs-namenode.service loaded active running Hadoop namenode
hadoop-httpfs.service loaded active running Hadoop httpfs
hadoop-kms.service loaded active running Hadoop kms
hadoop-mapreduce-historyserver.service loaded active running Hadoop historyserver
hadoop-state-pusher.service loaded active running Daemon process that processes and serves EMR metrics data.
hadoop-yarn-proxyserver.service loaded active running Hadoop proxyserver
hadoop-yarn-resourcemanager.service loaded active running Hadoop resourcemanager
hadoop-yarn-timelineserver.service loaded active running Hadoop timelineserver
```
**Example : Sehen Sie sich einen detaillierten Statusbericht für einen bestimmten Prozess an**
Im folgenden Beispiel wird ein detaillierter Statusbericht für den `hadoop-hdfs-namenode`-Service angezeigt.
```
sudo systemctl status hadoop-hdfs-namenode
```
Beispielausgabe:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:01:46 UTC; 26min ago
Main PID: 9733 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 9733 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p ...
Aug 18 21:01:37 ip-172-31-20-123 systemd[1]: Starting Hadoop namenode...
Aug 18 21:01:37 ip-172-31-20-123 su[9715]: (to hdfs) root on none
Aug 18 21:01:37 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: starting namenode, logging to /var/log/hadoop-hdfs/ha...out
Aug 18 21:01:46 ip-172-31-20-123 hadoop-hdfs-namenode[9683]: Started Hadoop namenode:[ OK ]
Aug 18 21:01:46 ip-172-31-20-123 systemd[1]: Started Hadoop namenode.
Hint: Some lines were ellipsized, use -l to show in full.
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : Listet alle laufenden Prozesse auf**
Das folgende Beispiel listet alle laufenden Prozesse auf.
```
initctl list
```
------
#### [ EMR 2.x - 3.x ]
**Example : Listet alle laufenden Prozesse auf**
Das folgende Beispiel listet alle laufenden Prozesse auf.
```
ls /etc/init.d/
```
------
## Beenden und Neustarten von Prozessen
Nachdem Sie bestimmen, welche Prozesse ausgeführt werden, können Sie diese beenden und dann neu starten.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : Stoppt einen Prozess**
Das folgende Beispiel stoppt den `hadoop-hdfs-namenode`-Prozess.
```
sudo systemctl stop hadoop-hdfs-namenode
```
Sie können `status` abfragen, um zu überprüfen, ob der Prozess gestoppt wurde.
```
sudo systemctl status hadoop-hdfs-namenode
```
Beispielausgabe:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Wed 2021-08-18 21:37:50 UTC; 8s ago
Main PID: 9733 (code=exited, status=143)
```
**Example : Startet einen Prozess**
Das folgende Beispiel startet den `hadoop-hdfs-namenode`-Prozess.
```
sudo systemctl start hadoop-hdfs-namenode
```
Sie können den Status überprüfen, um sicherzustellen, dass der Prozess ausgeführt wird.
```
sudo systemctl status hadoop-hdfs-namenode
```
Beispielausgabe:
```
hadoop-hdfs-namenode.service - Hadoop namenode
Loaded: loaded (/etc/systemd/system/hadoop-hdfs-namenode.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-08-18 21:38:24 UTC; 2s ago
Process: 13748 ExecStart=/etc/init.d/hadoop-hdfs-namenode start (code=exited, status=0/SUCCESS)
Main PID: 13800 (java)
Tasks: 0
Memory: 1.1M
CGroup: /system.slice/hadoop-hdfs-namenode.service
‣ 13800 /etc/alternatives/jre/bin/java -Dproc_namenode -Xmx1843m -server -XX:OnOutOfMemoryError=kill -9 %p...
```
------
#### [ EMR 4.x - 5.29.0 ]
**Example : Stoppt einen laufenden Prozess**
Im folgenden Beispiel wird der `hadoop-hdfs-namenode`-Service gestoppt.
```
sudo stop hadoop-hdfs-namenode
```
**Example : Startet einen gestoppten Prozess neu**
Im folgenden Beispiel wird der `hadoop-hdfs-namenode`-Service neu gestartet. Sie müssen den `start`-Befehl verwenden und nicht `restart`.
```
sudo start hadoop-hdfs-namenode
```
**Example : Überprüfen des Prozessstatus**
Im Folgenden wird der Status für `hadoop-hdfs-namenode` abgerufen. Sie können den `status` Befehl verwenden, um zu überprüfen, ob der Prozess gestoppt oder gestartet wurde.
```
sudo status hadoop-hdfs-namenode
```
------
#### [ EMR 2.x - 3.x ]
**Example : Beenden eines Anwendungsprozesses**
Im folgenden Beispiel wird der `hadoop-hdfs-namenode`-Service beendet, der mit der auf dem Cluster installierten Version von Amazon EMR verknüpft ist.
```
sudo /etc/init.d/hadoop-hdfs-namenode stop
```
**Example : Startet einen Anwendungsprozess neu**
Geben Sie den folgenden Befehl ein, um den Prozess `hadoop-hdfs-namenode` neu zu starten:
```
sudo /etc/init.d/hadoop-hdfs-namenode start
```
**Example : Beendet einen Amazon-EMR-Prozesses**
Das folgende Beispiel stoppt einen Prozess, wie z. B. instance-controller, der nicht mit der Version von Amazon EMR auf dem Cluster verknüpft ist.
```
sudo /sbin/stop instance-controller
```
**Example : Neustart eines Amazon-EMR-Prozesses**
Im folgenden Beispiel wird ein Prozess neu gestartet, z. B. instance-Controller, der nicht mit der Version von Amazon EMR auf dem Cluster verknüpft ist.
```
sudo /sbin/start instance-controller
```
**Anmerkung**
Die Befehle `/sbin/start, stop` und `restart` sind symbolische Links zu `/sbin/intictl`. Weitere Informationen zu `initctl`finden Sie auf der initctl man-Seite. Geben Sie `man initctl` in die Befehlszeile ein.
------
# Sammlungen häufiger Fehler in Amazon EMR
Manchmal schlagen Cluster fehl oder verarbeiten Daten nur langsam. In den folgenden Abschnitten werden häufig auftretende Probleme mit Clustern aufgeführt. Zu den Fehlern gehören Bootstrap-Fehler und Validierungsfehler sowie Vorschläge zu deren Behebung.
**Topics**
+ [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md)
+ [Ressourcenfehler bei Amazon EMR-Clustervorgängen](emr-troubleshoot-error-resource.md)
+ [Cluster-Eingabe- und Ausgabefehler bei Amazon EMR-Vorgängen](emr-troubleshoot-errors-io.md)
+ [Berechtigungsfehler bei Amazon EMR-Clustervorgängen](emr-troubleshoot-error-permissions.md)
+ [Hive-Cluster-Fehler](emr-troubleshoot-error-hive.md)
+ [VPC-Fehler bei Amazon EMR-Clustervorgängen](emr-troubleshoot-error-vpc.md)
+ [Fehler beim Streaming von Amazon EMR-Clustern](emr-troubleshoot-error-streaming.md)
+ [Amazon EMR: Fehler beim benutzerdefinierten JAR-Cluster](emr-troubleshoot-error-custom-jar.md)
+ [Fehler bei Amazon EMR AWS GovCloud (US-West)](emr-troubleshoot-error-govcloud.md)
+ [Finden Sie einen fehlenden Cluster](#w2aac36c21c47)
# Fehlercodes mit ErrorDetail Informationen in Amazon EMR
Wenn ein EMR-Cluster mit einem Fehler beendet wird, werden ein Fehlercode und eine Fehlermeldung `ListClusters` APIs zurückgegeben. `DescribeCluster` Bei einigen Clusterfehlern kann Ihnen das `ErrorDetail`-Datenarray bei der Behebung des Fehlers helfen.
Fehler, die ein `ErrorDetail`-Array beinhalten, enthalten die folgenden Informationen:
**`ErrorCode`**
Ein eindeutiger Fehlercode, den Sie für den programmatischen Zugriff verwenden können.
**`ErrorData`**
Eine Liste von Bezeichnern in Schlüssel-Wert-Paaren, die Sie für die Programmierung oder die manuelle Suche verwenden können. Eine Beschreibung der `ErrorData` Werte, die ein Fehlercode enthält, finden Sie auf der Seite zur Problembehandlung für den Fehlercode.
**`ErrorMessage`**
Beschreibung des Fehlers mit einem Link zu weiteren Informationen in der Amazon-EMR-Dokumentation.
Es wird nicht empfohlen, den Text von `ErrorMessage` zu analysieren, da sich dieser Text ändern kann.
**Topics**
+ [Bootstrap-Fehler](emr-troubleshoot-error-errordetail-bootstrap.md)
+ [Interne Fehler](emr-troubleshoot-error-errordetail-internal.md)
+ [Validierungsfehler](emr-troubleshoot-error-errordetail-validation.md)
# Bootstrap-Fehlercodes in Amazon EMR
Die folgenden Abschnitte enthalten Informationen zur Fehlerbehebung bei Bootstrap-Fehlercodes.
**Topics**
+ [BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE](BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE.md)
+ [BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY](BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY](BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER](BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY.md)
+ [BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER](BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER.md)
# BOOTSTRAP\$1FAILURE\$1PRIMARY\$1WITH\$1NON\$1ZERO\$1CODE
## -Übersicht
Wenn ein Cluster mit einem `BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE`-Fehler beendet wird, ist eine Bootstrap-Aktion in der primären Instance fehlgeschlagen. Weitere Informationen zu Bootstrap-Aktionen finden Sie unter [Erstellen Sie Bootstrap-Aktionen, um zusätzliche Software mit einem Amazon EMR-Cluster zu installieren](emr-plan-bootstrap.md).
## Auflösung
Um diesen Fehler zu beheben, überprüfen Sie die im API-Fehler zurückgegebenen Details, ändern Sie Ihr Bootstrap-Aktionsskript und erstellen Sie einen neuen Cluster mit der aktualisierten Bootstrap-Aktion.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`primary-instance-id`**
Die ID der primären Instance, bei der die Bootstrap-Aktion fehlgeschlagen ist.
**`bootstrap-action`**
Die Ordinalzahl für die fehlgeschlagene Bootstrap-Aktion. Ein Skript mit dem `bootstrap-action`-Wert von `1` ist die erste Bootstrap-Aktion, die auf der Instance ausgeführt wird.
**`return-code`**
Der Rückgabecode für die fehlgeschlagene Bootstrap-Aktion.
**`amazon-s3-path`**
Der Amazon-S3-Speicherort der Bootstrap-Aktion, die fehlgeschlagen ist.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Gehen Sie wie folgt vor, um die Ursache des Bootstrap-Aktionsfehlers zu ermitteln und zu beheben. Starten Sie dann einen neuen Cluster.
1. Überprüfen Sie die Bootstrap-Aktionsprotokolldateien in Amazon S3, um die Hauptursache für den Fehler zu ermitteln. Weitere Informationen zum Anzeigen von Amazon-EMR-Protokollen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
1. Wenn Sie bei der Erstellung der Instance Cluster-Protokolle aktiviert haben, finden Sie weitere Informationen im `stdout`-Protokoll. Sie finden das `stdout`-Protokoll für die Bootstrap-Aktion an diesem Amazon-S3-Speicherort:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Weitere Informationen zu Clusterprotokollen finden Sie im Abschnitt [Amazon EMR-Cluster-Protokollierung und Debugging konfigurieren](emr-plan-debugging.md).
1. Um festzustellen, ob die Bootstrap-Aktion fehlgeschlagen ist, überprüfen Sie die Ausnahmen in den `stdout`-Protokollen und den `return-code`-Wert in `ErrorData`.
1. Verwenden Sie Ihre Ergebnisse aus dem vorherigen Schritt, um Ihre Bootstrap-Aktion so zu überarbeiten, dass Ausnahmen vermieden werden oder Ausnahmen ordnungsgemäß behandelt werden können, wenn sie auftreten.
1. Starten Sie einen neuen Cluster mit Ihrer aktualisierten Bootstrap-Aktion.
# BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY
## -Übersicht
Ein Cluster wird mit dem `BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY`-Fehler beendet, wenn die primäre Instance kein Bootstrap-Aktionsskript von dem von Ihnen angegebenen Amazon-S3-Speicherort herunterladen kann. Zu den potentiellen Ursachen zählen auch die Folgenden:
+ Die Bootstrap-Aktionsskriptdatei befindet sich nicht am angegebenen Amazon-S3-Speicherort.
+ Die Servicerolle für Amazon-EC2-Instances auf dem Cluster (auch *EC2-Instance-Profil für Amazon EMR genannt) hat keine Berechtigungen für* den Zugriff auf den Amazon-S3-Bucket, in dem sich das Bootstrap-Aktionsskript befindet. Weitere Informationen zu Servicerollen finden Sie unter [Servicerolle für EC2-Cluster-Instances (EC2-Instance-Profil)](emr-iam-role-for-ec2.md).
Weitere Informationen zu Bootstrap-Aktionen finden Sie unter [Erstellen Sie Bootstrap-Aktionen, um zusätzliche Software mit einem Amazon EMR-Cluster zu installieren](emr-plan-bootstrap.md).
## Auflösung
Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihre primäre Instance über angemessenen Zugriff auf das Bootstrap-Aktionsskript verfügt.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`primary-instance-id`**
Die ID der primären Instance, bei der die Bootstrap-Aktion fehlgeschlagen ist.
**`bootstrap-action`**
Die Ordinalzahl für die fehlgeschlagene Bootstrap-Aktion. Ein Skript mit dem `bootstrap-action`-Wert von `1` ist die erste Bootstrap-Aktion, die auf der Instance ausgeführt wird.
**`amazon-s3-path`**
Der Amazon-S3-Speicherort der Bootstrap-Aktion, die fehlgeschlagen ist.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Gehen Sie wie folgt vor, um die Ursache des Bootstrap-Aktionsfehlers zu ermitteln und zu beheben. Starten Sie dann einen neuen Cluster.
**Fehlerbehebungsschritte**
1. Verwenden Sie den `amazon-s3-path`-Wert aus dem `ErrorData`-Array, um das entsprechende Bootstrap-Aktionsskript in Amazon S3 zu finden.
1. Wenn Sie bei der Erstellung der Instance Cluster-Protokolle aktiviert haben, finden Sie weitere Informationen im `stdout`-Protokoll. Sie finden das `stdout`-Protokoll für die Bootstrap-Aktion an diesem Amazon-S3-Speicherort:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Weitere Informationen zu Clusterprotokollen finden Sie im Abschnitt [Amazon EMR-Cluster-Protokollierung und Debugging konfigurieren](emr-plan-debugging.md).
1. Um festzustellen, ob die Bootstrap-Aktion fehlgeschlagen ist, überprüfen Sie die Ausnahmen in den `stdout`-Protokollen und den `return-code`-Wert in `ErrorData`.
1. Verwenden Sie Ihre Ergebnisse aus dem vorherigen Schritt, um Ihre Bootstrap-Aktion so zu überarbeiten, dass Ausnahmen vermieden werden oder Ausnahmen ordnungsgemäß behandelt werden können, wenn sie auftreten.
1. Starten Sie einen neuen Cluster mit Ihrer aktualisierten Bootstrap-Aktion.
# BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY
## -Übersicht
Der `BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY`-Fehler weist darauf hin, dass die primäre Instance das Bootstrap-Aktionsskript nicht finden kann, das die Instance gerade aus dem angegebenen Amazon-S3-Bucket heruntergeladen hat.
## Auflösung
Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihre primäre Instance über angemessenen Zugriff auf das Bootstrap-Aktionsskript verfügt.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`primary-instance-id`**
Die ID der primären Instance, bei der die Bootstrap-Aktion fehlgeschlagen ist.
**`bootstrap-action`**
Die Ordinalzahl für die fehlgeschlagene Bootstrap-Aktion. Ein Skript mit dem `bootstrap-action`-Wert von `1` ist die erste Bootstrap-Aktion, die auf der Instance ausgeführt wird.
**`amazon-s3-path`**
Der Amazon-S3-Speicherort der Bootstrap-Aktion, die fehlgeschlagen ist.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Gehen Sie wie folgt vor, um die Ursache des Bootstrap-Aktionsfehlers zu ermitteln und zu beheben. Starten Sie dann einen neuen Cluster.
1. Verwenden Sie den `amazon-s3-path`-Wert aus dem `ErrorData`-Array, um das entsprechende Bootstrap-Aktionsskript in Amazon S3 zu finden.
1. Überprüfen Sie die Bootstrap-Aktionsprotokolldateien in Amazon S3, um die Hauptursache für den Fehler zu ermitteln. Weitere Informationen zum Anzeigen von Amazon-EMR-Protokollen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
**Anmerkung**
Wenn Sie die Protokolle für Ihren Cluster nicht aktiviert haben, müssen Sie einen neuen Cluster mit denselben Konfigurationen und Bootstrap-Aktionen erstellen. Informationen dazu, wie Sie sicherstellen können, dass die Clusterprotokolle aktiviert sind, finden Sie unter [Amazon EMR-Cluster-Protokollierung und Debugging konfigurieren](emr-plan-debugging.md).
1. Überprüfen Sie das `stdout`-Protokoll auf Ihre Bootstrap-Aktionen und stellen Sie sicher, dass es keine benutzerdefinierten Prozesse gibt, die Dateien im `/emr/instance-controller/lib/bootstrap-actions`-Ordner auf Ihren primären Instances löschen. Sie finden das `stdout`-Protokoll für die Bootstrap-Aktion an diesem Amazon-S3-Speicherort:
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
1. Starten Sie einen neuen Cluster mit Ihrer aktualisierten Bootstrap-Aktion.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY
## -Übersicht
Der `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY` Fehler weist darauf hin, dass die primäre Instanz bei der Installation der erforderlichen Software nicht über genügend Festplattenspeicher verfügt.
## Auflösung
Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihre primäre Instanz über ausreichend Speicherplatz auf dem Root-Volume verfügt.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`primary-instance-id`**
Die ID der primären Instanz mit unzureichendem Festplattenspeicher.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
1. Informieren Sie sich über die bewährten Methoden für das EBS-Root-Geräte-Volume Ihres Clusters. Weitere Informationen finden Sie unter [Anpassen des Root-Geräte-Volumes in Amazon EBS](emr-custom-ami-root-volume-size.md) im *Verwaltungshandbuch für Amazon EMR*.
1. Starten Sie einen neuen Cluster mit einem größeren EBS-Root-Geräte-Volume.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1WORKER
## -Übersicht
Der `BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER` Fehler weist darauf hin, dass eine oder mehrere Worker-Instanzen bei der Installation der erforderlichen Software nicht über genügend Speicherplatz verfügen.
## Auflösung
Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihre Worker-Instanzen über ausreichend Speicherplatz auf dem Root-Volume verfügen.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`worker-instance-ids`**
Die IDs der Worker-Instanzen mit unzureichendem Festplattenspeicher.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
1. Informieren Sie sich über die bewährten Methoden für das EBS-Root-Geräte-Volume Ihres Clusters. Weitere Informationen finden Sie unter [Anpassen des Root-Geräte-Volumes in Amazon EBS](emr-custom-ami-root-volume-size.md) im *Verwaltungshandbuch für Amazon EMR*.
1. Starten Sie einen neuen Cluster mit einem größeren EBS-Root-Geräte-Volume.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY
## -Übersicht
Der `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY` Fehler weist darauf hin, dass die primäre Instanz keine Verbindung zum konfigurierten externen Hive Metastore herstellen kann.
## Auflösung
Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihr externer Hive Metastore ordnungsgemäß konfiguriert ist und dass die primäre Instanz eine Verbindung zu ihm herstellen darf.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`primary-instance-id`**
Die ID der primären Instanz, die keine Verbindung zum konfigurierten externen Hive Metastore herstellen konnte.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
1. Lesen Sie die bewährten Methoden für die Konfiguration eines externen Metastores für Hive. Siehe [Konfiguration eines externen Metastores](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html) für Hive.
1. Starten Sie einen neuen Cluster mit Ihrer aktualisierten Cluster-Konfiguration.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER
## -Übersicht
Der `BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER` Fehler weist darauf hin, dass eine oder mehrere Worker-Instanzen keine Verbindung zum konfigurierten externen Hive Metastore herstellen können.
## Auflösung
Um diesen Fehler zu beheben, stellen Sie sicher, dass Ihr externer Hive Metastore ordnungsgemäß konfiguriert ist und dass die Worker-Instanzen eine Verbindung zu ihm herstellen dürfen.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`worker-instance-ids`**
Die IDs Worker-Instances konnten keine Verbindung zum konfigurierten externen Hive Metastore herstellen.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
1. Lesen Sie die bewährten Methoden für die Konfiguration eines externen Metastores für Hive. Siehe [Konfiguration eines externen Metastores](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html) für Hive.
1. Starten Sie einen neuen Cluster mit Ihrer aktualisierten Cluster-Konfiguration.
# Interne Fehlercodes für Amazon EMR
Die folgenden Abschnitte enthalten Informationen zur Fehlerbehebung für interne Fehlercodes, einschließlich Codes für unzureichende oder fehlende Kapazität.
**Topics**
+ [EC2INTERNAL\$1ERROR\$1 \$1INSUFFICIENT\$1CAPACITY\$1AZ](INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY](INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY.md)
+ [INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY](INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY.md)
# EC2INTERNAL\$1ERROR\$1 \$1INSUFFICIENT\$1CAPACITY\$1AZ
## -Übersicht
Ein Cluster wird mit einem `INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ`-Fehler beendet, wenn die ausgewählte Availability Zone nicht über genügend Kapazität verfügt, um Ihre Anfrage vom Amazon-EC2-Instance-Typ zu erfüllen. Die Availability Zone ist von dem von Ihnen für einen Cluster ausgewählten Subnetz abhängig. Weitere Informationen über die Amazon-EMR-Unterstützung erhalten Sie unter [Konfiguration von Netzwerken in einer VPC für Amazon EMR](emr-plan-vpc-subnet.md).
## Auflösung
Um diesen Fehler zu beheben, ändern Sie Ihre Instance-Typ-Konfigurationen und erstellen Sie einen neuen Cluster mit Ihrer aktualisierten Anfrage.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`instance-type`**
Der Instance-Typ, dessen Kapazität aufgebraucht ist.
**`availability-zone`**
Die Availability Zone, in die Ihr Subnetz aufgelöst wird.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Gehen Sie wie folgt vor, um die Ursache des Cluster Konfigurationsfehlers zu ermitteln und zu beheben:
+ Für andere Clusterkonfiguration lesen Sie die bewährten Methoden. Weitere Informationen finden Sie unter [Konfiguration von Amazon EMR-Cluster-Instance-Typen und Best Practices für Spot-Instances](emr-plan-instances-guidelines.md) im *Verwaltungshandbuch für Amazon EMR*.
+ Beheben Sie die Startprobleme und überprüfen Sie Ihre Konfiguration. Weitere Informationen finden Sie unter [Beheben von Problemen beim Starten von Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ Starten Sie einen neuen Cluster mit Ihrer aktualisierten Cluster-Konfiguration.
# INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY
## -Übersicht
Ein Cluster wird mit einem `INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY`-Fehler beendet, wenn Amazon EMR Ihre Spot Instance-Anfrage für den Primärknoten nicht erfüllen kann, weil Instances nicht zu oder unter Ihrem maximalen Spot-Preis verfügbar sind. Weitere Informationen finden Sie unter [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) im *Amazon-EC2-Benutzerhandbuch*.
## Auflösung
Um diesen Fehler zu beheben, geben Sie Instance-Typen für Ihren Cluster an, die innerhalb Ihres Preisziels liegen, oder erhöhen Sie Ihr Preislimit für denselben Instance-Typ.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`primary-instance-id`**
Die ID für die primäre Instance des Clusters, die fehlgeschlagen ist.
**`instance-type`**
Der Instance-Typ, dessen Kapazität aufgebraucht ist.
**`availability-zone`**
Die Availability Zone, in der sich Ihr Subnetz befindet.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Führen Sie die folgenden Schritte aus, um Probleme mit Ihrer Cluster-Konfigurationsstrategie zu beheben, und starten Sie dann einen neuen Cluster:
1. Lesen Sie die bewährten Methoden für Spot Instances in Amazon EC2 und überprüfen Sie Ihre Cluster-Konfigurationsstrategie. Weitere Informationen finden Sie unter [Bewährte Methoden für EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) im *Amazon EC2 EC2-Benutzerhandbuch* und. [Konfiguration von Amazon EMR-Cluster-Instance-Typen und Best Practices für Spot-Instances](emr-plan-instances-guidelines.md)
1. Um diesen Fehler zu beheben, ändern Sie Ihre Instance-Typ-Konfigurationen oder Availability Zone und erstellen Sie einen neuen Cluster mit Ihrer aktualisierten Anfrage.
1. Wenn das Problem weiterhin besteht, verwenden Sie On-Demand-Kapazität für Ihre primäre Instance.
# INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY
## -Übersicht
Ein Cluster wird mit einem `INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY`-Fehler beendet, wenn nicht genügend Kapazität vorhanden ist, um eine Spot-Instance-Anfrage für Ihren Primärknoten zu erfüllen. Weitere Informationen finden Sie unter [Spot Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) im *Amazon-EC2-Benutzerhandbuch*.
## Auflösung
Um diesen Fehler zu beheben, geben Sie Instance-Typen für Ihren Cluster an, die innerhalb Ihres Preisziels liegen, oder erhöhen Sie Ihr Preislimit für denselben Instance-Typ.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`primary-instance-id`**
Die ID für die primäre Instance des Clusters, die fehlgeschlagen ist.
**`instance-type`**
Der Instance-Typ, dessen Kapazität aufgebraucht ist.
**`availability-zone`**
Die Availability Zone, in die Ihr Subnetz aufgelöst wird.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Führen Sie die folgenden Schritte aus, um Probleme mit Ihrer Cluster-Konfigurationsstrategie zu beheben, und starten Sie dann einen neuen Cluster:
1. Lesen Sie die bewährten Methoden für Spot Instances in Amazon EC2 und überprüfen Sie Ihre Cluster-Konfigurationsstrategie. Weitere Informationen finden Sie unter [Bewährte Methoden für EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) im *Amazon EC2 EC2-Benutzerhandbuch* und. [Konfiguration von Amazon EMR-Cluster-Instance-Typen und Best Practices für Spot-Instances](emr-plan-instances-guidelines.md)
1. Ändern Sie Ihre Instance-Typ-Konfigurationen und erstellen Sie einen neuen Cluster mit Ihrer aktualisierten Anfrage.
1. Wenn das Problem weiterhin besteht, verwenden Sie On-Demand-Kapazität für Ihre primäre Instance.
# Fehlercodes für Validierungsfehler in Amazon EMR
Die folgenden Abschnitte enthalten Informationen zur Fehlerbehebung bei Validierung-Fehlercodes.
**Topics**
+ [VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC](VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC.md)
+ [VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME](VALIDATION_ERROR_INVALID_SSH_KEY_NAME.md)
+ [VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED](VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED.md)
# VALIDATION\$1ERROR\$1SUBNET\$1NOT\$1FROM\$1ONE\$1VPC
## -Übersicht
Wenn Ihr Cluster und die Subnetze, auf die Sie für Ihren Cluster verweisen, zu verschiedenen virtuellen privaten Clouds (VPCs) gehören, wird der Cluster mit einem Fehler beendet. `VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC` Sie können Cluster mit Amazon EMR mit der Konfiguration der Instance-Flotten in allen Subnetzen in einer VPC starten. Weitere Informationen über Instance-Flotten finden Sie unter [Planung und Konfiguration von Instance-Flotten für Ihren Amazon EMR-Cluster](emr-instance-fleet.md) im *Verwaltungshandbuch für Amazon EMR*.
## Auflösung
Verwenden Sie Subnetze, die zur gleichen VPC gehören wie der Cluster, um diesen Fehler zu beheben.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`vpc`**
Für jedes Subnetz:VPC-Paar die ID für die VPC, der das Subnetz angehört.
**`subnet`**
Für jedes Subnetz:VPC-Paar die ID für das Subnetz.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Führen Sie die folgenden Schritte aus, um den Fehler zu identifizieren und zu beheben:
1. Überprüfen Sie die Subnetze IDs , die im `ErrorData` Array aufgeführt sind, und stellen Sie sicher, dass sie zu der VPC gehören, in der Sie den EMR-Cluster starten möchten.
1. Ändern Sie Ihre Subnetzkonfigurationen. Sie können eine der folgenden Methoden verwenden, um alle verfügbaren öffentlichen und privaten Subnetze in einer VPC zu finden.
+ Navigieren Sie zur Amazon-VPC-Konsole. Wählen Sie **Subnetze** und listen Sie alle Subnetze auf, die sich in Ihrem Cluster befinden. AWS-Region Um nur öffentliche oder private Subnetze zu finden, wenden Sie den Filter Öffentliche Adresse **automatisch** zuweisen an. IPv4 Um Subnetze in der von Ihrem Cluster verwendeten VPC zu finden und auszuwählen, verwenden Sie die Option **Nach VPC filtern**. Weitere Informationen zum Erstellen von Subnetzen finden Sie unter [Erstellen eines Subnetzes](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) im *Benutzerhandbuch von Amazon Virtual Private Cloud*.
+ Verwenden Sie den AWS CLI , um alle verfügbaren öffentlichen und privaten Subnetze in der VPC zu finden, die Ihr Cluster verwendet. Weitere Informationen finden Sie in der [describe-subnets](https://amazonaws.com/ec2/describe-subnets.html)-API. Informationen zum Erstellen neuer Subnetze in einer VPC finden Sie in der [create-subnet](https://amazonaws.com/ec2/create-subnet.html)-API.
1. Starten Sie einen neuen Cluster mit Subnetzen aus derselben VPC wie der Cluster.
# VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC
## -Übersicht
Wenn Ihr Cluster und die Sicherheitsgruppen, die Sie Ihrem Cluster zuweisen, zu verschiedenen virtuellen privaten Clouds (VPCs) gehören, wird der Cluster mit einem Fehler beendet. `VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC` Weitere Informationen zu Sicherheitsgruppen finden Sie unter [Angeben von Amazon-EMR-verwalteten und zusätzlichen Sicherheitsgruppen](emr-sg-specify.md) und [Steuern Sie den Netzwerkverkehr mit Sicherheitsgruppen für Ihren Amazon EMR-Cluster](emr-security-groups.md).
## Auflösung
Um diesen Fehler zu beheben, verwenden Sie Sicherheitsgruppen, die zu derselben VPC gehören wie der Cluster.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`vpc`**
Für jedes Security-Group:VPC-Paar die ID für die VPC, zu der die Sicherheitsgruppe gehört.
**`security-group`**
Für jedes Security-Group:VPC-Paar die ID für die Sicherheitsgruppe.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Führen Sie die folgenden Schritte aus, um den Fehler zu identifizieren und zu beheben:
1. Überprüfen Sie die Sicherheitsgruppe IDs , die im `ErrorData` Array aufgeführt ist, und stellen Sie sicher, dass sie zu der VPC gehören, auf der Sie den EMR-Cluster starten möchten.
1. Navigieren Sie zur Amazon-VPC-Konsole. Wählen Sie **Sicherheitsgruppen** aus, um alle Sicherheitsgruppen in der ausgewählten Region aufzulisten. Suchen Sie die Sicherheitsgruppen aus derselben VPC wie Ihr Cluster und ändern Sie dann Ihre Sicherheitsgruppenkonfiguration.
1. Starten Sie einen neuen Cluster mit Sicherheitsgruppen aus derselben VPC wie der Cluster.
# VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME
## -Übersicht
Ein Cluster wird mit einem `VALIDATION_ERROR_INVALID_SSH_KEY_NAME`-Fehler beendet, wenn Sie ein Amazon-EC2-Schlüsselpaar verwenden, das für SSH-Verbindungen zur primären Instance nicht gültig ist. Der Name des Schlüsselpaars ist möglicherweise falsch, oder das key pair ist in der angeforderten Datei nicht vorhanden AWS-Region. Weitere Informationen zu Schlüsselpaaren finden Sie unter [Amazon EC2 EC2-Schlüsselpaare und Linux-Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
## Auflösung
Um diesen Fehler zu beheben, erstellen Sie einen neuen Cluster mit einem gültigen SSH-Schlüsselpaarnamen.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`ssh-key`**
Der Name des SSH-Schlüsselpaars, den Sie bei der Erstellung des Clusters angegeben haben.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Führen Sie die folgenden Schritte aus, um den Fehler zu identifizieren und zu beheben:
1. Überprüfen Sie Ihre *keypair* PEM-Datei und vergewissern Sie sich, dass sie mit dem Namen des SSH-Schlüssels übereinstimmt, den Sie in der Amazon EMR-Konsole sehen.
1. Navigieren Sie zur Amazon-EC2-Konsole. Stellen Sie sicher, dass der SSH-Schlüsselname, den Sie verwendet haben, in dem, den AWS-Region Ihr Cluster verwendet, verfügbar ist. Sie finden Ihre ID AWS-Region neben Ihrer Konto-ID oben im AWS-Managementkonsole.
1. Starten Sie einen neuen Cluster mit einem gültigen SSH-Schlüsselnamen.
# VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED
## -Übersicht
Ein Cluster wird mit einem `VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED`-Fehler beendet, wenn die AWS-Region und Availability Zones für Ihren Cluster den angegebenen Instance-Typ für eine oder mehrere Instance-Gruppen nicht unterstützen. Amazon EMR unterstützt möglicherweise einen Instance-Typ in einer Availability Zone innerhalb einer Region, aber nicht in einer anderen. Die Availability Zone innerhalb der Region ist von dem von Ihnen für einen Cluster ausgewählten Subnetz abhängig. Eine Liste der Instance-Typen und -Regionen, die Amazon EMR unterstützt, finden Sie unter [Unterstützte Instance-Typen mit Amazon EMR](emr-supported-instance-types.md).
## Auflösung
Um diesen Fehler zu beheben, geben Sie Instance-Typen für Ihren Cluster an, die Amazon EMR in der Region und Availability Zone unterstützt, in der Sie den Cluster anfordern.
Informationen zur Behebung des ausgefallenen EMR-Clusters finden Sie in den `ErrorDetail` Informationen, die von `DescribeCluster` und `ListClusters` APIs zurückgegeben wurden. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md). Das in `ErrorDetail` enthaltene `ErrorData`-Array gibt die folgenden Informationen für diesen Fehlercode zurück:
**`instance-types`**
Die Liste der nicht unterstützten Instance-Typen.
**`availability-zones`**
Die Availability Zone Liste, in die Ihr Subnetz aufgelöst wird.
**`public-doc`**
Die öffentliche URL der Dokumentation für den Fehlercode.
## Schritte zum Absolvieren
Führen Sie die folgenden Schritte aus, um den Fehler zu identifizieren und zu beheben:
1. Verwenden Sie den AWS CLI , um die verfügbaren Instance-Typen in einer Availability Zone abzurufen. Zu diesem Zweck können Sie den `[ec2 describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)` Befehl verwenden, um verfügbare Instance-Typen nach Standort (AWS-Region oder Availability Zone) zu filtern. Beispielsweise können Sie den folgenden Befehl verwenden, um die Instance-Typen anzuzeigen, die in der angegebenen AZ angeboten werden. `us-east-2a`
```
aws ec2 describe-instance-type-offerings --location-type "availability-zone" --filters Name=location,Values=us-east-2a --region us-east-2 --query "InstanceTypeOfferings[*].[InstanceType]" --output text | sort
```
Weitere Informationen darüber, wie Sie verfügbare Instance-Typen ermitteln können, finden Sie unter [Suchen eines Amazon-EC2-Instance-Typs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
1. Nachdem Sie die Instance-Typen ermittelt haben, die in derselben Region und Availability Zone wie der Cluster verfügbar sind, wählen Sie eine der folgenden Lösungen, um fortzufahren:
1. Erstellen Sie einen neuen Cluster und wählen Sie ein Subnetz für den Cluster aus, das sich in einer Availability Zone befindet, in der der von Ihnen ausgewählte Instance-Typ verfügbar ist und von Amazon EMR unterstützt wird.
1. Erstellen Sie einen neuen Cluster in derselben Region und demselben Amazon-EC2-Subnetz wie der ausgefallene Cluster, jedoch mit einem Instance-Typ, der an diesem Standort von Amazon EMR unterstützt wird.
Eine Liste der Instance-Typen und -Regionen, die Amazon EMR unterstützt, finden Sie unter [Unterstützte Instance-Typen mit Amazon EMR](emr-supported-instance-types.md). Informationen zum Vergleichen der Funktionen der Instance-Typen finden Sie unter [Amazon-EC2-Instance-Typen](https://aws.amazon.com/ec2/instance-types).
# Ressourcenfehler bei Amazon EMR-Clustervorgängen
Die folgenden Fehler werden häufig durch eingeschränkte Ressourcen im Cluster verursacht. Die Anleitung beschreibt jeden Fehler und bietet Hilfe bei der Fehlerbehebung.
**Topics**
+ [Der Amazon EMR-Cluster endet mit NO\$1SLAVE\$1LEFT und den Kernknoten FAILED\$1BY\$1MASTER](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md)
+ [Amazon EMR-Clusterfehler: Block kann nicht repliziert werden, es konnte nur auf Nullknoten repliziert werden.](enough-hdfs-space.md)
+ [Amazon EMR-Clusterfehler: EC2-KONTINGENT ÜBERSCHRITTEN](emr-EC2.md)
+ [Amazon EMR-Clusterfehler: Zu viele Abruffehler](emr-troubleshoot-error-resource-1.md)
+ [Amazon EMR-Clusterfehler: Datei konnte nur auf 0 statt auf 1 Knoten repliziert werden](emr-troubleshoot-error-resource-2.md)
+ [Amazon EMR-Clusterfehler: Knoten auf der Deni-List-Liste](emr-troubleshoot-error-resource-3.md)
+ [Drosselungsfehler mit einem Amazon EMR-Cluster](emr-throttling-error.md)
+ [Amazon EMR-Clusterfehler: Instanztyp wird nicht unterstützt](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md)
+ [Amazon EMR-Clusterfehler: EC2 hat keine Kapazität](emr-EC2_INSUFFICIENT_CAPACITY-error.md)
+ [Amazon EMR-Clusterfehler: HDFS-Replikationsfaktorfehler](emr-hdfs-insufficient-replication.md)
+ [Amazon EMR-Clusterfehler: HDFS-Fehler mit unzureichendem Speicherplatz](emr-hdfs-insufficient-space.md)
# Der Amazon EMR-Cluster endet mit NO\$1SLAVE\$1LEFT und den Kernknoten FAILED\$1BY\$1MASTER
Dies passiert in der Regel, da der Beendigungsschutz deaktiviert ist, und alle Core-Knoten überschreiten die Datenträger-Speicherkapazität, die durch einen Schwellenwert für die maximale Auslastung in der `yarn-site`-Konfigurationsklassifizierung angegeben ist, die der `yarn-site.xml`-Datei entspricht. Dieser Wert liegt standardmäßig bei 90 %. Wenn die Festplattenauslastung für einen Kernknoten den Auslastungsschwellenwert überschreitet, meldet der YARN-Health Service den Knoten als. NodeManager `UNHEALTHY` Während sich der Knoten in diesem Zustand befindet, wird er von Amazon EMR gesperrt und ihm werden keine YARN-Container zugeordnet. Wenn der Knoten 45 Minuten lang fehlerhaft bleibt, markiert Amazon EMR die zugehörige Amazon-EC2-Instance für die Beendigung als `FAILED_BY_MASTER`. Wenn alle mit Core-Knoten verknüpften Amazon-EC2-Instances für die Beendigung markiert sind, wird der Cluster mit dem Status `NO_SLAVE_LEFT` beendet, da keine Ressourcen zum Ausführen von Aufträgen vorhanden sind.
Das Überschreiten der Datenträgernutzung auf einem Core-Knoten könnte eine Kettenreaktion auslösen. Wenn ein einzelner Knoten den Schwellenwert für die Datenträgernutzung aufgrund von HDFS überschreitet, liegen andere Knoten wahrscheinlich auch in der Nähe des Schwellenwerts. Der erste Knoten überschreitet den Schwellenwert für die Datenträgernutzung, daher wird er von Amazon EMR zu einer Sperrliste hinzugefügt. Dies erhöht den Aufwand der Datenträgernutzung für die verbleibenden Knoten, da sie jetzt untereinander HDFS-Daten replizieren, die auf dem gesperrten Knoten verloren gingen. Jeder Knoten wird anschließend auf die gleiche Weise in den Zustand `UNHEALTHY` versetzt und der Cluster wird schließlich beendet.
## Bewährte Methoden und Empfehlungen
### Konfigurieren von Cluster-Hardware mit ausreichend Speicher
Wenn Sie einen Cluster erstellen, stellen Sie sicher, dass genügend Core-Knoten vorhanden sind und alle über ausreichend Instance-Speicher und EBS-Speicher-Volumes für HDFS verfügen. Weitere Informationen finden Sie unter [Berechnen der erforderlichen HDFS-Kapazität eines Clusters](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs). Sie können auch Core-Instances manuell oder mithilfe der automatischen Skalierung zu vorhandenen Instance-Gruppen hinzuzufügen. Die neuen Instances haben dieselbe Speicherkonfiguration wie andere Instances in der Instance-Gruppe. Weitere Informationen finden Sie unter [Verwenden Sie die Amazon EMR-Cluster-Skalierung, um sich an wechselnde Workloads anzupassen](emr-scale-on-demand.md).
### Aktivieren des Beendigungsschutzes
Beendigungsschutz aktivieren. Wenn ein Core-Knoten gesperrt wird, können Sie auf diese Weise mithilfe von SSH eine Verbindung mit der zugehörigen Amazon-EC2-Instance herstellen, um den Fehler zu beheben und Daten wiederherzustellen. Wenn Sie den Beendigungsschutz aktivieren, sollten Sie daran denken, dass Amazon EMR die Amazon-EC2-Instance nicht durch eine neue Instance ersetzt. Weitere Informationen finden Sie unter [Verwenden Sie den Kündigungsschutz, um Ihre Amazon EMR-Cluster vor einem versehentlichen Herunterfahren zu schützen](UsingEMR_TerminationProtection.md).
### Erstellen Sie einen Alarm für die MRUnhealthy CloudWatch Nodes-Metrik
Diese Metrik meldet die Anzahl der Knoten mit dem Status `UNHEALTHY`. Sie entspricht der YARN-Metrik `mapred.resourcemanager.NoOfUnhealthyNodes`. Sie können eine Benachrichtigung für diesen Alarm einrichten, um über fehlerhafte Knoten informiert zu werden, bevor der 45-Minuten-Timeout erreicht ist. Weitere Informationen finden Sie unter [Überwachung von Amazon EMR-Metriken mit CloudWatch](UsingEMR_ViewingMetrics.md).
### Anpassen von Einstellungen mit yarn-site
Die folgenden Einstellungen können an Ihre Anwendungsanforderungen angepasst werden. Beispiel: Sie möchten den Schwellenwert für die Datenträgernutzung erhöhen, bei dem ein Knoten `UNHEALTHY` melden, indem Sie den Wert von `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` erhöhen.
Sie können diese Werte festlegen, wenn Sie einen Cluster mithilfe der `yarn-site`-Konfigurationsklassifizierung erstellen. Weitere Informationen finden Sie unter [Konfigurieren von Anwendungen](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) in den *Amazon-EMR-Versionshinweisen*. Sie können mit SSH auch eine Verbindung zu den mit Core-Knoten verknüpften Amazon-EC2-Instances herstellen und die Werte dann mithilfe eines Texteditors in `/etc/hadoop/conf.empty/yarn-site.xml` hinzufügen. Nachdem Sie die Änderung vorgenommen haben, müssen Sie hadoop-yarn-nodemanager wie unten gezeigt neu starten.
**Wichtig**
Wenn Sie den NodeManager Dienst neu starten, werden aktive YARN-Container beendet, es `yarn.nodemanager.recovery.enabled` sei denn, Sie sind bei der Erstellung des Clusters auf die `true` Verwendung der `yarn-site` Konfigurationsklassifizierung eingestellt. Darüber hinaus müssen Sie über die Eigenschaft `yarn.nodemanager.recovery.dir` das Verzeichnis angeben, in dem der Containerstatus gespeichert werden soll.
```
sudo /sbin/stop hadoop-yarn-nodemanager
sudo /sbin/start hadoop-yarn-nodemanager
```
Weitere Informationen zu den aktuellen `yarn-site`-Eigenschaften und Standardwerten finden Sie unter [YARN-Standardeinstellungen](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml) in der Apache Hadoop-Dokumentation.
| Eigenschaft | Standardwert | Description |
| --- | --- | --- |
| yarn.nodemanager. disk-health-checker.interval-ms | 120000 | Die Häufigkeit (in Sekunden), mit der die Datenträger-Zustandsprüfung ausgeführt wird. |
| garn.nodemanager. disk-health-checker. min-healthy-disks | 0,25 | Der Mindestanteil der Anzahl der Festplatten, die fehlerfrei sein müssen, NodeManager damit neue Container gestartet werden können. Dies entspricht sowohl yarn.nodemanager.local-dirs (standardmäßig `/mnt/yarn` in Amazon EMR) und yarn.nodemanager.log-dirs (standardmäßig `/var/log/hadoop-yarn/containers`, was symbolisch mit `mnt/var/log/hadoop-yarn/containers` in Amazon EMR verknüpft ist). |
| `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90.0 | Der maximale Prozentsatz der zulässigen Speicherplatzauslastung, ab der ein Datenträger als fehlerhaft markiert wird. Die Werte können zwischen 0,0 und 100,0 liegen. Wenn der Wert größer oder gleich 100 ist, wird NodeManager geprüft, ob eine volle Festplatte vorhanden ist. Dies gilt für `yarn-nodemanager.local-dirs` und `yarn.nodemanager.log-dirs`. |
| `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | Der mindestens erforderliche verfügbare Speicherplatz, damit ein Datenträger verwendet werden kann. Dies gilt für `yarn-nodemanager.local-dirs` und `yarn.nodemanager.log-dirs`. |
# Amazon EMR-Clusterfehler: Block kann nicht repliziert werden, es konnte nur auf Nullknoten repliziert werden.
Der Fehler „Replizieren von Block nicht möglich, nur Replizieren auf null Knoten möglich“ tritt in der Regel auf, wenn ein Cluster nicht über genügend HDFS-Speicher verfügt. Dieser Fehler tritt auf, wenn Sie mehr Daten in Ihrem Cluster generieren als in HDFS gespeichert werden können. Sie sehen diesen Fehler nur, während der Cluster ausgeführt wird, da der HDFS-Speicherplatz nach dem Beenden des Auftrags freigegeben wird.
Die Menge des für einen Cluster verfügbaren HDFS-Speicherplatzes hängt von der Anzahl und Art der Amazon EC2 Instances ab, die als Core-Knoten verwendet werden. Für HDFS-Speicher werden keine Aufgabenknoten verwendet. Der gesamte Speicherplatz auf jeder Amazon-EC2-Instance, einschließlich angefügter EBS-Speichervolumen, ist für HDFS verfügbar. Weitere Informationen zur Größe des lokalen Speichers für jeden EC2-Instance-Typ finden Sie unter [Instance-Typen und -Familien](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
Der zweite Faktor, der sich auf die Menge des verfügbaren HDFS Speicherplatzes auswirkt, ist der Replikationsfaktor. Dieser beschreibt die Anzahl von Kopien jedes Datenblocks, die in HDFS zu Redundanzzwecken gespeichert werden können. Der Replikationsfaktor steigt mit der Anzahl der Knoten im Cluster: Es gibt 3 Kopien jedes Datenblocks für einen Cluster mit 10 oder mehr Knoten, 2 Kopien jedes Blocks für einen Cluster mit 4 bis 9 Knoten und 1 Kopie (keine Redundanz) für Cluster mit 3 oder weniger Knoten. Der gesamte verfügbare HDFS-Speicherplatz wird durch den Replikationsfaktor dividiert. In einigen Fällen, z. B. bei Erhöhung der Anzahl von Knoten von 9 auf 10, kann der Anstieg des Replikationsfaktors dazu führen, dass der verfügbare HDFS-Speicherplatz verringert wird.
Beispielsweise kann ein Cluster mit 10 Core-Knoten vom Typ m1.large 2.833 GB Speicherplatz für HDFS zur Verfügung stellen ((10 Knoten X 850 GB pro Knoten)/Replikationsfaktor 3).
Wenn Ihr Cluster den HDFS zur Verfügung stehenden Speicherplatz überschreitet, können Sie Ihrem Cluster weitere Core-Knoten hinzufügen oder die Datenkomprimierung verwenden, um mehr HDFS-Speicherplatz zu erstellen. Wenn Ihr Cluster beendet und neu gestartet werden kann, können Sie ggf. Core-Knoten eines größeren Amazon EC2 Instance-Typs verwenden. Sie können auch den Replikationsfaktor anpassen. Beachten Sie, dass durch Verringern des Replikationsfaktors die Redundanz der HDFS-Daten sowie die Cluster-Funktion zur Wiederherstellung von verlorenen oder beschädigten HDFS-Blöcken beeinträchtigt wird.
# Amazon EMR-Clusterfehler: EC2-KONTINGENT ÜBERSCHRITTEN
Wenn Sie die Meldung `EC2 QUOTA EXCEEDED` erhalten, gibt es möglicherweise mehrere Ursachen. Je nach Konfigurationsunterschieden kann es zwischen 5 und 20 Minuten dauern, bis vorherige Cluster beendet und die entsprechenden Ressourcen wieder freigegeben werden. Wenn Sie beim Versuch, einen Custer zu starten, die Fehlermeldung `EC2 QUOTA EXCEEDED` erhalten, kann es daran liegen, dass Ressourcen eines kürzlich beendeten Clusters noch nicht zur Verfügung stehen. Diese Meldung kann auch durch die Größenanpassung einer Instance-Gruppe oder Instance-Flotte an eine Zielgröße, die das aktuelle Instance-Kontingent für das Konto überschreitet, verursacht werden. Dies kann manuell oder automatisch durch Auto Scaling geschehen.
Sie können das Problem u. U. mit den folgenden Optionen beheben:
+ Folgen Sie den Anweisungen unter [AWS -Service-Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in *Allgemeine Amazon Web Services-Referenz*, um eine Erhöhung des Servicelimits zu beantragen. Für einige ist APIs die Einrichtung einer CloudWatch Veranstaltung möglicherweise eine bessere Option als die Erhöhung der Grenzwerte. Weitere Details finden Sie unter [Wann sollten EMR-Ereignisse eingerichtet werden in CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Wenn einer oder mehrere der aktiven Cluster nicht ausgelastet sind, skalieren Sie Instance-Gruppen oder reduzieren Sie Zielkapazitäten von Instance-Flotten für aktive Cluster.
+ Erstellen Sie Cluster mit weniger EC2-Instances oder reduzierter Zielkapazität.
# Amazon EMR-Clusterfehler: Zu viele Abruffehler
Die Fehlermeldung „**Too many fetch-failures (Zu viele Abruffehler)**“ oder „**Error reading task output (Fehler beim Lesen der Aufgabenausgabe)**“ in Schritt- oder Aufgabenversuchsprotokollen gibt an, dass die auszuführende Aufgabe von der Ausgabe einer anderen Aufgabe abhängt. Dies geschieht häufig, wenn eine Reduce-Aufgabe zur Ausführung in die Warteschlange gestellt wird und die Ausgabe einer oder mehrerer Map-Aufgaben erfordert, die jedoch noch nicht verfügbar ist.
Es gibt mehrere Gründe, warum die Ausgabe noch nicht verfügbar ist:
+ Die erforderliche Aufgabe befindet sich noch in Bearbeitung. Dies ist oft eine Map-Aufgabe.
+ Die Daten sind möglicherweise aufgrund einer schlechten Netzwerkverbindung nicht verfügbar, wenn sie sich auf einer anderen Instance befinden.
+ Wenn HDFS verwendet wird, um die Ausgabe abzurufen, kann ein Problem mit HDFS vorliegen.
Der häufigste Grund ist, dass sich die vorherige Aufgabe noch in Bearbeitung befindet. Dies ist besonders wahrscheinlich, wenn die Fehler beim ersten Ausführen der Reduce-Aufgaben auftreten. Sie können prüfen, ob dies der Fall ist, indem Sie sich das Syslog-Protokoll für den Cluster-Schritt ansehen, der den Fehler zurückgibt. Wenn das Syslog den Fortschritt beider Map- und Reduce-Aufgaben belegt, weist dies darauf hin, dass die Reduce-Phase gestartet wurde und einige Map-Aufgaben noch nicht abgeschlossen sind.
Sehen Sie sich in den Protokollen den Prozentsatz für den Map-Fortschritt an, der auf 100 % ansteigt und dann wieder auf einen niedrigeren Wert zurückfällt. Wenn der Map-Prozentsatz 100 % beträgt, bedeutet das nicht, dass alle Map-Aufgaben abgeschlossen sind. Es bedeutet lediglich, dass Hadoop alle Map-Aufgaben ausführt. Wenn dieser Wert unter 100 % fällt, bedeutet dies, dass eine Map-Aufgabe fehlgeschlagen ist und Hadoop je nach Konfiguration versucht, die Aufgabe neu zu planen. Bleibt der Zuordnungsprozentsatz in den Protokollen bei 100%, schauen Sie sich vor allem die CloudWatch Metriken an, um zu überprüfen`RunningMapTasks`, ob die Zuordnungsaufgabe noch bearbeitet wird. Sie finden diese Informationen auch mithilfe der Hadoop-Weboberfläche auf dem Master-Knoten.
Wenn dieses Problem auftritt, können Sie verschiedene Schritte versuchen:
+ Weisen Sie die Reduce-Phase an, länger zu warten, bis sie startet. Ändern Sie dazu die Konfigurationseinstellung mapred.reduce.slowstart.completed.maps in Hadoop und legen Sie sie auf einen längeren Zeitraum fest. Weitere Informationen finden Sie unter [Erstellen Sie Bootstrap-Aktionen, um zusätzliche Software mit einem Amazon EMR-Cluster zu installieren](emr-plan-bootstrap.md).
+ Passen Sie die Reducer-Anzahl der gesamten Reducer-Kapazität des Clusters an. Ändern Sie dazu die Konfigurationseinstellung mapred.reduce.tasks für den Auftrag in Hadoop.
+ Verwenden Sie einen Kombinationsklassencode zum Minimieren der Anzahl der Ausgaben, die abgerufen werden müssen.
+ Stellen Sie sicher, dass keine Probleme mit dem Amazon-EC2-Service bestehen, die die Netzwerkleistung des Clusters beeinträchtigen. Verwenden Sie dazu das [Dashboard zum Servicestatus](https://status.aws.amazon.com/).
+ Überprüfen Sie die CPU- und Arbeitsspeicherressourcen für die Instances in Ihrem Cluster, um sicherzustellen, dass Ihre Datenverarbeitung die Ressourcen Ihrer Knoten nicht überlastet. Weitere Informationen finden Sie unter [Amazon EMR-Cluster-Hardware und -Netzwerke konfigurieren](emr-plan-instances.md).
+ Prüfen Sie die Version des Amazon Machine Image (AMI), das in Ihrem Amazon-EMR-Cluster verwendet wird. Wenn die Version 2.3.0 bis einschließlich 2.4.4 ist, aktualisieren Sie auf eine neuere Version. AMI-Versionen im angegebenen Bereich verwenden eine Jetty-Version, die ggf. keine Ausgabe aus der Map-Phase liefert. Der Abruf-Fehler tritt auf, wenn die Reducer keine Ausgabe aus der Map-Phase abrufen können.
Jetty ist ein Open-Source-HTTP-Server, der für die Maschine-zu-Maschine-Kommunikation innerhalb eines Hadoop-Clusters verwendet wird.
# Amazon EMR-Clusterfehler: Datei konnte nur auf 0 statt auf 1 Knoten repliziert werden
Wenn eine Datei in HDFS geschrieben wird, wird sie in mehreren Core-Knoten repliziert. Wenn Sie diesen Fehler sehen, bedeutet dies, dass der NameNode Daemon keine verfügbaren DataNode Instances hat, in die Daten in HDFS geschrieben werden können. Mit anderen Worten, es findet keine Block-Replikation statt. Dieser Fehler kann durch eine Reihe von Problemen verursacht werden:
+ Das HDFS-Dateisystem hat keinen verfügbaren Speicherplatz. Dies ist die wahrscheinlichste Ursache.
+ DataNode Instanzen waren möglicherweise nicht verfügbar, als der Job ausgeführt wurde.
+ DataNode Instanzen wurden möglicherweise für die Kommunikation mit dem Master-Knoten gesperrt.
+ Instances in der Core-Instance-Gruppe sind möglicherweise nicht verfügbar.
+ Berechtigungen können fehlen. Beispielsweise ist der JobTracker Daemon möglicherweise nicht berechtigt, Job-Tracker-Informationen zu erstellen.
+ Die Einstellung für den reservierten Speicherplatz für eine DataNode Instanz ist möglicherweise unzureichend. Stellen Sie fest, ob dies der Fall ist, indem Sie die Konfigurationseinstellung dfs.datanode.du.reserved prüfen.
Um zu überprüfen, ob dieses Problem dadurch verursacht wird, dass HDFS nicht mehr genügend Festplattenspeicher hat, sehen Sie sich die `HDFSUtilization` Metrik unter an. CloudWatch Wenn dieser Wert zu hoch ist, können Sie zusätzliche Core-Knoten zum Cluster hinzufügen. Wenn Sie einen Cluster haben, von dem Sie glauben, dass der HDFS-Festplattenspeicher knapp wird, können Sie einen Alarm einrichten, der Sie warnt, wenn der Wert von `HDFSUtilization` einen bestimmten Wert überschreitet. CloudWatch Weitere Informationen erhalten Sie unter [Manuelles Ändern der Größe eines laufenden Amazon EMR-Clusters](emr-manage-resize.md) und [Überwachung von Amazon EMR-Metriken mit CloudWatch](UsingEMR_ViewingMetrics.md).
Falls HDFS nicht zu wenig Speicherplatz zur Verfügung gestellt hat, überprüfen Sie die DataNode Protokolle, NameNode Protokolle und Netzwerkverbindungen auf andere Probleme, die HDFS daran gehindert haben könnten, Daten zu replizieren. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
# Amazon EMR-Clusterfehler: Knoten auf der Deni-List-Liste
Der NodeManager Daemon ist für den Start und die Verwaltung von Containern auf Kern- und Taskknoten verantwortlich. Die Container werden dem NodeManager Daemon von dem Daemon zugewiesen, der ResourceManager auf dem Master-Knoten läuft. Der ResourceManager überwacht den NodeManager Knoten über einen Heartbeat.
Es gibt eine Reihe von Situationen, in denen der ResourceManager Daemon eine Liste auflistet und sie aus dem Pool der Knoten entfernt NodeManager, die für die Bearbeitung von Aufgaben zur Verfügung stehen:
+ Wenn der in den NodeManager letzten 10 Minuten (600.000 Millisekunden) keinen Heartbeat an den ResourceManager Daemon gesendet hat. Dieser Zeitraum kann über die Konfigurationseinstellung `yarn.nm.liveness-monitor.expiry-interval-ms` festgelegt werden. Weitere Informationen zur Änderung von Yarn-Konfigurationseinstellungen finden Sie unter [Anwendungen konfigurieren](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) im *Amazon-EMR-Versionshandbuch*.
+ NodeManager überprüft den Zustand der Festplatten, der durch und bestimmt wird. `yarn.nodemanager.local-dirs` `yarn.nodemanager.log-dirs` Die Prüfungen umfassen Berechtigungen und freien Speicherplatz (< 90 %). Wenn eine Festplatte die Prüfung nicht besteht, verwendet sie diese bestimmte Festplatte nicht NodeManager mehr, meldet den Knotenstatus aber trotzdem als fehlerfrei. Wenn mehrere Festplatten die Prüfung nicht bestehen, wird der Knoten als fehlerhaft gemeldet ResourceManager und dem Knoten werden keine neuen Container zugewiesen.
Der Anwendungsmaster kann einen NodeManager Knoten auch ablehnen, wenn er mehr als drei fehlgeschlagene Aufgaben hat. Sie können hierfür mithilfe des Konfigurationsparameters `mapreduce.job.maxtaskfailures.per.tracker` einen höheren Wert einstellen. Andere Konfigurationseinstellungen, die Sie ändern können, steuern, wie oft versucht wird, eine Aufgabe auszuführen, bevor ein Fehler gemeldet wird: `mapreduce.map.max.attempts` für Map-Aufgaben und `mapreduce.reduce.maxattempts` für Reduce-Aufgaben. Weitere Informationen zur Änderung von Konfigurationseinstellungen finden Sie unter [Anwendungen konfigurieren](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) im *Amazon-EMR-Versionshandbuch*.
# Drosselungsfehler mit einem Amazon EMR-Cluster
Die Fehler „Throttled from *Amazon EC2* while launch cluster“ und „Failed to provision instances due to throttling from*Amazon EC2*“ treten auf, wenn Amazon EMR eine Anfrage nicht abschließen kann, weil ein anderer Service die Aktivität gedrosselt hat. Amazon EC2 ist die häufigste Ursache für Drosselungsfehler, aber auch andere Services können die Ursache für Drosselungsfehler sein. [AWS -Service-Limits](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) gelten für jede Region, um die Leistung zu verbessern. Ein Drosselungsfehler weist darauf hin, dass Sie das Service-Limit für Ihr Konto in dieser Region überschritten haben.
## Mögliche Ursachen
Die häufigste Quelle von Amazon-EC2-Drosselungsfehlern besteht darin, dass durch das Starten einer großen Anzahl von Cluster-Instances das Service-Limit für EC2-Instances überschritten wird. Cluster-Instances können aus den folgenden Gründen gestartet werden:
+ Es werden neue Cluster erstellt.
+ Die Clustergröße wird manuell angepasst. Weitere Informationen finden Sie unter [Manuelles Ändern der Größe eines laufenden Amazon EMR-Clusters](emr-manage-resize.md).
+ Instance-Gruppen in einem Cluster fügen Instances als Ergebnis einer Auto Scaling-Regel hinzu ("Scale-Out" oder horizontales Skalieren). Weitere Informationen finden Sie unter [Grundlegendes zu Auto-Scaling-Regeln](emr-automatic-scaling.md#emr-scaling-rules).
+ Instance-Flotten in einem Cluster fügen Instances hinzu, um eine erhöhte Zielkapazität zu erreichen. Weitere Informationen finden Sie unter [Planung und Konfiguration von Instance-Flotten für Ihren Amazon EMR-Cluster](emr-instance-fleet.md).
Es ist auch möglich, dass durch die Häufigkeit oder den Typ der API-Anforderung an Amazon EC2 Drosselungsfehler verursacht werden. Weitere Informationen darüber, wie Amazon EC2 API-Anforderungen drosselt, finden Sie unter [Anforderungsrate der Abfrage-API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) in der *Amazon-EC2-API- Referenz*.
## Lösungen
Erwägen Sie die folgenden Lösungen:
+ Folgen Sie den Anweisungen unter [AWS -Service-Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) in *Allgemeine Amazon Web Services-Referenz*, um eine Erhöhung des Servicelimits zu beantragen. Für manche APIs ist die Organisation einer CloudWatch Veranstaltung möglicherweise eine bessere Option als die Erhöhung der Limits. Weitere Details finden Sie unter [Wann sollten EMR-Ereignisse eingerichtet werden in CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Wenn Sie Cluster haben, die nach demselben Zeitplan gestartet werden, z. B. zu Beginn der Stunde, sollten Sie gestaffelte Startzeiten in Betracht ziehen.
+ Wenn die Nachfragespitzen für Ihre Cluster zu groß angelegt sind und Sie Ihre Instance-Kapazitäten in regelmäßigen Abständen angeben, sollten Sie Ihre Instance mit Auto Scaling nach Bedarf hinzufügen und entfernen. Auf diese Weise werden Instances effizienter genutzt und können je nach Bedarfsprofil zu jedem beliebigen Zeitpunkt für ein Konto weniger Instances angefordert werden. Weitere Informationen finden Sie unter [Verwenden der automatischen Skalierung mit einer benutzerdefinierten Richtlinie für Instanzgruppen in Amazon EMR](emr-automatic-scaling.md).
# Amazon EMR-Clusterfehler: Instanztyp wird nicht unterstützt
Wenn Sie einen Cluster erstellen und dieser mit der Fehlermeldung „Der angeforderte Instance-Typ *InstanceType* wird in der angeforderten Availability Zone nicht unterstützt“ fehlschlägt, bedeutet dies, dass Sie den Cluster erstellt und einen Instance-Typ für eine oder mehrere Instance-Gruppen angegeben haben, der von Amazon EMR in der Region und Availability Zone, in der der Cluster erstellt wurde, nicht unterstützt wird. Amazon EMR unterstützt möglicherweise einen Instance-Typ in einer Availability Zone innerhalb einer Region und nicht in einer anderen. Die Availability Zone innerhalb der Region ist von dem von Ihnen für einen Cluster ausgewählten Subnetz abhängig.
## Lösung
**Ermitteln Sie die verfügbaren Instance-Typen in einer Availability Zone mithilfe der AWS CLI**
+ Verwenden Sie den Befehl `ec2 run-instances` mit der Option `--dry-run` . Ersetzen *m5.xlarge* Sie im folgenden Beispiel durch den Instance-Typ, den Sie verwenden möchten, durch das *ami-035be7bafff33b6b6* mit diesem Instance-Typ verknüpfte AMI und *subnet-12ab3c45* durch ein Subnetz in der Availability Zone, die Sie abfragen möchten.
```
aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45
```
Anweisungen zum Suchen einer AMI-ID finden Sie unter [Suchen eines Linux-AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html). Um eine Subnetz-ID zu finden, können Sie den Befehl [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html) verwenden.
Weitere Informationen darüber, wie Sie verfügbare Instance-Typen ermitteln können, finden Sie unter [Suchen eines Amazon-EC2-Instance-Typs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
Nachdem Sie die verfügbaren Instance-Typen bestimmt haben, können Sie beliebige der folgenden Aktionen ausführen:
+ Erstellen Sie den Cluster in der gleichen Region und im gleichen EC2-Subnetz und wählen Sie einen anderen Instance-Typ mit ähnlichen Funktionen wie Ihre erste Wahl aus. Eine Liste mit unterstützten Instance-Typen finden Sie unter [Unterstützte Instance-Typen mit Amazon EMR](emr-supported-instance-types.md). Informationen zum Vergleichen der Funktionen der EC2-Instance-Typen finden Sie unter [Amazon-EC2-Instance-Typen](https://aws.amazon.com/ec2/instance-types/).
+ Wählen Sie ein Subnetz für den Cluster in einer Availability Zone aus, in der der Instance-Typ verfügbar ist und von Amazon EMR unterstützt wird.
**Vermeiden Sie Fehler beim Start von Instance-Flotten und Clustern, die auf nicht unterstützte primäre Instance-Typen in Amazon EMR zurückzuführen sind**
Primäre Knoten sind in Amazon EMR-Clustern unverzichtbar. Ein EMR-Cluster-Start schlägt möglicherweise mit einem `instance type not supported` Fehler fehl, wenn Amazon EMR versucht, den Cluster in einer Availability Zone zu starten, in der der primäre Instance-Typ nicht unterstützt wird. Die erweiterte Availability Zone-Auswahl für Instance-Flottencluster in Amazon EMR filtert automatisch nicht unterstützte AZs Instance-Typen heraus, die Sie in der Cluster-Konfiguration angegeben haben. Das bedeutet, dass Amazon EMR keine Availability Zone auswählt, in der die konfigurierten primären Instance-Typen nicht unterstützt werden, wodurch Cluster-Startfehler aufgrund nicht unterstützter Instance-Typen verhindert werden.
Um diese Verbesserung zu aktivieren, fügen Sie der Servicerolle oder -richtlinie für Ihren Cluster die erforderliche Berechtigung hinzu. Die neueste Version von `AmazonEMRServicePolicy_v2` beinhaltet diese Berechtigung. Wenn Sie also diese Richtlinie verwenden, ist die Verbesserung bereits verfügbar. Wenn Sie eine benutzerdefinierte Servicerolle oder Richtlinie verwenden, fügen Sie die Berechtigung hinzu, `ec2:DescribeInstanceTypeOfferings` wenn Sie Ihren Cluster starten.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstanceTypeOfferings"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowEC2Describeinstancetypeofferings"
}
]
}
```
------
# Amazon EMR-Clusterfehler: EC2 hat keine Kapazität
Ein *InstanceType* Fehler tritt auf, wenn Sie versuchen, in einer Availability Zone, in der es keine *EC2-Instance-Typen* mehr gibt, einen Cluster zu erstellen oder Instances zu einem Cluster hinzuzufügen. Die Availability Zone ist von dem von Ihnen für einen Cluster ausgewählten Subnetz abhängig.
Um einen Cluster zu erstellen, führen Sie einen der folgenden Schritte aus:
+ Geben Sie einen anderen Instance-Typ mit ähnlichen Funktionen an
+ Erstellen des Clusters in einer anderen Region
+ Wählen Sie ein Subnetz in einer Availability Zone aus, in dem der gewünschte Instance-Typ möglicherweise verfügbar ist.
Führen Sie einen der folgenden Schritte aus, um Instances zu einem laufenden Cluster hinzuzufügen:
+ Ändern Sie Instance-Gruppenkonfigurationen oder Instance-Flottenkonfigurationen so bearbeiten, dass verfügbare Instance-Typen mit ähnlichen Funktionen hinzugefügt werden. Eine Liste mit unterstützten Instance-Typen finden Sie unter [Unterstützte Instance-Typen mit Amazon EMR](emr-supported-instance-types.md). Informationen zum Vergleichen der Funktionen der EC2-Instance-Typen finden Sie unter [Amazon-EC2-Instance-Typen](https://aws.amazon.com/ec2/instance-types/).
+ Beenden Sie den Cluster und erstellen Sie ihn in einer Region und Verfügbarkeitszone neu, in der der Instancetyp verfügbar ist.
# Amazon EMR-Clusterfehler: HDFS-Replikationsfaktorfehler
Wenn Sie einen Core-Knoten aus einer [Core-Instance-Gruppe oder [Instance-Flotte](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) entfernen, tritt bei Amazon EMR möglicherweise ein HDFS-Replikationsfehler auf. Dieser Fehler tritt auf, wenn Sie Kernknoten entfernen und die Anzahl der Kernknoten unter den konfigurierten [dfs.replication-Faktor](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) für das Hadoop Distributed File System (HDFS) fällt. Daher kann Amazon EMR den Vorgang nicht sicher ausführen. Um den Standardwert der Konfiguration zu ermitteln, `dfs.replication` [HDFS-Konfiguration](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html).
## Mögliche Ursachen
Im Folgenden finden Sie die möglichen Ursachen für einen HDFS-Replikationsfaktorfehler:
+ Wenn Sie die [Größe einer Core-Instanzgruppe oder Instanzflotte manuell](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html) unter den konfigurierten `dfs.replication` Faktor ändern.
+ Ihre Richtlinien für [verwaltete Skalierung](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) oder [Autoscaling](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) ermöglichen möglicherweise eine Skalierung, um die Anzahl der Kernknoten unter den Schwellenwert von zu reduzieren. `dfs.replication`
+ Dieser Fehler kann auch auftreten, wenn Amazon EMR versucht, einen fehlerhaften Kernknoten zu [ersetzen](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html), obwohl ein Cluster die minimale Anzahl von Kernknoten hat, die von definiert ist. []()
## Lösungen und bewährte Methoden
Im Folgenden finden Sie Lösungen und bewährte Verfahren:
+ Wenn Sie die Größe eines Amazon EMR-Clusters manuell ändern, sollten Sie nicht unter den Wert herunterskalieren, `dfs.replication` da Amazon EMR die Größenänderung nicht sicher abschließen kann.
+ Wenn Sie Managed Scaling oder Autoscaling verwenden, stellen Sie sicher, dass die Mindestkapazität Ihres Clusters nicht unter dem Faktor liegt. `dfs.replication`
+ Die Anzahl der Core-Instances sollte mindestens `dfs.replication` plus eins sein. Dadurch wird sichergestellt, dass Amazon EMR einen fehlerhaften Core-Knoten erfolgreich ersetzen kann, wenn Sie den Austausch fehlerhafter Kerne aktiviert haben.
**Wichtig**
Der Ausfall eines einzelnen Core-Knotens kann zu HDFS-Datenverlust führen, wenn Sie auf 1 setzen. `dfs.replication` Wenn Ihr Cluster über HDFS-Speicher verfügt, empfehlen wir, den Cluster mit mindestens vier Kernknoten für Produktionsworkloads zu konfigurieren, um Datenverlust zu vermeiden, und außerdem den `dfs.replication` Faktor auf mindestens 2 festzulegen.
# Amazon EMR-Clusterfehler: HDFS-Fehler mit unzureichendem Speicherplatz
Wenn Sie versuchen, einen Core-Knoten zu entfernen, Amazon EMR den Vorgang jedoch nicht sicher abschließen kann, weil im HDFS nicht genügend Speicherplatz vorhanden ist, kann es zu einem Fehler im Hadoop Distributed File System (HDFS) kommen. Bevor Amazon EMR einen Core-Knoten entfernt, müssen alle HDFS-Daten auf dem Knoten auf andere Core-Knoten übertragen werden, um Datenredundanz zu gewährleisten. Wenn auf den anderen Kernknoten jedoch nicht genügend Speicherplatz für die Replikation vorhanden ist, kann Amazon EMR den Knoten nicht ordnungsgemäß außer Betrieb nehmen.
## Mögliche Ursachen
Im Folgenden finden Sie eine Liste der möglichen Ursachen für den Fehler, dass HDFS nicht genügend Speicherplatz hat:
+ Wenn Sie eine Core-Instanzgruppe oder Instanzflotte manuell herunterskalieren, obwohl auf den verbleibenden Knoten vor dem Herunterskalieren nicht genügend HDFS-Speicherplatz für die Datenreplikation vorhanden ist.
+ Durch verwaltetes Skalieren oder Autoscaling wird eine Core-Instanzgruppe oder Instanzflotte herunterskaliert, wenn nicht genügend HDFS-Speicherplatz für die Datenreplikation vorhanden ist.
+ Amazon EMR versucht, einen fehlerhaften Core-Knoten zu ersetzen, kann den Knoten jedoch aufgrund des unzureichenden HDFS-Speicherplatzes nicht sicher ersetzen.
## Lösungen und bewährte Methoden
Im Folgenden finden Sie Lösungen und bewährte Verfahren:
+ Skalieren Sie die Anzahl der Kernknoten in Ihrem Amazon EMR-Cluster. Wenn Sie Managed Scaling oder Autoscaling verwenden, erhöhen Sie die Mindestkapazität Ihrer Kernknoten.
+ Verwenden Sie größere EBS-Volumes für Ihre Kernknoten, wenn Sie Ihren EMR-Cluster erstellen.
+ Löschen Sie nicht benötigte HDFS-Daten in Ihrem EMR-Cluster. Wir empfehlen Ihnen, CloudWatch Alarme einzurichten, um die `HDFSUtilization` Metrik in Ihrem Cluster zu überwachen, um festzustellen, ob Ihr EMR-Cluster wenig Speicherplatz hat.
# Cluster-Eingabe- und Ausgabefehler bei Amazon EMR-Vorgängen
Die folgenden Fehler treten in Cluster-Ein- und Ausgabeoperationen häufig auf. Verwenden Sie die Anleitungen in diesem Thema, um Fehler zu beheben und Ihre Konfiguration zu überprüfen.
**Topics**
+ [Hat Ihr Pfad zu Amazon Simple Storage Service (Amazon S3) mindestens drei Schrägstriche?](#threeslashes)
+ [Versuchen Sie Eingabeverzeichnisse rekursiv zu durchlaufen?](#recurseinput)
+ [Ist Ihr Ausgabeverzeichnis bereits vorhanden?](#directoryexist)
+ [Versuche Sie, eine Ressource mit einer HTTP-URL anzugeben?](#httpurl)
+ [Verweisen Sie mit einem ungültigen Namensformat auf einen Amazon-S3-Bucket?](#validdnsname)
+ [Haben Sie Probleme beim Laden von Daten in oder aus Amazon S3?](#emr-troubleshoot-errors-io-1)
## Hat Ihr Pfad zu Amazon Simple Storage Service (Amazon S3) mindestens drei Schrägstriche?
Wenn Sie einen Amazon-S3-Bucket angeben, müssen Sie einen Abschlussschrägstrich am Ende der URL anfügen. Anstatt beispielsweise auf einen Bucket als „s3n: //amzn-s3-demo-bucket1" zu verweisen, sollten Sie „s3n: //amzn-s3-demo-bucket1/“ verwenden, da Hadoop Ihren Cluster sonst in den meisten Fällen ausfallen lässt.
## Versuchen Sie Eingabeverzeichnisse rekursiv zu durchlaufen?
Hadoop durchsucht Eingabeverzeichnisse nicht rekursiv nach Dateien. Wenn Sie über eine Verzeichnisstruktur wie beispielsweise /corpus/01/01.txt, /corpus/01/02.txt, /corpus/02/01.txt usw. verfügen und /corpus/ als Eingabeparameter für Ihren Cluster angeben, findet Hadoop keine Eingabedateien, da das Verzeichnis /corpus/ leer ist und Hadoop den Inhalt der Unterverzeichnisse nicht überprüft. Entsprechend überprüft Hadoop die Unterverzeichnisse von Amazon-S3-Buckets nicht rekursiv.
Die Eingabedateien müssen sich direkt in dem Eingabeverzeichnis oder dem Amazon-S3-Bucket, das bzw. den Sie angeben, befinden und nicht in Unterverzeichnissen.
## Ist Ihr Ausgabeverzeichnis bereits vorhanden?
Wenn Sie einen Ausgabepfad angeben, der bereits vorhanden ist, schlägt der Hadoop-Cluster in den meisten Fällen fehl. Das bedeutet, dass Sie, wenn Sie einen Cluster ausführen und dann diesen Vorgang mit denselben Parametern wiederholen, der erste Lauf und kein weiterer funktioniert. Nach dem ersten Lauf ist der Ausgabepfad vorhanden, was dazu führt, dass alle nachfolgenden Läufe fehlschlagen.
## Versuche Sie, eine Ressource mit einer HTTP-URL anzugeben?
Hadoop akzeptiert keine Ressourcenspeicherorte, die mit dem Präfix http:// angegeben werden. Sie können auf eine Ressource nicht mit einer HTTP-URL verweisen. Beispiel: Das Übergeben von http://mysite/myjar.jar als JAR-Parameter bewirkt, dass der Cluster fehlschlägt.
## Verweisen Sie mit einem ungültigen Namensformat auf einen Amazon-S3-Bucket?
Wenn Sie versuchen, einen Bucket-Namen wie „amzn-s3-demo-bucket1.1“ mit Amazon EMR zu verwenden, schlägt Ihr Cluster fehl, weil Amazon EMR verlangt, dass Bucket-Namen gültige RFC 2396-Hostnamen sind; der Name darf nicht mit einer Zahl enden. Um die Anforderungen von Hadoop zu erfüllen, dürfen Namen von mit Amazon EMR verwendeten Amazon-S3-Buckets darüber hinaus nur Kleinbuchstaben, Zahlen, Punkte (.) und Bindestriche (-) enthalten. Weitere Informationen zum Formatieren von Amazon-S3-Bucket-Namen finden Sie unter [Bucket-Einschränkungen und -Limits](https://docs.aws.amazon.com/AmazonS3/latest/userguide/index.html?BucketRestrictions.html) im *Benutzerhandbuch für Amazon Simple Storage Service*.
## Haben Sie Probleme beim Laden von Daten in oder aus Amazon S3?
Amazon S3 ist die beliebteste Ein- und Ausgabequelle für Amazon EMR. Ein häufiger Fehler besteht darin, Amazon S3 so zu behandeln wie ein typisches Dateisystem. Es gibt Unterschiede zwischen Amazon S3 und einem Dateisystem, die Sie berücksichtigen müssen, wenn Sie Ihren Cluster ausführen.
+ Wenn ein interner Fehler in Amazon S3 auftritt, muss Ihre Anwendung diesen problemlos behandeln und die Operation wiederholen.
+ Wenn Aufrufe in Amazon S3 zu lange dauern, muss Ihre Anwendung die Häufigkeit der Amazon-S3-Aufrufe ggf. reduzieren.
+ Das Auflisten aller Objekte in einem Amazon-S3-Bucket ist ein teurer Aufruf. Ihre Anwendung sollte die Anzahl solcher Aufrufe minimieren.
Es gibt mehrere Möglichkeiten, wie Sie die Interaktion Ihres Cluster mit Amazon S3 verbessern können.
+ Starten Sie Ihren Cluster mit der neuesten Version von Amazon EMR.
+ Verwenden Sie S3DistCp , um Objekte in und aus Amazon S3 zu verschieben. S3 DistCp implementiert Fehlerbehandlung, Wiederholungsversuche und Back-offs, um die Anforderungen von Amazon S3 zu erfüllen. Weitere Informationen finden Sie unter [Verteilte Kopie](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/UsingEMR_s3distcp.html) mit S3. DistCp
+ Entwickeln Sie Ihre Anwendung mit letztendlicher Datenkonsistenz im Blick. Verwenden Sie HDFS für das Zwischenspeichern von Daten, während der Cluster ausgeführt wird, und Amazon S3 nur für die Eingabe der Ausgangsdaten und für die Ausgabe der Endergebnisse.
+ Wenn Ihre Cluster einen Commit für mindestens 200 Transaktionen pro Sekunde in Amazon S3 [contact support](https://aws.amazon.com/contact-us/)durchführen, wenden Sie sich an den Support, um Ihren Bucket auf größere Transaktionen pro Sekunde vorzubereiten. Ziehen Sie dazu die unter [Tipps und Tricks zur Leistung von Amazon S3](https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/) beschriebenen Strategien in Erwägung.
+ Legen Sie die Hadoop-Konfigurationseinstellung "io.file.buffer.size" auf "65536" fest. Diese bewirkt, dass Hadoop weniger Zeit damit verbringt, Amazon-S3-Objekte zu durchsuchen.
+ Überlegen Sie sich, ob Sie dasie Speculative-Execution-Feature in Hadoop deaktivieren, wenn Ihr Cluster Probleme mit der gleichzeitigen Ausführung von Amazon S3 hat. Diese Vorgehensweise ist auch bei der Problembehandlung eines langsamen Clusters nützlich. Sie tun dies, indem Sie die `mapreduce.map.speculative`- und die `mapreduce.reduce.speculative`-Eigenschaften auf `false` festlegen. Wenn Sie einen Cluster starten, können Sie diese Werte mithilfe der `mapred-env`-Konfigurationsklassifizierung festlegen. Weitere Informationen finden Sie unter [Konfigurieren von Anwendungen](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) in den *Amazon EMR-Versionshinweisen*.
+ Wenn Sie einen Hive-Cluster ausführen, finden Sie weitere Informationen unter [Haben Sie Probleme beim Laden von Daten in oder aus Amazon S3 in Hive?](emr-troubleshoot-error-hive.md#emr-troubleshoot-error-hive-3).
Weitere Informationen finden Sie unter [Bewährte Methoden für Amazon-S3-Fehler](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html) im *Benutzerhandbuch von Amazon Simple Storage Service*.
# Berechtigungsfehler bei Amazon EMR-Clustervorgängen
Die folgenden Fehler treten häufig im Zusammenhang mit Berechtigungen oder Anmeldeinformationen auf.
**Topics**
+ [Haben Sie für SSH die korrekten Anmeldeinformationen angegeben?](#correctcred)
+ [Haben Sie bei der Verwendung von IAM die korrekten Amazon-EC2-Richtlinien festgelegt?](#check-iam-permissions)
## Haben Sie für SSH die korrekten Anmeldeinformationen angegeben?
Wenn Sie keine SSH-Verbindung zum Master-Knoten herstellen können, gibt es höchstwahrscheinlich ein Problem mit Ihren Anmeldeinformationen.
Prüfen Sie zunächst, ob die PEM-Datei mit dem SSH-Schlüssel über die entsprechenden Berechtigungen verfügt. Verwenden Sie chmod, um die Berechtigungen für Ihre .PEM-Datei zu ändern. Im folgenden Beispiel würden Sie mykey.pem durch den Namen Ihre eigenen PEM-Datei ersetzen.
```
1. chmod og-rwx mykey.pem
```
Die zweite Fehlerquelle besteht darin, dass Sie nicht das Schlüsselpaar verwenden, das Sie beim Erstellen des Clusters angegeben haben. Dies passiert schnell, falls Sie mehrere Schlüsselpaare erstellt haben. Prüfen Sie die Cluster-Details in der Amazon-EMR-Konsole (oder verwenden Sie die Option `--describe` in der CLI). Stellen Sie fest, ob der Name des Schlüsselpaares mit dem bei der Erstellung des Clusters angegebenen übereinstimmt.
Nachdem Sie überprüft haben, ob Sie das richtige Schlüsselpaar und die korrekten Berechtigungen für die PEM-Datei verwendet haben, können Sie den folgenden Befehl nutzen, um eine SSH-Verbindung mit dem Hauptknoten herzustellen. Ersetzen Sie mykey.pem durch den Namen Ihrer PEM-Datei und `hadoop@ec2-01-001-001-1.compute-1.amazonaws.com` durch den öffentlichen DNS-Namen des Hauptknotens (über die Option `--describe` in der CLI und über die Amazon-EMR-Konsole abrufbar).
**Wichtig**
Sie müssen den Anmeldenamen `hadoop` verwenden, wenn Sie eine Verbindung mit dem Amazon-EMR-Cluster-Knoten herstellen. Andernfalls kann eine Fehlermeldung wie `Server refused our key` angezeigt werden.
```
1. ssh -i mykey.pem hadoop@ec2-01-001-001-1.compute-1.amazonaws.com
```
Weitere Informationen finden Sie unter [Stellen Sie mithilfe von SSH eine Connect zum primären Knoten des Amazon EMR-Clusters her](emr-connect-master-node-ssh.md).
## Haben Sie bei der Verwendung von IAM die korrekten Amazon-EC2-Richtlinien festgelegt?
Da Amazon-EMR-EC2-Instances als Knoten verwendet, muss ein Benutzer von Amazon EMR auch bestimmte Amazon-EC2-Richtlinien festgelegt haben, damit Amazon EMR diese Instances im Namen des Benutzers verwalten kann. Wenn Sie nicht über die erforderlichen Berechtigungen verfügen, gibt Amazon EMR den folgenden Fehler zurück: **„Das Benutzerkonto ist nicht berechtigt, EC2 aufzurufen.“**
Weitere Informationen über die zur Ausführung von Amazon EC2 erforderlichen Amazon-EMR-Richtlinien in Ihrem IAM-Konto finden Sie unter [Funktionsweise von Amazon EMR mit IAM](security_iam_service-with-iam.md).
# Hive-Cluster-Fehler
Den Grund für einen Hive-Fehler finden Sie in der Regel in der Datei `syslog`, auf die Sie im Bereich **Steps (Schritte)** zugreifen können. Wenn Sie das Problem nicht ermitteln können, sehen Sie sich die Fehlermeldung für die versuchte Hadoop-Aufgabe an. Erstellen Sie einen Link dahin im Abschnitt **Task Attempts (Aufgaben-Versuche)**.
Die folgenden Fehler treten häufig bei Hive-Clustern auf.
**Topics**
+ [Verwenden Sie die neueste Version von Hive?](#emr-troubleshoot-error-hive-0)
+ [Ist im Hive-Skript ein Syntaxfehler aufgetreten?](#emr-troubleshoot-error-hive-1)
+ [Ist ein interaktiv ausgeführter Auftrag fehlgeschlagen?](#emr-troubleshoot-error-hive-2)
+ [Haben Sie Probleme beim Laden von Daten in oder aus Amazon S3 in Hive?](#emr-troubleshoot-error-hive-3)
## Verwenden Sie die neueste Version von Hive?
Die neueste Version von Hive verfügt über alle aktuellen Patches und Fehlerbehebungen und kann Ihr Problem lösen.
## Ist im Hive-Skript ein Syntaxfehler aufgetreten?
Wenn ein Schritt fehlschlägt, sehen Sie sich die Datei `stdout` der Protokolle für den Schritt an, die das Hive-Skript ausgeführt hat. Wenn der Fehler nicht vorhanden ist, sehen Sie sich die Datei `syslog` der Aufgabenprotokolle für die versuchte Aufgabe an, die fehlgeschlagen ist. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
## Ist ein interaktiv ausgeführter Auftrag fehlgeschlagen?
Wenn Sie Hive interaktiv auf dem Master-Knoten ausführen und der Cluster fehlschlägt, sehen Sie sich die Einträge `syslog` im Aufgabenprotokoll für die fehlgeschlagene Aufgabe an. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
## Haben Sie Probleme beim Laden von Daten in oder aus Amazon S3 in Hive?
Falls Sie Probleme mit dem Zugriff auf Daten in Amazon S3 haben, überprüfen Sie zuerst die möglichen Ursachen, die in [Haben Sie Probleme beim Laden von Daten in oder aus Amazon S3?](emr-troubleshoot-errors-io.md#emr-troubleshoot-errors-io-1) aufgeführt sind. Wenn keines dieser Probleme die Ursache ist, ziehen Sie die folgenden, für Hive spezifischen Optionen in Betracht.
+ Stellen Sie sicher, dass Sie die neueste Version von Hive verwenden, die über alle aktuellen Patches und Fehlerbehebungen verfügt, die Ihr Problem lösen können. Weitere Informationen finden Sie unter [Apache Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive.html).
+ Wenn Sie `INSERT OVERWRITE` verwenden, müssen Sie die Inhalte des Amazon-S3-Buckets oder -Ordners auflisten. Dies ist eine teure Operation. Wenn möglich, optimieren Sie den Pfad manuell die vorhandenen Objekte von Hive auflisten und löschen zu lassen.
+ Wenn Sie ältere Versionen als Amazon EMR 5.0 verwenden, können Sie den folgenden Befehl in HiveQL ausführen, um die Ergebnisse einer Amazon-S3-Auflistungsoperation vorab lokal auf dem Cluster zwischenzuspeichern:
```
set hive.optimize.s3.query=true;
```
+ Verwenden Sie statische Partitionen, wenn möglich.
+ In einigen Versionen von Hive und Amazon EMR ist es möglich, dass mit ALTER TABLES ein Fehler auftritt, da die Tabelle an einem anderen Ort gespeichert ist, als von Hive erwartet wird. Die Lösung ist, Folgendes in `/home/hadoop/conf/core-site.xml` hinzuzufügen oder zu aktualisieren:
```
fs.s3n.endpoint
s3.amazonaws.com
```
# VPC-Fehler bei Amazon EMR-Clustervorgängen
Die folgenden Fehler treten häufig bei der VPC-Konfiguration in Amazon EMR auf.
**Topics**
+ [Ungültige Subnetzkonfiguration](#emr-troubleshoot-error-gateway)
+ [Fehlende DHCP-Optionsliste](#emr-troubleshoot-error-dhcp)
+ [Berechtigungsfehler](#emr-troubleshoot-error-denied)
+ [Fehler, die zu `START_FAILED` führen](#emr-troubleshoot-error-vpc-dns)
+ [Cluster und kann nicht gestartet werden `Terminated with errors` NameNode](#emr-troubleshoot-namenode-dns)
## Ungültige Subnetzkonfiguration
Auf der Seite **Cluster Details (Cluster-Details)** im Feld **Status** sehen Sie eine Fehlermeldung wie folgende:
`The subnet configuration was invalid: Cannot find route to InternetGateway in main RouteTable rtb-id for vpc vpc-id.`
Um dieses Problem zu lösen, müssen Sie ein Internet-Gateway erstellen und Ihre VPC anfügen. Weitere Informationen finden Sie unter [Hinzufügen eines Internet-Gateways zu Ihrer VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html).
Alternativ stellen Sie sicher, dass Sie Ihre VPC mit **Enable DNS resolution (DNS-Auflösung aktivieren)** und **Enable DNS hostname support (DNS-Hostnamen-Unterstützung aktivieren)** aktiviert konfiguriert haben. Weitere Informationen finden Sie unter [Verwenden von DNS in Ihrer VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html).
## Fehlende DHCP-Optionsliste
Sie sehen einen Schrittfehler im Cluster-Systemprotokoll (syslog) mit einer Fehlermeldung ähnlich der folgenden:
` ERROR org.apache.hadoop.security.UserGroupInformation (main): PriviledgedActionException as:hadoop (auth:SIMPLE) cause:java.io.IOException: org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM. `
oder
`ERROR org.apache.hadoop.streaming.StreamJob (main): Error Launching job : org.apache.hadoop.yarn.exceptions.ApplicationNotFoundException: Application with id 'application_id' doesn't exist in RM.`
Um dieses Problem zu lösen, müssen Sie eine VPC mit einer DHCP-Optionsliste konfigurieren, deren Parameter auf die folgenden Werte festgelegt sind:
**Anmerkung**
Wenn Sie die Region AWS GovCloud (US-West) verwenden, setzen Sie domain-name auf **us-gov-west-1.compute.internal** anstelle des im folgenden Beispiel verwendeten Werts.
+ **domain-name** = **ec2.internal**
Verwenden Sie **ec2.internal**, wenn Ihre Region USA Ost (Nord-Virginia) ist. Verwenden Sie für andere Regionen. *region-name* **.compute.internal** Verwenden Sie zum Beispiel in us-west-2 **domain-name**=**us-west-2.compute.internal**.
+ **domain-name-servers** = **AmazonProvidedDNS**
Weitere Informationen finden Sie unter [DHCP-Options-Sets](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
## Berechtigungsfehler
Ein Fehler im `stderr`-Protokoll für einen Schritt gibt an, dass eine Amazon-S3-Ressource nicht über die entsprechenden Berechtigungen verfügt. Dies ist ein Fehler 403, der wie folgt aussieht:
```
Exception in thread "main" com.amazonaws.services.s3.model.AmazonS3Exception: Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: REQUEST_ID
```
Wenn der auf gesetzt ActionOnFailure ist`TERMINATE_JOB_FLOW`, würde dies dazu führen, dass der Cluster mit dem Status, `SHUTDOWN_COMPLETED_WITH_ERRORS` beendet wird.
Möglichkeiten, um dieses Problem zu beheben, sind beispielsweise:
+ Wenn Sie eine Amazon-S3-Bucket-Richtlinie in einer VPC verwenden, stellen Sie sicher, dass der Zugriff auf alle Buckets ermöglicht wird. Erstellen Sie dazu einen VPC-Endpunkt und wählen Sie beim Erstellen des Endpunkts **Alle zulassen** unter der Option „Richtlinie“ aus.
+ Stellen Sie sicher, dass alle Richtlinien im Zusammenhang mit S3-Ressourcen die VPC umfassen, in der Sie den Cluster starten.
+ Führen Sie den folgenden Befehl über Ihren Cluster aus, um zu überprüfen, ob Sie auf den Bucket zugreifen können.
```
hadoop fs -copyToLocal s3://path-to-bucket /tmp/
```
+ Sie können spezifischere Debugging-Informationen abrufen, indem Sie den Parameter `log4j.logger.org.apache.http.wire` in der Datei `DEBUG`-Datei im Cluster auf `/home/hadoop/conf/log4j.properties` festlegen. Sie können die `stderr`-Protokolldatei prüfen, nachdem Sie versucht haben, über den Cluster auf den Bucket zuzugreifen. Die Protokolldatei enthält detaillierte Informationen:
```
Access denied for getting the prefix for bucket - us-west-2.elasticmapreduce with path samples/wordcount/input/
15/03/25 23:46:20 DEBUG http.wire: >> "GET /?prefix=samples%2Fwordcount%2Finput%2F&delimiter=%2F&max-keys=1 HTTP/1.1[\r][\n]"
15/03/25 23:46:20 DEBUG http.wire: >> "Host: us-west-2.elasticmapreduce.s3.amazonaws.com[\r][\n]"
```
## Fehler, die zu `START_FAILED` führen
Vor AMI 3.7.0, für die ein VPCs Hostname angegeben wurde, ordnet Amazon EMR die internen Hostnamen des Subnetzes den benutzerdefinierten Domainadressen wie folgt zu:. `ip-X.X.X.X.customdomain.com.tld` Wenn beispielsweise der Hostname `ip-10.0.0.10` lautet und die Domainnamenoption der VPC auf customdomain.com festgelegt ist, wird von Amazon EMR der Hostname `ip-10.0.1.0.customdomain.com` zugeordnet. Ein Eintrag wird in `/etc/hosts` hinzugefügt, um den Hostnamen in 10.0.0.10 aufzulösen. Dieses Verhalten wird ab AMI 3.7.0 geändert. Jetzt erkennt Amazon EMR die DHCP-Konfiguration der VPC vollständig an. Bislang konnten Kunden eine Zuweisung des Hostnamens auch mit einer Bootstrap-Aktion angeben.
Wenn Sie dieses Verhalten beibehalten möchten, müssen Sie die Einrichtung der DNS- und Weiterleitungsauflösung angeben, die Sie für die benutzerdefinierte Domain benötigen.
## Cluster und kann nicht gestartet werden `Terminated with errors` NameNode
Beim Starten eines EMR-Clusters in einer VPC, die einen benutzerdefinierten DNS-Domainnamen verwendet, tritt bei Ihrem Cluster möglicherweise ein Fehler mit der folgende Fehlermeldung in der Konsole auf:
```
Terminated with errors On the master instance(instance-id), bootstrap action 1 returned a non-zero return code
```
Der Fehler ist darauf zurückzuführen, dass der Start NameNode nicht möglich ist. Dies führt zu dem folgenden Fehler in den NameNode Protokollen, deren Amazon S3 S3-URI die folgende Form hat`s3://amzn-s3-demo-bucket/logs/cluster-id/daemons/master instance-id/hadoop-hadoop-namenode-master node hostname.log.gz`:
```
2015-07-23 20:17:06,266 WARN
org.apache.hadoop.hdfs.server.namenode.FSNamesystem (main): Encountered exception
loading fsimage java.io.IOException: NameNode is not formatted.
at
org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:212)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1020)
at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:739)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:537)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:596)
at org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:765)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.(NameNode.java:749)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1441)
at
org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1507)
```
Der Grund hierfür ist ein potenzielles Problem, bei dem eine EC2 Instance mehrere Gruppen von vollständig qualifizierten Domainnamen beim Starten von EMR-Clustern in einer VPC besitzen kann, die sowohl einen von AWS bereitgestellten DNS-Server als auch einen benutzerdefinierten vom Benutzer bereitgestellten DNS-Server verwendet. Wenn der vom Benutzer bereitgestellte DNS-Server keine Zeigerdatensätze (PTR) für die A-Datensätze bereitstellt, die zum Angeben von Knoten in einem EMR-Cluster dienen, können die so konfigurierten Cluster nicht starten. Die Lösung besteht darin, einen PTR-Datensatz für jeden A-Datensatz hinzuzufügen, der erstellt wird, wenn eine EC2 Instance in einem der Subnetze der VPC gestartet wird.
# Fehler beim Streaming von Amazon EMR-Clustern
Sie können in der Regel die Ursache für einen Streaming-Fehler in einer `syslog`-Datei finden. Erstellen Sie einen Link dahin im Abschnitt **Steps (Schritte)**.
Die folgenden Fehler treten häufig bei Streaming-Clustern auf.
**Topics**
+ [Werden Daten an den Mapper im falschen Format gesendet?](#emr-troubleshoot-error-streaming-1)
+ [Gibt es eine Zeitüberschreitung bei der Skriptausführung?](#emr-troubleshoot-error-streaming-2)
+ [Werden ungültige Streaming-Argumente übergeben?](#invalidarg)
+ [Wurde Ihr Skript mit einem Fehler beendet?](#emr-troubleshoot-error-streaming-3)
## Werden Daten an den Mapper im falschen Format gesendet?
Suchen Sie in der `syslog`-Datei nach einer Fehlermeldung über einen fehlgeschlagenen Aufgabenversuch in den Protokolldateien der Aufgabenversuche, um dies zu überprüfen. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
## Gibt es eine Zeitüberschreitung bei der Skriptausführung?
Die standardmäßige Zeitbeschränkung für ein Mapper- oder Reducer-Skript beträgt 600 Sekunden. Wenn Ihr Skript mehr Zeit benötigt, schlägt der Aufgabenversuch fehl. Suchen Sie in der `syslog`-Datei nach einem fehlgeschlagenen Aufgabenversuch in den Protokolldateien der Aufgabenversuche, um dies zu überprüfen. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
Sie können die Zeitbeschränkung ändern, indem Sie einen neuen Wert für die Konfigurationseinstellung `mapred.task.timeout` festlegen. Diese Einstellung gibt die Anzahl von Millisekunden an, nach der Amazon EMR eine Aufgabe beendet, die keine Eingabe gelesen, Ausgabe geschrieben oder ihre Status-Zeichenfolge nicht aktualisiert hat. Sie können diesen Wert aktualisieren, indem Sie ein zusätzliches Streaming-Argument `-jobconf mapred.task.timeout=800000` übergeben.
## Werden ungültige Streaming-Argumente übergeben?
Hadoop-Streaming unterstützt nur die folgenden Argumente. Wenn Sie andere als die unten aufgeführten Argumente übergeben, schlägt der Cluster fehl.
```
1. -blockAutoGenerateCacheFiles
2. -cacheArchive
3. -cacheFile
4. -cmdenv
5. -combiner
6. -debug
7. -input
8. -inputformat
9. -inputreader
10. -jobconf
11. -mapper
12. -numReduceTasks
13. -output
14. -outputformat
15. -partitioner
16. -reducer
17. -verbose
```
Darüber hinaus erkennt Hadoop-Streaming nur in Java-Syntax übergebene Argumente, also mit einem vorangestellten einzelnen Bindestrich. Wenn Argumente mit vorangestelltem doppelten Bindestrich übergeben werden, schlägt der Cluster fehl.
## Wurde Ihr Skript mit einem Fehler beendet?
Wenn Ihr Mapper- oder Reducer-Skript mit einem Fehler beendet wird, können Sie den Fehler in der `stderr`-Datei des fehlgeschlagenen Aufgabenversuchs in den Protokolldateien der Aufgabenversuche ermitteln. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
# Amazon EMR: Fehler beim benutzerdefinierten JAR-Cluster
Die folgenden Fehler treten häufig bei benutzerdefinierten JAR-Clustern auf.
**Topics**
+ [Löst Ihr JAR-Cluster vor dem Erstellen eines Auftrags eine Ausnahme aus?](#emr-troubleshoot-error-custom-jar-1)
+ [Tritt auf Ihrem JAR-Cluster ein Fehler in einer Map-Aufgabe auf?](#emr-troubleshoot-error-custom-jar-2)
## Löst Ihr JAR-Cluster vor dem Erstellen eines Auftrags eine Ausnahme aus?
Wenn das Hauptprogramm des benutzerdefinierten JAR-Clusters einen Ausnahmefehler beim Erstellen des Hadoop-Auftrags ausgibt, sehen Sie sich am besten die Datei `syslog` der Schrittprotokolle an. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
## Tritt auf Ihrem JAR-Cluster ein Fehler in einer Map-Aufgabe auf?
Wenn Ihr benutzerdefinierte JAR-Cluster und Mapper einen Ausnahmefehler beim Verarbeiten von Eingabedaten ausgibt, sehen Sie sich am besten die Datei `syslog` der Aufgabenversuchsprotokolle an. Weitere Informationen finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
# Fehler bei Amazon EMR AWS GovCloud (US-West)
Die Region AWS GovCloud (US-West) unterscheidet sich von anderen Regionen in Bezug auf Sicherheit, Konfiguration und Standardeinstellungen. Verwenden Sie daher die folgende Checkliste, um Amazon EMR-Fehler zu beheben, die für die Region AWS GovCloud (USA West) spezifisch sind, bevor Sie allgemeinere Empfehlungen zur Problembehandlung verwenden.
+ Überprüfen Sie, ob Ihre IAM-Rollen ordnungsgemäß konfiguriert sind. Weitere Informationen finden Sie unter [Konfiguration von IAM-Servicerollen für Amazon EMR-Berechtigungen für AWS Dienste und Ressourcen](emr-iam-roles.md).
+ Stellen Sie sicher, dass Ihre VPC-Konfiguration die Parameter resolution/hostname DNS-Unterstützung, Internet Gateway und DHCP-Optionssatz korrekt konfiguriert hat. Weitere Informationen finden Sie unter [VPC-Fehler bei Amazon EMR-Clustervorgängen](emr-troubleshoot-error-vpc.md).
Wenn diese Schritte das Problem nicht lösen, fahren Sie mit den Schritten zur Problembehebung allgemeiner Amazon-EMR-Fehler fort. Weitere Informationen finden Sie unter [Sammlungen häufiger Fehler in Amazon EMR](emr-troubleshoot-errors.md).
## Finden Sie einen fehlenden Cluster
Wenn Ihr Cluster in der Konsolenliste oder `ListClusters`-API fehlt, überprüfen Sie Folgendes:
+ Vergewissern Sie sich, dass das Alter des Clusters ab dem Zeitpunkt der Fertigstellung weniger als zwei Monate beträgt. Amazon EMR bewahrt Metadateninformationen für abgeschlossene Cluster zwei Monate lang kostenlos auf. Sie können abgeschlossene Cluster nicht aus der Konsole löschen. Stattdessen löscht Amazon EMR abgeschlossene Cluster automatisch nach zwei Monaten.
+ Bestätigen Sie, dass Sie über Rollenberechtigungen zum Anzeigen des Clusters verfügen.
+ Vergewissern Sie sich, dass Sie dort, AWS-Region wo sich der Cluster befindet, dieselbe Ansicht sehen.
# Fehlerbehebung bei einem Amazon EMR-Cluster, der mit einem Fehlercode ausgefallen ist
In diesem Abschnitt werden Sie durch den Vorgang zur Fehlerbehebung eines Cluster geführt, der ausgefallen ist. Das bedeutet, dass der Cluster mit einem Fehlercode beendet wurde.
**Anmerkung**
Wenn ein EMR-Cluster mit einem Fehler beendet wird, werden ein Fehlercode und eine Fehlermeldung `ListClusters` APIs zurückgegeben. `DescribeCluster` Bei einigen Clusterfehlern kann Ihnen das `ErrorDetail`-Datenarray bei der Behebung des Fehlers helfen. Weitere Informationen finden Sie unter [Fehlercodes mit ErrorDetail Informationen in Amazon EMR](emr-troubleshoot-error-errordetail.md).
Wenn Ihr Cluster ausgeführt wird, aber lange braucht, bis Ergebnisse zurückgegeben werden, finden Sie unter [Fehlerbehebung bei einem langsamen Amazon EMR-Cluster](emr-troubleshoot-slow.md).
**Topics**
+ [Schritt 1: Sammeln Sie Daten über das Problem mit dem Amazon EMR-Cluster](emr-troubleshoot-failed-1.md)
+ [Schritt 2: Die Umgebung prüfen](emr-troubleshoot-failed-2.md)
+ [Schritt 3: Die letzte Statusänderung überprüfen](emr-troubleshoot-failed-3.md)
+ [Schritt 4: Untersuchen Sie die Amazon EMR-Protokolldateien](emr-troubleshoot-failed-4.md)
+ [Schritt 5: Testen Sie den Amazon EMR-Cluster Schritt für Schritt](emr-troubleshoot-failed-5-test-steps.md)
# Schritt 1: Sammeln Sie Daten über das Problem mit dem Amazon EMR-Cluster
Der erste Schritt bei der Fehlerbehebung bei einem Cluster besteht darin, Informationen darüber zu sammeln, was schief gelaufen ist, sowie über den aktuellen Status und die Konfiguration des Clusters. Diese Informationen werden in den folgenden Schritten verwendet, um mögliche Ursachen des Problems zu bestätigen oder auszuschließen.
## Definieren des Problems
Eine klare Definition des Problems ist der erste Ausgangspunkt. Einige Fragen, die Sie sich stellen sollten:
+ Was habe ich erwartet? Was ist stattdessen passiert?
+ Wann ist dieses Problem zum ersten Mal aufgetreten? Wie oft ist es seitdem passiert?
+ Hat sich etwas an der Konfiguration oder Ausführung meines Clusters geändert?
## Cluster-Details
Die folgenden Clusterdetails sind hilfreich, um Probleme aufzuspüren. Weitere Informationen zum Sammeln dieser Informationen finden Sie unter [Status und Details des Amazon EMR-Clusters anzeigen](emr-manage-view-clusters.md).
+ Die Cluster-ID. (Wird auch als Job-Flow-Identifier bezeichnet.)
+ AWS-Region und Availability Zone, in der der Cluster gestartet wurde.
+ Status des Clusters, einschließlich Details zur letzten Statusänderung.
+ Typ und Anzahl der EC2-Instances, die für die Master-, Core- und Aufgabenknoten angegeben wurden.
# Schritt 2: Die Umgebung prüfen
Amazon EMR wird als Teil eines Ökosystems von Web-Services und Open-Source-Software betrieben. Faktoren, die sich auf diese Abhängigkeiten auswirken, können die Leistung von Amazon EMR beeinträchtigen.
**Topics**
+ [Prüfen auf Service-Ausfälle](#emr-troubleshoot-failed-2-outages)
+ [Prüfen auf Nutzungsgrenzen](#emr-troubleshoot-failed-2-limits)
+ [Überprüfen der Version](#emr-troubleshoot-failed-2-ami)
+ [Prüfen der Amazon-VPC-Subnetzkonfiguration](#emr-troubleshoot-failed-2-vpc)
## Prüfen auf Service-Ausfälle
Amazon EMR verwendet intern mehrere Amazon Web Services. Es betreibt virtuelle Server auf Amazon EC2, speichert Daten und Skripts auf Amazon S3 und meldet Metriken an CloudWatch. Ereignisse, die diese Services stören, sind selten – wenn sie jedoch auftreten, können sie zu Problemen in Amazon EMR führen.
Überprüfen Sie die [Übersicht zum Servicestatus](https://status.aws.amazon.com/), bevor Sie fortfahren. Prüfen Sie in der Region, in der Sie Ihren Cluster gestartet haben, ob es bei einem dieser Services zu Störungen gekommen ist.
## Prüfen auf Nutzungsgrenzen
Wenn Sie einen großen Cluster starten, viele Cluster gleichzeitig gestartet haben oder wenn Sie ein Benutzer sind, der sich einen Cluster AWS-Konto mit anderen Benutzern teilt, ist der Cluster möglicherweise ausgefallen, weil Sie ein AWS Service-Limit überschritten haben.
Amazon EC2 begrenzt die Anzahl der virtuellen Server-Instances, die in einer einzelnen AWS Region ausgeführt werden, auf 20 On-Demand-Instances oder Reserved Instances. Wenn Sie einen Cluster mit mehr als 20 Knoten starten oder einen Cluster starten, der dazu führt, dass die Gesamtzahl der auf Ihrem AWS-Konto Computer aktiven EC2-Instances 20 überschreitet, kann der Cluster nicht alle benötigten EC2-Instances starten und kann ausfallen. In diesem Fall gibt Amazon EMR einen `EC2 QUOTA EXCEEDED`-Fehler zurück. Sie können eine AWS Erhöhung der Anzahl der EC2-Instances, die Sie auf Ihrem Konto ausführen können, beantragen, indem Sie einen [Antrag auf Erhöhung des Amazon EC2 EC2-Instance-Limits](https://aws.amazon.com/contact-us/ec2-request/) einreichen.
Eine weitere Sache, die dazu führen kann, dass Sie Ihre Nutzungslimits überschreiten, ist die Verzögerung zwischen der Beendigung eines Clusters und der Freigabe aller seiner Ressourcen. Je nach Konfiguration kann es bis zu 5–20 Minuten dauern, bis ein Cluster vollständig beendet ist und zugewiesene Ressourcen freigibt. Wenn Sie beim Versuch, einen Custer zu starten, die Fehlermeldung `EC2 QUOTA EXCEEDED` erhalten, kann es daran liegen, dass Ressourcen eines kürzlich beendeten Clusters noch nicht zur Verfügung stehen. In diesem Fall können Sie entweder [eine Erhöhung Ihres Amazon-EC2-Kontingents](https://aws.amazon.com/contact-us/ec2-request/) beantragen oder zwanzig Minuten warten und den Cluster neu starten.
Amazon S3 begrenzt die Anzahl der auf einem Konto erstellten Buckets auf 100. Wenn Ihr Cluster einen neuen Bucket erstellt, der dieses Limit überschreitet, schlägt die Bucket-Erstellung fehl und kann dazu führen, dass der Cluster fehlschlägt.
## Überprüfen der Version
Vergleichen Sie die Versionsbezeichnung, die Sie zum Start des Clusters verwendet haben, mit der aktuellen Amazon-EMR-Version. Jede Version von Amazon EMR beinhaltet Verbesserungen, wie z. B. neue Anwendungen, Features, Patches und Fehlerbehebungen. Das Problem, das Ihren Cluster betrifft, wurde in der aktuellen Version möglicherweise bereits behoben. Führen Sie Ihren Cluster wenn möglich mit der aktuellen Version erneut aus.
## Prüfen der Amazon-VPC-Subnetzkonfiguration
Wenn Ihr Cluster in einem Amazon VPC-Subnetz gestartet wurde, muss das Subnetz wie unter [Konfiguration von Netzwerken in einer VPC für Amazon EMR](emr-plan-vpc-subnet.md) beschrieben konfiguriert werden. Überprüfen Sie außerdem, ob das Subnetz, in dem Sie den Cluster starten, über genügend freie elastische IP-Adressen verfügt, um jedem Knoten im Cluster eine zuzuweisen.
# Schritt 3: Die letzte Statusänderung überprüfen
Die letzte Statusänderung gibt Aufschluss darüber, welches Ereignis bei der letzten Statusänderung des Clusters aufgetreten ist. Häufig lassen sich Informationen gewinnen, die Hinweise darauf geben, welcher Fehler auftrat, als sich der Cluster-Status in `FAILED` änderte. Wenn Sie beispielsweise einen Streaming-Cluster starten und einen Ausgabespeicherort angeben, der in Amazon S3 bereits vorhanden ist, tritt beim Cluster ein Fehler auf und die letzte Statusänderung weist darauf hin, dass das Streaming-Ausgabeverzeichnis bereits vorhanden ist.
Sie können den Wert der letzten Statusänderung über die Konsole ermitteln, indem Sie den Detailbereich für den Cluster über die Befehlszeilenschnittstelle (CLI) mit dem Argument `list-steps` oder `describe-cluster` bzw. über die API mit den Aktionen `DescribeCluster` und `ListSteps` anzeigen. Weitere Informationen finden Sie unter [Status und Details des Amazon EMR-Clusters anzeigen](emr-manage-view-clusters.md).
# Schritt 4: Untersuchen Sie die Amazon EMR-Protokolldateien
Der nächste Schritt besteht darin, die Protokolldateien zu untersuchen, um einen Fehlercode oder einen anderen Hinweis auf das Problem zu finden, das in Ihrem Cluster aufgetreten ist. Informationen zu den verfügbaren Protokolldateien, wo sie zu finden sind und wie Sie sie anzeigen können, finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
Es kann einige Nachforschungen erfordern, um herauszufinden, was passiert ist. Hadoop führt die Arbeit der Aufträge in Aufgabenversuchen auf verschiedenen Knoten im Cluster aus. Amazon EMR kann spekulative Aufgabenversuche initiieren und die anderen Aufgabenversuche beenden, die nicht zuerst abgeschlossen werden. Dadurch werden umfangreiche Aktivitäten generiert, die in den Controller-, Stderr- und Syslog-Protokolldateien protokolliert werden. Darüber hinaus werden mehrere Aufgaben gleichzeitig ausgeführt, aber eine Protokolldatei kann die Ergebnisse nur linear anzeigen.
Überprüfen Sie zunächst die Bootstrap-Aktionsprotokolle auf Fehler oder unerwartete Konfigurationsänderungen beim Start des Clusters. Suchen Sie anschließend in den Schrittprotokollen nach Hadoop-Aufträgen, die als Teil eines fehlerhaften Schritts gestartet wurden. Untersuchen Sie die Hadoop-Auftragsprotokolle, um die fehlgeschlagenen Aufgabenversuche zu identifizieren. Das Protokoll der Aufgabenversuche wird Details darüber enthalten, was zum Fehlschlagen eines Aufgabenversuchs geführt hat.
In den folgenden Abschnitten wird erläutert, wie die verschiedenen Protokolldateien verwendet werden, um Fehler in Ihrem Cluster zu identifizieren.
## Die Bootstrap-Aktionsprotokolle überprüfen
Bootstrap-Aktionen führen Skripts auf dem Cluster aus, während dieser gestartet wird. Sie werden häufig verwendet, um zusätzliche Software auf dem Cluster zu installieren oder um Konfigurationseinstellungen gegenüber den Standardwerten zu ändern. Die Überprüfung dieser Protokolle kann Aufschluss über Fehler geben, die bei der Einrichtung des Clusters aufgetreten sind, sowie über Änderungen der Konfigurationseinstellungen, die sich auf die Leistung auswirken könnten.
## Die Schrittprotokolle überprüfen
Es gibt vier Arten von Schrittprotokollen.
+ **Controller – ** Enthält von Amazon EMR (Amazon EMR) generierte Dateien, die auf Fehler zurückzuführen sind, die bei der Ausführung Ihres Schritts aufgetreten sind. Wenn Ihr Schritt beim Laden fehlschlägt, finden Sie den Stack-Trace in diesem Protokoll. Fehler beim Laden oder Zugreifen auf Ihre Anwendung werden hier häufig beschrieben, ebenso wie Fehler in der fehlenden Mapper-Datei.
+ **stderr – ** Enthält Fehlermeldungen, die bei der Verarbeitung des Schritts aufgetreten sind. Fehler beim Laden von Anwendungen werden hier häufig beschrieben. Dieses Protokoll enthält manchmal einen Stack-Trace.
+ **stdout – ** Enthält den Status, der von Ihren ausführbaren Mapper- und Reducer-Dateien generiert wurde. Fehler beim Laden von Anwendungen werden hier häufig beschrieben. Dieses Protokoll enthält manchmal Anwendungsfehlermeldungen.
+ **syslog – ** Enthält Protokolle von Software, die nicht von Amazon stammt, wie Apache und Hadoop. Streaming-Fehler werden hier häufig beschrieben.
Überprüfen Sie stderr auf offensichtliche Fehler. Wenn stderr eine kurze Liste von Fehlern anzeigt, wurde der Schritt schnell beendet und es wurde ein Fehler ausgelöst. Dies wird meistens durch einen Fehler in den Mapper- und Reducer-Anwendungen verursacht, die im Cluster ausgeführt werden.
Untersuchen Sie die letzten Zeilen von Controller und Syslog auf Hinweise auf Fehler oder Ausfälle. Folgen Sie allen Hinweisen zu fehlgeschlagenen Aufgaben, insbesondere wenn dort „Auftrag fehlgeschlagen“ steht.
## Die Aufgabenversuchsprotokolle überprüfen
Wenn die vorherige Analyse der Schrittprotokolle eine oder mehrere fehlgeschlagene Aufgaben ergeben hat, suchen Sie in den Protokollen der entsprechenden Aufgabenversuche nach detaillierteren Fehlerinformationen.
# Schritt 5: Testen Sie den Amazon EMR-Cluster Schritt für Schritt
Eine nützliche Strategie zum Nachverfolgen der Ursache für einen Fehler besteht darin, den Cluster neu zu starten und die Schritte einzeln auszuführen. So können Sie die Ergebnisse für jeden Schritt überprüfen, bevor Sie die Verarbeitung des nächsten Schritts starten, und erhalten die Möglichkeit, einen fehlgeschlagenen Schritt zu korrigieren und erneut auszuführen. Dies hat den Vorteil, dass Sie Ihre Eingabedaten nur einmal laden müssen.
**So testen Sie den Cluster Schritt für Schritt**
1. Starten Sie einen neuen Cluster mit aktiviertem Keepalive und Beendigungsschutz. Keepalive sorgt dafür, dass der Cluster weiterhin ausgeführt wird, nachdem er alle ausstehenden Schritte verarbeitet hat. Der Beendigungsschutz verhindert, dass ein Cluster im Falle eines Fehlers heruntergefahren wird. Weitere Informationen erhalten Sie unter [Konfiguration eines Amazon EMR-Clusters zum Fortfahren oder Beenden nach der Ausführung des Schritts](emr-plan-longrunning-transient.md) und [Verwenden Sie den Kündigungsschutz, um Ihre Amazon EMR-Cluster vor einem versehentlichen Herunterfahren zu schützen](UsingEMR_TerminationProtection.md).
1. Senden Sie einen Schritt an den Cluster. Weitere Informationen finden Sie unter [Arbeit an einen Amazon EMR-Cluster einreichen](emr-work-with-steps.md).
1. Wenn die Verarbeitung des Schritts abgeschlossen ist, prüfen Sie die Schrittprotokolldateien auf Fehler. Weitere Informationen finden Sie unter [Schritt 4: Untersuchen Sie die Amazon EMR-Protokolldateien](emr-troubleshoot-failed-4.md). Die schnellste Möglichkeit zum Auffinden dieser Protokolldateien besteht darin, eine Verbindung mit dem Master-Knoten herzustellen und die Protokolldateien hier anzuzeigen. Die Schrittprotokolldateien werden erst angezeigt, wenn der Schritt einige Zeit ausgeführt wird, beendet wird oder ein Fehler auftritt.
1. Wenn der Schritt erfolgreich ohne Fehler abgeschlossen wurde, führen Sie den nächsten Schritt aus. Wenn Fehler vorliegen, ermitteln Sie den Fehler in den Protokolldateien. Wenn in Ihrem Code ein Fehler aufgetreten ist, korrigieren Sie ihn und führen Sie den Schritt erneut aus. Fahren Sie fort, bis alle Schritte ohne Fehler ausgeführt werden.
1. Wenn Sie das Debuggen des Clusters abgeschlossen haben, müssen Sie den Cluster ggf. manuell beenden. Dies ist erforderlich, da der Cluster mit aktiviertem Beendigungsschutz gestartet wurde. Weitere Informationen finden Sie unter [Verwenden Sie den Kündigungsschutz, um Ihre Amazon EMR-Cluster vor einem versehentlichen Herunterfahren zu schützen](UsingEMR_TerminationProtection.md).
# Fehlerbehebung bei einem langsamen Amazon EMR-Cluster
In diesem Abschnitt wird die Fehlerbehebung eines Clusters beschrieben, der noch ausgeführt wird, aber viel Zeit benötigt, um Ergebnisse zurückzugeben. Weitere Informationen zu Verfahren, die Sie anwenden können, wenn der Cluster mit einem Fehlercode beendet wurde, finden Sie unter [Fehlerbehebung bei einem Amazon EMR-Cluster, der mit einem Fehlercode ausgefallen ist](emr-troubleshoot-failed.md)
Mit Amazon EMR können Sie die Anzahl und Art der Instances im Cluster festlegen. Diese Spezifikationen sind die beste Möglichkeit, die Geschwindigkeit, mit der Ihre Daten verarbeitet werden, zu beeinflussen. Sie können eine erneute Ausführung des Clusters in Betracht ziehen. Hierbei legen Sie EC2-Instances mit mehr Ressourcen oder eine größere Anzahl der Instances im Cluster fest. Weitere Informationen finden Sie unter [Amazon EMR-Cluster-Hardware und -Netzwerke konfigurieren](emr-plan-instances.md).
In den folgenden Themen wird erklärt, wie Sie alternative Ursachen für einen langsamen Cluster identifizieren.
**Topics**
+ [Schritt 1: Sammeln Sie Daten über das Problem mit dem Amazon EMR-Cluster](emr-troubleshoot-slow-1.md)
+ [Schritt 2: Überprüfen Sie die EMR-Cluster-Umgebung](emr-troubleshoot-slow-2.md)
+ [Schritt 3: Untersuchen Sie die Protokolldateien für den Amazon EMR-Cluster](emr-troubleshoot-slow-3.md)
+ [Schritt 4: Überprüfen Sie den Zustand des Amazon EMR-Clusters und der Instance](emr-troubleshoot-slow-4.md)
+ [Schritt 5: Nach gesperrten Gruppen suchen](emr-troubleshoot-slow-5.md)
+ [Schritt 6: Überprüfen Sie die Konfigurationseinstellungen für den Amazon EMR-Cluster](emr-troubleshoot-slow-6.md)
+ [Schritt 7: Untersuchen Sie die Eingabedaten für den Amazon EMR-Cluster](emr-troubleshoot-slow-7.md)
# Schritt 1: Sammeln Sie Daten über das Problem mit dem Amazon EMR-Cluster
Der erste Schritt bei der Fehlerbehebung bei einem Cluster besteht darin, Informationen darüber zu sammeln, was schief gelaufen ist, sowie über den aktuellen Status und die Konfiguration des Clusters. Diese Informationen werden in den folgenden Schritten verwendet, um mögliche Ursachen des Problems zu bestätigen oder auszuschließen.
## Definieren des Problems
Eine klare Definition des Problems ist der erste Ausgangspunkt. Einige Fragen, die Sie sich stellen sollten:
+ Was habe ich erwartet? Was ist stattdessen passiert?
+ Wann ist dieses Problem zum ersten Mal aufgetreten? Wie oft ist es seitdem passiert?
+ Hat sich etwas an der Konfiguration oder Ausführung meines Clusters geändert?
## Cluster-Details
Die folgenden Clusterdetails sind hilfreich, um Probleme aufzuspüren. Weitere Informationen zum Sammeln dieser Informationen finden Sie unter [Status und Details des Amazon EMR-Clusters anzeigen](emr-manage-view-clusters.md).
+ Die Cluster-ID. (Wird auch als Job-Flow-Identifier bezeichnet.)
+ AWS-Region und Availability Zone, in der der Cluster gestartet wurde.
+ Status des Clusters, einschließlich Details zur letzten Statusänderung.
+ Typ und Anzahl der EC2-Instances, die für die Master-, Core- und Aufgabenknoten angegeben wurden.
# Schritt 2: Überprüfen Sie die EMR-Cluster-Umgebung
Prüfen Sie in Ihrer Umgebung, ob es Serviceausfälle gibt oder ob Sie ein AWS Servicelimit überschritten haben.
**Topics**
+ [Prüfen auf Service-Ausfälle](#emr-troubleshoot-slow-2-outages)
+ [Prüfen auf Nutzungsgrenzen](#emr-troubleshoot-slow-2-limits)
+ [Prüfen der Amazon-VPC-Subnetzkonfiguration](#emr-troubleshoot-slow-2-vpc)
+ [Neustarten des Clusters](#emr-troubleshoot-slow-2-restart)
## Prüfen auf Service-Ausfälle
Amazon EMR verwendet intern mehrere Amazon Web Services. Es betreibt virtuelle Server auf Amazon EC2, speichert Daten und Skripts auf Amazon S3 und meldet Metriken an CloudWatch. Ereignisse, die diese Services stören, sind selten – wenn sie jedoch auftreten, können sie zu Problemen in Amazon EMR führen.
Überprüfen Sie die [Übersicht zum Servicestatus](https://status.aws.amazon.com/), bevor Sie fortfahren. Prüfen Sie in der Region, in der Sie Ihren Cluster gestartet haben, ob es bei einem dieser Services zu Störungen gekommen ist.
## Prüfen auf Nutzungsgrenzen
Wenn Sie einen großen Cluster starten, viele Cluster gleichzeitig gestartet haben oder wenn Sie ein Benutzer sind, der sich einen Cluster AWS-Konto mit anderen Benutzern teilt, ist der Cluster möglicherweise ausgefallen, weil Sie ein AWS Service-Limit überschritten haben.
Amazon EC2 begrenzt die Anzahl der virtuellen Server-Instances, die in einer einzelnen AWS Region ausgeführt werden, auf 20 On-Demand-Instances oder Reserved Instances. Wenn Sie einen Cluster mit mehr als 20 Knoten starten oder einen Cluster starten, der dazu führt, dass die Gesamtzahl der auf Ihrem AWS-Konto Computer aktiven EC2-Instances 20 überschreitet, kann der Cluster nicht alle benötigten EC2-Instances starten und kann ausfallen. In diesem Fall gibt Amazon EMR einen `EC2 QUOTA EXCEEDED`-Fehler zurück. Sie können eine AWS Erhöhung der Anzahl der EC2-Instances, die Sie auf Ihrem Konto ausführen können, beantragen, indem Sie einen [Antrag auf Erhöhung des Amazon EC2 EC2-Instance-Limits](https://aws.amazon.com/contact-us/ec2-request/) einreichen.
Eine weitere Sache, die dazu führen kann, dass Sie Ihre Nutzungslimits überschreiten, ist die Verzögerung zwischen der Beendigung eines Clusters und der Freigabe aller seiner Ressourcen. Je nach Konfiguration kann es bis zu 5–20 Minuten dauern, bis ein Cluster vollständig beendet ist und zugewiesene Ressourcen freigibt. Wenn Sie beim Versuch, einen Custer zu starten, die Fehlermeldung `EC2 QUOTA EXCEEDED` erhalten, kann es daran liegen, dass Ressourcen eines kürzlich beendeten Clusters noch nicht zur Verfügung stehen. In diesem Fall können Sie entweder [eine Erhöhung Ihres Amazon-EC2-Kontingents](https://aws.amazon.com/contact-us/ec2-request/) beantragen oder zwanzig Minuten warten und den Cluster neu starten.
Amazon S3 begrenzt die Anzahl der auf einem Konto erstellten Buckets auf 100. Wenn Ihr Cluster einen neuen Bucket erstellt, der dieses Limit überschreitet, schlägt die Bucket-Erstellung fehl und kann dazu führen, dass der Cluster fehlschlägt.
## Prüfen der Amazon-VPC-Subnetzkonfiguration
Wenn Ihr Cluster in einem Amazon VPC-Subnetz gestartet wurde, muss das Subnetz wie unter [Konfiguration von Netzwerken in einer VPC für Amazon EMR](emr-plan-vpc-subnet.md) beschrieben konfiguriert werden. Überprüfen Sie außerdem, ob das Subnetz, in dem Sie den Cluster starten, über genügend freie elastische IP-Adressen verfügt, um jedem Knoten im Cluster eine zuzuweisen.
## Neustarten des Clusters
Die Verlangsamung der Verarbeitung kann von einer vorübergehenden Bedingung herrühren. Überlegen Sie sich, ob Sie den Cluster beenden und neu starten möchten, um zu prüfen, ob sich die Leistung verbessert.
# Schritt 3: Untersuchen Sie die Protokolldateien für den Amazon EMR-Cluster
Der nächste Schritt besteht darin, die Protokolldateien zu untersuchen, um einen Fehlercode oder einen anderen Hinweis auf das Problem zu finden, das in Ihrem Cluster aufgetreten ist. Informationen zu den verfügbaren Protokolldateien, wo sie zu finden sind und wie Sie sie anzeigen können, finden Sie unter [Amazon EMR-Protokolldateien anzeigen](emr-manage-view-web-log-files.md).
Es kann einige Nachforschungen erfordern, um herauszufinden, was passiert ist. Hadoop führt die Arbeit der Aufträge in Aufgabenversuchen auf verschiedenen Knoten im Cluster aus. Amazon EMR kann spekulative Aufgabenversuche initiieren und die anderen Aufgabenversuche beenden, die nicht zuerst abgeschlossen werden. Dadurch werden umfangreiche Aktivitäten generiert, die in den Controller-, Stderr- und Syslog-Protokolldateien protokolliert werden. Darüber hinaus werden mehrere Aufgaben gleichzeitig ausgeführt, aber eine Protokolldatei kann die Ergebnisse nur linear anzeigen.
Überprüfen Sie zunächst die Bootstrap-Aktionsprotokolle auf Fehler oder unerwartete Konfigurationsänderungen beim Start des Clusters. Suchen Sie anschließend in den Schrittprotokollen nach Hadoop-Aufträgen, die als Teil eines fehlerhaften Schritts gestartet wurden. Untersuchen Sie die Hadoop-Auftragsprotokolle, um die fehlgeschlagenen Aufgabenversuche zu identifizieren. Das Protokoll der Aufgabenversuche wird Details darüber enthalten, was zum Fehlschlagen eines Aufgabenversuchs geführt hat.
In den folgenden Abschnitten wird erläutert, wie die verschiedenen Protokolldateien verwendet werden, um Fehler in Ihrem Cluster zu identifizieren.
## Die Bootstrap-Aktionsprotokolle überprüfen
Bootstrap-Aktionen führen Skripts auf dem Cluster aus, während dieser gestartet wird. Sie werden häufig verwendet, um zusätzliche Software auf dem Cluster zu installieren oder um Konfigurationseinstellungen gegenüber den Standardwerten zu ändern. Die Überprüfung dieser Protokolle kann Aufschluss über Fehler geben, die bei der Einrichtung des Clusters aufgetreten sind, sowie über Änderungen der Konfigurationseinstellungen, die sich auf die Leistung auswirken könnten.
## Die Schrittprotokolle überprüfen
Es gibt vier Arten von Schrittprotokollen.
+ **Controller – ** Enthält von Amazon EMR (Amazon EMR) generierte Dateien, die auf Fehler zurückzuführen sind, die bei der Ausführung Ihres Schritts aufgetreten sind. Wenn Ihr Schritt beim Laden fehlschlägt, finden Sie den Stack-Trace in diesem Protokoll. Fehler beim Laden oder Zugreifen auf Ihre Anwendung werden hier häufig beschrieben, ebenso wie Fehler in der fehlenden Mapper-Datei.
+ **stderr – ** Enthält Fehlermeldungen, die bei der Verarbeitung des Schritts aufgetreten sind. Fehler beim Laden von Anwendungen werden hier häufig beschrieben. Dieses Protokoll enthält manchmal einen Stack-Trace.
+ **stdout – ** Enthält den Status, der von Ihren ausführbaren Mapper- und Reducer-Dateien generiert wurde. Fehler beim Laden von Anwendungen werden hier häufig beschrieben. Dieses Protokoll enthält manchmal Anwendungsfehlermeldungen.
+ **syslog – ** Enthält Protokolle von Software, die nicht von Amazon stammt, wie Apache und Hadoop. Streaming-Fehler werden hier häufig beschrieben.
Überprüfen Sie stderr auf offensichtliche Fehler. Wenn stderr eine kurze Liste von Fehlern anzeigt, wurde der Schritt schnell beendet und es wurde ein Fehler ausgelöst. Dies wird meistens durch einen Fehler in den Mapper- und Reducer-Anwendungen verursacht, die im Cluster ausgeführt werden.
Untersuchen Sie die letzten Zeilen von Controller und Syslog auf Hinweise auf Fehler oder Ausfälle. Folgen Sie allen Hinweisen zu fehlgeschlagenen Aufgaben, insbesondere wenn dort „Auftrag fehlgeschlagen“ steht.
## Die Aufgabenversuchsprotokolle überprüfen
Wenn die vorherige Analyse der Schrittprotokolle eine oder mehrere fehlgeschlagene Aufgaben ergeben hat, suchen Sie in den Protokollen der entsprechenden Aufgabenversuche nach detaillierteren Fehlerinformationen.
## Die Hadoop-Daemon-Protokolle überprüfen
In seltenen Fällen kann Hadoop selbst ausfallen. Um zu sehen, ob das der Fall ist, müssen Sie sich die Hadoop-Protokolle ansehen. Sie befinden sich auf `/var/log/hadoop/` auf jedem Knoten.
Sie können die JobTracker Protokolle verwenden, um einen fehlgeschlagenen Taskversuch dem Knoten zuzuordnen, auf dem er ausgeführt wurde. Sobald Sie den Knoten kennen, der mit dem Aufgabenversuch verknüpft ist, können Sie den Zustand der EC2-Instance überprüfen, die diesen Knoten hostet, um festzustellen, ob Probleme wie etwa ein Mangel an CPU oder Arbeitsspeicher aufgetreten sind.
# Schritt 4: Überprüfen Sie den Zustand des Amazon EMR-Clusters und der Instance
Ein Amazon-EMR-Cluster besteht aus Knoten, die auf Amazon EC2 Instances ausgeführt werden. Wenn diese Instances viele Ressourcen binden (z. B. CPU oder Speicherplatz), Probleme mit der Netzwerkkonnektivität haben oder beendet werden, leidet die Geschwindigkeit der Cluster-Verarbeitung.
Es gibt bis zu drei Arten von Knoten in einem Cluster:
+ **Hauptknoten** – verwaltet den Cluster. Wenn ein Leistungsproblem auftritt, ist der gesamte Cluster betroffen.
+ **Core-Knoten** – verarbeiten Map- und Reduce-Aufgaben und verwalten das Hadoop Distributed File System (HDFS). Wenn einer dieser Knoten ein Leistungsproblem hat, kann dies sowohl HDFS-Operationen als auch Map- und Reduce-Verarbeitungen verlangsamen. Sie können einem Cluster zusätzliche Core-Knoten hinzufügen, um die Leistung zu verbessern, aber keine Core-Knoten entfernen. Weitere Informationen finden Sie unter [Manuelles Ändern der Größe eines laufenden Amazon EMR-Clusters](emr-manage-resize.md).
+ **Aufgabenknoten** – verarbeiten Map- und Reduce-Aufgaben. Dies sind reine Rechenressourcen und speichern keine Daten. Sie können einem Cluster Aufgabenknoten hinzufügen, um die Leistung zu beschleunigen, oder nicht benötigte Aufgabenknoten entfernen. Weitere Informationen finden Sie unter [Manuelles Ändern der Größe eines laufenden Amazon EMR-Clusters](emr-manage-resize.md).
Wenn Sie den Zustand eines Clusters prüfen, sollten Sie sich sowohl die Leistung des Clusters insgesamt als auch die Leistung der einzelnen Instances anschauen. Es gibt mehrere Tools, die Sie verwenden können:
## Überprüfen Sie den Zustand des Clusters mit CloudWatch
Jeder Amazon EMR-Cluster meldet Metriken an CloudWatch. Diese Metriken stellen zusammenfassende Leistungsinformationen über den Cluster bereit, wie z. B. Gesamtlast, HDFS-Auslastung, ausgeführte Aufgaben, verbleibende Aufgaben und beschädigte Blöcke. Wenn Sie sich die CloudWatch Metriken ansehen, erhalten Sie einen Überblick darüber, was in Ihrem Cluster vor sich geht, und Sie erhalten einen Einblick in die Ursachen für die Verlangsamung der Verarbeitung. Sie können nicht nur ein vorhandenes Leistungsproblem analysieren, sondern auch Alarme einrichten, die eine Warnung auslösen CloudWatch , wenn ein future Leistungsproblem auftritt. CloudWatch Weitere Informationen finden Sie unter [Überwachung von Amazon EMR-Metriken mit CloudWatch](UsingEMR_ViewingMetrics.md).
## Überprüfen von Auftragsstatus und HDFS-Zustand
Verwenden Sie die Option **Application user interface (Anwendungsbenutzeroberflächen)** auf der Detailseite des Clusters, um Details zur YARN-Anwendung anzuzeigen. Bei bestimmten Anwendungen können Sie weitere Details und Zugriffsprotokolle direkt anzeigen. Dies ist besonders nützlich für Spark-Anwendungen. Weitere Informationen finden Sie unter [Amazon EMR-Anwendungsverlauf anzeigen](emr-cluster-application-history.md).
Hadoop bietet eine Reihe von Webschnittstellen, mit denen Sie Informationen anzeigen lassen können. Weitere Informationen darüber, wie Sie auf diese Webschnittstellen zugreifen können, finden Sie unter [Anzeigen von auf Amazon-EMR-Clustern gehosteten Webschnittstellen](emr-web-interfaces.md).
+ JobTracker — liefert Informationen über den Status des Jobs, der vom Cluster verarbeitet wird. Mit dieser Schnittstelle können Sie ermitteln, wann ein Auftrag blockiert ist.
+ HDFS NameNode — liefert Informationen über den Prozentsatz der HDFS-Auslastung und den verfügbaren Speicherplatz auf jedem Knoten. Sie können mit dieser Schnittstelle bestimmen, wann HDFS Ressourcen bindet und zusätzliche Kapazität benötigt.
+ TaskTracker — liefert Informationen über die Aufgaben des Jobs, die vom Cluster verarbeitet werden. Mit dieser Schnittstelle können Sie ermitteln, wann eine Aufgabe blockiert ist.
## Instance-Zustandsprüfung mit Amazon EC2
Die Amazon-EC2-Konsole bietet eine weitere Möglichkeit, um Informationen über den Status der Instances in Ihrem Cluster zu ermitteln. Da jeder Knoten im Cluster auf einer EC2-Instance ausgeführt wird, können Sie mithilfe der von Amazon EC2 bereitgestellten Tools ihren Status überprüfen. Weitere Informationen finden Sie unter [Anzeigen von Cluster-Instances in Amazon EC2](UsingEMR_Tagging.md).
# Schritt 5: Nach gesperrten Gruppen suchen
Eine Instance-Truppe wird angehalten, wenn beim Versuch, einen Knoten zu starten, zu viele Fehler auftreten. Wenn z. B. neue Knoten während der Durchführung von Bootstrap-Aktionen wiederholt fehlschlagen, wechselt die Instance-Gruppe nach einiger Zeit in den Status `SUSPENDED`, anstatt fortlaufend zu versuchen, neue Knoten bereitzustellen.
In folgenden Fällen kann ein Knoten fehlschlagen:
+ Hadoop oder der Cluster ist irgendwie beschädigt und akzeptiert keinen neuen Knoten im Cluster.
+ Eine Bootstrap-Aktion schlägt auf dem neuen Knoten fehl.
+ Der Knoten arbeitet nicht ordnungsgemäß und kann nicht mit Hadoop einchecken
Wenn sich eine Instance-Gruppe im Status `SUSPENDED` befindet und der Cluster den Status `WAITING` hat, können Sie einen Cluster-Schritt hinzufügen, um die gewünschte Anzahl von Core- und Aufgabenknoten zurückzusetzen. Durch Hinzufügen des Schritts wird die Verarbeitung des Clusters fortgesetzt und die Instance-Gruppe wieder in den Status `RUNNING` versetzt.
Weitere Informationen zum Zurücksetzen eines Clusters im angehaltenen Zustand finden Sie unter [Suspendierter Zustand](emr-manage-resize.md#emr-manage-resizeSuspended).
# Schritt 6: Überprüfen Sie die Konfigurationseinstellungen für den Amazon EMR-Cluster
Konfigurationseinstellungen legen die Ausführung eines Clusters im Detail fest, z. B. wie häufig eine Aufgabe wiederholt wird und wie viel Arbeitsspeicher zum Sortieren verfügbar ist. Wenn Sie einen Cluster mithilfe von Amazon EMR starten, gibt es zusätzlich zu den standardmäßigen Hadoop-Konfigurationseinstellungen auch Amazon-EMR-spezifische Einstellungen. Die Konfigurationseinstellungen werden im Master-Knoten des Clusters gespeichert. Sie können die Konfigurationseinstellungen überprüfen, um sicherzustellen, dass Ihr Cluster über die benötigten Ressourcen für einen effizienten Betrieb verfügt.
Amazon EMR legt standardmäßige Hadoop-Konfigurationseinstellungen fest, die zum Starten eines Clusters verwendet werden. Die Werte basieren auf dem AMI und dem Instance-Typ, den Sie für den Cluster angeben. Ändern können Sie die Standardwerte der Konfigurationseinstellungen mithilfe einer Bootstrap-Aktion oder indem Sie neue Wert in den Parametern für die Auftragsausführung festlegen. Weitere Informationen finden Sie unter [Erstellen Sie Bootstrap-Aktionen, um zusätzliche Software mit einem Amazon EMR-Cluster zu installieren](emr-plan-bootstrap.md). Um zu bestimmen, ob eine Bootstrap-Aktion die Konfigurationseinstellungen geändert hat, prüfen Sie die Bootstrap-Aktionsprotokolle.
Amazon EMR protokolliert die Hadoop-Einstellungen für die Ausführung aller Aufträge. Die Protokolldaten werden in einer Datei gespeichert, die `job_job-id_conf.xml` unter dem `/mnt/var/log/hadoop/history/` Verzeichnis des Master-Knotens benannt *job-id* ist und dort durch die ID des Auftrags ersetzt wird. Wenn Sie die Protokollarchivierung aktiviert haben, werden diese Daten in dem `logs/date/jobflow-id/jobs` Ordner nach Amazon S3 kopiert, wo sich das Datum *date* befindet, an dem der Job ausgeführt wurde, und der Identifier des Clusters *jobflow-id* ist.
Die folgenden Konfigurationseinstellungen des Hadoop-Auftrags eignen sich besonders für die Untersuchung von Leistungsproblemen. Weitere Informationen zu den Hadoop-Konfigurationseinstellungen und deren Auswirkungen auf das Verhalten von Hadoop finden Sie unter [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/).
**Warnung**
Das Festlegen von `dfs.replication` auf 1 auf Clustern mit weniger als vier Knoten kann zu einem HDFS-Datenverlust führen, wenn ein einzelner Knoten ausfällt. Wir empfehlen, für Produktionsworkloads einen Cluster mit mindestens vier Core-Knoten zu verwenden.
Amazon EMR erlaubt Clustern nicht, Core-Knoten unter `dfs.replication` zu skalieren. Bei `dfs.replication = 2` z. B. beträgt die Mindestanzahl von Core-Knoten 2.
Wenn Sie verwaltete Skalierung oder Auto-Scaling verwenden oder die Größe Ihres Clusters manuell ändern möchten, empfehlen wir Ihnen, `dfs.replication` auf 2 oder höher einzustellen.
| Konfigurationseinstellung | Description |
| --- | --- |
| dfs.replication | Die Anzahl der HDFS-Knoten, in die ein einziger Block (z. B. der Festplattenblock) kopiert wird, um eine RAID-ähnliche Umgebung zu erstellen. Bestimmt die Anzahl der HDFS-Knoten, die eine Kopie des Blocks enthalten. |
| io.sort.mb | Für die Sortierung verfügbarer Gesamtspeicher. Dieser Wert sollte das Zehnfache von "io.sort.factor" sein. Diese Einstellung kann auch für die Berechnung des vom Aufgabenknoten genutzten Gesamtspeichers durch Berechnen von "io.sort.mb" multipliziert mit "mapred.tasktracker.ap.tasks.maximum" verwendet werden. |
| io.sort.spill.percent | Wird während der Sortierung verwendet. An diesem Punkt beginnt die Verwendung des Datenträgers, da der für die Sortierung zugewiesene Speicherplatz knapp wird. |
| mapred.child.java.opts | Als veraltet gekennzeichnet. Verwenden Sie stattdessen "mapred.map.child.java.opts" und "mapred.reduce.child.java.opts". Die Java-Optionen, die TaskTracker verwendet werden, wenn eine JVM gestartet wird, damit eine Aufgabe darin ausgeführt wird. "-Xmx" ist ein üblicher Parameter zum Festlegen der maximalen Arbeitsspeichergröße. |
| mapred.map.child.java.opts | Die Java-Optionen, die beim Starten einer JVM für eine Map-Aufgabe TaskTracker verwendet werden, die darin ausgeführt werden soll. "-Xmx" ist ein üblicher Parameter zum Festlegen der maximalen Heap-Arbeitsspeichergröße. |
| mapred.map.tasks.speculative.execution | Legt fest, ob Map-Aufgabenversuche derselben Aufgabe parallel gestartet werden können. |
| mapred.reduce.tasks.speculative.execution | Legt fest, ob Reduce-Aufgabenversuche derselben Aufgabe parallel gestartet werden können. |
| mapred.map.max.attempts | Die maximale Anzahl an Map-Aufgabenversuchen. Wenn alle fehlschlagen, wird die Map-Aufgabe als fehlgeschlagen markiert. |
| mapred.reduce.child.java.opts | Die Java-Optionen, die beim Starten einer JVM für eine Reduce-Aufgabe zur Ausführung innerhalb einer JVM TaskTracker verwendet werden. "-Xmx" ist ein üblicher Parameter zum Festlegen der maximalen Heap-Arbeitsspeichergröße. |
| mapred.reduce.max.attempts | Die maximale Anzahl an Reduce-Aufgabenversuchen. Wenn alle fehlschlagen, wird die Map-Aufgabe als fehlgeschlagen markiert. |
| mapred.reduce.slowstart.completed.maps | Die Anzahl an Map-Aufgaben, die abgeschlossen werden, bevor Reduce-Aufgabenversuche durchgeführt werden. Bei zu geringer Wartezeit kann der Fehler „Too many fetch" in Versuchen ausgelöst werden. |
| mapred.reuse.jvm.num.tasks | Eine Aufgabe wird innerhalb einer einzelnen JVM ausgeführt. Gibt an, wie viele Aufgaben dieselbe JVM wiederverwenden dürfen. |
| mapred.tasktracker.map.tasks.maximum | Die maximale Anzahl von Aufgaben, die während des Map-Vorgangs pro Aufgabenknoten parallel ausgeführt werden können. |
| mapred.tasktracker.reduce.tasks.maximum | Die maximale Anzahl von Aufgaben, die während des Reduce-Vorgangs pro Aufgabenknoten parallel ausgeführt werden können. |
Wenn Ihre Cluster-Aufgaben arbeitsspeicherintensiv sind, können Sie die Leistung verbessern, indem Sie weniger Aufgaben pro Core-Knoten verwenden und die Heap-Größe des JobTrackers reduzieren.
# Schritt 7: Untersuchen Sie die Eingabedaten für den Amazon EMR-Cluster
Schauen Sie sich Ihre Eingabedaten an. Sind diese gleichmäßig auf Ihre Schlüsselwerte verteilt? Bei einer starken Datenschiefe in Richtung eines oder weniger Schlüsselwerte wird die Verarbeitungslast möglicherweise einer kleinen Anzahl von Knoten zugeordnet, während sich andere Knoten im Leerlauf befinden. Diese ungleichmäßige Verteilung der Arbeit kann zu einer langsameren Verarbeitung führen.
Um einen ungleichmäßigen Datensatz handelt es sich z. B., wenn ein Cluster ausgeführt wird, um Wörter alphabetisch anzuordnen, aber ein Datensatz zur Verfügung steht, dessen Wörter alle nur mit "a" beginnen. Beim Map-Vorgang wird dann der Knoten überfordert, der Werte verarbeitet, die mit "a" anfangen, während diejenigen Knoten nicht beschäftigt sind, die Wörter mit anderen Anfangsbuchstaben verarbeiten.
# Behebung häufiger Probleme bei der Verwendung von Amazon EMR mit AWS Lake Formation
Dieser Abschnitt führt Sie durch die Fehlerbehebung bei Probleme, die häufig bei der Verwendung von Amazon EMR mit AWS Lake Formation auftreten.
## Der Zugriff auf den Data Lake ist nicht zulässig
Sie müssen sich ausdrücklich für die Datenfilterung auf Amazon-EMR-Clustern entscheiden, bevor Sie Daten in Ihrem Data Lake analysieren und verarbeiten können. Wenn der Datenzugriff fehlschlägt, wird in der Ausgabe Ihrer Notebookeinträge eine allgemeine `Access is not allowed`-Meldung angezeigt.
Anweisungen dazu, wie Sie die Datenfilterung in Amazon EMR aktivieren und zulassen können, finden Sie unter [Datenfilterung auf Amazon EMR zulassen](https://docs.aws.amazon.com/lake-formation/latest/dg/getting-started-setup.html#emr-switch) im *AWS Lake Formation -Entwicklerhandbuch*.
## Sitzungsablauf
Das Sitzungs-Timeout für EMR Notebooks und Zeppelin wird durch die Einstellung `Maximum CLI/API session duration` der IAM-Rolle zur Lake Formation gesteuert. Der Standardwert für diese Einstellung ist eine Stunde. Wenn ein Sitzungs-Timeout auftritt, wird in der Ausgabe Ihrer Notebook-Einträge die folgende Meldung angezeigt, wenn Sie versuchen, Spark SQL-Befehle auszuführen.
```
Error 401 HTTP ERROR: 401 Problem accessing /sessions/2/statements.
Reason: JWT token included in request failed validation.
Powered by Jetty:// 9.3.24.v20180605 org.springframework.web.client.HttpClientErrorException: 401 JWT token included in request failed validation…
```
Aktualisieren Sie die Seite, um Ihre Sitzung zu validieren. Sie werden aufgefordert, sich erneut über Ihren Identitätsanbieter zu authentifizieren und dann zu dem Notebook zurückgeleitet. Sie können nach der erneuten Authentifizierung weiter Abfragen ausführen.
## Keine Berechtigungen für Benutzer in der angeforderten Tabelle
Beim Versuch, auf eine Tabelle zuzugreifen, auf die Sie keinen Zugriff haben, wird in der Ausgabe Ihrer Notebook-Einträge die folgende Ausnahme angezeigt, wenn Sie versuchen, Spark SQL-Befehle auszuführen.
```
org.apache.spark.sql.AnalysisException: org.apache.hadoop.hive.ql.metadata.HiveException: Unable to fetch table table.
Resource does not exist or requester is not authorized to access requested permissions.
(Service: AWSGlue; Status Code: 400; Error Code: AccessDeniedException; Request ID: …
```
Um auf die Tabelle zuzugreifen, müssen Sie dem Benutzer Zugriff gewähren, indem Sie die mit dieser Tabelle verknüpften Berechtigungen in Lake Formation aktualisieren.
## Abfragen von kontenübergreifenden Daten, die mit Lake Formation geteilt wurden
Wenn Sie Amazon EMR verwenden, um auf Daten zuzugreifen, die von einem anderen Konto aus mit Ihnen geteilt wurden, versuchen einige Spark-Bibliotheken, den `Glue:GetUserDefinedFunctions`-API-Vorgang aufzurufen. Da die Versionen 1 und 2 der AWS RAM verwalteten Berechtigungen diese Aktion nicht unterstützen, erhalten Sie die folgende Fehlermeldung:
`"ERROR: User: arn:aws:sts::012345678901:assumed-role/my-spark-role/i-06ab8c2b59299508a is not authorized to perform: glue:GetUserDefinedFunctions on resource: arn:exampleCatalogResource because no resource-based policy allows the glue:GetUserDefinedFunctions action"`
Um diesen Fehler zu beheben, muss der Data Lake-Administrator, der die Ressourcenfreigabe erstellt hat, die AWS RAM verwalteten Berechtigungen aktualisieren, die der Ressourcenfreigabe zugeordnet sind. Version 3 der von AWS RAM verwalteten Berechtigungen ermöglicht es Prinzipalen, die `glue:GetUserDefinedFunctions`-Aktion auszuführen.
Wenn Sie eine neue Ressourcenfreigabe erstellen, wendet Lake Formation standardmäßig die neueste Version der AWS RAM verwalteten Berechtigung an, sodass Sie nichts unternehmen müssen. Um den kontenübergreifenden Datenzugriff für bestehende Ressourcenfreigaben zu ermöglichen, müssen Sie die AWS RAM verwalteten Berechtigungen auf Version 3 aktualisieren.
Die AWS RAM Berechtigungen, die Ressourcen zugewiesen wurden, die mit Ihnen geteilt wurden, finden Sie unter AWS RAM. Die folgenden Berechtigungen sind in Version 3 enthalten:
```
Databases
AWSRAMPermissionGlueDatabaseReadWriteForCatalog
AWSRAMPermissionGlueDatabaseReadWrite
Tables
AWSRAMPermissionGlueTableReadWriteForCatalog
AWSRAMPermissionGlueTableReadWriteForDatabase
AllTables
AWSRAMPermissionGlueAllTablesReadWriteForCatalog
AWSRAMPermissionGlueAllTablesReadWriteForDatabase
```
**Um die Version mit AWS RAM verwalteten Berechtigungen vorhandener Ressourcenfreigaben zu aktualisieren**
Sie (Data Lake-Administrator) können entweder [AWS RAM verwaltete Berechtigungen auf eine neuere Version aktualisieren](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-update-permissions.html), indem Sie den Anweisungen im *AWS RAM Benutzerhandbuch* folgen, oder Sie können alle vorhandenen Berechtigungen für den Ressourcentyp widerrufen und sie erneut gewähren. Wenn Sie Berechtigungen widerrufen, wird die mit dem AWS RAM Ressourcentyp verknüpfte Ressourcenfreigabe AWS RAM gelöscht. Wenn Sie Berechtigungen erneut gewähren, AWS RAM erstellt es neue Ressourcenfreigaben, denen die neueste Version der verwalteten Berechtigungen angehängt wird. AWS RAM
## Einfügen in, Erstellen und Ändern von Tabellen
Das Einfügen von Daten in Tabellen in Datenbanken und das Erstellen und Ändern von Datenbanken, die durch Lake Formation Richtlinien geschützt sind, wird nicht unterstützt. Wenn Sie diese Operationen ausführen, wird in der Ausgabe Ihrer Notebook-Einträge die folgende Ausnahme angezeigt, wenn Sie versuchen, Spark SQL-Befehle auszuführen:
```
java.io.IOException: com.amazon.ws.emr.hadoop.fs.shaded.com.amazonaws.services.s3.model.AmazonS3Exception:
Access Denied (Service: Amazon S3; Status Code: 403; Error Code: AccessDenied; Request ID: …
```
Weitere Informationen finden Sie unter [Einschränkungen der Amazon EMR-Integration mit AWS Lake Formation](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-scope.html#emr-lf-limitations).