E-MapReduce:FAQ

En quoi consiste un redémarrage avec état d'un cluster ?

Un redémarrage avec état d'un cluster comprend un redémarrage du ResourceManager et un redémarrage du NodeManager. Le ResourceManager conserve les informations de base et l'état des applications. Le NodeManager maintient les informations et l'état des conteneurs en cours d'exécution. Le ResourceManager et le NodeManager synchronisent en permanence leur propre état vers des systèmes de stockage externes tels que ZooKeeper, LevelDB et Hadoop Distributed File System (HDFS). L'état du ResourceManager et du NodeManager peut être automatiquement rechargé et récupéré après leur redémarrage. Cela garantit que l'état des applications et des conteneurs peut être automatiquement restauré après la mise à niveau ou le redémarrage du cluster. Dans la plupart des cas, la mise à niveau ou le redémarrage d'un cluster est imperceptible pour les applications et les conteneurs.

Comment activer la haute disponibilité (HA) du ResourceManager ?

Comment configurer une mise à jour à chaud ?

1. Configurez les paramètres clés.

   Vous pouvez consulter ou configurer les paramètres relatifs à la mise à jour à chaud dans l'onglet Configure de la page du service YARN d'un cluster, depuis la console EMR. Le tableau suivant décrit ces paramètres.

   Parameter	Description	Recommended value
   yarn.scheduler.configuration.store.class	Le type du magasin de données. Si vous définissez ce paramètre sur fs, un système de fichiers est utilisé comme magasin de données.	fs
   yarn.scheduler.configuration.max.version	Le nombre maximal de fichiers de configuration pouvant être stockés dans le système de fichiers. Les fichiers de configuration excédentaires sont automatiquement supprimés si le nombre de fichiers dépasse la valeur de ce paramètre.	100
   yarn.scheduler.configuration.fs.path	Le chemin de stockage du fichier capacity-scheduler.xml. Si vous ne configurez pas ce paramètre, un chemin de stockage est automatiquement créé. Si aucun préfixe n'est spécifié, le chemin relatif du système de fichiers par défaut est utilisé comme chemin de stockage.	/yarn/<Nom du cluster>/scheduler/conf Important Remplacez <Nom du cluster> par un nom de cluster spécifique. Plusieurs clusters pour lesquels le service YARN est déployé peuvent utiliser le même stockage distribué.

2. Consultez les configurations du fichier capacity-scheduler.xml.

   • Méthode 1 (API RESTful) : Accédez à une URL au format suivant : http://<rm-address>/ws/v1/cluster/scheduler-conf.

   • Méthode 2 (HDFS) : Accédez au chemin de configuration ${yarn.scheduler.configuration.fs.path}/capacity-scheduler.xml.<timestamp> pour consulter les configurations du fichier capacity-scheduler.xml. <timestamp> indique l'heure de génération du fichier capacity-scheduler.xml. Le fichier capacity-scheduler.xml dont la valeur d'horodatage est la plus récente correspond au dernier fichier de configuration.

3. Mettez à jour les configurations.

   Par exemple, vous pouvez modifier le paramètre yarn.scheduler.capacity.maximum-am-resource-percent et supprimer le paramètre yarn.scheduler.capacity.xxx. Pour supprimer un paramètre, il suffit de retirer le champ de valeur associé.

   curl -X PUT -H "Content-type: application/json" 'http://<rm-address>/ws/v1/cluster/scheduler-conf' -d '
   {
     "global-updates": [
       {
         "entry": [{
           "key":"yarn.scheduler.capacity.maximum-am-resource-percent",
           "value":"0.2"
         },{
           "key":"yarn.scheduler.capacity.xxx"
         }]
       }
     ]
   }'

Comment gérer une répartition inégale des ressources entre les applications au sein d'une file d'attente ?

Consulter l'utilisation des ressources d'une file d'attente

Consultez Used Capacity sur l'interface YARN. Cette valeur indique le pourcentage de ressources actuellement utilisées par une file d'attente, calculé sur la base de la valeur la plus élevée entre l'utilisation de la mémoire et celle des vCore.

1. Accédez à l'interface YARN. Pour plus de détails, consultez Accéder aux interfaces web des composants open source.

2. Sur la page All Applications, cliquez sur l'ID de la tâche cible.

3. Cliquez sur la file d'attente dans la ligne Queue.

   La section Application Queues affiche l'utilisation des ressources de la file d'attente.

   Les détails de la file d'attente incluent des paramètres tels que Queue State, Used Capacity, Configured Capacity, Configured Max Capacity, Effective Capacity, Absolute Used Capacity et Used Resources. Le paramètre Used Capacity indique l'utilisation actuelle des ressources, par exemple <memory:896, vCores:1> (10.9%).

Accumulation des fichiers journaux .out de YARN

• Cause : Certaines bibliothèques dépendantes de Hadoop utilisent les API Java Logging, contournant ainsi les paramètres de rotation de log4j. La sortie d'erreur standard (stderr) de ces daemons est redirigée vers des fichiers .out. Sans nettoyage automatique, ces fichiers s'accumulent et peuvent saturer le disque de données.

• Solution : Utilisez les commandes head et tail avec les horodatages des journaux pour vérifier si ces journaux issus des API Java consomment trop d'espace disque. Ces journaux sont généralement au niveau INFO et n'affectent pas le fonctionnement des composants. Pour éviter la saturation du disque, vous pouvez désactiver cette journalisation.

  Par exemple, pour optimiser le Timeline Server en désactivant la journalisation de la bibliothèque dépendante Jersey, procédez comme suit :

  1. Exécutez la commande suivante pour surveiller les fichiers journaux .out associés à hadoop-timelineserver- dans le chemin des journaux YARN. Le chemin des journaux est /var/log/emr/yarn/ pour un cluster DataLake et /mnt/disk1/log/hadoop-yarn pour un cluster Hadoop.

     tail /var/log/emr/yarn/*-hadoop-timelineserver-*.out

     La sortie du journal affiche des enregistrements provenant du composant com.sun.jersey.

     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
                             com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response
     xxx                     com.sun.jersey.server.wadl.generators.AbstractWadlGeneratorGrammarGenerator attachTypes
     INFO: Couldn't find grammar element for class javax.ws.rs.core.Response

  2. Pour désactiver les journaux de niveau INFO de la bibliothèque Jersey, créez un fichier de configuration. Sur le nœud EMR qui héberge le Timeline Server, exécutez la commande suivante en tant qu'utilisateur root pour créer le fichier.

     sudo su root -c "echo 'com.sun.jersey.level = OFF' > $HADOOP_CONF_DIR/off-logging.properties"

  3. Dans la console EMR, accédez à l'onglet Configure du service YARN. Recherchez le paramètre YARN_TIMELINESERVER_OPTS (ou yarn_timelineserver_opts pour un cluster Hadoop) et ajoutez -Djava.util.logging.config.file=off-logging.properties à sa valeur.

  4. Enregistrez la configuration et redémarrez le Timeline Server pour prendre en compte la modification. Surveillez le service. Si le Timeline Server démarre correctement et que son journal .out n'affiche plus de messages provenant de com.sun.jersey, vous avez réussi à désactiver la journalisation.

Comment vérifier que le service ResourceManager fonctionne correctement ?

Comment obtenir le statut d'une application ?

Dépannage des applications

1. Vérifiez l'état de l'application sur sa page de détails ou via l'API REST correspondante.

   • État de l'application introuvable. Causes possibles :

     • Le processus client s'est terminé avant la soumission de l'application à YARN. Cela peut indiquer un problème avec un composant côté client, tel que BRS ou flowagent. Vérifiez les journaux de soumission du client.

     • Le client ne parvient pas à se connecter au ResourceManager YARN. Vérifiez que l'adresse du ResourceManager est correcte et qu'il n'y a aucun problème réseau. Un problème réseau peut générer l'erreur suivante sur le client : com.aliyun.emr.flow.agent.common.exceptions.EmrFlowException: ###[E40001,RESOURCE_MANAGER]: Failed to access to resource manager, cause: The stream is closed.

   • NEW_SAVING : Dans cet état, les informations de l'application sont en cours d'écriture dans le magasin d'état ZooKeeper. Si l'application reste dans cet état, les causes possibles sont :

     • Un problème avec ZooKeeper. Vérifiez que le service ZooKeeper fonctionne correctement.

     • Un problème de lecture ou d'écriture des données dans ZooKeeper. Pour la solution, consultez Que faire si le ResourceManager est à l'état Standby et ne bascule pas automatiquement vers l'état Active ?

   • SUBMITTED : Cet état est rare. Une cause possible est un blocage du Capacity Scheduler dû à une contention de verrous provoquée par trop de requêtes de mise à jour des nœuds. Cela se produit généralement dans les clusters à grande échelle et nécessite une optimisation des processus. Pour un cas connexe, consultez YARN-9618.

   • ACCEPTED : Vérifiez les diagnostics. Agissez en fonction du message fourni.

     • Message d'erreur : "Queue's AM resource limit exceeded."

       • Cause possible : La somme des ressources ApplicationMaster (AM) utilisées et des ressources AM demandées dépasse la limite de la file d'attente pour les ressources AM. La condition vérifiée dans l'interface utilisateur est : ${Used Application Master Resources} + ${AM Resource Request} < ${Max Application Master Resources}.

       • Solution : Augmentez la limite de ressources AM pour la file d'attente. Par exemple, définissez le paramètre yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent sur 0,5.

     • Message d'erreur : "User's AM resource limit exceeded."

       • Cause possible : La somme des ressources AM utilisées par l'utilisateur et des ressources AM demandées dépasse la limite de ressources AM par utilisateur pour la file d'attente.

       • Solution : Augmentez le ratio de limite utilisateur. Modifiez les valeurs des paramètres yarn.scheduler.capacity.<queue-path>.user-limit-factor et yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent.

     • Message d'erreur : "AM container is launched, waiting for AM container to Register with RM."

       • Cause possible : L'ApplicationMaster a démarré, mais son initialisation interne n'est pas terminée, par exemple en raison d'un délai d'expiration de la connexion ZooKeeper.

       • Solution : Examinez les journaux de l'ApplicationMaster.

     • Message d'erreur : "Application is Activated, waiting for resources to be assigned for AM."

       Passez à l'étape Étape 3 pour déterminer pourquoi la demande de ressources de l'ApplicationMaster n'est pas satisfaite.

   • RUNNING : Passez à l'étape Étape 2 pour vérifier si les demandes de ressources des conteneurs ont été satisfaites.

   • FAILED : Vérifiez les diagnostics. Agissez en fonction du message fourni.

     • Message d'erreur : "Maximum system application limit reached,cannot accept submission of application"

       • Cause possible : Le nombre total d'applications en cours d'exécution dans le cluster a dépassé la limite configurée (paramètre : yarn.scheduler.capacity.maximum-applications, valeur par défaut : 10 000).

       • Solution : Vérifiez les métriques JMX pour confirmer que chaque file d'attente contient le nombre attendu d'applications en cours d'exécution. Identifiez et corrigez les applications provoquant des soumissions répétées excessives. Si toutes les applications sont légitimes, envisagez d'augmenter cette valeur de configuration en fonction de la charge de travail du cluster.

     • Message d'erreur : "Application XXX submitted by user YYY to unknown queue: ZZZ"

       • Cause possible : L'application a été soumise à une file d'attente inexistante.

       • Solution : Soumettez l'application à une file d'attente feuille existante.

     • Message d'erreur : "Application XXX submitted by user YYY to non-leaf queue: ZZZ"

       • Cause possible : L'application a été soumise à une file d'attente parente.

       • Solution : Soumettez l'application à une file d'attente feuille existante.

     • Message d'erreur : "Queue XXX is STOPPED. Cannot accept submission of application: YYY"

       • Cause possible : L'application a été soumise à une file d'attente à l'état STOPPED ou DRAINING. Une file d'attente dans l'un de ces états est hors ligne ou en cours de déclassement.

       • Solution : Soumettez l'application à une file d'attente à l'état RUNNING.

     • Message d'erreur : "Queue XXX already has YYY applications, cannot accept submission of application: ZZZ"

       • Cause possible : Le nombre d'applications dans la file d'attente a atteint sa limite.

       • Solution :

         1. Vérifiez si des applications problématiques sont soumises de manière répétée à la file d'attente.

         2. Ajustez la configuration : yarn.scheduler.capacity.<queue-path>.maximum-applications.

     • Message d'erreur : "Queue XXX already has YYY applications from user ZZZ cannot accept submission of application: AAA"

       • Cause possible : Le nombre d'applications de l'utilisateur a atteint sa limite.

       • Solution :

         1. Vérifiez si l'utilisateur soumet de manière répétée une application problématique.

         2. Ajustez les paramètres de configuration suivants : yarn.scheduler.capacity.<queue-path>.maximum-applications, yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent et yarn.scheduler.capacity.<queue-path>.user-limit-factor.

2. Vérifiez si l'allocation des ressources YARN est incomplète.

   1. Dans la liste des applications, cliquez sur un ID d'application pour accéder à sa page de détails.

   2. Dans la liste en bas de la page, cliquez sur l'AM-ID pour ouvrir la page App Attempt.

   3. Vérifiez la liste Total Outstanding Resource Requests pour identifier les ressources en attente. Vous pouvez également les rechercher via l'API REST PendingRequests.

      • Aucune ressource en attente : YARN a terminé l'allocation. Quittez cette vérification et examinez l'ApplicationMaster. En l'absence de ressources en attente, la section Total Outstanding Resource Requests affiche 0 pour toutes les métriques (par exemple, memory:0, vCores:0), et le tableau des demandes de ressources ci-dessous est vide. Ce tableau comprend des colonnes telles que Priority, ResourceName, Capability et NumContainers.

      • Des ressources sont en attente : L'allocation des ressources YARN n'est pas terminée. Passez à l'étape suivante.

3. Vérifiez les limites de ressources.

   Vérifiez les ressources du cluster ou de la file d'attente. Consultez les informations sur les ressources, telles que Effective Max Resource et Used Resources.

   1. Vérifiez si les ressources du cluster, de la file d'attente ou de sa file d'attente parente sont épuisées.

   2. Vérifiez si une dimension de ressource dans la file d'attente feuille approche ou a atteint sa limite.

   3. Lorsque l'utilisation des ressources du cluster est élevée (par exemple, supérieure à 85 %), la vitesse d'allocation des applications peut diminuer. Cela peut se produire parce que la plupart des nœuds ne disposent plus de ressources disponibles. Lorsqu'un nœud ne peut pas satisfaire une demande de ressources, le planificateur peut réserver la demande. Un grand nombre de réservations peut ralentir le processus d'allocation. Ce problème peut également être causé par un déséquilibre entre les ressources mémoire et CPU. Par exemple, certains nœuds peuvent avoir de la mémoire disponible mais pas de CPU, tandis que d'autres ont du CPU disponible mais pas de mémoire.

4. Vérifiez si les conteneurs échouent à démarrer même après l'allocation de leurs ressources. La page App Attempt de l'interface web YARN affiche le nombre de conteneurs alloués. Observez ce nombre pendant une courte période pour voir s'il change. Si un conteneur ne démarre pas, examinez les journaux correspondants du NodeManager ou du conteneur pour enquêter sur l'échec.

5. Modifiez dynamiquement le niveau de journalisation. Accédez à la page Log Level de l'interface web YARN (http://RM_IP:8088/logLevel). Dans le champ Class Name, saisissez le nom de la classe cible (par exemple, une classe du package org.apache.hadoop.yarn.server.resourcemanager.scheduler, telle que org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity). Dans la liste déroulante Level, sélectionnez DEBUG, puis cliquez sur Set Log Level. Cette action définit dynamiquement le niveau de journalisation de la classe spécifiée sur DEBUG.

   Important

   Activez la journalisation DEBUG uniquement lors de la reproduction du problème. Une durée inférieure à une minute suffit généralement, car les journaux sont générés très rapidement. Après avoir capturé les journaux nécessaires, rétablissez le niveau de journalisation sur INFO.

Paramètres pour les ressources maximales disponibles

Les modifications de configuration YARN ne prennent pas effet

• Causes possibles

  • Pour les configurations qui ne prennent pas en charge les mises à jour à chaud, le composant associé n'a pas été redémarré.

  • Pour les configurations qui prennent en charge les mises à jour à chaud, l'action requise n'a pas été effectuée.

• Solution : Après avoir modifié une configuration, effectuez les actions de suivi appropriées.

  Fichier de configuration	Type	Actions
  capacity-scheduler.xml fair-scheduler.xml	Configuration du planificateur	Exécutez l'opération refresh_queues sur le ResourceManager.
  yarn-env.sh yarn-site.xml mapred-env.sh mapred-site.xml	Configuration d'exécution des composants YARN	Redémarrez le composant associé. Par exemple : Si vous modifiez un paramètre tel que YARN_RESOURCEMANAGER_HEAPSIZE dans le fichier yarn-env.sh ou yarn.resourcemanager.nodes.exclude-path dans le fichier yarn-site.xml, vous devez redémarrer le ResourceManager. Si vous modifiez un paramètre tel que YARN_NODEMANAGER_HEAPSIZE dans le fichier yarn-env.sh ou yarn.nodemanager.log-dirs dans le fichier yarn-site.xml, vous devez redémarrer le NodeManager. Si vous modifiez un paramètre tel que MAPRED_HISTORYSERVER_OPTS dans le fichier mapred-env.sh ou mapreduce.jobhistory.http.policys dans le fichier mapred-site.xml, vous devez redémarrer MRHistoryServer.

Que faire si le message d'erreur suivant est signalé pour une exception survenue sur un client d'application : Exception while invoking getClusterNodes of class ApplicationClientProtocolPBClientImpl over rm2 after 1 fail over attempts. Trying to fail over immediately ?

• Description du problème : Impossible d'accéder au ResourceManager actif. Les journaux du ResourceManager contiennent les informations d'exception suivantes : WARN org.apache.hadoop.ipc.Server: Incorrect header or version mismatch from 10.33..:53144 got version 6 expected version 9.

• Cause : Une version ancienne de Hadoop est utilisée. La version de l'appel de procédure distante (RPC) utilisée par le client d'application est incompatible avec la version de Hadoop.

• Solution : Utilisez une version de Hadoop compatible avec le client d'application de la version RPC.

Que faire si ResourceManager ne parvient pas à passer automatiquement de l'état Standby à l'état Active ?

Résolution des erreurs OOM de ResourceManager

Pourquoi la localisation échoue-t-elle lorsqu'un nœud commence à exécuter une tâche, et pourquoi les journaux de tâche ne peuvent-ils pas être collectés ou supprimés ?

• Description du problème : les journaux du NodeManager contiennent les informations d'exception suivantes : java.io.IOException: Couldn't create proxy provider class org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider.

• Cause : les configurations HDFS sont incorrectes.

• Solution :

  1. Les informations d'exception sont encapsulées et ne constituent pas la cause première du problème. Pour identifier la cause première, vous devez examiner les journaux au niveau debug.

     • Dans l'interface CLI d'un client Hadoop, vous pouvez exécuter une commande telle que hadoop fs -ls / pour accéder à Hadoop. Exécutez ensuite la commande suivante pour activer le débogage :

       export HADOOP_LOGLEVEL=DEBUG

     • Dans un environnement d'exécution avec la configuration Log4j, ajoutez log4j.logger.org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider=DEBUG à la fin de la configuration Log4j.

  2. L'exemple illustré dans la figure suivante montre que la cause première du problème réside dans la modification des configurations des NameServices par un utilisateur. L'utilisateur a remplacé emr-cluster par hadoop-emr-cluster. Toutefois, le nouveau nœud a utilisé les configurations d'origine des NameServices après une mise à l'échelle horizontale.

  3. Sous l'onglet Configure de la page du service HDFS d'un cluster dans la console EMR, vérifiez que les paramètres sont correctement configurés.

Comment gérer une exception de localisation des ressources ?

• Description du problème :

  • Le conteneur AM utilisé pour traiter les tâches ne démarre pas et le message d'erreur suivant s'affiche :

    Application application_1412960082388_788293 failed 2 times due to AM Container for appattempt_1412960082388_788293_000002 exited with exitCode: -1000 due to: EPERM: Operation not permitted. The exception information is the diagnostic information about the failed job.

  • Une erreur est signalée lors de la décompression d'un package de ressources d'application après son téléchargement pour la localisation des ressources. Vous pouvez consulter les journaux suivants du NodeManager :

    INFO org.apache.hadoop.yarn.server.nodemanager.containermanager.localizer.ResourceLocalizationService: Failed to download rsrc { { hdfs://hadoopnnvip.cm6:9000/user/heyuan.lhy/apv/small_apv_20141128.tar.gz, 1417144849604, ARCHIVE, null },pending,[(container_1412960082388_788293_01_000001)],14170282104675332,DOWNLOADING}
    EPERM: Operation not permitted
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmodImpl(Native Method)
            at org.apache.hadoop.io.nativeio.NativeIO$POSIX.chmod(NativeIO.java:226)
            at org.apache.hadoop.fs.RawLocalFileSystem.setPermission(RawLocalFileSystem.java:629)
            at org.apache.hadoop.fs.DelegateToFileSystem.setPermission(DelegateToFileSystem.java:186)
            at org.apache.hadoop.fs.FilterFs.setPermission(FilterFs.java:235)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:949)
            at org.apache.hadoop.fs.FileContext$10.next(FileContext.java:945)
            at org.apache.hadoop.fs.FSLinkResolver.resolve(FSLinkResolver.java:90)
            at org.apache.hadoop.fs.FileContext.setPermission(FileContext.java:945)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:398)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.changePermissions(FSDownload.java:412)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:352)
            at org.apache.hadoop.yarn.util.FSDownload.call(FSDownload.java:57)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
            at java.util.concurrent.FutureTask.run(FutureTask.java:262)
            at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
            at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
            at java.lang.Thread.run(Thread.java:744)

• Cause : le package de ressources de l'application contient des liens symboliques, ce qui entraîne l'exception de localisation des ressources.

• Solution : supprimez les liens symboliques contenus dans le package de ressources de l'application.

Que faire si le message d'erreur « No space left on device » s'affiche et qu'un conteneur ne parvient pas à démarrer ou à s'exécuter ?

Les noms de domaine ne sont pas résolus dans NodeManager ou pendant l'exécution des tâches. Que faire ?

• Description du problème : le message d'erreur suivant s'affiche : java.net.UnknownHostException: Invalid host name: local host is: (unknown).

• Causes possibles et solutions :

  • Vérifiez que le serveur DNS (Domain Name System) est correctement configuré.

    Exécutez la commande suivante pour vérifier la configuration du serveur DNS :

    cat /etc/resolv.conf

  • Vérifiez que les règles requises sont configurées pour le port 53 du pare-feu.

    Si les règles requises sont configurées, désactivez le pare-feu.

  • Vérifiez si le service NSCD (Name Service Cache Daemon) est activé pour le serveur DNS.

    Exécutez la commande suivante pour vérifier l'état du service NSCD :

    systemctl status nscd

    Si le service NSCD est activé pour le serveur DNS, exécutez la commande suivante pour désactiver le service NSCD :

    systemctl stop nscd

Gestion des erreurs OOM de NodeManager

Échec du démarrage de NodeManager : répertoire cgroup manquant

• Message d'erreur : ResourceHandlerException: Unexpected: Cannot create yarn cgroup Subsystem:cpu Mount point:/proc/mounts User:hadoop Path:/sys/fs/cgroup/cpu/hadoop-yarn

• Cause : un redémarrage inattendu de l'instance ECS, souvent provoqué par un défaut du noyau (un problème connu dans la version 4.19.91-21.2.al7.x86_64), détruit les données en mémoire du groupe de contrôle CPU et invalide le cgroup.

• Solution : modifiez le script bootstrap pour les groupes de nœuds existants et mis à l'échelle horizontalement afin de créer le répertoire cgroup et configurez le fichier rc.local pour recréer automatiquement ce répertoire à chaque démarrage de l'instance.

  # enable cgroups
  mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn
  chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn
  # enable cgroups after reboot
  echo "mkdir -p /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  echo "chown -R hadoop:hadoop /sys/fs/cgroup/cpu/hadoop-yarn" >> /etc/rc.d/rc.local
  chmod +x /etc/rc.d/rc.local

Configuration inefficace des ressources NodeManager

• Description : après avoir modifié les paramètres yarn.nodemanager.resource.cpu-vcores et yarn.nodemanager.resource.memory-mb, enregistré la configuration et redémarré NodeManager, les comptes de ressources ne sont pas mis à jour.

• Cause : ces paramètres doivent être appliqués au niveau du groupe de nœuds, car les instances d'un groupe de nœuds peuvent avoir des spécifications CPU et mémoire différentes.

• Solution : dans la console E-MapReduce (EMR), appliquez les paramètres de ressources au groupe de nœuds du NodeManager. Pour plus d'informations, consultez la rubrique Gérer les éléments de configuration. Sous l'onglet Configure du service YARN, basculez le filtre vers Node Group Configuration. Sélectionnez le groupe de nœuds cible, tel que emr-core (CORE), et modifiez les paramètres dans le sous-onglet yarn-site.xml.

Dépannage des nœuds non sains

• Causes

  • Le vérificateur d'intégrité des disques marque un nœud comme non sain si le ratio entre les répertoires sains et le nombre total de répertoires tombe en dessous du seuil défini par le paramètre yarn.nodemanager.disk-health-checker.min-healthy-disks dans yarn-site.xml (par défaut : 0,25). Par exemple, sur un nœud NodeManager doté de quatre disques, le nœud devient non sain uniquement si les répertoires des quatre disques sont non sains. Dans le cas contraire, le rapport d'état du NodeManager indique simplement que local-dirs are bad ou log-dirs are bad. Pour plus d'informations, consultez la rubrique Que faire si le message « local-dirs are bad » ou « log-dirs are bad » est signalé ?.

  • Problème signalé par le script de vérification de l'intégrité du NodeManager : cette vérification est désactivée par défaut. Vous pouvez l'activer en définissant le paramètre yarn.nodemanager.health-checker.script.path dans yarn-site.xml sur le chemin d'accès à un script de vérification de l'intégrité.

• Solutions

  • Pour les problèmes de disque, consultez la rubrique Que faire si le message « local-dirs are bad » ou « log-dirs are bad » est signalé ?.

  • Pour les problèmes signalés par le script de vérification de l'intégrité, résolvez le problème en fonction de votre script personnalisé.

Problèmes de disque des nœuds : « local-dirs are bad » ou « log-dirs are bad »

• Cause : Le vérificateur d'intégrité des disques contrôle périodiquement que les répertoires local-dirs (cache des dépendances de tâches, des données intermédiaires et d'autres fichiers) et log-dirs (répertoire des journaux d'exécution des tâches) respectent les conditions suivantes. Tout répertoire ne satisfaisant pas à une condition est marqué comme défectueux.

  • Lisible

  • Accessible en écriture

  • Exécutable

  • L'utilisation du disque reste inférieure au seuil configuré. Ce paramètre est contrôlé par yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage dans le fichier yarn-site.xml, dont la valeur par défaut est 90 %.

    L'espace disque disponible est supérieur à l'espace libre minimal requis. Ce paramètre est contrôlé par yarn.nodemanager.disk-health-checker.min-free-space-per-disk-mb dans le fichier yarn-site.xml, dont la valeur par défaut est 0.

• Solution

  • Un espace disque insuffisant est généralement à l'origine de ce problème. Si l'un des scénarios suivants s'applique, envisagez d'ajouter des disques :

    • Le nœud NodeManager dispose de spécifications élevées et exécute de nombreuses tâches.

    • La capacité du disque est relativement faible.

    • Les tâches dépendent de volumes importants de données ou de fichiers volumineux.

    • Les tâches génèrent une grande quantité de données intermédiaires.

    • Les journaux des tâches sont volumineux et consomment beaucoup d'espace disque.

  • Vérifiez le paramètre yarn.nodemanager.localizer.cache.target-size-mb dans le fichier yarn-site.xml. Si cette valeur est trop élevée par rapport à la capacité du disque, le cache des tâches historiques peut occuper un espace disque excessif. Le système nettoie automatiquement ce cache uniquement lorsqu'il dépasse la taille configurée.

  • Si un disque endommagé est à l'origine du problème, consultez Remplacer un disque local endommagé dans le cluster.

Que faire si le message d'erreur « User [dr.who] is not authorized to view the logs for application *** » s'affiche ?

• Description du problème : Les informations illustrées ci-dessous s'affichent lors de l'ouverture de la page des journaux.

• Cause : Les règles de liste de contrôle d'accès (ACL) sont vérifiées lorsque vous accédez à la page des journaux NodeManager. Si les règles ACL sont activées et qu'un utilisateur distant souhaite consulter les journaux d'une application, cet utilisateur doit remplir l'une des conditions suivantes :

  • L'utilisateur distant est l'administrateur.

  • L'utilisateur distant est le propriétaire de l'application.

  • L'utilisateur distant respecte les règles ACL personnalisées pour l'application.

• Solution : Vérifiez si l'utilisateur distant remplit l'une des conditions précédentes.

Que faire si le message d'erreur « HTTP ERROR 401 Authentication required » ou « HTTP ERROR 403 Unauthenticated users are not authorized to access this page » s'affiche ?

• Description du problème : Une erreur HTTP ERROR 401 ou HTTP ERROR 403 se produit lors de l'accès à une interface utilisateur web ou de l'appel d'une API RESTful. La figure suivante illustre les détails de l'erreur HTTP ERROR 401.

  

• Cause : YARN utilise la méthode d'authentification simple et n'autorise pas l'accès anonyme. Pour plus d'informations, consultez la section Authentication for Hadoop HTTP web-consoles de la documentation officielle d'Apache Hadoop.

• Solutions :

  • Méthode 1 : Configurez un paramètre d'URL pour spécifier un utilisateur distant, par exemple user.name=***.

  • Méthode 2 : Dans la section Configuration Filter de l'onglet Configure de la page du service HDFS d'un cluster dans la console EMR, recherchez le paramètre hadoop.http.authentication.simple.anonymous.allowed et définissez sa valeur sur true pour autoriser l'accès anonyme. Pour plus d'informations sur ce paramètre, consultez la section Authentication for Hadoop HTTP web-consoles de la documentation officielle d'Apache Hadoop. Redémarrez ensuite le service HDFS. Pour plus d'informations, consultez la rubrique Restart a service.

Pourquoi la valeur affichée pour TotalVcore est-elle incorrecte ?

Dans la section des API RESTful du cluster ou des métriques, située dans le coin supérieur droit de l'interface utilisateur web de YARN, la valeur affichée pour TotalVcore est incorrecte. Il s'agit d'un problème de logique de calcul pour TotalVcore dans les versions d'Apache Hadoop antérieures à la 2.9.2. Pour plus d'informations, consultez la page Total #VCores in cluster metrics is wrong when CapacityScheduler reserved some containers de la documentation officielle d'Apache Hadoop.

Ce problème est corrigé dans les versions EMR V3.37.x, EMR V5.3.x et leurs versions mineures ultérieures.

Que faire si les informations relatives à une application affichées sur l'interface utilisateur web de TEZ sont incomplètes ?

Tâche Spark Thrift Server sur l'interface utilisateur web de YARN

Si vous sélectionnez Spark lors de la création d'un cluster, le cluster démarre automatiquement un service Spark Thrift Server par défaut. Ce service utilise les ressources d'un pilote YARN. Par défaut, les tâches Spark Thrift Server demandent des ressources à YARN via ce pilote.

Prise en charge des URL OSS pour yarn.timeline-service.leveldb-timeline-store.path

Le paramètre yarn.timeline-service.leveldb-timeline-store.path ne prend pas en charge les URL de bucket OSS.

Lors de la création d'un cluster Hadoop, le paramètre yarn.timeline-service.leveldb-timeline-store.path prend par défaut la valeur du paramètre hadoop.tmp.dir. Ne modifiez pas le paramètre hadoop.tmp.dir pour HDFS, car cela affecte le paramètre yarn.timeline-service.leveldb-timeline-store.path.

Délais de connexion au serveur Timeline ou utilisation élevée des ressources

L'exécution d'un grand nombre de tâches Tez peut provoquer des délais de connexion lors de l'écriture d'événements dans le serveur Timeline de YARN. Cela se produit parce que le processus Timeline Server consomme des ressources CPU excessives, entraînant une saturation de l'utilisation du processeur du nœud. Cette situation affecte l'exécution des tâches et les services non essentiels, tels que la génération de rapports. Pour résoudre ce problème, modifiez les éléments de configuration suivants.

Dans la console EMR, modifiez les configurations des services Tez et YARN. Pour obtenir des instructions, consultez la rubrique Manage configuration items.

1. Dans l'onglet tez-site.xml de la page Configure du service Tez, ajoutez le paramètre tez.yarn.ats.event.flush.timeout.millis et définissez sa valeur sur 60000. Ce paramètre définit le délai d'attente pour l'écriture des événements par les tâches Tez dans le serveur Timeline de YARN.

2. Dans l'onglet yarn-site.xml de la page Configure du service YARN, ajoutez ou modifiez les éléments de configuration suivants. Ensuite, sur la page Status du service YARN, redémarrez TimelineServer.

   Parameter	Value	Description
   yarn.timeline-service.store-class	org.apache.hadoop.yarn.server.timeline.RollingLevelDBTimelineStore	Classe de stockage des événements pour le serveur Timeline de YARN.
   yarn.timeline-service.rolling-period	daily	Période de rotation des événements pour le serveur Timeline de YARN.
   yarn.timeline-service.leveldb-timeline-store.read-cache-size	4194304	Taille du cache de lecture pour le magasin LevelDB du serveur Timeline de YARN.
   yarn.timeline-service.leveldb-timeline-store.write-buffer-size	4194304	Taille du tampon d'écriture pour le magasin LevelDB du serveur Timeline de YARN.
   yarn.timeline-service.leveldb-timeline-store.max-open-files	500	Nombre maximal de fichiers ouverts pour le magasin LevelDB du serveur Timeline de YARN.