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
Die Amazon-EMR-Clusterprotokolle werden in einem Amazon-S3-Bucket (Amazon Simple Storage Service) gespeichert, der beim Cluster-Start angegeben wurde. 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 Namen 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: Die oben genannten sind die häufigsten Terminierungsfehler. EMR-Cluster können aufgrund anderer als der aufgelisteten Fehler beendet werden. Weitere Informationen finden Sie unter Ressourcenfehler.
SHUTDOWN_STEP_FAILED (USER_ERROR)
Wenn Sie einen Step-Auftrag in Ihrem EMR-Cluster einreichen, können Sie das Schrittfehlerverhalten im Parameter ActionOnFailure angeben. Der EMR-Cluster wird beendet, wenn Sie TERMINATE_CLUSTER oder TERMINATE_JOB_FLOW für den Paramter 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-Auftrags die Option CONTINUE oder CANCEL_AND_WAIT im Parameter ActionOnFailure.
NO_SLAVES_LEFT (SYSTEM_ERROR)
Dieser Fehler tritt auf, wenn:
- Der Terminierungsschutz ist im EMR-Cluster deaktiviert.
- Alle Core-Knoten überschreiten die Festplattenspeicherkapazität, wie in der Yarn-Site-Konfigurationsklassifizierung durch einen Grenzwert für die maximale Auslastung festgelegt. Der Standardschwellenwert für die maximale Auslastung liegt bei 90 %.
- Die CORE-Instance ist eine Spot-Instance und die Spot-Instance ist TERMINATED_BY_SPOT_DUE_TO_NO_CAPACITY.
Informationen zur Kündigung von Spot-Instances finden Sie unter Warum hat Amazon EC2 meine Spot-Instance gekündigt?
Weitere Hinweise zum Fehler NO_SLAVE_LEFT finden Sie unter Cluster terminated with NO_SLAVE_LEFT and core nodes FAILED_BY_MASTER.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung vom Instance-Controller:
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% ]
So beheben Sie diesen Fehler:
- Lassen Sie den Terminierungsschutz für Ihre Cluster aktiviert. Weitere Informationen finden Sie unter Kündigungsschutz und fehlerhafte YARN-Knoten.
- Verwenden Sie die Amazon-EMR-Skalierungsrichtlinien (automatische Skalierung und verwaltete Skalierung), um Core-Knoten gemäß Ihren Anforderungen zu skalieren. Weitere Informationen finden Sie unter Skalieren von Clusterressourcen.
- Fügen Sie Ihrem Cluster mehr Amazon-Elastic-Block-Storage-Kapazität (Amazon EBS) hinzu. Weitere Informationen finden Sie unter Wie kann ich den „Ausgangsstatus: -100“ beheben. Diagnose: Container auf einem *lost*-Knoten freigegeben in Amazon EMR lösen?
- 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 CloudWatch-Alarm basierend auf einem statischen Schwellenwert erstellen.
502 Bad Gateway
Der Fehler 502 Bad Gateway tritt auf, wenn interne Systeme von Amazon EMR den Primärknoten für einen bestimmten Zeitraum nicht erreichen können. Amazon EMR wird beendet, wenn der Kündigungsschutz deaktiviert ist. Überprüfen Sie die neuesten Instance-Controller-Protokolle und Instance-Statusprotokolle, wenn der Instance-Controller-Service ausgefallen ist. Die Standardausgabe des Instance-Controllers zeigt, dass der Service beendet wurde, weil nicht genügend Speicher vorhanden ist. Dies weist darauf hin, dass der Primärknoten des Clusters wenig Arbeitsspeicher hat.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung aus dem Instance-Statusprotokoll:
# 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 den Festplattenspeicher, um Speicherausfälle in Clustern mit langer Laufzeit zu vermeiden. Weitere Informationen finden Sie unter Wie behebe ich den Ausfall eines Primärknotens mit dem Fehler „502 Bad Gateway“ oder „504 Gateway Timeout“ 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-Stammgerä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 die Berechtigungen verfügt, den angegebenen AWS-Key-Management-Service-Schlüssel (AWS KMS) zu verwenden.
Mit Fehlern beendet, der Hauptknoten wurde vom Benutzer beendet
Wenn der primäre EMR-Clusterknoten aus irgendeinem Grund stoppt, endet der Cluster mit dem Fehler Der Hauptknoten wurde durch einen Benutzer 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 EMR-Primärknotens oder aller EMR-Core-Knoten zur Clusterbeendigung führt, sollten Sie Clusterknoten nicht anhalten oder neu starten.

Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 6 Monaten
- AWS OFFICIALAktualisiert vor 5 Monaten
- AWS OFFICIALAktualisiert vor einem Jahr
- AWS OFFICIALAktualisiert vor 9 Monaten