Warum wurde mein Amazon-EMR-Cluster mit dem Fehler „Application Provisioning failed“ beendet?
Mein Amazon-EMR-Cluster wurde mit dem Fehler „Application Provisioning failed“ beendet. Was bedeutet dieser Fehler und wie kann ich ihn beheben?
Lösung
Der Fehler „application provisioning failed“ (Anwendungsbereitstellung ist fehlgeschlagen) wird angezeigt, wenn Amazon EMR beim Starten eines EMR-Clusters eine bestimmte Software nicht installieren, konfigurieren oder starten kann. In den folgenden Abschnitten erfahren Sie, wie Sie Bereitstellungsprotokolle finden und überprüfen können. Sie zeigen Ihnen auch verschiedene Arten von Fehlern und Schritte, die Sie ergreifen können, um diese Fehler zu beheben.
Überprüfen Sie die in Amazon S3 gespeicherten Amazon-EMR-Bereitstellungsprotokolle
Die Amazon-EMR-Bereitstellungsprotokolle werden in einem Amazon-S3-Bucket (Amazon Simple Storage Service) gespeichert, der beim Cluster-Start angegeben wurde. Der Speicherort der Protokolle verwendet die folgende Amazon-S3-URI-Syntax:
s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/puppet.log.gz
Hinweis: Ersetzen Sie example-log-location, example-cluster-ID, example-primary-node-ID und example-UUID durch die Namen Ihres Systems.
- Öffnen Sie die Amazon-EMR-Konsole. Wählen Sie im Navigationsbereich Cluster. Wählen Sie dann den ausgefallenen EMR-Cluster aus, um die Clusterdetails zu sehen.
- Wählen Sie im Abschnitt Zusammenfassung die Option „Mit Fehlern beendet“ und notieren Sie sich die in der Fehlermeldung enthaltene Primärknoten-ID.
- Wählen Sie im Abschnitt Cluster-Protokolle die Amazon-S3-Standort-URL aus, die zu den Cluster-Protokollen in der Amazon-S3-Konsole umgeleitet werden soll.
- Navigieren Sie zu Ihrem UUID-Ordner, indem Sie diesem Pfad folgen: node/example-primary-node-id/provision-node/apps-Phase/0/example-UUID/.
Hinweis: Ersetzen Sie example-primary-node-ID und example-UUID durch die Namen Ihres Systems. - Wählen Sie in der resultierenden Liste puppet.log.gz und dann Öffnen aus, um die Bereitstellung auf einer neuen Browser-Registerkarte zu sehen.
Identifizieren der Gründe für Fehler in den Bereitstellungsprotokollen
Nicht unterstützte Konfigurationsparameter können zu Fehlern führen. Fehler können auch durch falsche Hostnamen, falsche Passwörter oder allgemeine Betriebssystemprobleme verursacht werden. Suchen Sie in den Protokollen nach verwandten Schlüsselwörtern, einschließlich „error“ oder „fail“.
Im Folgenden finden Sie eine Liste der häufigsten Fehlertypen:
- Probleme beim Herstellen einer Verbindung zu einem externen Metastore mit einer Instance von Amazon Relational Database Service (Amazon RDS).
- Probleme mit der Verbindung zu einem externen Key Distribution Center (KDC).
- Probleme beim Starten von Services wie YARN ResourceManager und Hadoop NameNode.
- Probleme beim Herunterladen oder Installieren von Anwendungen.
- S3-Protokolle sind nicht verfügbar.
Probleme beim Herstellen einer Verbindung zu einem externen Metastore mit einer Amazon-RDS-Instance
Einige Amazon-EMR-Anwendungen, wie Hive, Hue oder Oozie, können so konfiguriert werden, dass sie Daten in einer externen Datenbank wie Amazon RDS speichern. Wenn es ein Problem mit einer Verbindung gibt, wird eine Meldung angezeigt.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung von Hive:
2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): org.apache.hadoop.hive.metastore.HiveMetaException: Failed to get schema version. 2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): Underlying cause: java.sql.SQLNonTransientConnectionException : Could not connect to address=(host=hostname)(port=3306)(type=master) : Socket fail to connect to host:hostname, port:3306. hostname 2022-11-26 02:59:36 +0000 /Stage[main]/Hadoop_hive::Init_metastore_schema/Exec[init hive-metastore schema]/returns (notice): SQL Error code: -1
Gehen Sie wie folgt vor, um diese Art von Fehler zu beheben:
- Stellen Sie sicher, dass der Hostname, der Benutzer, das Passwort und die Datenbank der RDS-Instance korrekt sind.
- Stellen Sie sicher, dass die Regeln für eingehenden Datenverkehr der RDS-Instance-Sicherheitsgruppe Verbindungen von der Amazon-EMR-Sicherheitsgruppe für den Primärknoten zulassen.
Probleme beim Verbinden mit einem externen KDC
Mit Amazon EMR können Sie ein externes KDC konfigurieren, um eine zusätzliche Sicherheitsebene hinzuzufügen. Sie können auch eine Vertrauensbeziehung mit einem Active-Directory-Server erstellen. Wenn es ein Problem mit der Kontaktaufnahme mit dem KDC oder dem Beitritt zu einer Domäne gibt, wird eine Meldung angezeigt.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung von Puppet:
2022-11-26 03:02:01 +0000 Puppet (err): 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0] 2022-11-26 03:02:01 +0000 /Stage[main]/Kerberos::Ad_joiner/Exec[realm_join]/returns (err): change from 'notrun' to ['0'] failed: 'echo "${AD_DOMAIN_JOIN_PASSWORD}" | realm join -v -U "${AD_DOMAIN_JOIN_USER}"@"${CROSS_REALM_TRUST_REALM}" "${CROSS_REALM_TRUST_DOMAIN}"' returned 1 instead of one of [0]
Gehen Sie wie folgt vor, um diese Art von Fehler zu beheben:
- Stellen Sie sicher, dass der Kerberos-Bereich richtig geschrieben ist.
- Stellen Sie sicher, dass das KDC-Administratorpasswort richtig geschrieben ist.
- Stellen Sie sicher, dass der Active -Directory-Beitrittsbenutzer und das Passwort richtig geschrieben sind.
- Stellen Sie sicher, dass der Active-Directory-Beitrittsbenutzer in Active Directory existiert und über die richtigen Berechtigungen verfügt.
- Stellen Sie sicher, dass sich die KDC- und Active Directory-Server in Amazon EC2 befinden. Stellen Sie anschließend sicher, dass die Regeln für eingehenden Datenverkehr von KDC und der Active-Directory-Sicherheitsgruppe Verbindungen von der Amazon-EMR-Sicherheitsgruppe für den Primärknoten zulassen.
- Stellen Sie sicher, dass KDC und Active Directory nicht in Amazon EC2 sind. Stellen Sie anschließend sicher, dass KDC und Active Directory Verbindungen von der virtuellen privaten Cloud (VPC) und dem Subnetz des EMR-Clusters zulassen.
Probleme beim Starten von Services wie YARN ResourceManager, Hadoop NameNode oder Spark History Server
Amazon EMR ermöglicht die benutzerdefinierte Konfiguration aller Anwendungen beim Start des EMR-Clusters. Manchmal verhindern diese Konfigurationen jedoch den Start von Services. Wenn ein Problem auftritt, das den Start eines Services verhindert, wird eine Meldung angezeigt.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung vom Spark History Server:
2022-11-26 03:34:13 +0000 Puppet (err): Systemd start for spark-history-server failed! journalctl log for spark-history-server: -- Logs begin at Sat 2022-11-26 03:27:57 UTC, end at Sat 2022-11-26 03:34:13 UTC. -- Nov 26 03:34:10 ip-192-168-1-32 systemd[1]: Starting Spark history-server... Nov 26 03:34:10 ip-192-168-1-32 spark-history-server[1076]: Starting Spark history-server (spark-history-server):[OK] Nov 26 03:34:10 ip-192-168-1-32 su[1112]: (to spark) root on none Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service: control process exited, code=exited status=1 Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Failed to start Spark history-server. Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: Unit spark-history-server.service entered failed state. Nov 26 03:34:13 ip-192-168-1-32 systemd[1]: spark-history-server.service failed. 2022-11-26 03:34:13 +0000 /Stage[main]/Spark::History_server/Service[spark-history-server]/ensure (err): change from 'stopped' to 'running' failed: Systemd start for spark-history-server failed! journalctl log for spark-history-server:
Gehen Sie wie folgt vor, um diese Art von Fehler zu beheben:
- Überprüfen Sie den Service, der nicht gestartet werden konnte. Prüfen Sie, ob die bereitgestellten Konfigurationen richtig geschrieben sind.
- Navigieren Sie zum folgenden Pfad, um das S3-Protokoll einzusehen und den Grund für den Fehler zu untersuchen: s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/applications/example-failed-application/example-failed-service.gz.
Hinweise: Ersetzen Sie example-log-location, example-cluster-ID, example-primary-node-ID, example-failed-application und example-failed-service durch die Namen Ihres Systems.
Probleme beim Herunterladen oder Installieren von Anwendungen
Amazon EMR kann viele Anwendungen installieren. Manchmal gibt es jedoch ein Problem, wenn eine Anwendung nicht heruntergeladen oder installiert werden kann. Dies kann dazu führen, dass der EMR-Cluster ausfällt. Wenn dieser Fehler auftritt, werden die Bereitstellungsprotokolle nicht abgeschlossen. Sie müssen stattdessen das Protokoll stderr.gz überprüfen, um ähnliche Meldungen zu finden, die durch fehlgeschlagene yum-Installationen verursacht wurden.
Im Folgenden finden Sie ein Beispiel für eine Fehlermeldung von stderr.gz:
stderr.gz Error Summary ------------- Disk Requirements: At least 2176MB more space needed on the / filesystem. 2022-11-26 03:18:44,662 ERROR Program: Encountered a problem while provisioning java.lang.RuntimeException: Amazon-linux-extras topics enabling or yum packages installation failed.
Um diese Art von Fehler zu beheben, erhöhen Sie das Stammvolume von Amazon Elastic Block Store (Amazon EBS) während des EMR-Cluster-Starts.
S3-Protokolle sind nicht verfügbar
Amazon EMR kann keine Anwendungen bereitstellen, und in Amazon S3 werden keine Protokolle generiert. In diesem Szenario ist es wahrscheinlich, dass ein Netzwerkfehler dazu geführt hat, dass die S3-Protokollierung fehlschlägt.
Gehen Sie wie folgt vor, um diese Art von Fehler zu beheben:
- Stellen Sie sicher, dass die Option zumProtokollieren beim Start des EMR-Clusters aktiviert ist. Weitere Informationen finden Sie unter Konfigurieren der Clusterprotokollierung und Debugging.
- Wenn Sie ein benutzerdefiniertes AMI verwenden, stellen Sie sicher, dass keine Firewall-Regeln die erforderlichen Amazon-EMR-Netzwerkeinstellungen beeinträchtigen. Weitere Informationen finden Sie unter Arbeiten mit von Amazon EMR verwalteten Sicherheitsgruppen.
- Wenn Sie ein benutzerdefiniertes AMI verwenden, überprüfen Sie, ob primäre Knoten ausgefallen sind. Öffnen Sie die Amazon-EMR-Konsole und wählen Sie im Navigationsbereich Hardware aus, um festzustellen, ob Cluster keine primären Knoten starten konnten.
- Wenn Sie ein benutzerdefiniertes AMI verwenden, stellen Sie sicher, dass Sie die bewährten Methoden befolgen. Weitere Informationen finden Sie unter Verwenden eines benutzerdefinierten AMI.
Ähnliche Informationen
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 5 Monaten
- AWS OFFICIALAktualisiert vor 2 Monaten