## 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.conf ou dans spark-submit avec --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/hosts a 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/hosts et 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 iperf entre 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.
ÉtapeCommande/ActionRésultat attenduSi échec
1. Vérifier la version Sparkspark-submit --versionAffiche la version 3.5.0Corriger le PATH ou l'installation
2. Vérifier la version Javajava -versionOpenJDK 11 ou pris en chargeInstaller le bon Java
3. Vérifier le processus maîtreps -ef | grep MasterProcessus maître en cours d'exécutionDémarrer le maître : /opt/spark/sbin/start-master.sh
4. Vérifier les ports en écoutess -tuln | grep -E '7077|8080'Ports listésInvestiguer le processus ou la configuration
5. Tester la connectivité depuis le travailleurnc -zv master.example.com 7077Connexion réussieVérifier le réseau et le pare-feu
6. Tester la résolution DNSnslookup master.example.comRenvoie l'IP 192.168.1.10Corriger le DNS ou /etc/hosts
7. Vérifier la configuration Sparkgrep spark.driver.host /opt/spark/conf/spark-defaults.confNom d'hôte ou IP correctAjuster la configuration et redémarrer
8. Examiner les journaux du pilotetail -n 50 /opt/spark/work/app-/driver-.logAucune exception réseauDiagnostiquer l'erreur spécifique
9. Vérifier les règles du pare-feufirewall-cmd --list-allPorts 7077, 8080 ouvertsAjouter des règles
10. Vérifier l'exécution de l'applicationspark-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 10Le travail se termine avec une sortieInvestiguer 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.