Warum wurde mein EMR-Cluster beendet?
Mein Amazon-EMR-Cluster wurde unerwartet beendet.
Lösung
Die in Amazon S3 gespeicherten Amazon-EMR-Bereitstellungsprotokolle überprüfen
Amazon-EMR-Clusterprotokolle werden in einem Amazon Simple Storage Service (Amazon S3)-Bucket gespeichert, der beim Clusterstart festgelegt wird. Die Protokolle werden unter s3://example-log-location/example-cluster-ID/node/example-EC2-instance-ID/ gespeichert.
Hinweis: Ersetzen Sie example-log-location, example-cluster-ID und example-EC2-instance-ID durch die Benennung Ihres Systems.
Im Folgenden finden Sie eine Liste der häufigsten Fehler:
SHUTDOWN_STEP_FAILED (USER_ERROR)
NO_SLAVES_LEFT (SYSTEM_ERROR)
The master failed: Error occurred: <html>??<head><title>502 Bad Gateway</title></head>??<body>??<center><h1>502 Bad Gateway</h1></center>??<hr><center>nginx/1.16.1</center>??</body>??</html>??
KMS_ISSUE (USER_ERROR)Terminated with errors, The master node was terminated by user.
Hinweis: Vorstehend finden Sie die häufigsten Abbruchfehler. EMR-Cluster können neben den aufgelisteten Fehlern jedoch auch aufgrund anderer Fehler beendet werden. Weitere Informationen finden Sie unter Ressourcenfehler.
SHUTDOWN_STEP_FAILED (USER_ERROR)
Wenn Sie einen Step-Job an Ihrem EMR-Cluster übermitteln, können Sie das Verhalten bei Step-Fehlern im Parameter ActionOnFailure festlegen. Der EMR-Cluster wird beendet, wenn Sie TERMINATE_CLUSTER oder TERMINATE_JOB_FLOW für den Parameter ActionOnFailure auswählen. Weitere Informationen finden Sie unter StepConfig.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung von AWS CloudTrail:
{ "severity": "ERROR", "actionOnFailure": "TERMINATE_JOB_FLOW", "stepId": "s-2I0GXXXXXXXX", "name": "Example Step", "clusterId": "j-2YJXXXXXXX", "state": "FAILED", "message": "Step s-2I0GXXXXXXXX (Example Step) in Amazon EMR cluster j-2YJXXXXXXX failed at 202X-1X-0X 0X:XX UTC." }
Um diesen Fehler zu vermeiden, verwenden Sie beim Senden des Step-Jobs die Option CONTINUE oder CANCEL_AND_WAIT für den Parameter ActionOnFailure.
NO_SLAVES_LEFT (SYSTEM_ERROR)
Dieser Fehler tritt auf, wenn:
- Der Beendigungsschutz im EMR-Cluster deaktiviert ist.
- Alle Core-Knoten die Festplattenspeicherkapazität überschreiten, wie in der Klassifizierung der Yarn-Site-Konfiguration durch einen Schwellenwert für die maximale Auslastung angegeben. Der standardmäßige Schwellenwert für die maximale Auslastung liegt bei 90 %.
- Die CORE-Instance ist eine Spot Instance, und die Spot Instance wird TERMINATED_BY_SPOT_DUE_TO_NO_CAPACITY.
Informationen zur Beendigung von Spot Instances finden Sie unter Warum hat Amazon EC2 meine Spot Instance unterbrochen?
Weitere Informationen zum Fehler NO_SLAVE_LEFT finden Sie unter Cluster mit NO_SLAVE_LEFT beendet und Core-Knoten FAILED_BY_MASTER.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung des Instance-Controllers:
202X-0X-0X 1X:5X:5X,968 INFO Poller: InstanceJointStatusMap contains X entries (DD:5 R:3): i-0e336xxxxxxxxxxxx 25d21h R 25d21h ig-22 ip-1x-2xx-xx-1xx.local.xxx.com I: 52s Y:U 98s c: 0 am: 0 H:R 1.1%Yarn unhealthy Reason : 1/4 local-dirs usable space is below configured utilization percentage/no more usable space [ /mnt/yarn : used space above threshold of 90.0% ] ; 1/1 log-dirs usable space is below configured utilization percentage/no more usable space [ /var/log/hadoop-yarn/containers : used space above threshold of 90.0% ]
Um diesen Fehler zu beheben:
- Belassen Sie den Beendigungsschutz für Ihre Cluster auf ON. Weitere Informationen finden Sie unter Beendigungsschutz und fehlerhafte YARN-Knoten.
- Verwenden Sie Amazon-EMR-Skalierungsrichtlinien (automatische Skalierung und verwaltete Skalierung), um die Core-Knoten entsprechend Ihren Anforderungen zu skalieren. Weitere Informationen finden Sie unter Verwenden der Clusterskalierung.
- Fügen Sie Ihrem Cluster mehr Amazon Elastic Block Storage (Amazon EBS)-Kapazität hinzu. Weitere Informationen finden Sie unter Wie kann ich „Exit status: -100. Diagnostics: Container released on a *lost* node“-Fehler in Amazon EMR beheben?
- Erstellen Sie einen Alarm für die Amazon-CloudWatch-Metrik MRUnhealthyNodes. Sie können eine Benachrichtigung für diesen Alarm einrichten, um Sie vor fehlerhaften Knoten zu warnen, bevor das 45-minütige Timeout erreicht ist. Weitere Informationen finden Sie unter Erstellen eines CloudWatch-Alarms auf der Grundlage eines statischen Schwellenwerts.
502 Bad Gateway
Der Fehler 502 Bad Gateway tritt auf, wenn interne Amazon-EMR-Systeme den primären Knoten für einen bestimmten Zeitraum nicht erreichen können. Amazon EMR wird beendet, wenn der Beendigungsschutz deaktiviert ist. Überprüfen Sie die aktuellsten Instance-Controller-Protokolle und Instance-Status-Protokolle, wenn der Instance-Controller-Dienst ausgefallen ist. Die Standardausgabe des Instance-Controllers zeigt, dass der Dienst beendet wurde, weil nicht genügend Speicher zur Verfügung steht. Dies weist darauf hin, dass der primäre Knoten des Clusters über zu wenig Speicher verfügt.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung aus dem Instance-Status-Protokoll:
# dump instance controller stdout tail -n 100 /emr/instance-controller/log/instance-controller.out OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00007fb46c7c8000, 12288, 0) failed; error='Cannot allocate memory' (errno=12) # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 12288 bytes for committing reserved memory. # An error report file with more information is saved as: # /tmp/hs_err_pid16110.log # whats memory usage look like free -m total used free shared buff/cache available Mem: 15661 15346 147 0 167 69 Swap: 0 0 0
Um den vorherigen Fehler zu vermeiden, starten Sie einen EMR-Cluster mit einem höheren Instance-Typ, um mehr Speicher für die Anforderungen Ihres Clusters zu nutzen. Bereinigen Sie außerdem Speicherplatz, um Speicherausfälle in Clustern mit langer Laufzeit zu vermeiden. Weitere Informationen finden Sie unter Wie behebe ich den Ausfall des primären Knotens mit dem Fehler „502 Bad Gateway“ oder „504 Gateway Time-out“ in Amazon EMR?
KMS_ISSUE (USER_ERROR)
Wenn Sie eine Amazon-EMR-Sicherheitskonfiguration verwenden, um ein Amazon-EBS-Root-Gerät und Speichervolumes zu verschlüsseln, muss die Rolle über die entsprechenden Berechtigungen verfügen. Wenn die erforderlichen Berechtigungen fehlen, erhalten Sie den Fehler KMS_ISSUE.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung von AWS CloudTrail:
The EMR Service Role must have the kms:GenerateDataKey* and kms:ReEncrypt* permission for the KMS key configuration when you enabled EBS encryption by default. You can retrieve that KMS key's ID by using the ec2:GetEbsDefaultKmsKeyId API.
Um den vorherigen Fehler zu vermeiden, stellen Sie sicher, dass die Sicherheitskonfigurationen, die zur Verschlüsselung des Amazon-EBS-Root-Geräts und der Speichervolumes verwendet werden, über die erforderlichen Berechtigungen verfügen. Stellen Sie für diese Konfigurationen sicher, dass die Amazon-EMR-Servicerolle (EMR_DefaultRole_V2) über Berechtigungen zur Verwendung des angegebenen AWS Key Management Service (AWS KMS)-Schlüssels verfügt.
Mit Fehlern beendet, Der Master-Knoten wurde vom Benutzer beendet
Wenn der primäre Knoten des EMR-Clusters aus irgendeinem Grund beendet wird, wird der Cluster mit dem Fehler The master node was terminated by user beendet.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung von AWS CloudTrail:
eventTime": "2023-01-18T08:07:02Z", "eventSource": "ec2.amazonaws.com", "eventName": "StopInstances", "awsRegion": "us-east-1", "sourceIPAddress": "52.xx.xx.xx", "userAgent": "AWS Internal", "requestParameters": { "instancesSet": { "items": [ { "instanceId": "i-xxf6c5xxxxxxxxxxx" } ] }, "force": false },
Da das Stoppen des primären EMR-Knotens oder aller Core-Knoten zur Clusterbeendigung führt, sollten Sie das Stoppen oder Neustarten der Clusterknoten vermeiden.
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 9 Monaten
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor einem Jahr