Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Résoudre les problèmes liés aux clusters Amazon EMR
Un cluster EMR s'exécute dans un écosystème complexe comprenant des logiciels open source, du code d'application personnalisé et. Services AWS Lorsqu'un problème survient avec l'une de ces parties, le cluster peut échouer ou prendre plus de temps que prévu à s'arrêter. Les rubriques suivantes peuvent vous aider à identifier les problèmes de cluster et à les résoudre.
**Topics**
+ [
# Quels sont les outils disponibles pour résoudre les problèmes liés à un cluster Amazon EMR ?
](emr-troubleshoot-tools.md)
+ [
# Afficher et redémarrer Amazon EMR et les processus d'application (démon)
](emr-process-restart-stop-view.md)
+ [
# Collections d'erreurs courantes dans Amazon EMR
](emr-troubleshoot-errors.md)
+ [
# Résoudre les problèmes liés à un cluster Amazon EMR défaillant avec un code d'erreur
](emr-troubleshoot-failed.md)
+ [
# Résoudre les problèmes liés à la lenteur d'un cluster Amazon EMR
](emr-troubleshoot-slow.md)
+ [
# Résoudre les problèmes courants liés à l'utilisation d'Amazon EMR AWS avec Lake Formation
](emr-troubleshoot-lf.md)
Conseils sur la résolution des problèmes liés [aux applications Spark sur EMR](https://aws.github.io/aws-emr-best-practices/docs/bestpractices/Applications/Spark/troubleshooting/).
Lorsque vous développez une nouvelle application Hadoop, nous vous recommandons d'activer le débogage et de traiter un sous-ensemble restreint, mais représentatif de vos données pour tester l'application. Vous pouvez également exécuter l'application step-by-step pour tester chaque étape séparément. Pour plus d’informations, consultez [Configuration de la journalisation et du débogage du cluster Amazon EMR](emr-plan-debugging.md) et [Étape 5 : tester le cluster Amazon EMR étape par étape](emr-troubleshoot-failed-5-test-steps.md).
# Quels sont les outils disponibles pour résoudre les problèmes liés à un cluster Amazon EMR ?
Pour identifier et corriger les erreurs de cluster, vous pouvez utiliser les outils décrits sur cette page. Lorsque vous lancez le cluster, il se peut que vous deviez initialiser certains outils. D'autres outils sont disponibles par défaut pour chaque cluster.
**Topics**
+ [
## Consulter les détails du cluster EMR
](#emr-troubleshoot-tools-details)
+ [
## Afficher les détails des erreurs du cluster EMR
](#emr-troubleshoot-errordetail)
+ [
## Exécuter des scripts et configurer les processus Amazon EMR
](#emr-troubleshoot-tools-commands)
+ [
## Afficher les fichiers journaux
](#emr-troubleshoot-tools-logs)
+ [
## Surveillez les performances du cluster EMR
](#emr-troubleshoot-tools-performance)
## Consulter les détails du cluster EMR
Vous pouvez utiliser l'API AWS Management Console AWS CLI, ou EMR pour récupérer des informations détaillées sur un cluster EMR et l'exécution des tâches. Pour plus d'informations sur l'utilisation du AWS Management Console et AWS CLI, consultez[Afficher l'état et les détails du cluster Amazon EMR](emr-manage-view-clusters.md).
### Volet de détails de la console Amazon EMR
Dans la liste **Clusters** de la console Amazon EMR, vous pouvez voir des informations de haut niveau sur le statut de chaque cluster de votre compte et de votre Région AWS. La liste affiche tous les clusters actifs et terminés que vous avez lancés au cours des deux derniers mois. Dans la liste **Clusters**, vous pouvez sélectionner un **Nom** de cluster pour en visualiser les informations détaillées. Ces informations sont organisées en différentes catégories pour faciliter la navigation.
Les **interfaces utilisateur d'application** disponibles dans la page de détails du cluster peuvent être utiles pour dépanner les clusters. Il fournit le statut des applications YARN et pour certaines, comme les applications Spark, vous pouvez explorer les différentes métriques et facettes, telles que les travaux, les phases et les exécuteurs. Pour de plus amples informations, veuillez consulter [Afficher l'historique des applications Amazon EMR](emr-cluster-application-history.md). Cette fonctionnalité n'est disponible que pour les versions 5.8.0 et supérieures d'Amazon EMR.
### Interface de ligne de commande Amazon EMR
Vous pouvez trouver des informations sur un cluster à l' AWS CLI aide de l'`--describe`argument.
### API Amazon EMR
Vous pouvez rechercher les détails relatifs à un cluster à partir de l'API à l'aide de l'action `DescribeJobFlows`.
## Afficher les détails des erreurs du cluster EMR
Lorsqu'un cluster EMR se termine avec une erreur, les `DescribeCluster` et `ListClusters` APIs renvoient un code d'erreur et un message d'erreur. Pour certaines erreurs de cluster, le tableau de données `ErrorDetail` peut vous aider à résoudre le problème.
Pour obtenir la liste des codes d'erreur incluant des données `ErrorDetail`, consultez [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md).
**Note**
Nous affinons continuellement nos messages d'erreur afin que vous receviez les informations les plus récentes et les plus pertinentes. Nous vous déconseillons d'analyser le texte à partir de `ErrorMessage`, car celui-ci est sujet à modification.
## Exécuter des scripts et configurer les processus Amazon EMR
Dans le cadre de votre processus de résolution des problèmes, il peut être utile d'exécuter des scripts personnalisés sur votre cluster ou d'afficher et de configurer les processus du cluster.
### Afficher et redémarrer les processus d'application
Il peut être utile de visualiser les processus en cours sur votre cluster afin de diagnostiquer les problèmes potentiels. Vous pouvez arrêter et redémarrer les processus du cluster en vous connectant au nœud principal de votre cluster. Pour de plus amples informations, veuillez consulter [Afficher et redémarrer Amazon EMR et les processus d'application (démon)](emr-process-restart-stop-view.md).
### Exécuter des commandes et des scripts sans connexion SSH
Pour exécuter une commande ou un script sur votre cluster en tant qu'étape, vous pouvez utiliser les outils `command-runner.jar` ou `script-runner.jar` sans établir de connexion SSH avec le nœud principal. Pour plus d'informations, consultez [Exécuter des commandes et des scripts sur un cluster Amazon EMR.](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-commandrunner.html)
## Afficher les fichiers journaux
Amazon EMR et Hadoop génèrent tous deux des fichiers journaux lorsque le cluster s'exécute. Vous pouvez accéder à ces fichiers journaux grâce à différents outils, en fonction de la configuration que vous avez spécifiée lorsque vous avez lancé le cluster. Pour de plus amples informations, veuillez consulter [Configuration de la journalisation et du débogage du cluster Amazon EMR](emr-plan-debugging.md).
### Fichiers journaux sur le nœud principal
Chaque cluster publie des fichiers journaux dans le répertoiremnt/var/log//du nœud principal. Ces fichiers journaux sont disponibles uniquement pendant l'exécution du cluster.
### Fichiers journaux archivés sur Amazon S3
Si vous lancez le cluster et que vous spécifiez un chemin de journal Amazon S3, le cluster copie les fichiers journaux stockés dans/mnt/var/log/sur le nœud principal vers Amazon S3 à intervalles de 5 minutes. Vous avez ainsi la garantie de pouvoir accéder aux fichiers journaux même après la mise hors service du cluster. Etant donné que les fichiers sont archivés toutes les 5 minutes, les dernières minutes d'un cluster mis hors service soudainement peuvent ne pas être disponibles.
## Surveillez les performances du cluster EMR
Amazon EMR propose plusieurs outils pour surveiller les performances de votre cluster.
### Interfaces Web Hadoop
Chaque cluster publie un ensemble d'interfaces Web sur le nœud maître, qui contient des informations sur le cluster. Vous pouvez accéder à ces pages Web à l'aide d'un tunnel SSH pour les connecter sur le nœud maître. Pour de plus amples informations, veuillez consulter [Affichage des interfaces Web hébergées sur des clusters Amazon EMR](emr-web-interfaces.md).
### CloudWatch métriques
Chaque cluster communique des métriques à CloudWatch. CloudWatch est un service Web qui suit les métriques et que vous pouvez utiliser pour définir des alarmes sur ces métriques. Pour de plus amples informations, veuillez consulter [Surveillance des métriques Amazon EMR avec CloudWatch](UsingEMR_ViewingMetrics.md).
# Afficher et redémarrer Amazon EMR et les processus d'application (démon)
Lorsque vous dépannez un cluster, vous pouvez souhaiter afficher les processus en cours d'exécution. Il se peut que vous ayez besoin de redémarrer ou arrêter des processus. Par exemple, vous pouvez redémarrer un processus après avoir modifié une configuration ou remarquer un problème avec un processus particulier, une fois que vous avez analysé les fichiers journaux et les messages d'erreur.
Deux types de processus s'exécutent sur un cluster : les processus Amazon EMR (par exemple, instance-controller et Log Pusher) et les processus associés aux applications installées sur le cluster (par exemple, et). hadoop-hdfs-namenode hadoop-yarn-resourcemanager
Pour utiliser directement les processus sur un cluster, vous devez d'abord vous connectez au nœud principal. Pour de plus amples informations, veuillez consulter [Connexion à un cluster Amazon EMR](emr-connect-master-node.md).
## Affichage des processus en cours d'exécution
La méthode pour visualiser les processus en cours sur un cluster varie en fonction de la version d'Amazon EMR que vous utilisez.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : liste tous les processus en cours**
L'exemple suivant utilise `systemctl` et indique à `--type` d'afficher tous les processus.
```
systemctl --type=service
```
**Example : Répertorier les processus spécifiques**
L'exemple suivant répertorie tous les processus dont les noms contiennent `hadoop`.
```
systemctl --type=service | grep -i hadoop
```
Exemple de sortie :
```
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 : Afficher un rapport d'état détaillé pour un processus spécifique**
L'exemple suivant affiche un rapport d'état détaillé du service `hadoop-hdfs-namenode`.
```
sudo systemctl status hadoop-hdfs-namenode
```
Exemple de sortie :
```
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 : liste tous les processus en cours**
L'exemple suivant répertorie tous les processus en cours d'exécution.
```
initctl list
```
------
#### [ EMR 2.x - 3.x ]
**Example : liste tous les processus en cours**
L'exemple suivant répertorie tous les processus en cours d'exécution.
```
ls /etc/init.d/
```
------
## Arrêt et redémarrage des processus
Après que vous avez déterminé les processus en cours d'exécution, vous pouvez les arrêter et les redémarrer si nécessaire.
------
#### [ EMR 5.30.0 and 6.0.0 and later ]
**Example : Arrêter un processus**
L'exemple suivant arrête le processus `hadoop-hdfs-namenode`.
```
sudo systemctl stop hadoop-hdfs-namenode
```
Vous pouvez interroger le `status` pour vérifier que le processus est arrêté.
```
sudo systemctl status hadoop-hdfs-namenode
```
Exemple de sortie :
```
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 : Démarrer un processus**
L'exemple suivant lance le processus `hadoop-hdfs-namenode`.
```
sudo systemctl start hadoop-hdfs-namenode
```
Vous pouvez interroger l'état pour vérifier que le processus est en cours d'exécution.
```
sudo systemctl status hadoop-hdfs-namenode
```
Exemple de sortie :
```
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 : Arrêter un processus en cours**
L'exemple suivant arrête le service `hadoop-hdfs-namenode`.
```
sudo stop hadoop-hdfs-namenode
```
**Example : Redémarrer un processus arrêté**
L'exemple suivant redémarre le service `hadoop-hdfs-namenode`. Vous devez utiliser la commande `start` et non `restart`.
```
sudo start hadoop-hdfs-namenode
```
**Example : Vérifier l'état du processus**
Ce qui suit permet de récupérer l'état de `hadoop-hdfs-namenode`. Vous pouvez utiliser la commande `status` pour vérifier que le processus s'est arrêté ou a démarré.
```
sudo status hadoop-hdfs-namenode
```
------
#### [ EMR 2.x - 3.x ]
**Example : Arrêter un processus d'application**
L'exemple suivant arrête le service `hadoop-hdfs-namenode`, qui est rattaché à la version d'Amazon EMR installée sur le cluster.
```
sudo /etc/init.d/hadoop-hdfs-namenode stop
```
**Example : Redémarrer un processus d'application**
L'exemple de commande suivant redémarre le processus `hadoop-hdfs-namenode` :
```
sudo /etc/init.d/hadoop-hdfs-namenode start
```
**Example : Arrêter un processus Amazon EMR**
L'exemple suivant arrête un processus, tel que le contrôleur d'instance, qui n'est pas rattaché à la version d'Amazon EMR sur le cluster.
```
sudo /sbin/stop instance-controller
```
**Example : Redémarrer un processus Amazon EMR**
L'exemple suivant redémarre un processus, tel que le contrôleur d'instance, qui n'est pas rattaché à la version d'Amazon EMR sur le cluster.
```
sudo /sbin/start instance-controller
```
**Note**
Les commandes `/sbin/start, stop` et `restart` sont des liens symboliques vers `/sbin/intictl`. Pour plus d'informations sur `initctl`, consulte la page consacrée à initctl man en entrant `man initctl` à l'invite de commande.
------
# Collections d'erreurs courantes dans Amazon EMR
Parfois, les clusters échouent ou mettent du temps à traiter les données. Les sections suivantes répertorient les problèmes courants liés aux clusters. Les erreurs incluent les échecs de démarrage et les erreurs de validation, avec des suggestions pour les résoudre.
**Topics**
+ [
# Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR
](emr-troubleshoot-error-errordetail.md)
+ [
# Erreurs de ressources lors des opérations du cluster Amazon EMR
](emr-troubleshoot-error-resource.md)
+ [
# Erreurs d'entrée et de sortie du cluster lors des opérations Amazon EMR
](emr-troubleshoot-errors-io.md)
+ [
# Erreurs d'autorisations lors des opérations du cluster Amazon EMR
](emr-troubleshoot-error-permissions.md)
+ [
# Erreurs de cluster Hive
](emr-troubleshoot-error-hive.md)
+ [
# Erreurs VPC lors des opérations du cluster Amazon EMR
](emr-troubleshoot-error-vpc.md)
+ [
# Erreurs liées au cluster Amazon EMR lors du streaming
](emr-troubleshoot-error-streaming.md)
+ [
# Amazon EMR : erreurs du cluster JAR personnalisé
](emr-troubleshoot-error-custom-jar.md)
+ [
# Erreurs Amazon EMR AWS GovCloud (US-West)
](emr-troubleshoot-error-govcloud.md)
+ [
## Trouver un cluster manquant
](#w2aac36c21c47)
# Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR
Lorsqu'un cluster EMR se termine avec une erreur, les `DescribeCluster` et `ListClusters` APIs renvoient un code d'erreur et un message d'erreur. Pour certaines erreurs de cluster, le tableau de données `ErrorDetail` peut vous aider à résoudre le problème.
Les erreurs qui incluent un tableau `ErrorDetail` fournissent les informations suivantes :
**`ErrorCode`**
Code d'erreur unique que vous pouvez utiliser pour l'accès par programmation.
**`ErrorData`**
Liste d'identifiants sous forme de paires clé-valeur que vous pouvez utiliser pour la programmation ou la recherche manuelle. Pour une description des valeurs `ErrorData` incluses dans un code d'erreur, consultez la page de résolution des problèmes rattachée au code d'erreur.
**`ErrorMessage`**
Description de l'erreur avec un lien vers des informations supplémentaires dans la documentation Amazon EMR.
Nous vous déconseillons d'analyser le texte à partir de `ErrorMessage`, car celui-ci est sujet à modification.
**Topics**
+ [Défaillances de l'amorçage](emr-troubleshoot-error-errordetail-bootstrap.md)
+ [Erreurs internes.](emr-troubleshoot-error-errordetail-internal.md)
+ [Échecs de validation](emr-troubleshoot-error-errordetail-validation.md)
# Codes d'erreur d'échec du Bootstrap dans Amazon EMR
Les sections suivantes fournissent des informations de dépannage relatives aux codes d'erreur d'échec de l'amorçage.
**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 DISK\$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
## Présentation de
Lorsqu'un cluster se termine avec une erreur `BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE`, une action d'amorçage a échoué dans l'instance principale. Pour plus d'informations sur les actions d'amorçage, consultez [Créez des actions bootstrap pour installer des logiciels supplémentaires avec un cluster Amazon EMR](emr-plan-bootstrap.md).
## Résolution
Pour résoudre cette erreur, passez en revue les informations renvoyées dans l'erreur d'API, modifiez votre script d'action d'amorçage et créez un nouveau cluster avec l'action d'amorçage mise à jour.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`primary-instance-id`**
ID de l'instance principale où l'action d'amorçage a échoué.
**`bootstrap-action`**
Numéro ordinal de l'action d'amorçage qui a échoué. Un script dont la valeur `bootstrap-action` est égale à `1` est la première action d'amorçage exécutée sur l'instance.
**`return-code`**
Le code de retour de l'action d'amorçage qui a échoué.
**`amazon-s3-path`**
L'emplacement sur Amazon S3 de l'action d'amorçage qui a échoué.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger la cause première de l'erreur d'action d'amorçage. Lancez ensuite un nouveau cluster.
1. Consultez les fichiers journaux des actions d'amorçage dans Amazon S3 pour identifier la cause première de l'échec. Pour en savoir plus sur la façon de consulter les journaux Amazon EMR, consultez [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
1. Si vous avez activé les journaux de cluster lors de la création de l'instance, consultez le journal `stdout`pour plus d'informations. Vous pouvez trouver le journal `stdout` de l'action d'amorçage dans cet emplacement Amazon S3 :
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Pour plus d'informations sur les journaux de clusters, consultez [Configuration de la journalisation et du débogage du cluster Amazon EMR](emr-plan-debugging.md).
1. Pour déterminer l'échec de l'action d'amorçage, passez en revue les exceptions dans les journaux `stdout`et la valeur `return-code` dans `ErrorData`.
1. Utilisez les résultats de l'étape précédente pour revoir votre action d'amorçage afin qu'elle évite les exceptions ou qu'elle puisse gérer les exceptions correctement lorsqu'elles se produisent.
1. Lancez un nouveau cluster avec votre action d'amorçage mise à jour.
# BOOTSTRAP\$1FAILURE\$1BA\$1DOWNLOAD\$1FAILED\$1PRIMARY
## Présentation de
Un cluster se termine avec l'erreur `BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY` lorsque l'instance principale ne parvient pas à télécharger un script d'action d'amorçage depuis l'emplacement Amazon S3 que vous spécifiez. Les causes sont généralement les suivantes :
+ Le fichier de script d'action d'amorçage ne se trouve pas à l'emplacement Amazon S3 spécifié.
+ Le rôle de service pour les instances Amazon EC2 du cluster (également appelé *profil d'instance EC2 pour Amazon EMR*) n'est pas autorisé à accéder au compartiment Amazon S3 où réside le script d'action d'amorçage. Pour de plus amples informations sur les rôles de service, veuillez consulter [Rôle de service pour les instances EC2 de cluster (profil d'instance EC2)](emr-iam-role-for-ec2.md).
Pour plus d'informations sur les actions d'amorçage, consultez [Créez des actions bootstrap pour installer des logiciels supplémentaires avec un cluster Amazon EMR](emr-plan-bootstrap.md).
## Résolution
Pour résoudre cette erreur, assurez-vous que votre instance principale dispose d'un accès approprié au script d'action d'amorçage.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`primary-instance-id`**
ID de l'instance principale où l'action d'amorçage a échoué.
**`bootstrap-action`**
Numéro ordinal de l'action d'amorçage qui a échoué. Un script dont la valeur `bootstrap-action` est égale à `1` est la première action d'amorçage exécutée sur l'instance.
**`amazon-s3-path`**
L'emplacement sur Amazon S3 de l'action d'amorçage qui a échoué.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger la cause première de l'erreur d'action d'amorçage. Lancez ensuite un nouveau cluster.
**Étapes de résolution des problèmes**
1. Utilisez la valeur `amazon-s3-path` du tableau `ErrorData` pour trouver le script d'action d'amorçage approprié dans Amazon S3.
1. Si vous avez activé les journaux de cluster lors de la création de l'instance, consultez le journal `stdout`pour plus d'informations. Vous pouvez trouver le journal `stdout` de l'action d'amorçage dans cet emplacement Amazon S3 :
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
Pour plus d'informations sur les journaux de clusters, consultez [Configuration de la journalisation et du débogage du cluster Amazon EMR](emr-plan-debugging.md).
1. Pour déterminer l'échec de l'action d'amorçage, passez en revue les exceptions dans les journaux `stdout`et la valeur `return-code` dans `ErrorData`.
1. Utilisez les résultats de l'étape précédente pour revoir votre action d'amorçage afin qu'elle évite les exceptions ou qu'elle puisse gérer les exceptions correctement lorsqu'elles se produisent.
1. Lancez un nouveau cluster avec votre action d'amorçage mise à jour.
# BOOTSTRAP\$1FAILURE\$1FILE\$1NOT\$1FOUND\$1PRIMARY
## Présentation de
L'erreur `BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY` indique que l'instance principale ne trouve pas le script d'action d'amorçage qu'elle vient de télécharger depuis le compartiment Amazon S3 spécifié.
## Résolution
Pour résoudre cette erreur, assurez-vous que votre instance principale dispose d'un accès approprié au script d'action d'amorçage.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`primary-instance-id`**
ID de l'instance principale où l'action d'amorçage a échoué.
**`bootstrap-action`**
Numéro ordinal de l'action d'amorçage qui a échoué. Un script dont la valeur `bootstrap-action` est égale à `1` est la première action d'amorçage exécutée sur l'instance.
**`amazon-s3-path`**
L'emplacement sur Amazon S3 de l'action d'amorçage qui a échoué.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger la cause première de l'erreur d'action d'amorçage. Lancez ensuite un nouveau cluster.
1. Pour trouver le script d'action d'amorçage approprié dans Amazon S3, utilisez la valeur `amazon-s3-path` du tableau`ErrorData`.
1. Consultez les fichiers journaux des actions d'amorçage dans Amazon S3 pour identifier la cause première de l'échec. Pour en savoir plus sur la façon de consulter les journaux Amazon EMR, consultez [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
**Note**
Si vous n'avez pas activé les journaux pour votre cluster, vous devez créer un nouveau cluster avec les mêmes configurations et actions d'amorçage. Pour vous assurer que les journaux du cluster sont activés, consultez [Configuration de la journalisation et du débogage du cluster Amazon EMR](emr-plan-debugging.md).
1. Consultez le journal `stdout` de vos actions d'amorçage et vérifiez qu'aucun processus personnalisé ne supprime les fichiers `/emr/instance-controller/lib/bootstrap-actions` du dossier de vos instances principales. Vous pouvez trouver le journal `stdout` de l'action d'amorçage dans cet emplacement Amazon S3 :
```
s3://amzn-s3-demo-bucket/logs/Your_Cluster_Id/node/Primary_Instance_Id/bootstrap-actions/Failed_Bootstrap_Action_Number/stdout.gz
```
1. Lancez un nouveau cluster avec votre action d'amorçage mise à jour.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT\$1DISK\$1SPACE\$1PRIMARY
## Présentation de
L'`BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY`erreur indique que l'instance principale ne dispose pas de suffisamment d'espace disque lors de l'installation du logiciel nécessaire.
## Résolution
Pour résoudre cette erreur, vérifiez que votre instance principale dispose d'un espace disque suffisant sur le volume racine.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`primary-instance-id`**
ID de l'instance principale dont l'espace disque est insuffisant.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
1. Passez en revue les meilleures pratiques relatives au volume de périphérique racine EBS de votre cluster. Consultez [Personnalisation du volume du périphérique racine Amazon EBS](emr-custom-ami-root-volume-size.md) dans le *Guide de gestion Amazon EMR.*
1. Lancez un nouveau cluster avec un volume de périphérique racine EBS plus important.
# BOOTSTRAP\$1FAILURE\$1INSUFFICIENT DISK\$1SPACE\$1WORKER
## Présentation de
L'`BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER`erreur indique qu'une ou plusieurs instances de travail ne disposent pas de suffisamment d'espace disque lors de l'installation du logiciel nécessaire.
## Résolution
Pour résoudre cette erreur, vérifiez que vos instances de travail disposent d'un espace disque suffisant sur le volume racine.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`worker-instance-ids`**
Les instances IDs de travail dont l'espace disque est insuffisant.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
1. Passez en revue les meilleures pratiques relatives au volume de périphérique racine EBS de votre cluster. Consultez [Personnalisation du volume du périphérique racine Amazon EBS](emr-custom-ami-root-volume-size.md) dans le *Guide de gestion Amazon EMR.*
1. Lancez un nouveau cluster avec un volume de périphérique racine EBS plus important.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1PRIMARY
## Présentation de
L'`BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY`erreur indique que l'instance principale n'est pas en mesure d'établir une connexion avec le Hive Metastore externe configuré.
## Résolution
Pour résoudre cette erreur, vérifiez que votre Hive Metastore externe est correctement configuré et que l'instance principale est autorisée à s'y connecter.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`primary-instance-id`**
L'ID de l'instance principale incapable d'établir une connexion avec le Hive Metastore externe configuré.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
1. Consultez les meilleures pratiques relatives à la configuration d'un métastore externe pour Hive. Voir [Configuration d'un métastore externe pour Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html).
1. Lancez un nouveau cluster avec votre configuration de cluster mise à jour.
# BOOTSTRAP\$1FAILURE\$1HIVE\$1METASTORE\$1CONNECTION\$1ERROR\$1WORKER
## Présentation de
L'`BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER`erreur indique qu'une ou plusieurs instances de travail ne sont pas en mesure d'établir une connexion avec le Hive Metastore externe configuré.
## Résolution
Pour résoudre cette erreur, vérifiez que votre Hive Metastore externe est correctement configuré et que les instances de travail sont autorisées à s'y connecter.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`worker-instance-ids`**
Les instances IDs de travail incapables d'établir une connexion avec le métastore Hive externe configuré.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
1. Consultez les meilleures pratiques relatives à la configuration d'un métastore externe pour Hive. Voir [Configuration d'un métastore externe pour Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-metastore-external-hive.html).
1. Lancez un nouveau cluster avec votre configuration de cluster mise à jour.
# Codes d'erreur internes pour Amazon EMR
Les sections suivantes fournissent des informations de dépannage relatives aux codes d'erreur internes, y compris les codes indiquant une capacité insuffisante ou inexistante.
**Topics**
+ [
# ERREUR\$1INTERNE\$1 \$1CAPACITÉ\$1INSUFFISANTE\$1AZ EC2
](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)
# ERREUR\$1INTERNE\$1 \$1CAPACITÉ\$1INSUFFISANTE\$1AZ EC2
## Présentation de
Un cluster se termine avec une erreur `INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ` lorsque la zone de disponibilité sélectionnée ne dispose pas d'une capacité suffisante pour répondre à votre demande de type d'instance Amazon EC2. Le sous-réseau que vous sélectionnez pour un cluster détermine la zone de disponibilité. Pour plus d'informations sur les sous-réseaux pour Amazon EMR, consultez [Configuration de la mise en réseau dans un VPC pour Amazon EMR](emr-plan-vpc-subnet.md).
## Résolution
Pour résoudre cette erreur, modifiez les configurations des types d'instance et créez un nouveau cluster avec votre demande mise à jour.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`instance-type`**
Type d'instance dont la capacité est épuisée.
**`availability-zone`**
Zone de disponibilité vers laquelle correspond votre sous-réseau.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger la cause première de l'erreur de configuration du cluster :
+ Consultez les meilleures pratiques pour la configuration d'un cluster. Consultez [Configuration des types d'instances de cluster Amazon EMR et des meilleures pratiques pour les instances Spot](emr-plan-instances-guidelines.md) dans le *Guide de gestion Amazon EMR.*
+ Résolvez les problèmes de lancement et passez en revue votre configuration. Consultez la section [Résolution des problèmes de lancement d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-launch.html) dans le guide de l'*utilisateur Amazon EC2.*
+ Lancez un nouveau cluster avec votre configuration de cluster mise à jour.
# INTERNAL\$1ERROR\$1SPOT\$1PRICE\$1INCREASE\$1PRIMARY
## Présentation de
Un cluster se termine avec une erreur `INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY` lorsqu'Amazon EMR ne peut pas répondre à votre demande d'instance Spot pour le nœud primaire parce que le prix des instances dépassent votre prix Spot maximal. Pour plus d’informations, consultez la section [Instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) dans le *Guide de l’utilisateur Amazon EC2*.
## Résolution
Pour résoudre cette erreur, spécifiez pour votre cluster des types d'instance conformes à votre objectif de prix, ou augmentez votre limite de prix pour le même type d'instance.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`primary-instance-id`**
L'ID de l'instance principale du cluster qui a échoué.
**`instance-type`**
Type d'instance dont la capacité est épuisée.
**`availability-zone`**
Zone de disponibilité dans laquelle réside votre sous-réseau.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour résoudre les problèmes liés à votre stratégie de configuration de cluster, puis lancez un nouveau cluster :
1. Passez en revue les meilleures pratiques relatives aux instances Spot Amazon EC2 et passez en revue votre stratégie de configuration de cluster. Pour plus d'informations, consultez les [meilleures pratiques pour EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) dans le guide de l'*utilisateur Amazon EC2* et. [Configuration des types d'instances de cluster Amazon EMR et des meilleures pratiques pour les instances Spot](emr-plan-instances-guidelines.md)
1. Modifiez les configurations de votre type d'instance ou votre zone de disponibilité et créez un nouveau cluster avec votre demande mise à jour.
1. Si le problème persiste, utilisez la capacité à la demande pour votre instance principale.
# INTERNAL\$1ERROR\$1SPOT\$1NO\$1CAPACITY\$1PRIMARY
## Présentation de
Un cluster se termine avec une `INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY` erreur lorsque la capacité est insuffisante pour répondre à une demande d'instance Spot pour votre nœud primaire. Pour plus d’informations, consultez la section [Instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html) dans le *Guide de l’utilisateur Amazon EC2*.
## Résolution
Pour résoudre cette erreur, spécifiez pour votre cluster des types d'instance conformes à votre objectif de prix, ou augmentez votre limite de prix pour le même type d'instance.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`primary-instance-id`**
L'ID de l'instance principale du cluster qui a échoué.
**`instance-type`**
Type d'instance dont la capacité est épuisée.
**`availability-zone`**
Zone de disponibilité vers laquelle correspond votre sous-réseau.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour résoudre les problèmes liés à votre stratégie de configuration de cluster, puis lancez un nouveau cluster :
1. Passez en revue les meilleures pratiques relatives aux instances Spot Amazon EC2 et passez en revue votre stratégie de configuration de cluster. Pour plus d'informations, consultez les [meilleures pratiques pour EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) dans le guide de l'*utilisateur Amazon EC2* et. [Configuration des types d'instances de cluster Amazon EMR et des meilleures pratiques pour les instances Spot](emr-plan-instances-guidelines.md)
1. Modifiez les configurations de vos types d'instance et créez un nouveau cluster avec votre demande mise à jour.
1. Si le problème persiste, utilisez la capacité à la demande pour votre instance principale.
# Codes d'erreur d'échec de validation dans Amazon EMR
Les sections suivantes fournissent des informations de dépannage relatives aux codes d'erreur d'échec de validation.
**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
## Présentation de
Lorsque votre cluster et les sous-réseaux auxquels vous faites référence pour votre cluster appartiennent à des clouds privés virtuels différents (VPCs), le cluster se termine avec une `VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC` erreur. Vous pouvez lancer des clusters avec Amazon EMR avec la configuration des flottes d'instances sur les sous-réseaux d'un VPC. Pour plus d'informations sur les flottes d'instances, consultez [Planification et configuration de flottes d'instances pour votre cluster Amazon EMR](emr-instance-fleet.md) dans le *Guide de gestion Amazon EMR*.
## Résolution
Pour résoudre cette erreur, utilisez des sous-réseaux appartenant au même VPC que le cluster.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`vpc`**
Pour chaque paire VPC-sous-réseau : l'ID du VPC auquel appartient le sous-réseau.
**`subnet`**
Pour chaque paire VPC-sous-réseau : l'ID du sous-réseau.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger l'erreur :
1. Passez en revue le IDs sous-réseau répertorié dans le `ErrorData` tableau et confirmez qu'il appartient au VPC sur lequel vous souhaitez lancer le cluster EMR.
1. Modifiez les configurations de vos sous-réseaux. Vous pouvez utiliser l'une des méthodes suivantes pour rechercher tous les sous-réseaux publics et privés disponibles dans un VPC.
+ Accédez à la console Amazon VPC. Choisissez **Subnets** et listez tous les sous-réseaux qui résident au sein Région AWS de votre cluster. Pour rechercher uniquement les sous-réseaux publics ou privés, appliquez le filtre d'**attribution automatique des IPv4 adresses publiques**. Pour rechercher et sélectionner des sous-réseaux dans le VPC utilisé par votre cluster, utilisez l'option **Filtrer par VPC**. Pour plus d'informations sur la création de sous-réseaux, consultez la section [Créer un sous-réseau](https://docs.aws.amazon.com/vpc/latest/userguide/create-subnets.html) du *Guide de l'utilisateur du cloud privé virtuel Amazon*.
+ Utilisez le AWS CLI pour rechercher tous les sous-réseaux publics et privés disponibles dans le VPC utilisé par votre cluster. Pour plus d'informations, consultez l'API [describe-subnets](https://amazonaws.com/ec2/describe-subnets.html). Pour créer de nouveaux sous-réseaux dans un VPC, consultez l'API [create-subnet](https://amazonaws.com/ec2/create-subnet.html).
1. Lancez un nouveau cluster avec des sous-réseaux provenant du même VPC que le cluster.
# VALIDATION\$1ERROR\$1SECURITY\$1GROUP\$1NOT\$1FROM\$1ONE\$1VPC
## Présentation de
Lorsque votre cluster et les groupes de sécurité que vous lui attribuez appartiennent à des clouds privés virtuels différents (VPCs), le cluster se termine avec une `VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC` erreur. Pour de plus amples informations sur les groupes de sécurité consultez [Spécification des groupes de sécurité gérés par Amazon EMR et des groupes de sécurité supplémentaires](emr-sg-specify.md) et [Contrôlez le trafic réseau avec des groupes de sécurité pour votre cluster Amazon EMR](emr-security-groups.md).
## Résolution
Pour résoudre cette erreur, utilisez des groupes de sécurité appartenant au même VPC que le cluster.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`vpc`**
Pour chaque paire groupe de sécurité-VPC, l'ID du VPC auquel appartient le groupe de sécurité.
**`security-group`**
Pour chaque paire groupe de sécurité-VPC, l'ID du groupe de sécurité.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger l'erreur :
1. Passez en revue le groupe IDs de sécurité répertorié dans le `ErrorData` tableau et confirmez qu'il appartient au VPC sur lequel vous souhaitez lancer le cluster EMR.
1. Accédez à la console Amazon VPC. Choisissez **Groupes de sécurité** pour répertorier tous les groupes de sécurité de la région que vous sélectionnez. Recherchez les groupes de sécurité du même VPC que votre cluster, puis modifiez la configuration de votre groupe de sécurité.
1. Lancez un nouveau cluster avec des groupes de sécurité issus du même VPC que le cluster.
# VALIDATION\$1ERROR\$1INVALID\$1SSH\$1KEY\$1NAME
## Présentation de
Un cluster se termine avec une erreur `VALIDATION_ERROR_INVALID_SSH_KEY_NAME` lorsque vous utilisez une paire de clés Amazon EC2 qui n'est pas valide pour accéder à l'instance principale par SSH. Le nom de la paire de clés est peut-être incorrect ou la paire de clés n'existe peut-être pas dans le fichier demandé Région AWS. Pour plus d'informations sur les paires de clés, consultez les [paires de clés Amazon EC2 et les instances Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) dans le guide de l'utilisateur *Amazon EC2*.
## Résolution
Pour résoudre cette erreur, créez un nouveau cluster avec un nom de paire de clés SSH valide.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`ssh-key`**
Le nom de la paire de clés SSH que vous avez fourni lors de la création du cluster.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger l'erreur :
1. Vérifiez votre fichier *keypair* .pem et vérifiez qu'il correspond au nom de la clé SSH que vous voyez dans la console Amazon EMR.
1. Accédez à la console Amazon EC2. Vérifiez que le nom de clé SSH que vous avez utilisé est disponible dans Région AWS celui utilisé par votre cluster. Vous trouverez votre numéro de compte à Région AWS côté de votre numéro de compte en haut du AWS Management Console.
1. Lancez un nouveau cluster avec un nom de clé SSH valide.
# VALIDATION\$1ERROR\$1INSTANCE\$1TYPE\$1NOT\$1SUPPORTED
## Présentation de
Un cluster se termine avec une erreur `VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED` lorsque les zones de disponibilité Région AWS de votre cluster ne prennent pas en charge le type d'instance spécifié pour un ou plusieurs groupes d'instances. Amazon EMR peut prendre en charge un type d'instance dans une zone de disponibilité au sein d'une région, mais pas dans une autre. Le sous-réseau que vous sélectionnez pour un cluster détermine la zone de disponibilité au sein de la région. Pour consulter la liste des types d'instance et des régions pris en charge par Amazon EMR, consultez [Types d'instances pris en charge avec Amazon EMR](emr-supported-instance-types.md).
## Résolution
Pour résoudre cette erreur, spécifiez les types d'instances pour votre cluster pris en charge par Amazon EMR dans la région et la zone de disponibilité où vous demandez le cluster.
Pour dépanner le cluster EMR défaillant, reportez-vous aux informations renvoyées `ErrorDetail` par le et. `DescribeCluster` `ListClusters` APIs Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md). Le tableau `ErrorData` dans `ErrorDetail` renvoie les informations suivantes pour ce code d'erreur :
**`instance-types`**
La liste des types d'instances non pris en charge.
**`availability-zones`**
La liste des zones de disponibilité vers lesquelles votre sous-réseau est résolu.
**`public-doc`**
URL publique de la documentation du code d'erreur.
## Étapes à suivre
Procédez comme suit pour identifier et corriger l'erreur :
1. Utilisez le AWS CLI pour récupérer les types d'instances disponibles dans une zone de disponibilité. Pour ce faire, vous pouvez utiliser la `[ec2 describe-instance-type-offerings](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-type-offerings.html)` commande pour filtrer les types d'instances disponibles par emplacement (Région AWS ou zone de disponibilité). Par exemple, la commande suivante renvoie les types d'instances proposés dans la zone de disponibilité spécifié, `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
```
Pour plus d'informations sur la manière de découvrir les types d'instance disponibles, consultez [Rechercher un type d'instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
1. Après avoir déterminé les types d'instances disponibles dans la même région et zone de disponibilité que le cluster, choisissez l'une des solutions suivantes pour continuer :
1. Créez un nouveau cluster et choisissez un sous-réseau pour le cluster qui se trouve dans une zone de disponibilité où le type d'instance que vous avez sélectionné est disponible et pris en charge par Amazon EMR.
1. Créez un nouveau cluster dans la même région et dans le même sous-réseau Amazon EC2 que le cluster défaillant, mais avec un type d'instance pris en charge à cet emplacement par Amazon EMR.
Pour consulter la liste des types d'instance et des régions pris en charge par Amazon EMR, consultez [Types d'instances pris en charge avec Amazon EMR](emr-supported-instance-types.md). Pour comparer les capacités des types d'instance, consultez les [types d'instance Amazon EC2](https://aws.amazon.com/ec2/instance-types).
# Erreurs de ressources lors des opérations du cluster Amazon EMR
Les erreurs suivantes sont généralement causées par des ressources limitées sur le cluster. Le guide décrit chaque erreur et fournit de l'aide pour résoudre les problèmes.
**Topics**
+ [
# Le cluster Amazon EMR se termine par NO\$1SLAVE\$1LEFT et les nœuds principaux FAILED\$1BY\$1MASTER
](emr-cluster-NO_SLAVE_LEFT-FAILED_BY_MASTER.md)
+ [
# Erreur du cluster Amazon EMR : impossible de répliquer le bloc, mais uniquement sur zéro nœud.
](enough-hdfs-space.md)
+ [
# Erreur du cluster Amazon EMR : QUOTA EC2 DÉPASSÉ
](emr-EC2.md)
+ [
# Erreur du cluster Amazon EMR : trop d'échecs de récupération
](emr-troubleshoot-error-resource-1.md)
+ [
# Erreur du cluster Amazon EMR : le fichier n'a pu être répliqué que sur 0 nœud au lieu de 1
](emr-troubleshoot-error-resource-2.md)
+ [
# Erreur du cluster Amazon EMR : nœuds listés par refus
](emr-troubleshoot-error-resource-3.md)
+ [
# Erreurs de régulation avec un cluster Amazon EMR
](emr-throttling-error.md)
+ [
# Erreur du cluster Amazon EMR : type d'instance non pris en charge
](emr-INSTANCE_TYPE_NOT_SUPPORTED-error.md)
+ [
# Erreur du cluster Amazon EMR : EC2 est hors capacité
](emr-EC2_INSUFFICIENT_CAPACITY-error.md)
+ [
# Erreur du cluster Amazon EMR : erreur du facteur de réplication HDFS
](emr-hdfs-insufficient-replication.md)
+ [
# Erreur du cluster Amazon EMR : erreur d'espace insuffisant sur HDFS
](emr-hdfs-insufficient-space.md)
# Le cluster Amazon EMR se termine par NO\$1SLAVE\$1LEFT et les nœuds principaux FAILED\$1BY\$1MASTER
Cela se produit généralement en raison de l'arrêt de la protection de la résiliation et tous les nœuds principaux dépassent la capacité de stockage de disque spécifiée par un seuil d'utilisation maximal dans la classification de configuration `yarn-site`, qui correspond au fichier `yarn-site.xml`. Par défaut, cette valeur est 90 %. Lorsque l'utilisation du disque pour un nœud principal dépasse le seuil d'utilisation, le service de NodeManager santé YARN signale le nœud comme`UNHEALTHY`. Lorsqu'il est dans cet état, Amazon EMR met le nœud sur la liste noire et n'y alloue pas de conteneurs YARN. Si le nœud reste non sain pendant 45 minutes, Amazon EMR marque l'instance Amazon EC2 rattachée pour la terminaison en tant que `FAILED_BY_MASTER`. Lorsque toutes les instances Amazon EC2 rattachées à des nœuds principaux sont marquées pour la résiliation, le cluster se résilie avec l'état `NO_SLAVE_LEFT`, car il n'y a pas de ressources pour exécuter des tâches.
Le dépassement de l'utilisation du disque sur un nœud principal peut entraîner une réaction en chaîne. Si un seul nœud dépasse le seuil d'utilisation du disque à cause de HDFS, d'autres nœuds sont également susceptibles d'être proches du seuil. Le premier nœud dépasse le seuil d'utilisation de disque, donc Amazon EMR le met sur la liste noire. Cela augmente la charge de l'utilisation du disque pour les nœuds restants, car ils commenceront à répliquer des données HDFS entre eux qu'ils ont perdues du nœud sur la liste noire. Chaque nœud devient ensuite `UNHEALTHY` de la même manière et le cluster se résilie finalement.
## Meilleures pratiques et recommandations
### Configuration du matériel de cluster avec un stockage adéquat
Lorsque vous créez un cluster, assurez-vous qu'il y ait suffisamment de nœuds principaux et que chacun possède suffisamment de stockage d'instance et de volumes de stockage EBS pour HDFS. Pour de plus amples informations, veuillez consulter [Calcul de la capacité HDFS requise pour un cluster](emr-plan-instances-guidelines.md#emr-plan-instances-hdfs). Vous pouvez également ajouter manuellement des instances principales à des groupes d'instances existants ou en utilisant la mise à l'échelle automatique. Les nouvelles instances possèdent la même configuration de stockage que d'autres instances dans le groupe d'instances. Pour de plus amples informations, veuillez consulter [Utilisez le dimensionnement du cluster Amazon EMR pour vous adapter à l'évolution des charges de travail](emr-scale-on-demand.md).
### Activer la protection de la résiliation
Activer la protection de la résiliation. De cette façon, si un nœud principal est placé sur liste noire, vous pouvez vous connecter à l'instance Amazon EC2 rattachée à l'aide de SSH pour diagnostiquer les problèmes et récupérer les données. Si vous activez la protection de la résiliation, sachez qu'Amazon EMR ne remplace pas l'instance Amazon EC2 par une nouvelle instance. Pour de plus amples informations, veuillez consulter [Utilisation de la protection contre la résiliation pour protéger vos clusters Amazon EMR d'un arrêt accidentel](UsingEMR_TerminationProtection.md).
### Créer une alarme pour la CloudWatch métrique MRUnhealthy Nodes
Cette métrique indique le nombre de nœuds de rapports d'un état `UNHEALTHY`. Elle est équivalente à la métrique YARN `mapred.resourcemanager.NoOfUnhealthyNodes`. Vous pouvez configurer une notification pour cette alarme afin de vous avertir des nœuds qui ne sont pas sains avant que le délai d'attente de 45 minutes soit atteint. Pour de plus amples informations, veuillez consulter [Surveillance des métriques Amazon EMR avec CloudWatch](UsingEMR_ViewingMetrics.md).
### Affiner les paramètres à l'aide de yarn-site
Les paramètres ci-dessous peuvent être ajustés en fonction des exigences de votre application. Par exemple, vous pouvez augmenter le seuil d'utilisation du disque lorsqu'un nœud signale un état `UNHEALTHY` en augmentant la valeur de `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage`.
Vous pouvez configurer ces valeurs lorsque vous créez un cluster à l'aide de la classification de configuration `yarn-site`. Pour de plus amples informations, veuillez consulter [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dans le *guide de version Amazon EMR*. Vous pouvez également vous connecter aux instances Amazon EC2 rattachées à des nœuds principaux à l'aide de SSH, puis ajoutez les valeurs dans `/etc/hadoop/conf.empty/yarn-site.xml` à l'aide d'un éditeur de texte. Après avoir effectué la modification, vous devez redémarrer hadoop-yarn-nodemanager comme indiqué ci-dessous.
**Important**
Lorsque vous redémarrez le NodeManager service, les conteneurs YARN actifs sont détruits sauf `yarn.nodemanager.recovery.enabled` s'ils sont configurés pour `true` utiliser la classification de `yarn-site` configuration lors de la création du cluster. Vous devez également spécifier le répertoire dans lequel stocker l'état de conteneur à l'aide de la propriété `yarn.nodemanager.recovery.dir`.
```
sudo /sbin/stop hadoop-yarn-nodemanager
sudo /sbin/start hadoop-yarn-nodemanager
```
Pour plus d'informations sur les propriétés actuelles de `yarn-site` et les valeurs par défaut, consultez [Paramètres YARN par défaut](http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-common/yarn-default.xml) dans la documentation Apache Hadoop.
| Propriété | Valeur par défaut | Description |
| --- | --- | --- |
| yarn.nodemanager. disk-health-checker.intervalle en ms | 120000 | La fréquence (en secondes) à laquelle la vérification de l'état du disque est exécutée. |
| yarn.nodemanager. disk-health-checker. min-healthy-disks | 0.25 | Fraction minimale du nombre de disques qui doivent être sains pour NodeManager lancer de nouveaux conteneurs. Cela correspond à la fois à yarn.nodemanager.local-dirs (par défaut, `/mnt/yarn` dans Amazon EMR) et yarn.nodemanager.log-dirs (par défaut `/var/log/hadoop-yarn/containers`, qui est symlinked à `mnt/var/log/hadoop-yarn/containers` dans Amazon EMR). |
| `yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage` | 90.0 | Le pourcentage maximal d'utilisation d'espace de disque autorisée après laquelle un disque est marqué comme défectueux. Les valeurs peuvent aller de 0.0 à 100.0. Si la valeur est supérieure ou égale à 100, NodeManager le disque est plein. Cela s'applique à `yarn-nodemanager.local-dirs` et `yarn.nodemanager.log-dirs`. |
| `yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb` | 0 | L'espace minimal qui doit être disponible sur un disque pour qu'il soit utilisé. Cela s'applique à `yarn-nodemanager.local-dirs` et `yarn.nodemanager.log-dirs`. |
# Erreur du cluster Amazon EMR : impossible de répliquer le bloc, mais uniquement sur zéro nœud.
Erreur : « Impossible de répliquer un bloc, réplication sur zéro nœud gérée uniquement » se produit généralement lorsqu'un cluster ne dispose pas d'un espace de stockage HDFS suffisant. Cette erreur se produit lors de la génération d'un volume de données dans votre cluster supérieur à ce qui peut être stocké dans HDFS. Vous voyez cette erreur uniquement pendant que le cluster est en cours d'exécution, parce que lorsque la tâche s'arrête, elle libère l'espace HDFS qu'elle utilisait.
La quantité d'espace HDFS disponible pour un cluster dépend du nombre et du type d'instances Amazon EC2 qui sont utilisées en tant que nœuds principaux. Les nœuds de tâche ne sont pas utilisés pour le stockage HDFS. Tout l'espace disque sur chaque instance Amazon EC2, y compris les volumes de stockage EBS attachés, est disponible pour HDFS. Pour plus d'informations sur la quantité de stockage local pour chaque type d'instance EC2, consultez la section [Types et familles d'instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le guide de l'*utilisateur Amazon EC2*.
L'autre facteur qui peut influer sur la quantité d'espace HDFS disponible est le facteur de réplication, qui correspond au nombre de copies de chaque bloc de données stockées dans HDFS pour la redondance. Le facteur de réplication augmente avec le nombre de nœuds dans le cluster : il y a 3 copies de chaque bloc de données pour un cluster avec 10 nœuds ou plus, 2 copies de chaque bloc pour un cluster avec 4 à 9 nœuds et 1 copie (pas de redondance) pour les clusters avec 3 nœuds ou moins. L'espace total HDFS disponible est divisé par le facteur de réplication. Dans certains cas, tels que l'augmentation du nombre de nœuds de 9 à 10, l'augmentation du facteur de réplication peut effectivement entraîner la diminution de la quantité d'espace HDFS disponible.
Par exemple, un cluster avec dix nœuds principaux de type m1.large aurait 2 833 Go d'espace disponible pour HDFS -((10 nœuds x 850 Go par nœud)/facteur de réplication de 3).
Si votre cluster dépasse la quantité d'espace disponible pour HDFS, vous pouvez ajouter des nœuds principaux supplémentaires à votre cluster ou utiliser des données de compression pour créer davantage d'espace HDFS. Si votre cluster est une version qui peut être arrêtée et redémarrée, vous pouvez envisage d'utiliser des nœuds principaux d'un type d'instance Amazon EC2 plus grand. Vous pouvez également envisager d'ajuster le facteur de réplication. Soyez conscient, cependant, que diminuer le facteur de réplication réduit la redondance des données HDFS et la capacité de votre cluster à récupérer à partir de blocs HDFS perdus ou corrompus.
# Erreur du cluster Amazon EMR : QUOTA EC2 DÉPASSÉ
Si vous obtenez un message `EC2 QUOTA EXCEEDED`, cela peut avoir plusieurs causes. En fonction des différences de configuration, l'arrêt et la libération des ressources allouées pour les clusters précédents peuvent prendre de 5 à 20 minutes. Si vous obtenez une erreur `EC2 QUOTA EXCEEDED` lorsque vous tentez de lancer un cluster, il est possible que des ressources provenant d'un cluster récemment arrêté n'aient pas encore été libérées. Ce message peut également être provoqué par le redimensionnement d'un groupe d'instances ou d'un parc d'instances à une taille cible supérieure au quota d'instances actuel pour le compte. Cela peut se produire manuellement ou automatiquement via un dimensionnement automatique.
Vous disposez des options suivantes pour résoudre ce problème :
+ Suivez les instructions figurant dans [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) dans la *Référence générale d'Amazon Web Services* pour demander une augmentation de la limite de service. Pour certains APIs, il peut être préférable de configurer un CloudWatch événement plutôt que d'augmenter les limites. Pour en savoir plus, consultez [Quand configurer des événements EMR dans CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Si un ou plusieurs clusters en cours d'exécution n'ont pas atteint leur capacité, redimensionnez des groupes d'instances ou réduisez les capacités cibles sur les parcs d'instances pour les clusters en cours d'exécution.
+ Créez des clusters avec moins d'instances EC2 ou réduisez la capacité cible.
# Erreur du cluster Amazon EMR : trop d'échecs de récupération
La présence de messages d'erreur « **Too many fetch-failures (Trop d'erreurs de récupération)** » ou « **Error reading task output (Erreur de lecture de sortie de tâche)** » dans les journaux de tentative de tâche ou d'étape indique que la tâche en cours d'exécution dépend du résultat d'une autre tâche. Cela se produit souvent lorsqu'une tâche de réduction est mise en attente d'exécution et requiert le résultat d'une ou de plusieurs tâches d'action mapper et que le résultat n'est pas encore disponible.
Il existe plusieurs raisons pour lesquelles la sortie peut ne pas être disponible :
+ La tâche prérequise est toujours en cours de traitement. Il s'agit souvent d'une tâche de mappage.
+ Les données peuvent être indisponibles en raison d'une connectivité réseau médiocre si les données se trouvent sur une autre instance.
+ Si HDFS est utilisé pour récupérer le résultat, il peut y avoir un problème avec HDFS.
La cause la plus courante de cette erreur est que la tâche précédente est encore en cours de traitement. Cela est particulièrement probable si les erreurs se produisent lorsque les tâches de réduction essaient en premier de s'exécuter. Vous pouvez vérifier si tel est le cas en passant en revue le journal syslog pour l'étape de cluster qui renvoie l'erreur. Si le syslog indique une progression des deux tâches réduire et mapper, cela indique que la phase de réduction a démarré tandis qu'il existe des tâches mapper qui ne sont pas encore terminées.
Une chose à rechercher dans les journaux est un pourcentage de progression de tâche mapper qui atteint 100 % puis revient à une valeur inférieure. Lorsque le pourcentage de tâche mapper est à 100 %, cela ne signifie pas que toutes les tâches mapper sont terminées. Cela signifie simplement que Hadoop exécute toutes les tâches mapper. Si cette valeur retombe en dessous de 100 %, cela signifie qu'une tâche mapper a échoué et, en fonction de la configuration, Hadoop peut tenter de replanifier la tâche. Si le pourcentage cartographique reste à 100 % dans les journaux, examinez les CloudWatch indicateurs, en particulier`RunningMapTasks`, pour vérifier si la tâche cartographique est toujours en cours de traitement. Vous pouvez également trouver ces informations à l'aide de l'interface Web de Hadoop sur le nœud maître.
Si vous rencontrez ce problème, il existe plusieurs choses que vous pouvez essayer :
+ Demandez à la phase de réduction d'attendre plus longtemps avant de démarrer. Vous pouvez le faire en modifiant le paramètre de configuration mapred.reduce.slowstart.completed.maps Hadoop sur une durée plus longue. Pour de plus amples informations, veuillez consulter [Créez des actions bootstrap pour installer des logiciels supplémentaires avec un cluster Amazon EMR](emr-plan-bootstrap.md).
+ Associez le nombre de réductions à la capacité de réduction totale du cluster. Pour cela, vous ajustez le paramètre de configuration mapred.reduce.tasks Hadoop pour la tâche.
+ Utilisez un code de classe d'association afin de réduire le nombre de résultats qui doivent être récupérés.
+ Vérifiez qu'il n'y a aucun problème avec le service Amazon EC2 qui affecte les performances réseau du cluster. Vous pouvez le faire à l'aide du [Tableau de bord de l'état des services](https://status.aws.amazon.com/).
+ Passez en revue les ressources CPU et la mémoire des instances dans votre cluster pour vous assurer que votre traitement des données ne submerge pas les ressources de vos nœuds. Pour de plus amples informations, veuillez consulter [Configuration du matériel et du réseau du cluster Amazon EMR](emr-plan-instances.md).
+ Vérifiez la version de l'Amazon Machine Image (AMI) utilisée dans votre cluster Amazon EMR. Si la version est 2.3.0 à 2.4.4 incluse, mettez à jour vers une version ultérieure. Les versions AMI dans la plage spécifiée utilisent une version de Jetty qui peut ne pas parvenir à fournir le résultat souhaité de la phase de mappage. L'erreur d'extraction se produit lorsque les réducteurs ne peuvent pas obtenir le résultat de la phase de mappage.
Jetty est un serveur HTTP open source qui est utilisé pour des communications machine à machine au sein d'un cluster Hadoop.
# Erreur du cluster Amazon EMR : le fichier n'a pu être répliqué que sur 0 nœud au lieu de 1
Lorsqu'un fichier est écrit dans HDFS, il est répliqué sur plusieurs nœuds principaux. Lorsque cette erreur s'affiche, cela signifie que le NameNode démon ne dispose d'aucune DataNode instance disponible sur laquelle écrire des données dans HDFS. En d'autres termes, la réplication de bloc n'a pas lieu. Cette erreur peut être provoquée par un certain nombre de problèmes :
+ Le système de fichiers HDFS peut être venu à manquer d'espace. C'est la cause la plus probable.
+ DataNode les instances n'étaient peut-être pas disponibles lors de l'exécution de la tâche.
+ DataNode les instances peuvent avoir été empêchées de communiquer avec le nœud maître.
+ Des instances dans le groupe d'instance principal peuvent ne pas être disponibles.
+ Des autorisations peuvent être manquantes. Par exemple, le JobTracker démon n'est peut-être pas autorisé à créer des informations de suivi des tâches.
+ Le paramètre d'espace réservé pour une DataNode instance peut être insuffisant. Vérifiez si tel est le cas en contrôlant le paramètre de configuration dfs.datanode.du.reserved.
Pour vérifier si ce problème est dû au manque d'espace disque de HDFS, examinez la `HDFSUtilization` métrique contenue dans CloudWatch. Si cette valeur est trop élevée, vous pouvez ajouter des nœuds principaux supplémentaires au cluster. Si vous pensez que votre cluster risque de manquer d'espace disque HDFS, vous pouvez configurer une alarme CloudWatch pour vous avertir lorsque la valeur de `HDFSUtilization` dépasse un certain niveau. Pour plus d’informations, consultez [Redimensionner manuellement un cluster Amazon EMR en cours d'exécution](emr-manage-resize.md) et [Surveillance des métriques Amazon EMR avec CloudWatch](UsingEMR_ViewingMetrics.md).
Si le problème n'est pas dû au manque d'espace du HDFS, vérifiez les DataNode journaux, les NameNode journaux et la connectivité réseau pour détecter d'autres problèmes qui auraient pu empêcher HDFS de répliquer les données. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
# Erreur du cluster Amazon EMR : nœuds listés par refus
Le NodeManager daemon est responsable du lancement et de la gestion des conteneurs sur les nœuds principaux et les nœuds de tâches. Les conteneurs sont alloués au NodeManager démon par le ResourceManager démon qui s'exécute sur le nœud maître. Le ResourceManager surveille le NodeManager nœud par un battement de cœur.
Dans certaines situations, le ResourceManager daemon deny répertorie a NodeManager, le supprimant du pool de nœuds disponibles pour traiter les tâches :
+ Si aucun battement de cœur n' NodeManager a été envoyé au ResourceManager daemon au cours des 10 dernières minutes (600 000 millisecondes). Cette période de temps peut être configurée à l'aide du paramètre de configuration `yarn.nm.liveness-monitor.expiry-interval-ms`. Pour plus d'informations sur la modification des paramètres de configuration de Yarn, consultez [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dans le *Guide de version Amazon EMR*.
+ NodeManager vérifie l'état des disques déterminé par `yarn.nodemanager.local-dirs` et`yarn.nodemanager.log-dirs`. Les vérifications incluent les autorisations et l'espace disque disponible (< 90 %). Si un disque échoue à la vérification, il NodeManager cesse de l'utiliser mais indique toujours que l'état du nœud est sain. Si plusieurs disques échouent à la vérification, le nœud est signalé comme étant défectueux ResourceManager et aucun nouveau conteneur ne lui est attribué.
Le responsable de l'application peut également refuser de NodeManager répertorier un nœud si plus de trois tâches ont échoué. Vous pouvez le remplacer par une valeur plus élevée à l'aide du paramètre de configuration `mapreduce.job.maxtaskfailures.per.tracker`. D'autres paramètres de configuration que vous pouvez modifier contrôlent le nombre de tentatives pour une tâche avant de l'indiquer comme ayant échoué : `mapreduce.map.max.attempts` pour les tâches Map et `mapreduce.reduce.maxattempts` pour les tâches Reduce. Pour plus d'informations sur la modification des paramètres de configuration, consultez [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dans le *Guide de version Amazon EMR*.
# Erreurs de régulation avec un cluster Amazon EMR
Les erreurs « Throttled from *Amazon EC2* while launch cluster » et « Impossible de provisionner les instances en raison d'une limitation » *Amazon EC2* se produisent lorsqu'Amazon EMR ne peut pas traiter une demande parce qu'un autre service a limité l'activité. Amazon EC2 est la source la plus courante d'erreurs de régulation, mais d'autres services peuvent être à l'origine d'erreurs de régulation. Les [limites de service AWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) s'appliquent par région afin d'améliorer les performances, et une erreur de régulation indique que vous avez dépassé la limite de service de votre compte dans cette région.
## Causes possibles :
La cause la plus courante d'erreurs de limitation Amazon EC2 est le lancement d'un grand nombre d'instances de cluster entraînant le dépassement de votre limite de service pour les instances EC2. Des instances de cluster peuvent être lancées pour les raisons suivantes :
+ De nouveaux clusters sont créés.
+ Des clusters sont redimensionnés manuellement. Pour de plus amples informations, veuillez consulter [Redimensionner manuellement un cluster Amazon EMR en cours d'exécution](emr-manage-resize.md).
+ Des groupes d'instances dans un cluster ajoute des instances (montée en charge) en raison d'une règle de dimensionnement automatique. Pour de plus amples informations, veuillez consulter [Présentation des règles de dimensionnement automatique](emr-automatic-scaling.md#emr-scaling-rules).
+ Des parcs d'instances dans un cluster ajoutent des instances pour répondre à une augmentation de la capacité cible. Pour de plus amples informations, veuillez consulter [Planification et configuration de flottes d'instances pour votre cluster Amazon EMR](emr-instance-fleet.md).
Il est également possible que la fréquence ou le type de demande d'API faite à Amazon EC2 entraîne des erreurs de limitation. Pour plus d'informations sur la façon dont Amazon EC2 gère les demandes d'API, consultez [Interroger le débit de demandes d'API](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/query-api-troubleshooting.html#api-request-rate) dans *Référence d'API Amazon EC2*.
## Solutions
Envisagez les solutions suivantes :
+ Suivez les instructions figurant dans [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) dans la *Référence générale d'Amazon Web Services* pour demander une augmentation de la limite de service. Pour certains APIs, il peut être préférable de configurer un CloudWatch événement plutôt que d'augmenter les limites. Pour en savoir plus, consultez [Quand configurer des événements EMR dans CloudWatch](emr-service-limits-cloudwatch-events.md).
+ Si vous avez des clusters qui se lancent au même moment (par exemple, en début d'heure), envisagez d'échelonner les heures de démarrage.
+ Si des clusters sont dimensionnés selon les pics de demande et que vous disposez périodiquement d'une capacité d'instance en excès, envisagez de spécifier le dimensionnement automatique pour ajouter et supprimer des instances à la demande. Les instances sont ainsi utilisées de façon plus efficace, et en fonction du profil demande, moins d'instances peuvent être demandées à un moment donné dans un compte. Pour de plus amples informations, veuillez consulter [Utilisation du dimensionnement automatique avec une politique personnalisée pour les groupes d'instances dans Amazon EMR](emr-automatic-scaling.md).
# Erreur du cluster Amazon EMR : type d'instance non pris en charge
Si vous créez un cluster et que celui-ci échoue avec le message d'erreur « Le type d'instance demandé n'*InstanceType*est pas pris en charge dans la zone de disponibilité demandée », cela signifie que vous avez créé le cluster et que vous avez spécifié un type d'instance pour un ou plusieurs groupes d'instances qui n'est pas pris en charge par Amazon EMR dans la région et la zone de disponibilité où le cluster a été créé. Amazon EMR peut prendre en charge un type d'instance dans une zone de disponibilité d'une région et pas dans une autre. Le sous-réseau que vous sélectionnez pour un cluster détermine la zone de disponibilité au sein de la région.
## Solution
**Déterminez les types d'instances disponibles dans une zone de disponibilité à l'aide du AWS CLI**
+ Utilisez la commande `ec2 run-instances` avec l’option `--dry-run`. Dans l'exemple ci-dessous, remplacez *m5.xlarge* par le type d'instance que vous souhaitez utiliser, *ami-035be7bafff33b6b6* par l'AMI associée à ce type d'instance et *subnet-12ab3c45* par un sous-réseau de la zone de disponibilité que vous souhaitez interroger.
```
aws ec2 run-instances --instance-type m5.xlarge --dry-run --image-id ami-035be7bafff33b6b6 --subnet-id subnet-12ab3c45
```
Pour obtenir des instructions sur la recherche d'un ID d'AMI, consultez [Trouver une AMI Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/finding-an-ami.html). Pour trouver un ID de sous-réseau, vous pouvez utiliser la commande [describe-subnets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-subnets.html).
Pour plus d'informations sur la manière de découvrir les types d'instance disponibles, consultez [Rechercher un type d'instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html).
Une fois que vous avez déterminé les types d'instance disponibles, vous pouvez effectuer l'une des opérations suivantes :
+ Créer le cluster dans la même région et le même sous-réseau EC2, puis choisir un autre type d'instance avec des capacités similaires à celles de votre premier choix. Pour obtenir la liste des types d’instances, consultez [Types d'instances pris en charge avec Amazon EMR](emr-supported-instance-types.md). Pour comparer les capacités des types d'instance EC2, consultez les [types d'instance Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Choisir un sous-réseau pour le cluster dans une zone de disponibilité où le type d'instance est disponible et pris en charge par Amazon EMR.
**Atténuer les échecs de lancement de clusters de parc d'instances en raison de types d'instances principales non pris en charge dans Amazon EMR**
Les nœuds principaux sont essentiels dans les clusters Amazon EMR. Le lancement d'un cluster EMR peut échouer avec une `instance type not supported` erreur lorsqu'Amazon EMR tente de lancer le cluster dans une zone de disponibilité où le type d'instance principale n'est pas pris en charge. La sélection améliorée des zones de disponibilité pour les clusters de parc d'instances dans Amazon EMR filtre automatiquement les types d'instances principaux non pris en charge AZs que vous avez spécifiés dans la configuration du cluster. Cela signifie qu'Amazon EMR ne choisira pas de zone de disponibilité dans laquelle les types d'instances principales configurés ne sont pas pris en charge, ce qui permet d'éviter les échecs de lancement de clusters dus à des types d'instances non pris en charge.
Pour activer cette amélioration, ajoutez l'autorisation requise au rôle de service ou à la politique de votre cluster. La dernière version de `AmazonEMRServicePolicy_v2` inclut cette autorisation, donc si vous utilisez cette politique, l'amélioration est déjà disponible. Si vous utilisez un rôle ou une politique de service personnalisé, ajoutez l'autorisation `ec2:DescribeInstanceTypeOfferings` lors du lancement de votre cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeInstanceTypeOfferings"
],
"Effect": "Allow",
"Resource": [
"*"
],
"Sid": "AllowEC2Describeinstancetypeofferings"
}
]
}
```
------
# Erreur du cluster Amazon EMR : EC2 est hors capacité
Un *EC2 est en panne. Une *InstanceType** erreur se produit lorsque vous tentez de créer un cluster, ou d'ajouter des instances à un cluster, dans une zone de disponibilité qui ne contient plus le type d'instance EC2 spécifié. Le sous-réseau que vous sélectionnez pour un cluster détermine la zone de disponibilité.
Pour créer un cluster, procédez comme suit :
+ Spécifiez un autre type d'instance doté de fonctionnalités similaires
+ Créez le cluster dans une autre région
+ Sélectionnez un sous-réseau dans une zone de disponibilité où le type d'instance souhaité peut être disponible.
Pour ajouter des instances à un cluster en cours d'exécution, effectuez l'une des opérations suivantes :
+ Modifiez des configurations de groupe d'instances ou des configurations de flotte d'instances pour ajouter des types d'instance disponibles avec des capacités similaires. Pour obtenir la liste des types d’instances, consultez [Types d'instances pris en charge avec Amazon EMR](emr-supported-instance-types.md). Pour comparer les capacités des types d'instance EC2, consultez les [types d'instance Amazon EC2](https://aws.amazon.com/ec2/instance-types/).
+ Arrêtez le cluster et recréez-le dans une région et une zone de disponibilité dans lesquelles le type d'instance est disponible.
# Erreur du cluster Amazon EMR : erreur du facteur de réplication HDFS
Lorsque vous supprimez un nœud principal d'un [groupe d'instances](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-uniform-instance-group.html) principal ou d'un [parc d'instances](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-instance-fleet.html), Amazon EMR peut rencontrer une erreur de réplication HDFS. Cette erreur se produit lorsque vous supprimez des nœuds principaux et que le nombre de nœuds principaux tombe en dessous du [facteur dfs.replication](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html) configuré pour le système de fichiers distribué Hadoop (HDFS). Amazon EMR ne peut donc pas effectuer l'opération en toute sécurité. Pour déterminer la valeur par défaut de la `dfs.replication` configuration, configuration [HDFS](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hdfs-config.html).
## Causes possibles :
Consultez les informations suivantes pour connaître les causes possibles de l'erreur du facteur de réplication HDFS :
+ Si vous [redimensionnez manuellement](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage-resize.html) un groupe d'instances principal ou un parc d'instances en dessous du `dfs.replication` facteur configuré.
+ Vos politiques de [dimensionnement géré](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-managed-scaling.html) ou d'[autoscaling](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-automatic-scaling.html) peuvent permettre le dimensionnement afin de réduire le nombre de nœuds principaux en dessous du seuil de`dfs.replication`.
+ Cette erreur peut également se produire si Amazon EMR tente de [remplacer](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-node-replacement.html) un nœud principal défectueux alors qu'un cluster possède le nombre minimal de nœuds principaux défini par. []()
## Solutions et meilleures pratiques
Consultez les informations suivantes pour connaître les solutions et les meilleures pratiques :
+ Lorsque vous redimensionnez manuellement un cluster Amazon EMR, ne le réduisez pas en dessous `dfs.replication` car Amazon EMR ne peut pas effectuer le redimensionnement en toute sécurité.
+ Lorsque vous utilisez le dimensionnement géré ou le dimensionnement automatique, assurez-vous que la capacité minimale de votre cluster n'est pas inférieure au `dfs.replication` facteur.
+ Le nombre d'instances principales doit être d'au moins `dfs.replication` plus un. Cela garantit qu'Amazon EMR peut remplacer avec succès un nœud principal défectueux si vous avez activé le remplacement de cœur défectueux.
**Important**
La défaillance d'un nœud à cœur unique peut entraîner une perte de données HDFS si vous définissez `dfs.replication` la valeur 1. Si votre cluster dispose d'un stockage HDFS, nous vous recommandons de le configurer avec au moins quatre nœuds principaux pour les charges de travail de production afin d'éviter toute perte de données et de définir le `dfs.replication` facteur sur au moins 2.
# Erreur du cluster Amazon EMR : erreur d'espace insuffisant sur HDFS
Une erreur d'espace insuffisant dans le système de fichiers distribué Hadoop (HDFS) peut se produire si vous tentez de supprimer un nœud principal, mais Amazon EMR ne peut pas terminer l'opération en toute sécurité en raison de l'espace insuffisant restant dans le HDFS. Avant qu'Amazon EMR ne supprime un nœud principal, toutes les données HDFS du nœud doivent être transférées vers d'autres nœuds principaux pour garantir la redondance des données. Toutefois, s'il n'y a pas assez d'espace sur les autres nœuds principaux pour la réplication, Amazon EMR ne peut pas mettre le nœud hors service correctement.
## Causes possibles :
Consultez la liste suivante pour obtenir une liste des causes possibles de l'erreur d'espace insuffisant du HDFS :
+ Si vous réduisez manuellement un groupe d'instances principal ou un parc d'instances alors qu'il n'y a pas assez d'espace HDFS sur les nœuds restants pour la réplication des données avant la réduction.
+ Le dimensionnement géré ou le dimensionnement automatique permet de réduire un groupe d'instances principal ou un parc d'instances lorsqu'il n'y a pas assez d'espace HDFS pour la réplication des données.
+ Amazon EMR tente de remplacer un nœud principal défectueux mais ne parvient pas à le remplacer en toute sécurité en raison d'un espace HDFS insuffisant.
## Solutions et meilleures pratiques
Consultez les informations suivantes pour connaître les solutions et les meilleures pratiques :
+ Augmentez le nombre de nœuds principaux de votre cluster Amazon EMR. Si vous utilisez le dimensionnement géré ou l'autoscaling, augmentez la capacité minimale de vos nœuds principaux.
+ Utilisez des volumes EBS plus importants pour vos nœuds principaux lorsque vous créez votre cluster EMR.
+ Supprimez les données HDFS inutiles de votre cluster EMR. Nous vous recommandons de configurer des CloudWatch alarmes pour surveiller la `HDFSUtilization` métrique de votre cluster afin de savoir si votre cluster EMR manque d'espace.
# Erreurs d'entrée et de sortie du cluster lors des opérations Amazon EMR
Les erreurs suivantes sont courantes dans les opérations d'entrée et sortie de cluster. Suivez les instructions de cette rubrique pour résoudre les problèmes et vérifier votre configuration.
**Topics**
+ [
## Votre chemin d'accès à Amazon Simple Storage Service (Amazon S3) comporte-t-il au moins trois barres obliques ?
](#threeslashes)
+ [
## Essayez-vous de parcourir de façon récursive les répertoires d'entrée ?
](#recurseinput)
+ [
## Votre répertoire de sortie existe-t-il déjà ?
](#directoryexist)
+ [
## Essayez-vous de spécifier une ressource à l'aide d'une URL HTTP ?
](#httpurl)
+ [
## Référencez-vous un compartiment Amazon S3 à l'aide d'un format de nom non valide ?
](#validdnsname)
+ [
## Rencontrez-vous des difficultés lors du chargement des données vers ou depuis Amazon S3 ?
](#emr-troubleshoot-errors-io-1)
## Votre chemin d'accès à Amazon Simple Storage Service (Amazon S3) comporte-t-il au moins trois barres obliques ?
Lorsque vous spécifiez un compartiment Amazon S3, vous devez inclure une barre oblique de terminaison à la fin de l'URL. Par exemple, au lieu de référencer un bucket comme « s3n : //amzn-s3-demo-bucket1 », vous devez utiliser « s3n : //amzn-s3-demo-bucket1/ », sinon Hadoop échouera dans votre cluster dans la plupart des cas.
## Essayez-vous de parcourir de façon récursive les répertoires d'entrée ?
Hadoop ne recherche pas de façon récursive les fichiers dans les répertoires d'entrée. Si vous avez une structure de répertoire telle que /corpus/01/01.txt, /corpus/01/02.txt, /corpus/02/01.txt, etc., et que vous spécifiez /corpus/ comme paramètre d'entrée pour votre cluster, Hadoop ne trouve aucun fichier d'entrée, car le répertoire /corpus/ est vide et Hadoop ne vérifie pas le contenu des sous-répertoires. De même, Hadoop ne vérifie pas de façon récursive les sous-répertoires des compartiments Amazon S3.
Les fichiers d'entrée doivent être directement dans le répertoire d'entrée ou le compartiment Amazon S3 que vous spécifiez, pas dans les sous-répertoires.
## Votre répertoire de sortie existe-t-il déjà ?
Si vous spécifiez un chemin de sortie qui existe déjà, Hadoop entraîne dans la plupart des cas l'échec du cluster. Cela signifie que si vous exécutez un cluster une première fois, puis l'exécutez à nouveau avec exactement les mêmes paramètres, il fonctionnera probablement la première fois puis jamais plus. Après la première utilisation, le chemin de sortie existe et il entraîne l'échec de toutes les exécutions suivantes.
## Essayez-vous de spécifier une ressource à l'aide d'une URL HTTP ?
Hadoop n'accepte pas les emplacements de ressources utilisant le préfixe http://. Vous ne pouvez pas faire référence à une ressource à l'aide d'une URL HTTP. Par exemple, transmettre http://mysite/myjar.jar comme paramètre JAR provoque l'échec du cluster.
## Référencez-vous un compartiment Amazon S3 à l'aide d'un format de nom non valide ?
Si vous essayez d'utiliser un nom de bucket tel que « amzn-s3-demo-bucket1.1 » avec Amazon EMR, votre cluster échouera car Amazon EMR exige que les noms de bucket soient des noms d'hôte RFC 2396 valides ; le nom ne peut pas se terminer par un chiffre. En outre, en raison des exigences de Hadoop, les noms des compartiments Amazon S3 utilisés avec Amazon EMR doivent contenir uniquement des lettres minuscules, des chiffres, des points (.) et des traits d'union (-). Pour plus d'informations sur la manière de formater les noms des compartiments Amazon S3, consultez la section [Restrictions et limitations des compartiments](https://docs.aws.amazon.com/AmazonS3/latest/userguide/index.html?BucketRestrictions.html) du *Guide de l'utilisateur Amazon Simple Storage Service*.
## Rencontrez-vous des difficultés lors du chargement des données vers ou depuis Amazon S3 ?
Amazon S3 est la source d'entrée et de sortie la plus populaire pour Amazon EMR. Une erreur courante est de traiter Amazon S3 comme un système de fichiers standard. Il existe des différences entre Amazon S3 et un système de fichiers que vous devez prendre en compte lorsque vous exécutez votre cluster.
+ Si une erreur interne se produit dans Amazon S3, votre application doit gérer cela de façon appropriée et répéter l'opération.
+ Si des appels à Amazon S3 mettent trop longtemps à être retournés, votre application peut avoir besoin de réduire la fréquence à laquelle elle appelle Amazon S3.
+ Répertorier tous les objets figurant dans un compartiment Amazon S3 représente un appel onéreux. Votre application doit réduire au maximum ce nombre d'opérations.
Il existe plusieurs façons d'améliorer la façon dont votre cluster interagit avec Amazon S3.
+ Lancez votre cluster à l'aide de la dernière version d'Amazon EMR.
+ Utilisez S3 DistCp pour déplacer des objets dans et hors d'Amazon S3. S3 DistCp implémente la gestion des erreurs, les nouvelles tentatives et les interruptions pour répondre aux exigences d'Amazon S3. Pour plus d'informations, consultez la section [Copie distribuée à l'aide de S3 DistCp](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/UsingEMR_s3distcp.html).
+ Concevez votre application en gardant à l'esprit la cohérence à terme. Utilisez le système HDFS pour le stockage de données intermédiaires quand le cluster est en cours d'exécution et Amazon S3 uniquement pour entrer les données initiales et générer les résultats finaux.
+ Si vos clusters valident 200 transactions ou plus par seconde sur Amazon S3, [contactez l'assistance](https://aws.amazon.com/contact-us/) pour préparer votre compartiment à un plus grand nombre de transactions par seconde et envisagez d'utiliser les stratégies de partition clés décrites dans [Conseils et astuces sur les performances d'Amazon S3](https://aws.amazon.com/blogs/aws/amazon-s3-performance-tips-tricks-seattle-hiring-event/).
+ Attribuez au paramètre de configuration Hadoop io.file.buffer.size la valeur 65536. Hadoop passe ainsi moins de temps à chercher dans les objets Amazon S3.
+ Envisagez de désactiver la fonctionnalité d'exécution spéculative de Hadoop si votre cluster connaît des problèmes de simultanéité avec Amazon S3. Cela s'avère utile également pour dépanner un cluster lent. Pour ce faire, définissez les propriétés `mapreduce.map.speculative` et `mapreduce.reduce.speculative` sur `false`. Lorsque vous lancez un cluster, vous pouvez définir ces valeurs l'aide de la classification de configuration `mapred-env`. Pour plus d’informations, consultez [Configuration des applications](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html) dans le *guide de version Amazon EMR*.
+ Si vous exécutez un cluster Hive, consultez [Rencontrez-vous des problèmes de chargement de données vers ou depuis Amazon S3 dans Hive ?](emr-troubleshoot-error-hive.md#emr-troubleshoot-error-hive-3).
Pour plus d'informations, consultez les [meilleures pratiques relatives aux erreurs Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/ErrorBestPractices.html) dans le *Guide de l'utilisateur d'Amazon Simple Storage Service*.
# Erreurs d'autorisations lors des opérations du cluster Amazon EMR
Les erreurs suivantes sont courantes lors de l'utilisation des autorisations ou des informations d'identification.
**Topics**
+ [
## Les informations d'identification que vous saisissez dans SSH sont-elles correctes ?
](#correctcred)
+ [
## Si vous utilisez IAM, les politiques Amazon EC2 appropriées sont-elles définies ?
](#check-iam-permissions)
## Les informations d'identification que vous saisissez dans SSH sont-elles correctes ?
Si vous ne pouvez pas utiliser SSH pour vous connecter au nœud maître, il s'agit probablement d'un problème lié à vos informations d'identification de sécurité.
Commencez par vérifier que le fichier .pem qui contient votre clé SSH dispose des autorisations appropriées. Vous pouvez utiliser chmod pour modifier les autorisations sur votre fichier .pem, comme indiqué dans l'exemple suivant, où vous remplacez « mykey.pem » par le nom de votre propre fichier .pem.
```
1. chmod og-rwx mykey.pem
```
Le problème peut également se produire si vous n'utilisez pas la paire de clés que vous avez spécifiée lors de la création du cluster. C'est une erreur courante si vous avez créé plusieurs paires de clés. Vérifiez les détails du cluster dans la console Amazon EMR (ou utilisez l'option `--describe` dans l'interface de ligne de commande) afin d'identifier le nom de la paire de clés qui a été spécifié lors de la création du cluster.
Après avoir vérifié que vous utilisez la paire de clés correcte et que les autorisations sont définies correctement dans le fichier .pem, vous pouvez utiliser la commande suivante pour utiliser SSH pour vous connecter au nœud principal, où vous remplacez « mykey.pem » par le nom de votre fichier .pem et `hadoop@ec2-01-001-001-1.compute-1.amazonaws.com` par le nom DNS public du nœud principal (disponible via l'option `--describe` dans l'interface de ligne de commande ou via la console Amazon EMR.)
**Important**
Vous devez utiliser le nom de connexion `hadoop` lorsque vous vous connectez à un nœud de cluster Amazon EMR, sinon une erreur similaire à l'erreur `Server refused our key` peut se produire.
```
1. ssh -i mykey.pem hadoop@ec2-01-001-001-1.compute-1.amazonaws.com
```
Pour de plus amples informations, veuillez consulter [Connectez-vous au nœud principal du cluster Amazon EMR à l'aide de SSH](emr-connect-master-node-ssh.md).
## Si vous utilisez IAM, les politiques Amazon EC2 appropriées sont-elles définies ?
Étant donné qu'Amazon EMR utilise des instances EC2 en tant que nœuds, les utilisateurs Amazon EMR ont également besoin de disposer de certaines politiques Amazon EC2 afin qu'Amazon EMR puisse gérer ces instances pour l'utilisateur. Si les autorisations requises ne sont pas définies, Amazon EMR renvoie l'erreur : **« Compte non autorisé à appeler EC2. »**
Pour de plus amples informations sur les politiques Amazon EC2 que votre compte IAM doit définir pour exécuter Amazon EMR, consultez [Fonctionnement d'Amazon EMR avec IAM](security_iam_service-with-iam.md).
# Erreurs de cluster Hive
Vous pouvez généralement trouver la cause d'une erreur Hive dans le fichier `syslog`, dont le lien est disponible dans le volet **Étapes**. Si vous ne pouvez pas déterminer le problème grâce à ce fichier, vérifiez le message d'erreur de la tentative de tâche Hadoop. Vous y accédez grâce au lien disponible dans le volet **Tentatives de tâche**.
Les erreurs suivantes sont communes aux clusters Hive.
**Topics**
+ [
## Utilisez-vous la dernière version de Hive ?
](#emr-troubleshoot-error-hive-0)
+ [
## Avez-vous rencontré une erreur de syntaxe dans le script Hive ?
](#emr-troubleshoot-error-hive-1)
+ [
## Une tâche a-t-elle échoué lors d'une exécution interactive ?
](#emr-troubleshoot-error-hive-2)
+ [
## Rencontrez-vous des problèmes de chargement de données vers ou depuis Amazon S3 dans Hive ?
](#emr-troubleshoot-error-hive-3)
## Utilisez-vous la dernière version de Hive ?
La dernière version de Hive comporte tous les correctifs et correctifs de bogues actuels, ce qui peut résoudre votre problème.
## Avez-vous rencontré une erreur de syntaxe dans le script Hive ?
Si une étape échoue, consultez le fichier `stdout` des journaux relatifs à l'étape dans laquelle le script Hive a été exécuté. Si l'erreur n'est pas indiquée dans ce fichier, consultez le fichier `syslog` des journaux de la tentative de tâche qui a échoué. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
## Une tâche a-t-elle échoué lors d'une exécution interactive ?
Si vous exécutez Hive de façon interactive sur le nœud principal et si le cluster a échoué, consultez les entrées du journal `syslog` dans le journal des tentatives de tâche afin d'identifier la tentative de tâche qui a échoué. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
## Rencontrez-vous des problèmes de chargement de données vers ou depuis Amazon S3 dans Hive ?
Si vous rencontrez des difficultés pour accéder aux données dans Amazon S3, commencez par vérifier les causes possibles répertoriées dans [Rencontrez-vous des difficultés lors du chargement des données vers ou depuis Amazon S3 ?](emr-troubleshoot-errors-io.md#emr-troubleshoot-errors-io-1). Si aucun de ces problèmes n'est à l'origine, vous pouvez utiliser les options spécifiques à Hive suivantes.
+ Veillez à utiliser la dernière version de Hive qui comporte tous les correctifs et correctifs de bogues actuels qui peuvent résoudre votre problème. Pour plus d'informations, consultez [Apache Hive](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive.html).
+ L'utilisation de `INSERT OVERWRITE` nécessite l'affichage du contenu du compartiment ou du dossier Amazon S3. Il s'agit d'une opération coûteuse. Si possible, réduisez manuellement le chemin d'accès plutôt que de faire répertorier et supprimer des objets existants par Hive.
+ Si vous utilisez une version antérieure à la version 5.0 d'Amazon EMR, vous pouvez utiliser la commande suivante dans HiveQL afin de mettre en pré-cache les résultats d'une opération de liste Amazon S3 localement sur le cluster :
```
set hive.optimize.s3.query=true;
```
+ Si possible, utilisez des partitions statiques.
+ Dans certaines versions de Hive et d'Amazon EMR, il est possible que l'utilisation de ALTER TABLES échoue, car le tableau est stockée dans un autre emplacement que celui prévu par Hive. La solution consiste à ajouter ou mettre à jour les éléments suivants dans `/home/hadoop/conf/core-site.xml`:
```
fs.s3n.endpoint
s3.amazonaws.com
```
# Erreurs VPC lors des opérations du cluster Amazon EMR
Les erreurs suivantes sont communes à la configuration de VPC dans Amazon EMR.
**Topics**
+ [
## Configuration de sous-réseau non valide
](#emr-troubleshoot-error-gateway)
+ [
## Jeu d'options DHCP manquant
](#emr-troubleshoot-error-dhcp)
+ [
## Erreurs d'autorisations
](#emr-troubleshoot-error-denied)
+ [
## Erreurs qui se traduisent par `START_FAILED`
](#emr-troubleshoot-error-vpc-dns)
+ [
## Cluster `Terminated with errors` et NameNode ne démarre pas
](#emr-troubleshoot-namenode-dns)
## Configuration de sous-réseau non valide
Sur la page **Cluster Details (Détails de cluster)**, dans le champ **Status (État)**, vous voyez une erreur similaire à ce qui suit :
`The subnet configuration was invalid: Cannot find route to InternetGateway in main RouteTable rtb-id for vpc vpc-id.`
Pour résoudre ce problème, vous devez créer une passerelle Internet et la connecter à votre VPC. Pour plus d'informations, consultez [Ajout d'une passerelle Internet à votre VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Internet_Gateway.html).
Sinon, vérifiez que vous avez configuré votre VPC avec les paramètres **Enable DNS resolution (Activer la résolution DNS)** et **Enable DNS hostname support (Activer le support de nom d'hôte DNS)** activés. Pour plus d'informations, consultez [Utilisation de DNS avec votre VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-dns.html).
## Jeu d'options DHCP manquant
Vous voyez un échec d'étape dans le journal système (syslog) de cluster avec une erreur similaire à ce qui suit :
` 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. `
or
`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.`
Pour résoudre ce problème, vous devez configurer un VPC incluant un jeu d'options DHCP dont les paramètres sont définis sur les valeurs suivantes :
**Note**
Si vous utilisez la région AWS GovCloud (USA Ouest), définissez domain-name sur au **us-gov-west-1.compute.internal** lieu de la valeur utilisée dans l'exemple suivant.
+ **nom-domaine** = **ec2.internal**
Utilisez **ec2.internal** si votre région est USA Est (Virginie du Nord). Pour les autres régions, utilisez *region-name***.compute.internal**. Par exemple, dans la région us-west-2, utilisez **domain-name (nom-domaine)**=**us-west-2.compute.internal**.
+ **domain-name-servers** = **AmazonProvidedDNS**
Pour plus d'informations, consultez [Jeux d'options DHCP](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_DHCP_Options.html).
## Erreurs d'autorisations
Une défaillance dans le journal `stderr` pour une étape indique qu'une ressource Amazon S3 n'a pas les autorisations appropriées. Il s'agit d'une erreur 403 et l'erreur ressemble à :
```
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
```
Si le ActionOnFailure paramètre est défini sur`TERMINATE_JOB_FLOW`, le cluster se terminera avec l'état,`SHUTDOWN_COMPLETED_WITH_ERRORS`.
Quelques façons pour résoudre ce problème incluent les suivantes :
+ Si vous utilisez une politique de compartiment Amazon S3 au sein d'un VPC, assurez-vous de donner accès à tous les compartiments en créant un point de terminaison de VPC et en sélectionnant **Tout autoriser** sous l'option Politique lorsque vous créez le point de terminaison.
+ Assurez-vous que toutes stratégies rattachées aux ressources S3 incluent le VPC dans lequel vous lancez le cluster.
+ Essayez d'exécuter la commande suivante à partir de votre cluster afin de vérifier que vous pouvez accéder au compartiment
```
hadoop fs -copyToLocal s3://path-to-bucket /tmp/
```
+ Vous pouvez obtenir des informations de débogage plus spécifiques en définissant le paramètre `log4j.logger.org.apache.http.wire` sur `DEBUG` dans le fichier `/home/hadoop/conf/log4j.properties` sur le cluster. Vous pouvez vérifier le fichier journal `stderr` après avoir essayé d'accéder au compartiment depuis le cluster. Le fichier journal fournira des informations plus détaillées :
```
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]"
```
## Erreurs qui se traduisent par `START_FAILED`
Avant AMI 3.7.0, VPCs lorsqu'un nom d'hôte est spécifié, Amazon EMR mappe les noms d'hôtes internes du sous-réseau avec des adresses de domaine personnalisées comme suit :. `ip-X.X.X.X.customdomain.com.tld` Par exemple, si le nom d'hôte était `ip-10.0.0.10` et le VPC a l'option de nom de domaine définie sur customdomain.com, le nom d'hôte mappé par Amazon EMR qui en résulte serait `ip-10.0.1.0.customdomain.com`. Une entrée est ajoutée dans `/etc/hosts` pour résoudre le nom d'hôte sur 10.0.0.10. Ce comportement est modifié avec l'AMI 3.7.0 et Amazon EMR respecte désormais entièrement la configuration DHCP du VPC. Précédemment, les clients pouvaient également utiliser une action d'amorçage pour spécifier un mappage de nom d'hôte.
Si vous souhaitez conserver ce comportement, vous devez fournir le DNS et transmettre la configuration de résolution dont vous avez besoin pour le domaine personnalisé.
## Cluster `Terminated with errors` et NameNode ne démarre pas
Lors du lancement d'un cluster EMR dans un VPC qui permet d'utiliser un nom de domaine DNS personnalisé, votre cluster peut échouer avec le message d'erreur suivant dans la console :
```
Terminated with errors On the master instance(instance-id), bootstrap action 1 returned a non-zero return code
```
L'échec est dû à l' NameNode impossibilité de démarrer. Cela entraînera la découverte de l'erreur suivante dans les NameNode journaux, dont l'URI Amazon S3 est de la forme `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)
```
Cela est dû à un problème potentiel où une instance EC2 peut avoir plusieurs jeux de noms de domaine pleinement qualifiés lors du lancement de clusters EMR dans un VPC, utilisant à la fois un serveur DNS fourni par AWS et un serveur DNS personnalisé fourni par l'utilisateur. Si le serveur DNS fourni par l'utilisateur ne fournit aucun enregistrement de pointeur (PTR) pour aucun enregistrement A utilisé pour désigner des nœuds dans un cluster EMR, les clusters échouent à démarrer lorsqu'ils sont configurés de cette façon. La solution consiste à ajouter 1 enregistrement PTR pour chaque enregistrement A créé lorsqu'une instance EC2 est démarrée dans un des sous-réseaux dans le VPC.
# Erreurs liées au cluster Amazon EMR lors du streaming
Vous pouvez généralement trouver la cause d'une erreur de diffusion en continu dans un fichier `syslog`. Lien vers ce fichier dans le volet **Steps (Étapes)**.
Les erreurs suivantes sont communes aux clusters de diffusion en continu.
**Topics**
+ [
## Les données sont-elles envoyées au mappeur dans un format incorrect ?
](#emr-troubleshoot-error-streaming-1)
+ [
## Votre script arrive-t-il à expiration ?
](#emr-troubleshoot-error-streaming-2)
+ [
## Transmettez-vous des arguments de diffusion en continu non valides ?
](#invalidarg)
+ [
## Votre script s'est-il terminé par une erreur ?
](#emr-troubleshoot-error-streaming-3)
## Les données sont-elles envoyées au mappeur dans un format incorrect ?
Pour vérifier si tel est le cas, recherchez un message d'erreur dans le fichier `syslog` d'une tentative de tâche ayant échoué dans les journaux de tentative de tâche. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
## Votre script arrive-t-il à expiration ?
L'expiration par défaut pour un script mappeur ou réducteur est de 600 secondes. Si votre script a besoin de davantage de temps, la tentative de la tâche échoue. Vous pouvez vérifier que c'est le cas en vérifiant le fichier `syslog` d'une tentative de tâche ayant échoué dans les journaux de tentative de tâche. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
Vous pouvez modifier le délai en définissant une nouvelle valeur pour le paramètre de configuration `mapred.task.timeout`. Ce paramètre spécifie le nombre de millisecondes après quoi Amazon EMR mettra fin à une tâche qui n'a pas lu l'entrée, écrit la sortie ou mis à jour sa chaîne de statut. Vous pouvez mettre à jour cette valeur en transmettant un argument supplémentaire de diffusion en continu `-jobconf mapred.task.timeout=800000`.
## Transmettez-vous des arguments de diffusion en continu non valides ?
La diffusion en continu de Hadoop prend en charge uniquement les arguments suivants. Si vous transmettez des arguments autres que ceux répertoriés ci-après, le cluster échoue.
```
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
```
En outre, la diffusion en continu Hadoop reconnaît uniquement les arguments transmis à l'aide de la syntaxe Java. C'est à dire, précédés d'un seul trait d'union. Si vous transmettez des arguments précédés d'un tiret double, le cluster échoue.
## Votre script s'est-il terminé par une erreur ?
Si votre script mappeur ou réducteur se termine par une erreur, vous pouvez localiser l'erreur dans le fichier `stderr` des journaux de tentative de tâche de la tentative de tâche qui a échoué. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
# Amazon EMR : erreurs du cluster JAR personnalisé
Les erreurs suivantes sont communes aux clusters des fichiers JAR personnalisés.
**Topics**
+ [
## Votre fichier JAR lève-t-il une exception avant de créer un travail ?
](#emr-troubleshoot-error-custom-jar-1)
+ [
## Votre fichier JAR génère-t-il une erreur au sein d'une tâche de mappage ?
](#emr-troubleshoot-error-custom-jar-2)
## Votre fichier JAR lève-t-il une exception avant de créer un travail ?
Si le programme principal de votre fichier JAR personnalisé lève une exception lorsqu'il crée le travail Hadoop, le meilleur emplacement à examiner est le fichier `syslog` des journaux d'étape. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
## Votre fichier JAR génère-t-il une erreur au sein d'une tâche de mappage ?
Si votre fichier JAR personnalisé et votre mappeur lèvent une exception lors du traitement de données d'entrée, le meilleur emplacement à examiner est le fichier `syslog` des journaux de tentatives de tâche. Pour de plus amples informations, veuillez consulter [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
# Erreurs Amazon EMR AWS GovCloud (US-West)
La région AWS GovCloud (USA Ouest) se distingue des autres régions en termes de sécurité, de configuration et de paramètres par défaut. Par conséquent, utilisez la liste de contrôle suivante pour résoudre les erreurs Amazon EMR spécifiques à la région AWS GovCloud (ouest des États-Unis) avant de suivre des recommandations de dépannage plus générales.
+ Vérifiez que vos rôles IAM sont correctement configurés. Pour de plus amples informations, veuillez consulter [Configurer les rôles de service IAM pour les autorisations Amazon EMR relatives AWS aux services et aux ressources](emr-iam-roles.md).
+ Assurez-vous que les paramètres de resolution/hostname support DNS, Internet Gateway et DHCP Option Set sont correctement configurés dans votre configuration VPC. Pour de plus amples informations, veuillez consulter [Erreurs VPC lors des opérations du cluster Amazon EMR](emr-troubleshoot-error-vpc.md).
Si ces étapes ne corrigent pas le problème, poursuivez avec les étapes de dépannage des erreurs courantes Amazon EMR. Pour de plus amples informations, veuillez consulter [Collections d'erreurs courantes dans Amazon EMR](emr-troubleshoot-errors.md).
## Trouver un cluster manquant
Si votre cluster ne figure pas dans la liste des consoles ou dans l'API `ListClusters`, vérifiez les points suivants :
+ Confirmez que l'âge du cluster à partir de la date d'achèvement est inférieur à deux mois. Amazon EMR conserve gratuitement pendant deux mois les informations relatives aux métadonnées des clusters terminés. Vous ne pouvez pas supprimer les clusters terminés de la console. Au lieu de cela, Amazon EMR purge automatiquement les clusters terminés au bout de deux mois.
+ Confirmez que vous disposez des autorisations de rôle pour afficher le cluster.
+ Vérifiez que vous visualisez le même Région AWS endroit où réside le cluster.
# Résoudre les problèmes liés à un cluster Amazon EMR défaillant avec un code d'erreur
Cette section vous guide tout au long du processus de dépannage d'un cluster qui a échoué. Cela signifie que le cluster s'est arrêté avec un code d'erreur.
**Note**
Lorsqu'un cluster EMR se termine avec une erreur, les `DescribeCluster` et `ListClusters` APIs renvoient un code d'erreur et un message d'erreur. Pour certaines erreurs de cluster, le tableau de données `ErrorDetail` peut également vous aider à résoudre le problème. Pour de plus amples informations, veuillez consulter [Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR](emr-troubleshoot-error-errordetail.md).
Si votre cluster s'exécute mais met du temps à renvoyer des résultats, consultez [Résoudre les problèmes liés à la lenteur d'un cluster Amazon EMR](emr-troubleshoot-slow.md).
**Topics**
+ [
# Étape 1 : recueillir des données sur le problème lié au cluster Amazon EMR
](emr-troubleshoot-failed-1.md)
+ [
# Étape 2 : Vérifier l'environnement
](emr-troubleshoot-failed-2.md)
+ [
# Étape 3 : Examiner le dernier changement d'état
](emr-troubleshoot-failed-3.md)
+ [
# Étape 4 : examiner les fichiers journaux Amazon EMR
](emr-troubleshoot-failed-4.md)
+ [
# Étape 5 : tester le cluster Amazon EMR étape par étape
](emr-troubleshoot-failed-5-test-steps.md)
# Étape 1 : recueillir des données sur le problème lié au cluster Amazon EMR
La première étape du dépannage d'un cluster consiste à recueillir des informations sur le problème rencontré, ainsi que sur l'état actuel et la configuration du cluster. Ces informations seront utilisées dans les étapes suivantes pour confirmer ou exclure les causes possibles du problème.
## Définition du problème
Définir clairement le problème est la première étape de résolution. Quelques questions à vous poser :
+ Quel était l'effet attendu ? Que s'est-il passé à la place ?
+ Quand ce problème s'est-il produit pour la première fois ? Combien de fois cela s'est-il produit depuis ?
+ Est-ce que quelque chose a changé dans la façon dont je configure ou gère mon cluster ?
## Détails du cluster
Les détails du cluster suivants sont utiles pour détecter les problèmes. Pour plus d'informations sur la manière de spécifier ces informations, consultez [Afficher l'état et les détails du cluster Amazon EMR](emr-manage-view-clusters.md).
+ Identifiant du cluster. (Également appelé identifiant de flux de travail.)
+ Région AWS et la zone de disponibilité dans laquelle le cluster a été lancé.
+ État du cluster, y compris les détails du dernier changement d'état.
+ Type et nombre d'instances EC2 spécifiées pour les nœuds principaux et de tâche.
# Étape 2 : Vérifier l'environnement
Amazon EMR opère dans le cadre d'un écosystème de services Web et de logiciels open source. Des éléments affectant ces dépendances peuvent attribuer les performances d'Amazon EMR.
**Topics**
+ [
## Recherche d'interruptions de service
](#emr-troubleshoot-failed-2-outages)
+ [
## Recherche des limites d'utilisation
](#emr-troubleshoot-failed-2-limits)
+ [
## Vérification de la version
](#emr-troubleshoot-failed-2-ami)
+ [
## Vérifiez la configuration du sous-réseau Amazon VPC
](#emr-troubleshoot-failed-2-vpc)
## Recherche d'interruptions de service
Amazon EMR utilise plusieurs services Web Amazon en interne. Il exécute des serveurs virtuels sur Amazon EC2, stocke des données et des scripts sur Amazon S3 et transmet des métriques à. CloudWatch Les événements qui perturbent ces services sont rares, mais lorsqu'ils se produisent, ils peuvent entraîner des problèmes dans Amazon EMR.
Avant d'aller plus loin, consultez le [Tableau de bord de l'état des services](https://status.aws.amazon.com/). Vérifiez la région dans laquelle vous avez lancé votre cluster pour voir s'il y a des interruptions dans l'un de ces services.
## Recherche des limites d'utilisation
Si vous lancez un cluster de grande taille, si vous avez lancé plusieurs clusters simultanément ou si vous êtes un utilisateur partageant un cluster Compte AWS avec d'autres utilisateurs, le cluster a peut-être échoué car vous avez dépassé une limite de AWS service.
Amazon EC2 limite le nombre d'instances de serveurs virtuels exécutées dans une même AWS région à 20 instances réservées ou à la demande. Si vous lancez un cluster comportant plus de 20 nœuds, ou si vous lancez un cluster dont le nombre total d'instances EC2 actives dépasse 20, le cluster ne sera pas en mesure de lancer toutes les instances EC2 dont il a besoin et risque d'échouer. Compte AWS Dans ce cas, Amazon EMR renvoie une erreur `EC2 QUOTA EXCEEDED`. Vous pouvez demander à AWS augmenter le nombre d'instances EC2 que vous pouvez exécuter sur votre compte en soumettant une [demande d'augmentation de la limite d'instance Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/).
Le délai entre la fermeture d'un cluster et le moment où il libère toutes ses ressources peut également vous faire dépasser vos limites d'utilisation. Selon sa configuration, il peut s'écouler entre 5 et 20 minutes avant que le cluster ne se termine complètement et ne libère les ressources qui lui ont été allouées. Si vous obtenez une erreur `EC2 QUOTA EXCEEDED` lorsque vous tentez de lancer un cluster, il est possible que des ressources provenant d'un cluster récemment arrêté n'aient pas encore été libérées. Dans ce cas, vous pouvez soit [demander à ce que votre quota Amazon EC2 soit augmenté](https://aws.amazon.com/contact-us/ec2-request/), soit attendre 20 minutes et relancer le cluster.
Amazon S3 limite le nombre de compartiments créés sur un compte à 100. Si votre cluster crée un nouveau compartiment qui dépasse cette limite, la création du compartiment échouera et peut entraîner l'échec du cluster.
## Vérification de la version
Comparez le libellé de la version que vous avez utilisée pour lancer le cluster avec la dernière version d'Amazon EMR. Chaque version d'Amazon EMR inclut des améliorations telles que de nouvelles applications et fonctions, des correctifs et des correctifs de bogues. Le problème qui affecte votre cluster a peut-être déjà été corrigé dans la dernière version. Si possible, réexécutez votre cluster à l'aide de la dernière version.
## Vérifiez la configuration du sous-réseau Amazon VPC
Si votre cluster a été lancé dans un sous-réseau Amazon VPC, celui-ci doit être configuré comme décrit dans [Configuration de la mise en réseau dans un VPC pour Amazon EMR](emr-plan-vpc-subnet.md). Vérifiez également que le sous-réseau dans lequel vous lancez le cluster possède suffisamment d'adresses IP élastiques libres pour en attribuer une à chaque nœud du cluster.
# Étape 3 : Examiner le dernier changement d'état
Le dernier changement d'état fournit des informations sur ce qui s'est passé la dernière fois que le cluster a changé d'état. Il contient souvent des informations explicitant les problèmes qui se sont posés lorsque l'état d'un cluster change et devient `FAILED`. Par exemple, si vous lancez un cluster de streaming et spécifiez un emplacement de sortie qui existe déjà dans Amazon S3, le cluster échoue avec un dernier changement d'état de « Le répertoire de sortie de streaming existe déjà ».
Vous pouvez localiser la valeur du dernier changement d'état dans la console en affichant le volet de détails pour le cluster, à partir de l'interface de ligne de commande à l'aide des arguments `list-steps` ou `describe-cluster`, ou à partir de l'API à l'aide des actions `DescribeCluster` et `ListSteps`. Pour de plus amples informations, veuillez consulter [Afficher l'état et les détails du cluster Amazon EMR](emr-manage-view-clusters.md).
# Étape 4 : examiner les fichiers journaux Amazon EMR
L'étape suivante consiste à examiner les fichiers journaux afin de trouver un code d'erreur ou une autre indication du problème rencontré par votre cluster. Pour plus d'informations sur les fichiers journaux disponibles, où les trouver et comment les consulter, consultez [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
Il faudra peut-être effectuer un certain travail d'enquête pour déterminer ce qui s'est passé. Hadoop exécute le travail des tâches lors de tentatives de tâches sur différents nœuds du cluster. Amazon EMR peut lancer des tentatives de tâches spéculatives, mettant fin aux autres tentatives de tâches qui n'aboutissent pas. Cela génère une activité importante qui est enregistrée au fur et à mesure dans les fichiers journaux du contrôleur : stderr et syslog. En outre, plusieurs tentatives de tâches sont exécutées simultanément, mais un fichier journal ne peut afficher les résultats que de manière linéaire.
Commencez par vérifier les journaux d'actions d'amorçage pour détecter les erreurs ou les modifications de configuration inattendues lors du lancement du cluster. À partir de là, consultez les journaux d'étapes pour identifier les tâches Hadoop lancées dans le cadre d'une étape comportant des erreurs. Examinez les journaux des tâches Hadoop pour identifier les tentatives de tâches qui ont échoué. Le journal des tentatives de tâche contiendra des détails sur la cause de l'échec d'une tentative de tâche.
Les sections suivantes décrivent comment utiliser les différents fichiers journaux pour identifier les erreurs dans votre cluster.
## Vérification des journaux d'actions d'amorçage
Les actions d'amorçage exécutent des scripts sur le cluster lors de son lancement. Elles servent généralement à installer des logiciels supplémentaires sur le cluster ou à modifier les paramètres de configuration par rapport aux valeurs par défaut. La vérification des journaux peut fournir un aperçu des erreurs survenues lors de la configuration du cluster ainsi que des modifications des paramètres de configuration susceptibles d'attribuer les performances.
## Vérification des journaux d'étape
Il existe quatre types de journaux d'étapes.
+ **Contrôleur :** contient les fichiers générés par Amazon EMR (Amazon EMR) à la suite d'erreurs rencontrées lors de l'exécution de votre étape. Si votre étape échoue lors du chargement, vous pouvez trouver la trace de la pile dans ce journal. Les erreurs de chargement ou d'accès à votre application sont souvent décrites ici, tout comme les erreurs manquantes dans les fichiers de mappage.
+ **stderr :** contient les messages d'erreur survenus lors du traitement de l'étape. Les erreurs de chargement des applications sont souvent décrites ici. Ce journal contient parfois une trace de pile.
+ **stdout :** contient le statut généré par les exécutables de votre mappeur et de votre réducteur. Les erreurs de chargement des applications sont souvent décrites ici. Ce journal contient parfois des messages d'erreur d'application.
+ **syslog :** contient des journaux provenant de logiciels autres qu'Amazon, tels qu'Apache et Hadoop. Les erreurs de diffusion sont souvent décrites ici.
Vérifiez stderr pour détecter les erreurs évidentes. Si stderr affiche une courte liste d'erreurs, l'étape s'est arrêtée rapidement et une erreur a été renvoyée. Cela est le plus souvent dû à une erreur dans les applications de mappage et de réduction exécutées dans le cluster.
Examinez les dernières lignes du contrôleur et du syslog pour détecter les erreurs ou les défaillances. Suivez toutes les instructions concernant les tâches ayant échoué, en particulier si le message « Échec de la tâche » s'affiche.
## Vérification des journaux de tentatives de tâche
Si l'analyse précédente des journaux d'étapes a révélé l'échec d'une ou de plusieurs tâches, examinez les journaux des tentatives de tâches correspondantes pour obtenir des informations plus détaillées sur les erreurs.
# Étape 5 : tester le cluster Amazon EMR étape par étape
Une technique utile lorsque vous essayez de déceler la source d'une erreur consiste à redémarrer le cluster et à lui soumettre les étapes une par une. Cela vous permet de vérifier les résultats de chaque étape avant de traiter la suivante, et vous donne l'occasion de corriger et de réexécuter une étape qui a échoué. Cela présente également l'avantage de vous faire charger une seule fois les données d'entrée.
**Pour tester un cluster étape par étape**
1. Lancez un nouveau cluster avec les deux options keep-alive et protection contre l'arrêt activées. L'option keep-alive maintient le cluster actif après qu'il a traité toutes ses étapes en suspens. La protection contre l'arrêt empêche un cluster de s'arrêter en cas d'erreur. Pour plus d’informations, consultez [Configuration d'un cluster Amazon EMR pour qu'il continue ou s'arrête après l'exécution de l'étape](emr-plan-longrunning-transient.md) et [Utilisation de la protection contre la résiliation pour protéger vos clusters Amazon EMR d'un arrêt accidentel](UsingEMR_TerminationProtection.md).
1. Soumettez une étape au cluster. Pour de plus amples informations, veuillez consulter [Soumettre un travail à un cluster Amazon EMR](emr-work-with-steps.md).
1. À la fin du traitement de l'étape, recherchez les erreurs dans les fichiers journaux d'étape. Pour de plus amples informations, veuillez consulter [Étape 4 : examiner les fichiers journaux Amazon EMR](emr-troubleshoot-failed-4.md). Le moyen le plus rapide de localiser ces fichiers journaux est de se connecter au nœud maître et d'y afficher les fichiers journaux. Les fichiers journaux d'étape n'apparaissent pas tant que l'étape ne s'est pas exécutée assez longtemps, ne s'est pas terminée ou n'a pas échoué.
1. Si l'étape a réussi sans erreur, exécutez l'étape suivante. Si des erreurs se sont produites, enquêtez sur l'erreur dans les fichiers journaux. Si l'erreur se situe dans votre code, effectuez la correction et réexécutez l'étape. Continuez jusqu'à ce que toutes les étapes s'exécutent sans erreur.
1. Lorsque vous avez terminé le débogage du cluster et souhaitez arrêter ce dernier, vous devez l'arrêter manuellement. Cela est nécessaire car le cluster a été lancé avec la protection contre l'arrêt activée. Pour de plus amples informations, veuillez consulter [Utilisation de la protection contre la résiliation pour protéger vos clusters Amazon EMR d'un arrêt accidentel](UsingEMR_TerminationProtection.md).
# Résoudre les problèmes liés à la lenteur d'un cluster Amazon EMR
Cette section explique le processus de résolution des problèmes d'un cluster qui est en cours d'exécution, mais qui met longtemps à renvoyer les résultats. Pour plus d'informations sur les actions à mettre en œuvre si un code d'erreur a été émis lors de la mise hors service du cluster, consultez [Résoudre les problèmes liés à un cluster Amazon EMR défaillant avec un code d'erreur](emr-troubleshoot-failed.md)
Amazon EMR vous permet de spécifier le nombre et le type d'instances dans le cluster. Ces éléments sont ceux qui ont le plus grand effet sur la vitesse de traitement de vos données. Vous pouvez envisager de ré-exécuter le cluster, cette fois-ci en spécifiant les instances EC2 avec davantage de ressources, ou en spécifiant un plus grand nombre d'instances dans le cluster. Pour de plus amples informations, veuillez consulter [Configuration du matériel et du réseau du cluster Amazon EMR](emr-plan-instances.md).
Les rubriques suivantes vous expliquent comment identifier d'autres causes possibles du ralentissement d'un cluster.
**Topics**
+ [
# Étape 1 : recueillir des données sur le problème lié au cluster Amazon EMR
](emr-troubleshoot-slow-1.md)
+ [
# Étape 2 : vérification de l'environnement du cluster EMR
](emr-troubleshoot-slow-2.md)
+ [
# Étape 3 : examiner les fichiers journaux du cluster Amazon EMR
](emr-troubleshoot-slow-3.md)
+ [
# Étape 4 : vérifier l'état du cluster et de l'instance Amazon EMR
](emr-troubleshoot-slow-4.md)
+ [
# Étape 5 : Vérifiez les groupes suspendus
](emr-troubleshoot-slow-5.md)
+ [
# Étape 6 : vérifier les paramètres de configuration du cluster Amazon EMR
](emr-troubleshoot-slow-6.md)
+ [
# Étape 7 : examiner les données d'entrée pour le cluster Amazon EMR
](emr-troubleshoot-slow-7.md)
# Étape 1 : recueillir des données sur le problème lié au cluster Amazon EMR
La première étape du dépannage d'un cluster consiste à recueillir des informations sur le problème rencontré, ainsi que sur l'état actuel et la configuration du cluster. Ces informations seront utilisées dans les étapes suivantes pour confirmer ou exclure les causes possibles du problème.
## Définition du problème
Définir clairement le problème est la première étape de résolution. Quelques questions à vous poser :
+ Quel était l'effet attendu ? Que s'est-il passé à la place ?
+ Quand ce problème s'est-il produit pour la première fois ? Combien de fois cela s'est-il produit depuis ?
+ Est-ce que quelque chose a changé dans la façon dont je configure ou gère mon cluster ?
## Détails du cluster
Les détails du cluster suivants sont utiles pour détecter les problèmes. Pour plus d'informations sur la manière de spécifier ces informations, consultez [Afficher l'état et les détails du cluster Amazon EMR](emr-manage-view-clusters.md).
+ Identifiant du cluster. (Également appelé identifiant de flux de travail.)
+ Région AWS et la zone de disponibilité dans laquelle le cluster a été lancé.
+ État du cluster, y compris les détails du dernier changement d'état.
+ Type et nombre d'instances EC2 spécifiées pour les nœuds principaux et de tâche.
# Étape 2 : vérification de l'environnement du cluster EMR
Vérifiez votre environnement pour voir s'il y a des interruptions de service ou si vous avez dépassé une limite AWS de service.
**Topics**
+ [
## Recherche d'interruptions de service
](#emr-troubleshoot-slow-2-outages)
+ [
## Recherche des limites d'utilisation
](#emr-troubleshoot-slow-2-limits)
+ [
## Vérifiez la configuration du sous-réseau Amazon VPC
](#emr-troubleshoot-slow-2-vpc)
+ [
## Redémarrage du cluster
](#emr-troubleshoot-slow-2-restart)
## Recherche d'interruptions de service
Amazon EMR utilise plusieurs services Web Amazon en interne. Il exécute des serveurs virtuels sur Amazon EC2, stocke des données et des scripts sur Amazon S3 et transmet des métriques à. CloudWatch Les événements qui perturbent ces services sont rares, mais lorsqu'ils se produisent, ils peuvent entraîner des problèmes dans Amazon EMR.
Avant d'aller plus loin, consultez le [Tableau de bord de l'état des services](https://status.aws.amazon.com/). Vérifiez la région dans laquelle vous avez lancé votre cluster pour voir s'il y a des interruptions dans l'un de ces services.
## Recherche des limites d'utilisation
Si vous lancez un cluster de grande taille, si vous avez lancé plusieurs clusters simultanément ou si vous êtes un utilisateur partageant un cluster Compte AWS avec d'autres utilisateurs, le cluster a peut-être échoué car vous avez dépassé une limite de AWS service.
Amazon EC2 limite le nombre d'instances de serveurs virtuels exécutées dans une même AWS région à 20 instances réservées ou à la demande. Si vous lancez un cluster comportant plus de 20 nœuds, ou si vous lancez un cluster dont le nombre total d'instances EC2 actives dépasse 20, le cluster ne sera pas en mesure de lancer toutes les instances EC2 dont il a besoin et risque d'échouer. Compte AWS Dans ce cas, Amazon EMR renvoie une erreur `EC2 QUOTA EXCEEDED`. Vous pouvez demander à AWS augmenter le nombre d'instances EC2 que vous pouvez exécuter sur votre compte en soumettant une [demande d'augmentation de la limite d'instance Amazon EC2](https://aws.amazon.com/contact-us/ec2-request/).
Le délai entre la fermeture d'un cluster et le moment où il libère toutes ses ressources peut également vous faire dépasser vos limites d'utilisation. Selon sa configuration, il peut s'écouler entre 5 et 20 minutes avant que le cluster ne se termine complètement et ne libère les ressources qui lui ont été allouées. Si vous obtenez une erreur `EC2 QUOTA EXCEEDED` lorsque vous tentez de lancer un cluster, il est possible que des ressources provenant d'un cluster récemment arrêté n'aient pas encore été libérées. Dans ce cas, vous pouvez soit [demander à ce que votre quota Amazon EC2 soit augmenté](https://aws.amazon.com/contact-us/ec2-request/), soit attendre 20 minutes et relancer le cluster.
Amazon S3 limite le nombre de compartiments créés sur un compte à 100. Si votre cluster crée un nouveau compartiment qui dépasse cette limite, la création du compartiment échouera et peut entraîner l'échec du cluster.
## Vérifiez la configuration du sous-réseau Amazon VPC
Si votre cluster a été lancé dans un sous-réseau Amazon VPC, celui-ci doit être configuré comme décrit dans [Configuration de la mise en réseau dans un VPC pour Amazon EMR](emr-plan-vpc-subnet.md). Vérifiez également que le sous-réseau dans lequel vous lancez le cluster possède suffisamment d'adresses IP élastiques libres pour en attribuer une à chaque nœud du cluster.
## Redémarrage du cluster
Une condition temporaire peut être à l'origine du ralentissement du traitement. Envisagez d'arrêter et de redémarrer le cluster pour vérifier si cela permet d'améliorer les performances.
# Étape 3 : examiner les fichiers journaux du cluster Amazon EMR
L'étape suivante consiste à examiner les fichiers journaux afin de trouver un code d'erreur ou une autre indication du problème rencontré par votre cluster. Pour plus d'informations sur les fichiers journaux disponibles, où les trouver et comment les consulter, consultez [Afficher les fichiers journaux Amazon EMR](emr-manage-view-web-log-files.md).
Il faudra peut-être effectuer un certain travail d'enquête pour déterminer ce qui s'est passé. Hadoop exécute le travail des tâches lors de tentatives de tâches sur différents nœuds du cluster. Amazon EMR peut lancer des tentatives de tâches spéculatives, mettant fin aux autres tentatives de tâches qui n'aboutissent pas. Cela génère une activité importante qui est enregistrée au fur et à mesure dans les fichiers journaux du contrôleur : stderr et syslog. En outre, plusieurs tentatives de tâches sont exécutées simultanément, mais un fichier journal ne peut afficher les résultats que de manière linéaire.
Commencez par vérifier les journaux d'actions d'amorçage pour détecter les erreurs ou les modifications de configuration inattendues lors du lancement du cluster. À partir de là, consultez les journaux d'étapes pour identifier les tâches Hadoop lancées dans le cadre d'une étape comportant des erreurs. Examinez les journaux des tâches Hadoop pour identifier les tentatives de tâches qui ont échoué. Le journal des tentatives de tâche contiendra des détails sur la cause de l'échec d'une tentative de tâche.
Les sections suivantes décrivent comment utiliser les différents fichiers journaux pour identifier les erreurs dans votre cluster.
## Vérification des journaux d'actions d'amorçage
Les actions d'amorçage exécutent des scripts sur le cluster lors de son lancement. Elles servent généralement à installer des logiciels supplémentaires sur le cluster ou à modifier les paramètres de configuration par rapport aux valeurs par défaut. La vérification des journaux peut fournir un aperçu des erreurs survenues lors de la configuration du cluster ainsi que des modifications des paramètres de configuration susceptibles d'attribuer les performances.
## Vérification des journaux d'étape
Il existe quatre types de journaux d'étapes.
+ **Contrôleur :** contient les fichiers générés par Amazon EMR (Amazon EMR) à la suite d'erreurs rencontrées lors de l'exécution de votre étape. Si votre étape échoue lors du chargement, vous pouvez trouver la trace de la pile dans ce journal. Les erreurs de chargement ou d'accès à votre application sont souvent décrites ici, tout comme les erreurs manquantes dans les fichiers de mappage.
+ **stderr :** contient les messages d'erreur survenus lors du traitement de l'étape. Les erreurs de chargement des applications sont souvent décrites ici. Ce journal contient parfois une trace de pile.
+ **stdout :** contient le statut généré par les exécutables de votre mappeur et de votre réducteur. Les erreurs de chargement des applications sont souvent décrites ici. Ce journal contient parfois des messages d'erreur d'application.
+ **syslog :** contient des journaux provenant de logiciels autres qu'Amazon, tels qu'Apache et Hadoop. Les erreurs de diffusion sont souvent décrites ici.
Vérifiez stderr pour détecter les erreurs évidentes. Si stderr affiche une courte liste d'erreurs, l'étape s'est arrêtée rapidement et une erreur a été renvoyée. Cela est le plus souvent dû à une erreur dans les applications de mappage et de réduction exécutées dans le cluster.
Examinez les dernières lignes du contrôleur et du syslog pour détecter les erreurs ou les défaillances. Suivez toutes les instructions concernant les tâches ayant échoué, en particulier si le message « Échec de la tâche » s'affiche.
## Vérification des journaux de tentatives de tâche
Si l'analyse précédente des journaux d'étapes a révélé l'échec d'une ou de plusieurs tâches, examinez les journaux des tentatives de tâches correspondantes pour obtenir des informations plus détaillées sur les erreurs.
## Vérification des journaux démons Hadoop
Dans de rares cas, Hadoop lui-même peut échouer. Pour voir si c'est le cas, vous devez consulter les journaux Hadoop. Ils sont situés au niveau de `/var/log/hadoop/` sur chaque nœud.
Vous pouvez utiliser les JobTracker journaux pour associer une tentative de tâche infructueuse au nœud sur lequel elle a été exécutée. Une fois que vous connaissez le nœud rattaché à la tentative de tâche, vous pouvez vérifier l'état de l'instance EC2 qui héberge ce nœud pour voir s'il existe des problèmes tels que le manque de processeur ou de mémoire.
# Étape 4 : vérifier l'état du cluster et de l'instance Amazon EMR
Un cluster Amazon EMR est composé de nœuds qui s'exécutent sur des instances Amazon EC2. Si ces instances deviennent dépendantes des ressources (par exemple, si l'UC ou la mémoire est saturée), rencontrent des problèmes de connectivité réseau ou sont mises hors service, cela a un impact sur la vitesse de traitement du cluster.
Il existe jusqu'à trois types de nœuds dans un cluster :
+ **nœud principal** : gère le cluster. En cas de problème de performances, l'ensemble du cluster est attribué.
+ **nœuds principaux** : traitent les tâches map-reduce et gèrent le système de fichiers distribué Hadoop (HDFS). Si l'un de ces nœuds rencontre des problèmes de performances, cela peut ralentir les opérations du système de fichiers distribué Hadoop ainsi que le traitement MapReduce. Vous pouvez ajouter des nœuds principaux supplémentaires à un cluster pour améliorer les performances, mais vous ne pouvez pas supprimer les nœuds principaux. Pour de plus amples informations, veuillez consulter [Redimensionner manuellement un cluster Amazon EMR en cours d'exécution](emr-manage-resize.md).
+ **nœuds de tâches** : traitent les tâches map-reduce. Il s'agit de ressources de calcul uniquement. Ils ne stockent pas de données. Vous pouvez ajouter des nœuds de tâches à un cluster pour accélérer les performances, ou supprimer les nœuds de tâches qui sont inutiles. Pour de plus amples informations, veuillez consulter [Redimensionner manuellement un cluster Amazon EMR en cours d'exécution](emr-manage-resize.md).
Lorsque vous vérifiez l'état d'un cluster, vous devez prendre en compte les performances du cluster dans son ensemble, ainsi que les performances des instances individuelles. Vous pouvez utiliser plusieurs outils :
## Vérifiez l'état du cluster avec CloudWatch
Chaque cluster Amazon EMR communique des métriques à. CloudWatch Ces métriques fournissent des informations résumées sur les performances du cluster, telles que la charge totale, l'utilisation HDFS, les tâches en cours d'exécution, les tâches restantes, les blocs corrompus etc. L'examen CloudWatch des indicateurs vous donne une vue d'ensemble de ce qui se passe dans votre cluster et peut vous donner un aperçu de la cause du ralentissement du traitement. Outre l'analyse CloudWatch d'un problème de performance existant, vous pouvez définir des alarmes qui CloudWatch déclenchent une alerte en cas de problème de performance futur. Pour de plus amples informations, veuillez consulter [Surveillance des métriques Amazon EMR avec CloudWatch](UsingEMR_ViewingMetrics.md).
## Vérifier l'état de la tâche et l'état HDFS
Utilisez l'onglet **Application user interfaces (Interfaces utilisateur d'application)** sur la page des détails du cluster pour afficher les détails de l'application YARN. Pour certaines applications, vous pouvez explorer plus en détail et accéder aux journaux directement. Cette fonctionnalité est particulièrement utile pour les applications Spark. Pour de plus amples informations, veuillez consulter [Afficher l'historique des applications Amazon EMR](emr-cluster-application-history.md).
Hadoop offre une série d'interfaces Web que vous pouvez utiliser pour afficher des informations. Pour plus d'informations sur la façon d'accéder à ces interfaces Web, consultez [Affichage des interfaces Web hébergées sur des clusters Amazon EMR](emr-web-interfaces.md).
+ JobTracker — fournit des informations sur l'avancement de la tâche traitée par le cluster. Vous pouvez utiliser cette interface pour savoir quand un travail se bloque.
+ HDFS NameNode : fournit des informations sur le pourcentage d'utilisation du HDFS et l'espace disponible sur chaque nœud. Vous pouvez utiliser cette interface pour savoir quand HDFS devient dépendant des ressources et nécessite une capacité supplémentaire.
+ TaskTracker — fournit des informations sur les tâches de la tâche traitée par le cluster. Vous pouvez utiliser cette interface pour savoir quand une tâche se bloque.
## Vérification de l'état de l'instance avec Amazon EC2
La console Amazon EC2 permet également de rechercher des informations sur l'état des instances de votre cluster. Etant donné que chaque nœud du cluster s'exécute sur une instance EC2, vous pouvez utiliser les outils fournis par Amazon EC2 pour vérifier leur état. Pour de plus amples informations, veuillez consulter [Afficher les instances de cluster dans Amazon EC2](UsingEMR_Tagging.md).
# Étape 5 : Vérifiez les groupes suspendus
Un groupe d'instances est considéré « interrompu » quand il rencontre trop d'erreurs lorsqu'il tente de lancer des nœuds. Par exemple, si de nouveaux nœuds échouent à plusieurs reprises lors de l'exécution d'actions d'amorçage, au bout d'un certain temps, le groupe d'instances passera à l'état `SUSPENDED` plutôt que de tenter continuellement de mettre en service de nouveaux nœuds.
Le traitement d'un nœud peut échouer si :
+ Hadoop ou le cluster est endommagé et n'accepte pas de nouveau nœud dans le cluster
+ Une action d'amorçage échoue sur le nouveau nœud
+ Le nœud ne fonctionne pas correctement et sa vérification échoue avec Hadoop
Si l'état d'un groupe d'instances est `SUSPENDED` et si l'état du cluster est `WAITING`, vous pouvez ajouter une étape de cluster pour réinitialiser le nombre souhaité de nœuds principaux et de tâches. L'ajout de l'étape déclenche la reprise du traitement du cluster et repasse l'état du groupe d'instance à `RUNNING`.
Pour plus d'informations sur la façon de réinitialiser un cluster dont l'état est interrompu, consultez [État Interrompu](emr-manage-resize.md#emr-manage-resizeSuspended).
# Étape 6 : vérifier les paramètres de configuration du cluster Amazon EMR
Les paramètres de configuration spécifient les informations relatives à l'exécution d'un cluster, comme le nombre de nouvelles tentatives pour une tâche et la quantité de mémoire disponible pour le tri. Lorsque vous lancez un cluster à l'aide d'Amazon EMR, des paramètres spécifiques à Amazon EMR s'ajoutent aux paramètres de configuration Hadoop standard. Les paramètres de configuration sont stockés dans le nœud maître du cluster. Vous pouvez vérifier les paramètres de configuration pour vous assurer que votre cluster possède les ressources nécessaires pour s'exécuter de manière efficace.
Amazon EMR définit les paramètres de configuration par défaut Hadoop qu'il utilise pour lancer un cluster. Les valeurs sont basées sur l'AMI et le type d'instance que vous spécifiez pour le cluster. Vous pouvez modifier les valeurs par défaut des paramètres de configuration à l'aide d'une action d'amorçage ou en spécifiant les nouvelles valeurs dans les paramètres de l'exécution des tâches. Pour de plus amples informations, veuillez consulter [Créez des actions bootstrap pour installer des logiciels supplémentaires avec un cluster Amazon EMR](emr-plan-bootstrap.md). Pour déterminer si une action d'amorçage a modifié les paramètres de configuration, vérifiez les journaux des actions d'amorçage.
Amazon EMR enregistre les paramètres de Hadoop utilisés pour exécuter chaque tâche. Les données du journal sont stockées dans un fichier `job_job-id_conf.xml` nommé dans le `/mnt/var/log/hadoop/history/` répertoire du nœud principal, où elles *job-id* sont remplacées par l'identifiant de la tâche. Si vous avez activé l'archivage des journaux, ces données sont copiées sur Amazon S3 dans le `logs/date/jobflow-id/jobs` dossier, où *date* se trouvent la date d'exécution de la tâche et *jobflow-id* l'identifiant du cluster.
Les paramètres de configuration des tâches Hadoop suivants sont particulièrement utiles pour tenter de résoudre les problèmes de performances. Pour plus d'informations sur les paramètres de configuration Hadoop et leur impact sur le comportement de Hadoop, accédez à [http://hadoop.apache.org/docs/](http://hadoop.apache.org/docs/).
**Avertissement**
Paramétrer `dfs.replication` sur la valeur 1 avec les clusters de moins de quatre nœuds peut entraîner une perte de données HDFS en cas de panne d'un seul nœud. Nous vous recommandons d'utiliser un cluster comportant au moins quatre nœuds principaux pour les charges de travail de production.
Amazon EMR n'autorisera pas les clusters à mettre à l'échelle les nœuds principaux situés en dessous de `dfs.replication`. Par exemple, si `dfs.replication = 2`, le nombre minimum de nœuds principaux est 2.
Lorsque vous utilisez la mise à l'échelle gérée, autoscaling, ou que vous choisissez de redimensionner manuellement votre cluster, nous vous recommandons de définir `dfs.replication` sur une valeur supérieure ou égale à 2.
| Paramètre de configuration | Description |
| --- | --- |
| dfs.replication | Nombre de nœuds HDFS dans lesquels un seul bloc (par exemple, le bloc disque dur) est copié afin de produire un environnement de type RAID. Détermine le nombre de nœuds HDFS contenant une copie du bloc. |
| io.sort.mb | Quantité totale de mémoire disponible pour le tri. Cette valeur doit être 10x io.sort.factor. Ce paramètre peut aussi être utilisé pour calculer la mémoire totale utilisée par chaque nœud de tâche, par l'opération io.sort.mb multiplié par mapred.tasktracker.ap.tasks.maximum. |
| io.sort.spill.percent | Utilisé pendant le tri. Point auquel le disque commence à être utilisé car la mémoire allouée pour le tri est saturée. |
| mapred.child.java.opts | Obsolète. Utiliser mapred.map.child.java.opts et mapred.reduce.child.java.opts à la place. Les options Java sont TaskTracker utilisées lors du lancement d'une machine virtuelle Java dans laquelle une tâche doit être exécutée. « -Xmx » est un paramètre courant pour définir la taille maximale de la mémoire. |
| mapred.map.child.java.opts | Les options Java sont TaskTracker utilisées lors du lancement d'une machine virtuelle Java pour qu'une tâche cartographique soit exécutée dans celle-ci. « -Xmx » est un paramètre courant pour définir la taille maximale du tas de la mémoire. |
| mapred.map.tasks.speculative.execution | Détermine si les tentatives de tâches de mappage de la même tâche peuvent être lancées en parallèle. |
| mapred.reduce.tasks.speculative.execution | Détermine si les tentatives de tâches de réduction de la même tâche peuvent être lancées en parallèle. |
| mapred.map.max.Attempts | Nombre maximum de tentatives pour une tâche de mappage. Si toutes les tentatives échouent, la tâche de mappage est marquée comme ayant échoué. |
| mapred.reduce.child.java.opts | Les options Java sont TaskTracker utilisées lors du lancement d'une machine virtuelle Java pour qu'une tâche de réduction soit exécutée au sein de celle-ci. « -Xmx » est un paramètre courant pour définir la taille maximale du tas de la mémoire. |
| mapred.reduce.max.attempts | Nombre maximum de tentatives pour une tâche de réduction. Si toutes les tentatives échouent, la tâche de mappage est marquée comme ayant échoué. |
| mapred.reduce.slowstart.completed.maps | Quantité de tâches de mappage devant se terminer avant le lancement de tâches de réduction. Si vous n'attendez pas assez longtemps, vous risquez de provoquer des erreurs « trop d'échecs de recherche » dans les tentatives. |
| mapred.reuse.jvm.num.tasks | Une tâche s'exécute dans une même machine virtuelle Java. Spécifie le nombre de tâches pouvant réutiliser la même machine virtuelle Java. |
| mapred.tasktracker.map.tasks.maximum | Quantité maximale de tâches qui peuvent s'exécuter en parallèle par nœud de tâches au cours du mappage. |
| mapred.tasktracker.reduce.tasks.maximum | Quantité maximale de tâches qui peuvent s'exécuter en parallèle par nœud de tâches au cours de la réduction. |
Si vos tâches de cluster utilisent beaucoup de mémoire, vous pouvez améliorer les performances en utilisant un nombre inférieur de tâches par nœud principal et en réduisant la taille du tas de votre dispositif de suivi des travaux.
# Étape 7 : examiner les données d'entrée pour le cluster Amazon EMR
Observez vos données d'entrée. Sont-elles réparties de manière uniforme sur vos valeurs de clés ? Si vos données sont majoritairement réparties vers une ou seulement quelques valeurs clés, la charge de traitement peut être mappée à un petit nombre de nœuds alors que d'autres nœuds sont inutilisés. Cette distribution déséquilibrée du travail peut entraîner un ralentissement de traitement.
Voici un exemple d'ensemble de données déséquilibré : un cluster est exécuté pour trier des mots par ordre alphabétique, mais l'ensemble de données contient uniquement des mots commençant par la lettre « a ». Le nœud qui traite les valeurs commençant par « a » est surchargé, tandis que les nœuds qui traitent les mots commençant par d'autres lettres sont inactifs.
# Résoudre les problèmes courants liés à l'utilisation d'Amazon EMR AWS avec Lake Formation
Cette section vous guide à travers le processus de dépannage des problèmes courants lors de l'utilisation d'Amazon EMR avec AWS Lake Formation.
## L'accès au lac de données n'est pas autorisé
Vous devez explicitement opter pour le filtrage des données sur les clusters Amazon EMR avant de pouvoir analyser et traiter les données de votre lac de données. En cas d'échec de l'accès aux données, un message `Access is not allowed` générique apparaît dans la sortie des entrées de votre bloc-notes.
Pour activer et autoriser le filtrage des données sur Amazon EMR, consultez la section [Autoriser le filtrage des données sur Amazon EMR](https://docs.aws.amazon.com/lake-formation/latest/dg/getting-started-setup.html#emr-switch) du *Guide du développeur AWS Lake Formation * pour obtenir des instructions.
## Expiration de session
Le délai d'expiration de session pour les blocs-notes EMR et Zeppelin est contrôlé par le paramètre `Maximum CLI/API session duration` du rôle IAM pour Lake Formation. La valeur par défaut de ce paramètre est une heure. Lorsqu'un délai d'expiration de session se produit, le message suivant s'affiche dans la sortie de vos entrées de bloc-notes lorsque vous essayez d'exécuter des commandes Spark SQL.
```
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…
```
Pour valider votre session, actualisez la page. Vous serez invité à vous authentifier à nouveau à l'aide de votre IdP et serez redirigé vers le bloc-notes. Vous pouvez continuer à exécuter des requêtes après vous être authentifié à nouveau.
## Aucune autorisation pour l'utilisateur sur le tableau demandé
Si vous essayez d'accéder à une table à laquelle vous n'avez pas accès, l'exception suivante apparaîtra dans la sortie de vos entrées de bloc-notes lorsque vous tenterez d'exécuter des commandes SQL Spark.
```
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: …
```
Pour accéder au tableau, vous devez accorder l'accès à l'utilisateur en mettant à jour les autorisations rattachées à ce tableau dans Lake Formation.
## Interrogation de données entre comptes partagées avec Lake Formation
Lorsque vous utilisez Amazon EMR pour accéder aux données partagées avec vous depuis un autre compte, certaines bibliothèques Spark tentent d'appeler l'opération d'API `Glue:GetUserDefinedFunctions`. Les versions 1 et 2 des autorisations AWS RAM gérées ne prenant pas en charge cette action, le message d'erreur suivant s'affiche :
`"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"`
Pour résoudre cette erreur, l'administrateur du lac de données qui a créé le partage de ressources doit mettre à jour les autorisations AWS RAM gérées associées au partage de ressources. La version 3 des autorisations gérées AWS RAM permet aux nœuds principaux d'effectuer l'action `glue:GetUserDefinedFunctions`.
Si vous créez un nouveau partage de ressources, Lake Formation applique la dernière version de l'autorisation AWS RAM gérée par défaut, et aucune action n'est requise de votre part. Pour activer l'accès aux données entre comptes pour les partages de ressources existants, vous devez mettre à jour les autorisations AWS RAM gérées vers la version 3.
Vous pouvez consulter les AWS RAM autorisations attribuées aux ressources partagées avec vous dans AWS RAM. Les autorisations suivantes sont incluses dans la version 3 :
```
Databases
AWSRAMPermissionGlueDatabaseReadWriteForCatalog
AWSRAMPermissionGlueDatabaseReadWrite
Tables
AWSRAMPermissionGlueTableReadWriteForCatalog
AWSRAMPermissionGlueTableReadWriteForDatabase
AllTables
AWSRAMPermissionGlueAllTablesReadWriteForCatalog
AWSRAMPermissionGlueAllTablesReadWriteForDatabase
```
**Pour mettre à jour la version des autorisations AWS RAM gérées des partages de ressources existants**
Vous (administrateur du lac de données) pouvez soit [mettre à jour les autorisations AWS RAM gérées vers une version plus récente](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-update-permissions.html) en suivant les instructions du *guide de AWS RAM l'utilisateur*, soit révoquer toutes les autorisations existantes pour le type de ressource et les réaccorder. Si vous révoquez les autorisations, le partage AWS RAM de AWS RAM ressources associé au type de ressource est supprimé. Lorsque vous réaccordez des autorisations, AWS RAM de nouveaux partages de ressources sont créés en y joignant la dernière version des autorisations AWS RAM gérées.
## Insertion, création et modification de tableaux
L'insertion, la création ou la modification de tableaux dans des bases de données protégées par des politiques Lake Formation ne sont pas prises en charge. Si vous effectuez ces opérations, l'exception suivante apparaîtra dans la sortie de vos entrées de bloc-notes lorsque vous tenterez d'exécuter des commandes Spark SQL :
```
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: …
```
Pour plus d'informations, consultez [Limitations de l'intégration d'Amazon EMR](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-lf-scope.html#emr-lf-limitations) avec. AWS Lake Formation