Introduction
Les problèmes réseau d'Apache Spark peuvent arrêter un travail avant même qu'il ne commence, ou pire, provoquer des défaillances intermittentes difficiles à reproduire. Ce guide fournit un dépannage pratique, étape par étape, des problèmes réseau dans Apache Spark. Il s'adresse aux développeurs, ingénieurs DevOps et équipes techniques qui exploitent des clusters Spark et doivent passer d'un problème observé à un résultat vérifié.
Nous couvrons la résolution DNS d'Apache Spark, les ports courants, les vérifications de connectivité et les commandes de dépannage réseau. Chaque section inclut des commandes concrètes avec les sorties attendues, les signaux de défaillance et les décisions de récupération. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés plutôt que des secrets, vérifier le résultat et documenter la récupération si l'état attendu n'est pas atteint.
Aucun identifiant réel, jeton ou identifiant de production n'est utilisé. Tous les exemples concernent un cluster autonome Spark 3.5.0 sous Linux, mais les principes s'appliquent à Spark sur YARN, Kubernetes ou les services cloud.
Inventaire de la version et de l'environnement
Avant de dépanner, recueillez la version exacte et la topologie. Cela évite d'appliquer des solutions destinées à une version Spark ou un mode de déploiement différent. Exécutez ces commandes en lecture seule sur le pilote et les exécuteurs :
# Sur le nœud pilote
spark-submit --version
# Sortie attendue (tronquée) :
# Welcome to
# ____ __
# / __/__ ___ _____/ /__
# _\ \/ _ \/ _ `/ __/ '_/
# /___/ .__/\_,_/_/ /_/\_\ version 3.5.0
# /_/
# Vérifier la version de Java (requis : Java 8/11/17 pour Spark 3.5.0)
java -version
# Sortie attendue :
# openjdk version "11.0.20" 2023-07-18
# Lister tous les processus Spark et leurs ports
ps -ef | grep -i spark
# Exemple de sortie (partielle) :
# spark 1234 1 0 10:00 ? 00:00:00 /usr/lib/jvm/java-11-openjdk-amd64/bin/java -cp /opt/spark/conf/:/opt/spark/jars/* -Xmx1g org.apache.spark.deploy.master.Master --host master.example.com --port 7077 --webui-port 8080
# spark 5678 1 0 10:01 ? 00:00:00 ... org.apache.spark.deploy.worker.Worker --webui-port 8081 master.example.com:7077
Notez la version de Spark, la version de Java, le mode de déploiement (autonome, YARN, Kubernetes) et l'URL du maître. Utilisez hostname -I pour obtenir toutes les adresses IP, et ip route pour vérifier la passerelle par défaut. Documentez la topologie du cluster : quels nœuds sont les pilotes, les exécuteurs et les services externes (comme HDFS, Kafka ou les bases de données).
Si une commande échoue ou si la sortie est inattendue, notez-le. Par exemple, si spark-submit --version échoue avec bash: spark-submit: command not found, les binaires Spark ne sont pas dans le PATH. Ajoutez-les ou utilisez le chemin complet.
Liste de contrôle version et environnement :
- Version Spark : 3.5.0 (confirmée via
spark-submit --version) - Version Java : OpenJDK 11.0.20 (doit être prise en charge par la version Spark)
- Mode de déploiement : cluster autonome
- Nœud maître : master.example.com, IP 192.168.1.10, port 7077
- Nœuds travailleurs : worker1.example.com (192.168.1.11), worker2.example.com (192.168.1.12)
- Services externes : NameNode HDFS à hdfs-namenode.example.com:8020, broker Kafka à kafka-broker.example.com:9092
Chemin de configuration sûr
Les configurations réseau liées à Spark doivent être modifiées avec précaution. Commencez par afficher la configuration actuelle. Pour un cluster autonome, vérifiez les fichiers spark-defaults.conf et spark-env.sh sur tous les nœuds.
# Afficher les paramètres réseau depuis les valeurs par défaut de Spark (lecture seule)
grep -E "spark\.(driver|executor|blockManager|shuffle|network|rpc|broadcast)" /opt/spark/conf/spark-defaults.conf
# Exemple de sortie :
# spark.driver.host 192.168.1.10
# spark.driver.port 7078
# spark.blockManager.port 7079
# spark.shuffle.service.port 7337
# spark.ui.port 4040
Si vous devez modifier un paramètre, suivez ces étapes :
- Identifiez la propriété exacte et sa valeur actuelle.
- Déterminez la valeur requise en fonction de votre topologie réseau.
- Faites une copie de sauvegarde du fichier de configuration.
- Modifiez le fichier sur les nœuds concernés (pilote, exécuteur, ou les deux).
- Redémarrez uniquement le composant affecté, pas tout le cluster si possible.
- Vérifiez le changement avec les commandes appropriées.
Exemple : supposons que les exécuteurs Spark ne peuvent pas se lier au port aléatoire par défaut pour le gestionnaire de blocs parce qu'un pare-feu bloque une plage. Vous devez définir un port spécifique. Dans spark-defaults.conf sur les nœuds exécuteurs, ajoutez :
spark.blockManager.port 40000
Avant d'effectuer le changement, vérifiez si le port est libre :
# Vérifier si le port 40000 est en écoute
ss -tuln | grep 40000
# Sortie attendue : aucune sortie (le port est libre)
Après l'édition, redémarrez le processus de l'exécuteur. Ensuite, vérifiez que l'exécuteur s'est lié au nouveau port :
# Sur le nœud exécuteur, trouvez le processus travailleur et vérifiez ses ports ouverts
ps -ef | grep spark | grep Worker
# Notez le PID, par exemple 5678
ss -tulnp | grep 5678
# La sortie attendue doit inclure une ligne comme :
# tcp LISTEN 0 128 0.0.0.0:40000 0.0.0.0:* users:(("java",pid=5678,fd=123))
Si le port n'est toujours pas en écoute, vérifiez les journaux Spark pour les erreurs.
Liste de contrôle chemin de configuration sûr :
- Valeur actuelle de spark.blockManager.port : (non défini, aléatoire)
- Nouvelle valeur : 40000
- Fichier de sauvegarde : /opt/spark/conf/spark-defaults.conf.bak.20250301
- Commande de vérification : ss -tulnp | grep 5678
- Restauration : restaurer la sauvegarde et redémarrer l'exécuteur
Vérification et diagnostics
Une fois qu'un problème réseau est soupçonné, utilisez un processus de vérification systématique. Les commandes suivantes aident à diagnostiquer les problèmes courants.
1. Vérifier les ports en écoute
# Lister tous les ports TCP en écoute sur le nœud
ss -tuln
# Exemple de sortie (extrait) :
# Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
# tcp LISTEN 0 128 0.0.0.0:7077 0.0.0.0:*
# tcp LISTEN 0 128 0.0.0.0:8080 0.0.0.0:*
# tcp LISTEN 0 128 0.0.0.0:4040 0.0.0.0:*
Assurez-vous que le maître Spark écoute sur 7077 (ou le port configuré), l'interface web sur 8080 et l'interface du pilote sur 4040 lorsqu'une application est en cours d'exécution.
2. Tester la connectivité avec nc ou telnet
Depuis un nœud travailleur, testez la connectivité vers le maître :
# Utiliser netcat (nc)
nc -zv master.example.com 7077
# Sortie attendue :
# Connection to master.example.com (192.168.1.10) 7077 port [tcp/*] succeeded!
Si nc n'est pas disponible, utilisez telnet :
telnet master.example.com 7077
# Si connecté, vous verrez quelque chose comme :
# Trying 192.168.1.10...
# Connected to master.example.com.
# Escape character is '^]'.
# Appuyez sur Ctrl+] puis tapez quit pour sortir.
Si la connexion échoue, vérifiez les règles du pare-feu avec iptables -L -n (ou firewall-cmd --list-all).
3. Vérifier la résolution DNS
# Résoudre les noms d'hôte
nslookup master.example.com
# Sortie attendue :
# Server: 192.168.1.1
# Address: 192.168.1.1#53
#
# Name: master.example.com
# Address: 192.168.1.10
# Recherche inversée
nslookup 192.168.1.10
# Sortie attendue :
# 10.1.168.192.in-addr.arpa name = master.example.com.
Le DNS direct et inversé doit être cohérent. Spark utilise souvent les noms d'hôte pour la communication, et les incohérences peuvent provoquer des échecs comme UnknownHostException.
4. Vérifier les journaux d'application Spark
Pour une application en cours d'exécution, consultez les journaux du pilote pour trouver les erreurs de connexion :
# Trouver les journaux du pilote (mode autonome)
ls /opt/spark/work/app-*/driver-*.log
# Ou utilisez l'interface web pour voir stdout/stderr.
Les erreurs réseau typiques incluent ConnectException: Connection refused, BindException: Address already in use et UnknownHostException.
Liste de contrôle vérification :
- Ports sur le maître : 7077, 8080 ouverts (confirmé)
- Connectivité du travailleur vers le maître : SUCCÈS
- DNS direct et inversé : CORRESPONDANCE
- Journaux du pilote : aucune exception réseau
Modes de défaillance et récupération
Voici les modes de défaillance réseau courants de Spark, leurs symptômes et les étapes de récupération.
Défaillance 1 : L'exécuteur ne peut pas se connecter au maître
Symptôme : Dans les journaux du travailleur, vous voyez des erreurs répétées comme :
WARN Worker: Failed to connect to master master.example.com:7077
Causes possibles :
- Le maître n'est pas en cours d'exécution ou a planté.
- Partition réseau ou pare-feu bloquant le port 7077.
- Mauvaise URL du maître dans la configuration du travailleur.
Étapes de récupération :
- Vérifiez si le processus maître est en cours d'exécution :
ps -ef | grep Master - Vérifiez si le port est en écoute :
ss -tuln | grep 7077 - Depuis le travailleur, testez la connectivité :
nc -zv master.example.com 7077 - Si le maître est arrêté, redémarrez-le :
/opt/spark/sbin/start-master.sh - Si pare-feu, autorisez le port 7077 :
firewall-cmd --add-port=7077/tcp --permanent && firewall-cmd --reload - Vérifiez que le travailleur se reconnecte en vérifiant les journaux pour
Successfully registered with master
Défaillance 2 : Le pilote ne peut pas se lier au port
Symptôme : L'application échoue avec java.net.BindException: Address already in use ou similaire. Souvent, le port du pilote (aléatoire par défaut) est en conflit.
Récupération :
- Définissez un port de pilote explicite dans
spark-defaults.confou dansspark-submitavec--conf spark.driver.port=4041(choisissez un port inutilisé). - Vérifiez les processus existants utilisant le port :
lsof -i :4041 - Si nécessaire, tuez le processus en conflit ou choisissez un autre port.
Défaillance 3 : Échecs de résolution DNS
Symptôme : Erreur java.net.UnknownHostException: master.example.com lors du lancement des exécuteurs ou de l'accès aux services externes.
Récupération :
- Vérifiez les paramètres DNS sur tous les nœuds (
cat /etc/resolv.conf). - Assurez-vous que
/etc/hostsa des entrées correctes si vous n'utilisez pas de DNS central. - Testez avec
nslookup master.example.com. - Si nécessaire, ajoutez temporairement des entrées dans
/etc/hostset vérifiez la résolution.
Défaillance 4 : Délai d'attente réseau pendant le brassage (shuffle)
Symptôme : Le travail échoue avec TimeoutException ou IOException: Connection reset pendant le brassage.
Causes possibles :
- Bande passante réseau insuffisante.
- Latence élevée entre les nœuds.
- Le pare-feu interrompt les connexions de longue durée.
Récupération :
- Augmentez les paramètres de délai :
spark.network.timeout=300s(défaut 120s). - Vérifiez les performances réseau avec
iperfentre les nœuds. - Assurez-vous que le pare-feu ne tue pas les connexions inactives.
Liste de contrôle récupération de défaillance :
- Identifier le mode de défaillance : L'exécuteur ne peut pas se connecter au maître (Défaillance 1)
- Cause racine : Pare-feu bloquant le port 7077 (confirmé via test nc)
- Correctif appliqué : Ajout d'une règle de pare-feu
- Vérification : Les journaux du travailleur montrent une inscription réussie
Liste de contrôle des opérations
Utilisez cette liste de contrôle comme référence rapide pour le dépannage réseau Spark.
| Étape | Commande/Action | Résultat attendu | Si échec |
|---|---|---|---|
| 1. Vérifier la version Spark | spark-submit --version | Affiche la version 3.5.0 | Corriger le PATH ou l'installation |
| 2. Vérifier la version Java | java -version | OpenJDK 11 ou pris en charge | Installer le bon Java |
| 3. Vérifier le processus maître | ps -ef | grep Master | Processus maître en cours d'exécution | Démarrer le maître : /opt/spark/sbin/start-master.sh |
| 4. Vérifier les ports en écoute | ss -tuln | grep -E '7077|8080' | Ports listés | Investiguer le processus ou la configuration |
| 5. Tester la connectivité depuis le travailleur | nc -zv master.example.com 7077 | Connexion réussie | Vérifier le réseau et le pare-feu |
| 6. Tester la résolution DNS | nslookup master.example.com | Renvoie l'IP 192.168.1.10 | Corriger le DNS ou /etc/hosts |
| 7. Vérifier la configuration Spark | grep spark.driver.host /opt/spark/conf/spark-defaults.conf | Nom d'hôte ou IP correct | Ajuster la configuration et redémarrer |
| 8. Examiner les journaux du pilote | tail -n 50 /opt/spark/work/app-/driver-.log | Aucune exception réseau | Diagnostiquer l'erreur spécifique |
| 9. Vérifier les règles du pare-feu | firewall-cmd --list-all | Ports 7077, 8080 ouverts | Ajouter des règles |
| 10. Vérifier l'exécution de l'application | spark-submit --class org.apache.spark.examples.SparkPi --master spark://master.example.com:7077 /opt/spark/examples/jars/spark-examples_2.12-3.5.0.jar 10 | Le travail se termine avec une sortie | Investiguer les erreurs dans les journaux |
Utilisation de la liste de contrôle :
- Effectuez d'abord les étapes 1 à 4 sur le nœud maître.
- Effectuez les étapes 5 à 6 depuis un nœud travailleur.
- Vérifiez la configuration et les journaux sur tous les nœuds concernés.
- Après avoir apporté des modifications, réexécutez l'étape échouée pour confirmer.
Conclusion
Le dépannage réseau d'Apache Spark nécessite une approche méthodique. Commencez par recueillir les détails de version et d'environnement, puis vérifiez la connectivité, le DNS, les ports et la configuration. Utilisez les commandes et listes de contrôle fournies pour identifier et résoudre les problèmes courants tels que les échecs de connexion, les exceptions de liaison et les problèmes DNS.
Séparez toujours l'observation de l'intervention. Capturez l'état actuel avec des commandes en lecture seule avant d'apporter des modifications. Limitez les modifications à un élément ciblé à la fois, et vérifiez chaque modification. Documentez votre chemin de récupération afin de pouvoir revenir en arrière si nécessaire.
Pour approfondir, consultez la documentation officielle d'Apache Spark pour votre version, en particulier les sections sur la configuration et le déploiement. Consultez également les paramètres liés au réseau pour votre gestionnaire de ressources (YARN, Kubernetes) et les services externes comme HDFS ou Kafka avec lesquels Spark interagit.
En suivant ce guide, vous pouvez rapidement diagnostiquer et corriger les problèmes réseau de Spark, assurant ainsi le bon fonctionnement de vos pipelines de données.