Dimensionnement des nœuds maîtres
Les nœuds maîtres d'un cluster ODP hébergent les services de coordination, de métadonnées et de gestion qui doivent rester hautement disponibles. Un mauvais dimensionnement des nœuds maîtres est une cause fréquente d'instabilité du cluster — notamment les pauses GC du NameNode, la lenteur de l'ordonnancement YARN, ou les timeouts de l'interface Ambari.
Cette page fournit des recommandations de dimensionnement détaillées pour chaque service maître, incluant les recommandations de heap JVM.
NameNode (paire HA)
Le HDFS NameNode conserve l'intégralité de l'espace de nommage du système de fichiers en mémoire. Les besoins en mémoire augmentent avec le nombre de fichiers, de blocs et de répertoires dans HDFS.
| Métrique | Recommandation |
|---|---|
| Heap par NameNode | 2 Go par million de blocs (minimum 8 Go, typiquement 16–64 Go) |
| CPU | 8–16 cœurs |
| RAM (nœud total) | 64–128 Go |
| Disque OS + métadonnées | 2x SSD RAID 1 (pour les journaux d'édition et fsimage) |
Exemple de heap JVM (hadoop-env) :
HADOOP_NAMENODE_OPTS="-Xms32g -Xmx32g -XX:+UseG1GC"
Notes :
- Exécutez toujours le NameNode en mode HA avec un journal d'édition partagé via des JournalNodes (minimum 3 JournalNodes, généralement co-localisés sur les nœuds maîtres)
- Les répertoires fsimage et journaux d'édition du NameNode (
dfs.namenode.name.dir,dfs.namenode.edits.dir) doivent être sur un stockage rapide et fiable. Les SSD avec miroir RAID 1 sont fortement recommandés - Surveillez attentivement l'utilisation de la heap du NameNode ; les crashs OOM du NameNode peuvent mettre le cluster hors ligne
ResourceManager (paire HA)
Le YARN ResourceManager ordonnance et suit tous les conteneurs d'applications à travers le cluster.
| Métrique | Recommandation |
|---|---|
| Heap | 4–16 Go (évolue avec la taille du cluster et le nombre d'applications) |
| CPU | 4–8 cœurs |
| RAM (nœud total) | 32–64 Go |
Exemple de heap JVM (yarn-env) :
YARN_RESOURCEMANAGER_HEAPSIZE=8192
Notes :
- La HA du ResourceManager utilise ZooKeeper pour le suivi de l'état actif/standby. Assurez-vous que ZooKeeper est opérationnel avant de démarrer le ResourceManager
- Dans les grands clusters (500+ nœuds), envisagez de co-localiser le ResourceManager sur un nœud dédié plutôt que de le partager avec le NameNode
HBase Master
Le HBase Master coordonne l'assignation des régions et gère les opérations administratives. Il n'est pas dans le chemin des données pour les lectures/écritures (contrairement aux RegionServers), donc son dimensionnement est plus modeste.
| Métrique | Recommandation |
|---|---|
| Heap | 2–4 Go |
| CPU | 4 cœurs |
| RAM (nœud total) | 16–32 Go (sur nœud maître partagé) |
Exemple de heap JVM (hbase-env) :
HBASE_MASTER_OPTS="-Xms4g -Xmx4g -XX:+UseG1GC"
Notes :
- Déployez HBase Master en mode HA (maître principal + maître de secours sur des nœuds différents)
- HBase Master partage ZooKeeper avec HDFS/YARN ; assurez-vous que l'ensemble ZooKeeper est dimensionné de manière appropriée
Quorum ZooKeeper
ZooKeeper fournit la coordination distribuée pour la HA NameNode HDFS, la HA ResourceManager YARN, HBase, Kafka et d'autres composants ODP.
| Métrique | Recommandation |
|---|---|
| Heap | 1–4 Go |
| CPU | 2–4 cœurs |
| Disque de données | SSD fortement recommandé (le journal de transactions ZooKeeper est sensible à la latence) |
| Taille du quorum | 3 nœuds (minimum), 5 pour les clusters plus grands |
Exemple de heap JVM (zoo.cfg / zookeeper-env) :
ZK_SERVER_HEAP=2048
Notes :
- Déployez toujours un nombre impair de nœuds ZooKeeper (3 ou 5) pour maintenir le quorum
- Les journaux de transactions ZooKeeper (
dataLogDir) doivent être sur un disque dédié avec une latence faible et constante. Les disques partagés provoquent des timeouts d'élection ZooKeeper sous charge - La co-localisation de ZooKeeper sur les nœuds maîtres est la pratique standard pour les clusters petits à moyens
Ambari Server
Ambari Server gère la configuration, le déploiement et la surveillance du cluster. Il intègre un conteneur servlet Tomcat et une pile de collecte de métriques.
| Métrique | Recommandation |
|---|---|
| Heap | 2–4 Go |
| CPU | 4 cœurs |
| RAM (nœud total) | 16–32 Go (sur nœud maître partagé) |
| Base de données | PostgreSQL ou MySQL externe sur SSD |
Exemple de heap JVM (ambari-env.sh) :
AMBARI_JVM_ARGS="-Xms2g -Xmx4g"
Notes :
- Ambari Server doit se connecter à une base de données externe (PostgreSQL recommandé) plutôt qu'à la base de données Derby intégrée, qui est inadaptée à la production
- Pour les clusters avec Ambari Metrics Service (AMS), l'AMetrics Collector nécessite de la RAM supplémentaire (heap de 4–8 Go) et un disque rapide pour le store de séries temporelles basé sur HBase
Ranger
Apache Ranger fournit la gestion centralisée des politiques de sécurité, la journalisation d'audit et le contrôle d'accès au niveau ligne/colonne pour Hive, HDFS, HBase, Kafka, Knox, NiFi et d'autres services.
| Métrique | Recommandation |
|---|---|
| Heap Ranger Admin | 2–4 Go |
| Heap Ranger UserSync | 512 Mo – 1 Go |
| CPU | 4 cœurs |
| BDD externe (politiques) | PostgreSQL ou MySQL sur SSD |
| Store d'audit | Solr (heap de 4–8 Go) ou HDFS |
Exemple de heap JVM (ranger-env) :
ranger_admin_max_heap_size=4096
Notes :
- Le store d'audit Ranger Solr (
ranger_audit_solr) doit avoir une heap dédiée de 4–8 Go et un disque rapide pour son index - Pour les clusters à volume d'audit élevé, envisagez un cluster Solr ou Elasticsearch externe plutôt que le Solr intégré géré par Ambari
Atlas
Apache Atlas fournit la gouvernance des métadonnées, le suivi de la lignée et la classification des données.
| Métrique | Recommandation |
|---|---|
| Heap Atlas Server | 4–8 Go |
| CPU | 4–8 cœurs |
| HBase intégré (pour le graphe) | Partagé avec HBase du cluster ou dédié |
| Solr intégré | Heap de 4–8 Go |
Exemple de heap JVM (atlas-env) :
export ATLAS_SERVER_OPTS="-Xms4g -Xmx8g -XX:+UseG1GC"
Notes :
- Atlas utilise JanusGraph adossé à HBase pour son store de graphe de métadonnées. Il utilise également Solr pour la recherche en texte intégral. Les deux sont gourmands en ressources
- Pour les grands environnements (millions d'entités), envisagez de dédier un nœud maître complet à Atlas
Knox
Apache Knox fournit un point d'entrée unique pour tous les accès REST API et UI aux services ODP via une passerelle API et un proxy SSO.
| Métrique | Recommandation |
|---|---|
| Heap Knox Server | 1–2 Go |
| CPU | 4–8 cœurs (la terminaison TLS est limitée par le CPU) |
| RAM (nœud total) | 16–32 Go (sur nœud edge ou maître) |
Exemple de heap JVM (knox-env) :
KNOX_MAX_MEM=2048
Notes :
- Knox gère TLS/SSL pour toutes les connexions entrantes. Un CPU moderne avec accélération matérielle AES-NI réduit significativement la surcharge TLS pour les déploiements à haute concurrence
- Knox est généralement déployé sur le nœud edge, pas sur les nœuds maîtres, pour isoler le trafic externe des services de coordination internes