Pourquoi mon cluster Amazon EMR s'est-il arrêté avec une erreur « application provisioning failed » (échec de provisionnement d'application) ?

Résolution

Vous pouvez voir un message d'erreur « application provisioning failed » (échec de provisionnement d'application) lorsqu'Amazon EMR ne peut pas installer, configurer ou démarrer le logiciel spécifié lors du lancement d'un cluster EMR. Les sections suivantes expliquent comment rechercher et consulter les journaux de provisionnement. Elles vous montrent également les différents types d'erreurs et les étapes que vous pouvez suivre pour résoudre ces erreurs.

Examiner les journaux de provisionnement d'Amazon EMR stockés dans Amazon S3

Les journaux de provisionnement Amazon EMR sont stockés dans un compartiment Amazon Simple Storage Service (Amazon S3) spécifié lors du lancement du cluster. L'emplacement de stockage des journaux utilise la syntaxe URI Amazon S3 suivante :

s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/puppet.log.gz

Remarque : remplacez example-log-location, example-cluster-ID, example-primary-node-ID et example-UUID par le nom de votre système.

1. Ouvrez la console Amazon EMR. Dans le panneau de navigation, choisissez Clusters. Choisissez ensuite le cluster EMR défaillant pour voir les détails du cluster.
2. Dans la section Summary (Résumé), choisissez « Terminated with errors » (Résilié avec des erreurs) et notez l'ID du nœud primaire inclus dans le message d'erreur.
3. Dans la section Cluster logs (Journaux du cluster), choisissez l'URL d'emplacement Amazon S3 pour être redirigé vers les journaux du cluster dans la console Amazon S3.
4. Accédez à votre dossier UUID en suivant ce chemin : node/example-primary-node-ID/provision-node/apps-phase/0/example-UUID/.
   Remarque : remplacez example-primary-node-ID et example-UUID par le nom de votre système.
5. Dans la liste qui s'affiche, sélectionnez puppet.log.gz et choisissez Open (Ouvrir) pour voir le provisionnement dans un nouvel onglet de navigateur.

Identifier les raisons des échecs dans les journaux de provisionnement

Les paramètres de configuration non pris en charge peuvent provoquer des erreurs. Les erreurs peuvent également être causées par des noms d'hôtes erronés, des mots de passe incorrects ou des problèmes généraux du système d'exploitation. Recherchez dans les journaux des mots-clés associés, notamment « error » (erreur) ou « fail » (échec).

La liste suivante répertorie les types d'erreurs les plus courants :

• Problèmes de connexion à un metastore externe avec une instance Amazon Relational Database Service (Amazon RDS).
• Problèmes de connexion à un centre de distribution de clés (KDC) externe.
• Problèmes lors du démarrage de services, tels ResourceManager de YARN et Hadoop NameNode.
• Problèmes lors du téléchargement ou de l'installation d'applications.
• Les journaux S3 ne sont pas disponibles.

Problèmes de connexion à un metastore externe avec une instance Amazon RDS

Certaines applications Amazon EMR, telles que Hive, Hue ou Oozie, peuvent être configurées pour stocker des données dans une base de données externe, telle qu'Amazon RDS. En cas de problème de connexion, un message s'affiche.

Voici un exemple de message d'erreur provenant de 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

Pour résoudre ce type d'erreur, procédez comme suit :

• Vérifiez que le nom d'hôte, l'utilisateur, le mot de passe et la base de données de l'instance RDS sont corrects.
• Vérifiez que les règles entrantes du groupe de sécurité de l'instance RDS autorisent les connexions depuis le groupe de sécurité du nœud primaire Amazon EMR.

Problèmes de connexion à un KDC externe

Amazon EMR vous permet de configurer un KDC externe afin d'ajouter un niveau de sécurité supplémentaire. Vous pouvez également créer une relation de confiance avec un serveur Active Directory. Lorsqu'il y a un problème pour contacter le KDC ou rejoindre un domaine, un message apparaît.

Voici un exemple de message d'erreur provenant de 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]

Pour résoudre ce type d'erreur, procédez comme suit :

• Vérifiez que le domaine Kerberos est correctement orthographié.
• Vérifiez que le mot de passe administratif du KDC est correctement orthographié.
• Vérifiez que l'utilisateur participant à Active Directory et son mot de passe sont correctement orthographiés.
• Vérifiez que l'utilisateur participant à Active Directory existe dans Active Directory et dispose des autorisations appropriées.
• Vérifiez que les serveurs KDC et Active Directory se trouvent sur Amazon EC2. Vérifiez ensuite que les règles entrantes du groupe de sécurité de KDC et d'Active Directory autorisent les connexions du groupe de sécurité du nœud primaire Amazon EMR.
• Vérifiez que KDC et Active Directory ne se trouvent pas sur Amazon EC2. Vérifiez ensuite que KDC et Active Directory autorisent les connexions depuis le cloud privé virtuel (VPC) et le sous-réseau du cluster EMR.

Problèmes lors du démarrage de services tels que ResourceManager de YARN, Hadoop NameNode ou Spark History Server

Amazon EMR permet la configuration personnalisée de toutes les applications lors du lancement du cluster EMR. Cependant, ces configurations empêchent parfois le démarrage des services. Lorsqu'un problème empêche un service de démarrer, un message s'affiche.

Voici un exemple de message d'erreur provenant de 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:

Pour résoudre ce type d'erreur, procédez comme suit :

• Vérifiez le service qui n'a pas pu démarrer. Vérifiez si les configurations fournies sont correctement orthographiées.
• Suivez le chemin suivant pour consulter le journal S3 et rechercher la raison de l'échec :s3://example-log-location/example-cluster-ID/node/example-primary-node-ID/applications/example-failed-application/example-failed-service.gz.
  Remarque : remplacez example-log-location, example-cluster-ID, example-primary-node-id, example-failed-application et example-failed-service par le nom de votre système.

Problèmes lors du téléchargement ou de l'installation d'applications

Amazon EMR peut installer de nombreuses applications. Mais, parfois, il y a un problème lorsqu'une application ne peut pas être téléchargée ou installée. Cela peut entraîner l'échec du cluster EMR. Lorsque cet échec se produit, les journaux de provisionnement ne sont pas complets. Vous devez plutôt consulter le journal stderr.gz pour trouver des messages similaires provoqués par l'échec des installations de yum.

Voici un exemple de message d'erreur provenant de 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.

Pour résoudre ce type d'erreur, augmentez le volume racine Amazon Elastic Block Store (Amazon EBS) lors du lancement du cluster EMR.

Les journaux S3 ne sont pas disponibles

Amazon EMR ne parvient pas à provisionner les applications et aucun journal n'est généré dans Amazon S3. Dans ce scénario, il est probable qu'une erreur réseau ait provoqué l'échec de la journalisation S3.

Pour résoudre ce type d'erreur, procédez comme suit :

• Vérifiez que l'option Logging (Journalisation) est activée lors du lancement du cluster EMR. Pour plus d'informations, consultez Configuration de la journalisation et du débogage du cluster (français non garanti).
• Lorsque vous utilisez une AMI personnalisée, vérifiez qu'aucune règle de pare-feu n'interfère avec les paramètres réseau Amazon EMR requis. Pour plus d'informations, consultez Utilisation des groupes de sécurité gérés par Amazon EMR (français non garanti).
• Lorsque vous utilisez une AMI personnalisée, vérifiez s'il existe des nœuds primaires défaillants. Ouvrez la console Amazon EMR, et dans le panneau de navigation, choisissez Hardware (Matériel) pour déterminer si les clusters n'ont pas pu lancer de nœuds primaires.
• Lorsque vous utilisez une AMI personnalisée, vérifiez que vous suivez les bonnes pratiques. Pour plus d'informations, consultez Utilisation d'une AMI personnalisée (français non garanti).

---

Informations connexes

Échec de provisionnement d'un cluster EMR (français non garanti)