

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.

# Codes d'erreur contenant ErrorDetail des informations dans Amazon EMR
<a name="emr-troubleshoot-error-errordetail"></a>

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
<a name="emr-troubleshoot-error-errordetail-bootstrap"></a>

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
<a name="BOOTSTRAP_FAILURE_PRIMARY_WITH_NON_ZERO_CODE"></a>

## Présentation de
<a name="BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_WITH_NON_ZERO_CODE_overview"></a>

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
<a name="BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_WITH_NON_ZERO_CODE_resolution"></a>

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
<a name="BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_WITH_NON_ZERO_CODE_stc"></a>

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
<a name="BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY"></a>

## Présentation de
<a name="BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY_overview"></a>

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
<a name="BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY_resolution"></a>

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
<a name="BOOTSTRAP_FAILURE_BA_DOWNLOAD_FAILED_PRIMARY_stc"></a>

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
<a name="BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY"></a>

## Présentation de
<a name="BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY_overview"></a>

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
<a name="BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY_resolution"></a>

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
<a name="BOOTSTRAP_FAILURE_FILE_NOT_FOUND_PRIMARY_stc"></a>

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
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY"></a>

## Présentation de
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY_overview"></a>

 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
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY_resolution"></a>

 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
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_PRIMARY_stc"></a>

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
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER"></a>

## Présentation de
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER_overview"></a>

 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
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER_resolution"></a>

 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
<a name="BOOTSTRAP_FAILURE_INSUFFICIENT_DISK_SPACE_WORKER_stc"></a>

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
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY"></a>

## Présentation de
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY_overview"></a>

 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
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY_resolution"></a>

 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
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_PRIMARY_stc"></a>

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
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER"></a>

## Présentation de
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER_overview"></a>

 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
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER_resolution"></a>

 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
<a name="BOOTSTRAP_FAILURE_HIVE_METASTORE_CONNECTION_ERROR_WORKER_stc"></a>

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
<a name="emr-troubleshoot-error-errordetail-internal"></a>

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
<a name="INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ"></a>

## Présentation de
<a name="INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ_overview"></a>

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
<a name="INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ_resolution"></a>

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
<a name="INTERNAL_ERROR_EC2_INSUFFICIENT_CAPACITY_AZ_stc"></a>

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
<a name="INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY"></a>

## Présentation de
<a name="INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY_overview"></a>

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
<a name="INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY_resolution"></a>

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
<a name="INTERNAL_ERROR_SPOT_PRICE_INCREASE_PRIMARY_stc"></a>

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
<a name="INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY"></a>

## Présentation de
<a name="INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY_overview"></a>

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
<a name="INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY_resolution"></a>

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
<a name="INTERNAL_ERROR_SPOT_NO_CAPACITY_PRIMARY_stc"></a>

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
<a name="emr-troubleshoot-error-errordetail-validation"></a>

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
<a name="VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC"></a>

## Présentation de
<a name="VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC_overview"></a>

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
<a name="VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC_resolution"></a>

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
<a name="VALIDATION_ERROR_SUBNET_NOT_FROM_ONE_VPC_stc"></a>

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
<a name="VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC"></a>

## Présentation de
<a name="VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC_overview"></a>

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
<a name="VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC_resolution"></a>

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
<a name="VALIDATION_ERROR_SECURITY_GROUP_NOT_FROM_ONE_VPC_stc"></a>

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
<a name="VALIDATION_ERROR_INVALID_SSH_KEY_NAME"></a>

## Présentation de
<a name="VALIDATION_ERROR_INVALID_SSH_KEY_NAME_overview"></a>

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
<a name="VALIDATION_ERROR_INVALID_SSH_KEY_NAME_resolution"></a>

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
<a name="VALIDATION_ERROR_INVALID_SSH_KEY_NAME_stc"></a>

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
<a name="VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED"></a>

## Présentation de
<a name="VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED_overview"></a>

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
<a name="VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED_resolution"></a>

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
<a name="VALIDATION_ERROR_INSTANCE_TYPE_NOT_SUPPORTED_stc"></a>

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).