Pourquoi la mise à l'échelle de mon cluster EMR n'est-elle pas réalisée alors que la mise à l'échelle gérée est activée ou que les métriques de redimensionnement ont été atteintes ?

Lecture de 5 minute(s)
0

J'ai activé la mise à l'échelle gérée ou les métriques de redimensionnement ont été respectées sur mon cluster Amazon EMR, mais le cluster ne se met pas à l'échelle.

Solution

Voici les raisons courantes pour lesquelles votre cluster EMR risque de ne pas se mettre à l'échelle même si la mise à l'échelle gérée est activée ou si les métriques de redimensionnement sont respectées :

Les seuils définis dans les métriques Amazon CloudWatch pour la mise à l'échelle ne sont pas atteints

La mise à l'échelle automatique dépend des métriques de CloudWatch. Si les seuils de métriques correspondants ne sont pas atteints pour une augmentation ou une diminution, la mise à l'échelle n'a pas lieu.

Consultez les métriques Amazon EMR dans Amazon CloudWatch pour vérifier que les métriques définies dans vos règles de mise à l'échelle sont renseignées. Par exemple, vérifiez que les valeurs ContainerPendingRatio, YARNMemoryAvailablePercentage, etc., sont renseignées conformément à vos règles de mise à l'échelle.

Les raisons courantes pour lesquelles les métriques Amazon EMR ne sont pas renseignées comme prévu dans CloudWatch sont les suivantes :

  • Le fichier /etc/hadoop/conf/hadoop-metrics2.properties n'existe pas ou est endommagé. Par exemple, le fichier a peut-être été remplacé par une action d'amorçage personnalisée.
  • Il peut y avoir des problèmes avec des composants liés aux métriques tels que Hadoop, YARN, etc. Consultez les journaux d'application correspondants pour vérifier la présence d'erreurs.
  • Pour la mise à l'échelle gérée, vérifiez que le démon MetricsCollector est en cours d'exécution en exécutant la commande sudo systemctl status MetricsCollector sur le nœud principal.

Vous utilisez des applications qui ne sont pas basées sur YARN

Les applications telles que Presto qui ne sont pas basées sur YARN utilisent des méthodes de mise à l'échelle basées sur des métriques générées par YARN. Ainsi, les clusters ne se mettront pas à l'échelle, même si l'utilisation des requêtes Presto est élevée. Si vous utilisez des applications qui ne sont pas basées sur YARN, utilisez la mise à l'échelle manuelle. Par exemple, vous pouvez configurer l'API de redimensionnement Amazon EMR pour utiliser des métriques Presto personnalisées.

Les groupes d'instances principaux ou de tâches sont en état de suspension ou d'arrêt

Les groupes d'instances principaux ou de tâches suspendus ou arrêtés sont bloqués lors du redimensionnement ou de la mise à l'échelle. Pour les étapes de résolution des problèmes, consultez la section État suspendu.

Les reconfigurations entraînent l'arrêt des groupes d'instances. Pour plus d'informations, consultez Résolution des problèmes de reconfiguration des groupes d'instances.

Des problèmes d'application HDFS dans EMR entraînent des problèmes lors de la mise à l'échelle des nœuds principaux

Il est recommandé de maintenir les nœuds principaux fixes si les conditions suivantes sont réunies :

  • Les données sont stockées dans des compartiments Amazon Simple Storage Service (Amazon S3), et
  • L'utilisation du HDFS est minimale.

Mettez à l'échelle les nœuds de tâches uniquement pour éviter les problèmes liés au HDFS.

La mise à l'échelle des nœuds principaux prend plus de temps que celle des nœuds de tâches. Cela est dû au fait que les nœuds principaux disposent d'un service supplémentaire (Datanode) utilisé pour stocker les données HDFS. La mise hors service des données HDFS prend du temps. Si votre cas d'utilisation nécessite la mise à l'échelle des nœuds principaux et que la mise à l'échelle est bloquée, il se peut que la mise hors service de HDFS pose un problème. Vérifiez les éléments suivants pour résoudre les problèmes de mise à l'échelle bloquée en raison de la mise hors service de HDFS :

  • Vérifiez l'état de santé des services HDFS (Namenode et Datanode).
  • Vérifiez s'il existe des blocs manquants, endommagés ou sous-répliqués en exécutant la commande hdfs dfsadmin -report.
  • Vérifiez si certains nœuds principaux ne sont pas défectueux en raison de problèmes de disque, de mémoire ou de processeur.
  • Déterminez si le facteur de réplication HDFS est défini sur un nombre supérieur, par exemple 3 ou 2. Si le facteur de réplication est défini sur 3 ou 2 et que vous essayez de réduire les nœuds principaux à 1, la mise à l'échelle est bloquée. Cela est dû au fait que le nombre minimal de réplicas doit être conservé.

La capacité demandée n'est pas disponible dans Amazon EMR

Si la capacité Amazon Elastic Compute Cloud (Amazon EC2) demandée n'est pas disponible dans Amazon EMR, la mise à l'échelle échoue après le délai imparti. Effectuez un redimensionnement manuel si la mise à l'échelle est bloquée pendant une longue période et que vous recevez des erreurs de capacité insuffisante lors des événements AWS CloudTrail. On considère que 2 à 3 heures représentent une longue période de blocage de la mise à l'échelle.


Informations connexes

Utilisation de la mise à l'échelle automatique avec une stratégie personnalisée pour les groupes d'instances

Redimensionnement manuel d'un cluster en cours d'exécution

Utilisation de la mise à l'échelle gérée dans Amazon EMR

Les 9 meilleurs conseils de réglage pour améliorer les performances de PrestoDB sur Amazon EMR

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a un an