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