Prérequis réseau

Un réseau bien configuré est essentiel pour la stabilité et les performances d'un cluster ODP. Cette page couvre les prérequis en matière de DNS, NTP, pare-feu et connectivité au KDC Kerberos.

Prérequis DNS

Résolution DNS directe et inverse

Tous les nœuds d'un cluster ODP doivent disposer d'une résolution DNS directe (nom d'hôte vers IP) et DNS inverse (IP vers nom d'hôte) valide. C'est une exigence impérative pour :

• La liaison des principals Kerberos (les principals de service sont liés aux noms de domaine pleinement qualifiés)
• La communication NameNode vers DataNode dans HDFS
• La communication ResourceManager vers NodeManager dans YARN
• L'enregistrement des agents Ambari

Vérifier la résolution DNS sur chaque nœud :

# Résolution directe
host $(hostname -f)

# Résolution inverse
host $(hostname -i)

Les deux résolutions doivent retourner des résultats cohérents. Le nom d'hôte retourné par hostname -f doit correspondre à l'entrée DNS inverse de l'adresse IP du nœud.

Recommandation : utiliser un serveur DNS (pas /etc/hosts)

Pour les clusters de plus de quelques nœuds, gérez le DNS via un serveur DNS approprié (par exemple, FreeIPA/BIND, Microsoft Active Directory DNS). L'utilisation de /etc/hosts n'est acceptable que pour les environnements de laboratoire ou de test et ne passe pas à l'échelle.

Exigences sur les noms d'hôtes

• Utilisez des noms de domaine pleinement qualifiés (FQDN) tels que master01.cluster.example.com
• N'utilisez pas de noms d'hôtes à étiquette unique (par exemple, master01 seul)
• Évitez les noms d'hôtes contenant des underscores (_) ; utilisez plutôt des tirets (-) — certains composants (Kerberos, Java SSL) rejettent les underscores dans les noms d'hôtes

Prérequis NTP

Tous les nœuds du cluster doivent avoir leurs horloges synchronisées via NTP. Un décalage d'horloge supérieur à 5 minutes provoquera l'échec de la validation des tickets Kerberos, entraînant des erreurs d'authentification sur tous les services Kerbérisés.

Configuration NTP recommandée :

• Utilisez chrony (recommandé sur RHEL 9) ou ntpd
• Pointez tous les nœuds du cluster vers la même source NTP ou un serveur NTP interne
• Vérifiez la synchronisation : chronyc tracking ou ntpstat

# Installer et activer chrony (RHEL 9 / Rocky Linux 9)
dnf install -y chrony
systemctl enable --now chronyd
chronyc tracking

Référence des ports pour le pare-feu

Le tableau suivant liste les ports clés requis pour les services ODP. Configurez votre pare-feu (firewalld, iptables ou groupes de sécurité) pour autoriser ces ports entre les types de nœuds concernés.

Infrastructure de base

Service	Port	Protocole	Direction
Interface web Ambari Server	8080	TCP	Client → Ambari Server
Interface web Ambari Server (HTTPS)	8442	TCP	Client → Ambari Server
Agent Ambari	8670	TCP	Ambari Server → Tous les nœuds
Client ZooKeeper	2181	TCP	Tous les nœuds → Nœuds ZooKeeper
Pairs ZooKeeper	2888, 3888	TCP	ZooKeeper → ZooKeeper

HDFS

Service	Port	Protocole	Direction
RPC NameNode	8020	TCP	Tous les nœuds / clients → NameNode
Interface web HTTP NameNode	9870	TCP	Admin → NameNode
Interface web HTTPS NameNode	9871	TCP	Admin → NameNode
Transfert de données DataNode	9866	TCP	NameNode / clients → DataNode
Interface web HTTP DataNode	9864	TCP	Admin → DataNode
JournalNode	8485	TCP	NameNode → JournalNode

remarque

Le port 50070 (HTTP NameNode historique) et 50010 (DataNode historique) ont été remplacés dans Hadoop 3.x par 9870 et 9866 respectivement.

YARN

Service	Port	Protocole	Direction
Interface web ResourceManager	8088	TCP	Client → ResourceManager
Planificateur ResourceManager	8030	TCP	NodeManager → ResourceManager
NodeManager	8042	TCP	Client / RM → NodeManager
Job History Server	19888	TCP	Client → History Server
Timeline Server	8188	TCP	Client → ATS

Hive

Service	Port	Protocole	Direction
HiveServer2 (JDBC/ODBC)	10000	TCP	Client → HiveServer2
HiveServer2 (HTTP)	10001	TCP	Client → HiveServer2
Hive Metastore	9083	TCP	HiveServer2 / Spark → Metastore

HBase

Service	Port	Protocole	Direction
HBase Master	16000	TCP	RegionServer → Master
Interface web HBase Master	16010	TCP	Admin → HBase Master
RegionServer	16020	TCP	Client → RegionServer
Interface web RegionServer	16030	TCP	Admin → RegionServer

Services de sécurité

Service	Port	Protocole	Direction
Interface web Ranger Admin	6080	TCP	Client → Ranger
Interface web Ranger Admin (HTTPS)	6182	TCP	Client → Ranger
Passerelle Knox (HTTPS)	8443	TCP	Client externe → Knox
Interface web Atlas (HTTP)	21000	TCP	Client → Atlas
Interface web Atlas (HTTPS)	21443	TCP	Client → Atlas

Kafka

Service	Port	Protocole	Direction
Broker Kafka	6667	TCP	Producteur / Consommateur → Broker
Broker Kafka (SSL)	6668	TCP	Producteur / Consommateur → Broker

NiFi

Service	Port	Protocole	Direction
Interface web NiFi (HTTPS)	9090	TCP	Client → NiFi
NiFi Site-to-Site	10000	TCP	NiFi → NiFi (si clusterisé)

Catalogue REST Polaris

Service	Port	Protocole	Direction
API REST Polaris	8181	TCP	Spark / Trino → Polaris

Kudu

Service	Port	Protocole	Direction
RPC Kudu Master	7051	TCP	Client / TabletServer → Master
Interface web Kudu Master	8051	TCP	Admin → Kudu Master
RPC Kudu TabletServer	7050	TCP	Client → TabletServer
Interface web Kudu TabletServer	8050	TCP	Admin → TabletServer

Connectivité au KDC Kerberos

Dans un cluster ODP sécurisé par Kerberos, tous les nœuds doivent pouvoir atteindre le Centre de Distribution de Clés (KDC) Kerberos. ODP prend en charge MIT Kerberos et FreeIPA (qui intègre MIT Kerberos).

Service	Port	Protocole	Direction
KDC Kerberos	88	TCP + UDP	Tous les nœuds → KDC
Administration Kerberos	749	TCP	Ambari Server → Admin KDC
LDAP FreeIPA	389	TCP	Ambari / Ranger → FreeIPA
LDAPS FreeIPA	636	TCP	Ambari / Ranger → FreeIPA

Exigences :

• Tous les nœuds du cluster doivent pouvoir résoudre le nom d'hôte du KDC et atteindre le port 88 (TCP et UDP)
• Ambari Server doit pouvoir atteindre le port d'administration du KDC (749) pour créer les principals de service lors de l'assistant d'activation Kerberos
• Si FreeIPA est utilisé, Ranger UserSync doit pouvoir atteindre le port LDAP (389 ou 636) pour la synchronisation des utilisateurs et des groupes

Décalage d'horloge

Kerberos est très sensible au décalage d'horloge. Le décalage maximum autorisé entre un client et le KDC est de 300 secondes (5 minutes) par défaut. Assurez-vous que la synchronisation NTP est en place sur tous les nœuds avant d'activer Kerberos (voir Prérequis NTP ci-dessus).