Recommandations matérielles pour ODP
Cette page fournit des recommandations de dimensionnement matériel pour le déploiement d'un cluster ODP. Ces recommandations couvrent la topologie typique à trois niveaux (nœuds maîtres, nœuds workers, nœud edge) et incluent des orientations spécifiques pour les composants sensibles au matériel tels que Kudu et Kafka.
Topologie typique d'un cluster ODP
Un cluster ODP est généralement organisé en trois catégories de nœuds :
| Type de nœud | Nombre (typique) | Rôle |
|---|---|---|
| Nœuds maîtres | 3–5 | Services de coordination : NameNode, ResourceManager, HBase Master, ZooKeeper, Ambari Server, Ranger, Atlas, Knox |
| Nœuds workers | 3–N | Stockage et traitement des données : HDFS DataNode, YARN NodeManager, daemon Impala, broker Kafka, serveur de tablettes Kudu |
| Nœud edge | 1–2 | Interface cliente : clients Hadoop, passerelle Knox, NiFi, connexions clients HiveServer2 |
Cette séparation des responsabilités garantit que les services de coordination maîtres ne sont pas impactés par la consommation de ressources des charges de travail de données s'exécutant sur les nœuds workers.
Recommandations pour les nœuds maîtres
Les nœuds maîtres hébergent les services de coordination, de métadonnées et de gestion qui doivent rester hautement disponibles et réactifs. ODP prend en charge la HA NameNode et la HA ResourceManager, nécessitant au minimum 2 nœuds maîtres pour les paires HA. Un troisième maître (ou un nœud quorum dédié) est généralement requis pour ZooKeeper et le HBase Master standby.
Spécification recommandée
| Ressource | Minimum | Recommandé |
|---|---|---|
| CPU | 8 cœurs | 16–32 cœurs |
| RAM | 32 Go | 64–128 Go |
| Disque OS / logs | 1x SSD 200 Go | 2x SSD 400 Go (RAID 1 ou miroir) |
| Réseau | 10 GbE | 25 GbE |
Notes :
- Utilisez des SSD pour le volume du système d'exploitation et les répertoires de journaux (
/var/log/) afin d'éviter que les I/O disque ne deviennent un goulot d'étranglement lors des vidages du journal d'édition NameNode ou de l'activité de l'agent Ambari - La base de données Ambari Server (PostgreSQL, MySQL ou Oracle) doit résider sur un volume à faible latence I/O ; les SSD sont fortement recommandés
- Ranger et Atlas bénéficient tous deux d'une heap dédiée et d'un disque rapide pour leurs stores d'audit Solr intégrés ou externes
Recommandations pour les nœuds workers
Les nœuds workers supportent l'essentiel de la charge de stockage et de calcul. Le dimensionnement dépend fortement du volume de données attendu, du facteur de réplication et des charges de travail de traitement (batch, interactif, streaming).
Spécification recommandée
| Ressource | Minimum | Recommandé (cluster moyen) |
|---|---|---|
| CPU | 8 cœurs | 16–24 cœurs |
| RAM | 32 Go | 64–256 Go |
| Disques de données | 4x HDD 4 To | 6–12x HDD 6–12 To (JBOD, sans RAID) |
| Disque OS | 1x SSD 200 Go | 1x SSD 200 Go |
| Réseau | 10 GbE | 25 GbE |
Notes :
- Les disques de données HDFS DataNode doivent être configurés en JBOD (Just a Bunch of Disks) — ne pas utiliser RAID pour les disques de données. HDFS fournit sa propre réplication (facteur par défaut : 3) et le RAID matériel est inutile et gaspilleur
- Dimensionnez le stockage brut total des workers comme suit :
stockage utile requis × facteur de réplication × 1,25(pour les surcharges) - La mémoire disponible du YARN NodeManager doit être réglée à la RAM totale moins les surcharges OS et les heaps des services co-localisés. Un bon point de départ est
RAM totale - 8 Gopour les conteneurs YARN
Kudu — Exigence SSD
Les serveurs de tablettes Kudu nécessitent un stockage SSD pour les répertoires de données de tablettes. L'exécution de Kudu sur des HDD rotatifs entraîne une dégradation sévère des performances et n'est pas prise en charge dans ODP.
Si Kudu est déployé, les nœuds workers hébergeant les serveurs de tablettes Kudu doivent disposer d'au minimum 2 à 4 SSD NVMe ou SATA dédiés aux répertoires de données Kudu, séparés des disques de données HDFS.
Kafka — Recommandation de disques dédiés
Les brokers Kafka sont intensifs en I/O et fonctionnent mieux avec des disques dédiés pour les répertoires de journaux Kafka.
Si Kafka est co-localisé avec des HDFS DataNodes sur des nœuds workers (un schéma courant pour les petits clusters), configurez les répertoires de journaux Kafka sur des disques séparés des répertoires de données HDFS. Pour les grands déploiements Kafka, envisagez des nœuds broker Kafka dédiés avec des SSD à haute performance ou des HDD haute capacité.
Recommandations pour le nœud edge
Le nœud edge sert de point d'entrée pour les utilisateurs et les applications se connectant au cluster. Il héberge les bibliothèques clientes Hadoop, Knox (passerelle API / SSO), et optionnellement NiFi pour les pipelines d'ingestion de données.
Spécification recommandée
| Ressource | Minimum | Recommandé |
|---|---|---|
| CPU | 4 cœurs | 8 cœurs |
| RAM | 16 Go | 32 Go |
| Disque | 1x SSD 200 Go | 1x SSD 500 Go |
| Réseau | 10 GbE | 10 GbE |
Notes :
- Knox gère la terminaison TLS et Kerberos SPNEGO ; un CPU plus rapide réduit la latence d'authentification pour les utilisateurs simultanés
- Si NiFi est déployé sur le nœud edge, augmentez la RAM à au moins 64 Go et assurez-vous d'avoir suffisamment de disque local pour les dépôts NiFi (FlowFile, Content, Provenance)
Exigences réseau
| Exigence | Minimum | Recommandé |
|---|---|---|
| Bande passante interne au cluster | 10 GbE | 25 GbE |
| Switch | Couche 2 (même VLAN) | Couche 3 avec VLAN dédié |
| Latence (intra-cluster) | < 1 ms | < 0,5 ms |
Pour les clusters de plus de 20 nœuds workers, des interconnexions 25 GbE sont fortement recommandées pour éviter que le réseau ne devienne un goulot d'étranglement pour le trafic de réplication HDFS et les opérations de shuffle Spark.
Consultez la page Exigences réseau pour les détails sur DNS, NTP, pare-feu et la connectivité Kerberos KDC.