Erreurs VPC lors des opérations du cluster Amazon EMR - Amazon EMR
Configuration de sous-réseau non valideJeu d'options DHCP manquantErreurs d'autorisationsErreurs qui se traduisent par START_FAILEDCluster Terminated with errors et NameNode ne parvient pas à démarrer

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 VPC lors des opérations du cluster Amazon EMR

Les erreurs suivantes sont communes à la configuration de VPC dans Amazon EMR.

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.

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.

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.

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 surTERMINATE_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 parvient pas à démarrer

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.<init>(NameNode.java:765)
           at
      org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(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 selon lequel une EC2 instance peut avoir plusieurs ensembles de noms de domaine complets lors du lancement de clusters EMR dans un VPC, qui utilise à la fois un serveur DNS fourni et un AWS 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 EC2 instance est lancée dans l'un des sous-réseaux du VPC.