Dimensionnement des nœuds worker

Les nœuds worker d'un cluster ODP fournissent la capacité de stockage et de calcul pour les charges de travail de données. Chaque nœud worker exécute généralement un DataNode HDFS, un NodeManager YARN, et éventuellement des services colocalisés tels qu'un RegionServer HBase, un daemon Impala, un broker Kafka ou un serveur de tablettes Kudu.

Cette page couvre la planification du stockage HDFS, l'allocation de la mémoire et des vcores YARN, les bonnes pratiques de disposition des disques, et le dimensionnement lors de la colocalisation avec Kafka.

Planification du stockage HDFS

Facteur de réplication

HDFS stocke chaque bloc de données sur plusieurs nœuds pour assurer la tolérance aux pannes. Le facteur de réplication par défaut est 3, ce qui signifie que chaque bloc consomme 3 fois sa taille logique en espace disque brut.

Formule de stockage brut :

Stockage brut requis par nœud = (données logiques totales / nombre de nœuds de données) × facteur de réplication × 1,25

Le facteur 1,25 tient compte des surcharges HDFS (métadonnées des blocs, fichiers intermédiaires, données de jobs temporaires et espace libre pour éviter la saturation des disques des DataNodes).

Exemple :

• 100 To de données logiques, 10 nœuds worker, facteur de réplication 3
• Brut par nœud : (100 To / 10) × 3 × 1,25 = 37,5 To de disque brut par worker

Configuration des disques — JBOD uniquement

attention

N'utilisez pas de RAID matériel (RAID 5, RAID 6, RAID 10) pour les disques de données HDFS. HDFS assure sa propre tolérance aux pannes via la réplication. Le RAID matériel ajoute du coût et de la complexité sans bénéfice, et peut réduire le débit en raison des surcharges de parité.

Configurez les disques de données HDFS en JBOD (Just a Bunch of Disks). Chaque disque est monté indépendamment (par exemple, /data/disk1, /data/disk2, ..., /data/diskN) et listé dans dfs.datanode.data.dir.

Exemple de configuration dfs.datanode.data.dir pour un nœud avec 8 disques de données :

/data/disk1/hdfs,/data/disk2/hdfs,/data/disk3/hdfs,/data/disk4/hdfs,
/data/disk5/hdfs,/data/disk6/hdfs,/data/disk7/hdfs,/data/disk8/hdfs

Cela permet à HDFS de distribuer les blocs sur tous les disques, maximisant le débit I/O agrégé.

Heap du DataNode

Le heap JVM du DataNode évolue avec le nombre de blocs gérés par nœud. Une formule couramment utilisée est 1 Go par million de blocs stockés sur le nœud.

Exemple de heap JVM (hadoop-env) :

HADOOP_DATANODE_OPTS="-Xms2g -Xmx4g -XX:+UseG1GC"

Pour la plupart des nœuds worker dans des clusters de taille moyenne, un heap DataNode de 4 Go est suffisant.

Allocation de la mémoire et des vcores YARN

YARN alloue les ressources des conteneurs à partir de la capacité configurée du NodeManager. Un dimensionnement correct évite à la fois la sous-utilisation des ressources et les conditions d'OOM.

Mémoire totale disponible

La mémoire YARN disponible (yarn.nodemanager.resource.memory-mb) doit être :

yarn.nodemanager.resource.memory-mb = RAM totale - surcharge OS - heap des services colocalisés

Exemple pour un nœud worker de 128 Go avec RegionServer HBase (heap 16 Go) et DataNode (heap 4 Go) :

128 Go - 8 Go (OS) - 16 Go (HBase) - 4 Go (DataNode) - 4 Go (tampon) = 96 Go → 98304 Mo

Vcores totaux disponibles

Définissez yarn.nodemanager.resource.cpu-vcores au nombre de CPU logiques du nœud moins la surcharge pour l'OS et les services colocalisés :

yarn.nodemanager.resource.cpu-vcores = CPU logiques totaux - 2 (OS) - [cœurs réservés aux services colocalisés]

Pour un nœud à 24 cœurs : 24 - 2 = 22 vcores disponibles pour YARN.

Paramètres de mémoire des conteneurs

Paramètre	Valeur recommandée
yarn.scheduler.minimum-allocation-mb	1024 Mo (1 Go)
yarn.scheduler.maximum-allocation-mb	Égal à nodemanager.resource.memory-mb
yarn.scheduler.minimum-allocation-vcores	1
yarn.scheduler.maximum-allocation-vcores	Égal à nodemanager.resource.cpu-vcores

Valeurs par défaut de mémoire pour MapReduce et Spark

Pour MapReduce :

• mapreduce.map.memory.mb : 2048–4096 Mo
• mapreduce.reduce.memory.mb : 4096–8192 Mo

Pour Spark (par exécuteur) :

• spark.executor.memory : 4–16 Go selon la charge de travail
• spark.executor.cores : 2–5 (évitez les exécuteurs à cœur unique pour l'efficacité)

Bonnes pratiques de disposition des disques

Séparation des disques OS et données

Utilisez toujours des disques séparés pour le système d'exploitation (et les journaux de service) par rapport aux données HDFS :

Rôle du disque	Type recommandé	Points de montage
OS + journaux	SSD 200–500 Go	/, /var/log/
Données HDFS	HDD 4–12 To chacun	/data/disk1 ... /data/diskN
Données Kudu (si déployé)	NVMe / SATA SSD	/kudu/disk1 ... /kudu/diskN
Journaux Kafka (si déployé)	HDD ou SSD	/kafka/disk1 ... /kafka/diskN

Lectures en circuit court HDFS

Activez les lectures en circuit court HDFS (dfs.client.read.shortcircuit=true) pour permettre aux tâches de calcul colocalisées (MapReduce, Spark, Impala) de lire les blocs HDFS directement depuis le disque local via un socket de domaine Unix, en contournant la pile réseau du DataNode. Cela réduit significativement la latence pour les lectures locales.

Dimensionnement des brokers Kafka (colocalisés)

Lorsque les brokers Kafka sont colocalisés avec les DataNodes HDFS sur des nœuds worker (acceptable pour les clusters petits à moyens), suivez ces recommandations :

Ressource	Recommandation
Heap Kafka	4–8 Go (-Xms6g -Xmx6g)
Disques de journaux Kafka	Disques séparés des disques de données HDFS
Rétention des journaux Kafka	Taille par broker : partitions × taille de rétention par partition
Réseau	Kafka est intensif en réseau ; 10 GbE minimum, 25 GbE recommandé pour les topics à haut débit

Exemple de heap JVM (kafka-env) :

export KAFKA_HEAP_OPTS="-Xms6g -Xmx6g"

Paramètres clés du broker Kafka pour les déploiements colocalisés :

• Définissez log.dirs sur des disques dédiés (non partagés avec HDFS ou l'OS)
• Définissez num.io.threads et num.network.threads en fonction des cœurs disponibles (typiquement num.io.threads = 2 × nombre de disques de données, num.network.threads = 3–8)
• Ajustez replica.fetch.max.bytes et message.max.bytes selon vos tailles de messages attendues

remarque

Pour les grands déploiements Kafka (débit de messages élevé ou rétention importante), envisagez des nœuds Kafka dédiés plutôt que la colocalisation avec les DataNodes HDFS afin d'éviter les contentions I/O et réseau.

Dimensionnement des RegionServers HBase (colocalisés)

Les RegionServers HBase sont généralement colocalisés sur les nœuds worker aux côtés du DataNode HDFS et du NodeManager YARN.

Ressource	Recommandation
Heap du RegionServer	16–32 Go
hfile.block.cache.size	0,40 (40 % du heap pour le cache de lecture)
hbase.regionserver.global.memstore.size	0,40 (40 % du heap pour le tampon d'écriture)
Régions par RegionServer	20–200 (commencez par 50 et ajustez selon la charge)

Exemple de heap JVM (hbase-env) :

HBASE_REGIONSERVER_OPTS="-Xms16g -Xmx16g -XX:+UseG1GC -XX:MaxGCPauseMillis=100"

Utilisez G1GC pour les RegionServers HBase afin de minimiser les temps de pause GC, qui peuvent provoquer des timeouts du serveur de régions et des réaffectations de régions inutiles.