YARN : tout savoir sur le gestionnaire de ressources d'Apache Hadoop

Les architectures Big Data reposent sur une gestion fine des ressources pour traiter de vastes volumes de données. YARN (Yet Another Resource Negotiator) est au cœur d’Apache Hadoop depuis la version 2.0. Véritable moteur de planification et d’allocation, il permet de faire tourner MapReduce, Spark et d’autres frameworks sur un même cluster. Dans ce guide complet, vous apprendrez comment fonctionne YARN, ses principaux composants, son mode de scheduling, son intégration avec HDFS et Spark, ainsi que les bonnes pratiques pour optimiser les performances et garantir la haute disponibilité de vos jobs.

Comprendre le rôle de YARN dans Hadoop

Avant l’apparition de YARN, Hadoop 1.x utilisait un framework tightly coupled pour exécuter exclusivement MapReduce. Avec l’essor d’autres modèles de calcul (Spark, Tez, Flink), la plateforme avait besoin d’un gestionnaire de ressources générique. YARN découple désormais le traitement (applications) de la gestion des ressources du cluster. Il agit comme une couche intermédiaire qui :

• assure la découverte et l’allocation des ressources CPU et mémoire,
• planifie et suit l’exécution des jobs,
• gère la fiabilité et la scalabilité du cluster.

Grâce à cette approche, vous pouvez exécuter simultanément plusieurs frameworks sur le même cluster, tout en garantissant une utilisation optimale des machines.

Architecture globale de YARN

À haut niveau, l’architecture de YARN se compose de trois couches :

• la couche client, qui soumet et suit les applications ;
• la couche de gestion, reposant sur le Resource Manager et le Node Manager ;
• la couche d’exécution, assurée par l’Application Master et les containers.

Cette séparation claire facilite le scaling horizontal et améliore la tolérance aux pannes.

Resource Manager (RM)

Le Resource Manager est le composant central chargé de :

• gérer l’inventaire des ressources disponibles sur chaque nœud,
• prendre les décisions de scheduling,
• superviser l’allocation et la libération des containers.

Il se divise lui-même en deux sous-composants :

• le Scheduler, responsable de la politique d’ordonnancement,
• le Application Manager, qui orchestre la création et l’arrêt de l’Application Master pour chaque job.

Node Manager (NM)

À chaque machine du cluster, un Node Manager tourne afin de :

• surveiller l’utilisation des ressources (CPU, mémoire),
• lancer et arrêter les containers conformément aux directives du Resource Manager,
• rapporter l’état des containers et envoyer des rapports de santé.

Application Master (AM)

Pour chaque application soumise, un Application Master spécifique est lancé. Il coordonne :

• le découpage du job en tâches,
• la demande de containers au Resource Manager,
• le suivi de l’état de chaque tâche,
• la gestion des échecs et relances.

Cela permet une grande flexibilité : le framework peut implémenter son propre AM, adapté à son modèle de programmation.

Le scheduling et l’allocation des ressources

L’un des enjeux clés de YARN est de fournir un scheduling efficace et équitable. Plusieurs planificateurs sont disponibles :

• Capacity Scheduler, pour garantir un partage minimal de ressources par file d’attente (queue),
• Fair Scheduler, pour partager équitablement selon la demande dynamique des applications,
• FIFO Scheduler, le plus simple, basé sur l’ordre d’arrivée.

Les queues permettent de segmenter le cluster selon des priorités métiers ou des équipes. Chaque queue peut être configurée avec :

• une capacité minimale et maximale,
• un ordre de priorité,
• un ensemble de règles d’accès.

Gestion des containers

Un container correspond à un ensemble de ressources (mémoire et CPU) réservées sur un nœud. Lors de la soumission de tâches, l’AM négocie le nombre et le type de containers nécessaires. Les paramètres essentiels :

• –container_memory : quantité de mémoire allouée,
• –container_vcores : nombre de cœurs CPU réservés.

Un mauvais dimensionnement peut entraîner des goulots d’étranglement ou un gaspillage de ressources.

Haute disponibilité et tolérance aux pannes

En production, garantir la continuité des services est crucial. YARN propose plusieurs mécanismes :

• HA du Resource Manager : deux nœuds élisent un leader via ZooKeeper,
• Recovery des Application Masters : en cas de redémarrage du RM, les AM peuvent être relancés et poursuivre leur travail,
• Logs et timeline server : centralisation des journaux d’exécution pour diagnostiquer les échecs.

Cette architecture robuste minimise l’impact des pannes matérielles ou logicielles.

Monitoring des jobs et log aggregation

La visibilité sur l’exécution des applications est assurée par plusieurs outils :

• l’interface web du Resource Manager,
• l’interface du timeline server, qui collecte les événements clés,
• les logs agrégés, accessibles depuis HDFS pour chaque container.

Pour accéder aux métriques et logs sans ouvrir de port supplémentaire, vous pouvez utiliser la YARN REST API. Elle fournit des endpoints pour :

• lister les applications et leur statut,
• récupérer les logs ou les métriques de ressource,
• soumettre et killer des jobs.

Intégration de MapReduce et Spark sur YARN

Par défaut, MapReduce version 2 (MRv2) s’appuie sur YARN. Le Application Master MapReduce gère la création de mappers et reducers sous forme de containers. Mais YARN ne se limite pas à MR :

Apache Spark peut fonctionner en mode YARN, en déployant un Spark AM et un ensemble de containers pour executors. Les avantages :

• partage des ressources avec d’autres frameworks,
• utilisation de la même infrastructure de sécurité et d’isolation,
• gestion centralisée des logs et de la scalabilité.

Tuning et optimisation des performances

Pour obtenir un cluster performant, plusieurs paramètres méritent attention :

Paramètre	Description	Recommandation
yarn.nodemanager.resource.memory-mb	Mémoire totale allouée au NM	80 % de la mémoire physique
yarn.scheduler.minimum-allocation-mb	Plus petite allocation de mémoire	1 Go ou plus selon workload
yarn.scheduler.maximum-allocation-vcores	Max vcores par container	Définir selon CPU physiques
yarn.resourcemanager.am.max-attempts	Nombre de relances AM	2 à 4

Voici quelques bonnes pratiques :

• adapter la taille des containers aux besoins réels des jobs,
• éviter d’allouer 100 % de la mémoire au NM pour préserver le système d’exploitation,
• monitorer l’utilisation des vcores pour détecter les surallocations.

Intégration avec HDFS et sécurité

YARN s’appuie sur HDFS pour stocker les fichiers temporaires, les containers logs et les journaux des AM. Les répertoires clés :

• hdfs:///yarn//,
• hdfs:///user//.

Côté sécurité, l’intégration avec Kerberos permet de :

• authentifier les utilisateurs,
• chiffrer les données en transit,
• contrôler les accès via ACL sur HDFS et YARN.

Exemple de configuration YARN

Voici un modèle simplifié du fichier yarn-site.xml :

<configuration>
  <property>
    <name>yarn.resourcemanager.hostname</name>
    <value>rm1.example.com</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>32768</value>
  </property>
  <property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>1024</value>
  </property>
</configuration>

Cette configuration de base peut être adaptée selon la taille de votre cluster et le profil des jobs.

Meilleures pratiques pour le dimensionnement

Pour dimensionner correctement un cluster YARN :

• collectez des métriques réelles pendant une période représentative,
• identifiez les goulots d’étranglement (CPU, mémoire, I/O),
• ajustez progressivement les paramètres (containers, queues, scheduler).

Une approche itérative permet de trouver le compromis idéal entre coût et performance.

FAQ

Qu’est-ce que YARN et pourquoi l’utiliser ?

YARN est le gestionnaire de ressources d’Apache Hadoop. Il découple l’allocation de ressources du framework de calcul, permettant d’exécuter MapReduce, Spark et d’autres moteurs sur le même cluster, tout en optimisant l’utilisation des machines.

Comment fonctionne le scheduling dans YARN ?

Le Resource Manager dispose d’un Scheduler (Capacity, Fair ou FIFO). Il répartit les containers parmi les queues configurées, selon les capacités minimales, maximales et la politique de partage définie.

Comment configurer la haute disponibilité du Resource Manager ?

Activez la HA en paramétrant deux nœuds RM dans yarn-site.xml et en configurant ZooKeeper. Un RM devient leader, l’autre standby. En cas de défaillance, le standby prend le relais avec l’historique des applications grâce à la recovery store.

Quelle quantité de mémoire allouer aux containers ?

Dimensionnez la mémoire container selon le type de job. Pour des tâches CPU-bound, privilégiez un ratio CPU/mémoire équilibré (par exemple 4 Go pour 2 vcores). Pour du traitement in-memory (Spark), allouez plus de mémoire.

Comment monitorer les applications YARN ?

Utilisez l’interface web du Resource Manager, le timeline server pour les événements clés, ainsi que la YARN REST API pour extraire des métriques et l’état des applications de manière automatisée.