Introduction
Le système de fichiers distribué Hadoop (HDFS) est l'épine dorsale du stockage de nombreuses plateformes de mégadonnées, mais son apprentissage et son dépannage peuvent être intimidants sans un environnement sûr pour s'exercer. Un laboratoire HDFS local offre un environnement contrôlé pour expérimenter les configurations, simuler des pannes et développer des applications sans risquer les données de production ni engendrer de coûts cloud. Ce guide vous accompagne dans la mise en place d'un laboratoire HDFS local pratique, de la sélection de la version à la vérification et à la récupération. Que vous soyez un développeur prototypant un pipeline de données ou un ingénieur d'exploitation perfectionnant ses compétences en dépannage, cette approche pratique vous aidera à gagner en confiance et en expertise.
Inventaire des versions et de l'environnement
Avant de commencer, établissez les versions, la topologie et les prérequis de votre laboratoire. Choisissez une distribution Hadoop qui correspond à votre environnement de production ou à vos objectifs d'apprentissage. Pour ce guide, nous utilisons Apache Hadoop 3.3.6, une version stable avec une documentation abondante.
Prérequis :
- Une machine Linux ou macOS avec au moins 4 Go de RAM et 10 Go d'espace disque libre (les utilisateurs Windows peuvent utiliser WSL2).
- Java 8 ou 11 (OpenJDK recommandé). Vérifiez avec
java -version. - Client et serveur SSH (pour l'accès à distance de Hadoop). Sur Debian/Ubuntu :
sudo apt install openssh-server openssh-client. - Familiarité de base avec la ligne de commande.
Topologie : une configuration pseudo-distribuée à nœud unique où tous les démons HDFS s'exécutent sur une seule machine. Cela suffit pour la plupart des expériences de laboratoire.
Inventaire des versions :
| Composant | Version | Notes |
|---|---|---|
| Apache Hadoop | 3.3.6 | HDFS et YARN de base |
| Java | OpenJDK 8 ou 11 | Environnement d'exécution requis |
| Système d'exploitation | Linux/macOS | Windows via WSL2 |
Mise en place de l'environnement :
- Créez un utilisateur dédié pour Hadoop (par exemple,
hadoopuser) pour éviter les problèmes de permissions. - Installez Java et définissez
JAVA_HOME. - Configurez la connexion SSH sans mot de passe à localhost :
ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
ssh localhost
Testez avec ssh localhost ; vous devriez vous connecter sans demande de mot de passe.
Chemin de configuration sûr
Nous utiliserons une configuration minimale qui maintient les données isolées et faciles à réinitialiser. Téléchargez l'archive binaire Hadoop depuis le site officiel Apache et extrayez-la dans un répertoire tel que /opt/hadoop. Par exemple :
wget https://downloads.apache.org/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz
sudo tar -xzf hadoop-3.3.6.tar.gz -C /opt
sudo mv /opt/hadoop-3.3.6 /opt/hadoop
sudo chown -R hadoopuser:hadoopuser /opt/hadoop
Structure des répertoires :
/opt/hadoop/
├── etc/hadoop/ # fichiers de configuration
├── bin/ # commandes utilisateur
├── sbin/ # scripts des démons
├── logs/ # fichiers journaux
└── data/ # répertoires de données HDFS (créés manuellement)
Fichiers de configuration principaux :
Modifiez etc/hadoop/core-site.xml :
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>
Modifiez etc/hadoop/hdfs-site.xml :
<configuration>
<property>
<name>dfs.replication</name>
<value>1</value>
</property>
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///opt/hadoop/data/namenode</value>
</property>
<property>
<name>dfs.datanode.data.dir</name>
<value>file:///opt/hadoop/data/datanode</value>
</property>
</configuration>
Définissez les variables d'environnement dans ~/.bashrc :
export HADOOP_HOME=/opt/hadoop
export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin
export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop
Puis exécutez source ~/.bashrc pour appliquer.
Initialisez le NameNode :
hdfs namenode -format
Résultat attendu : confirmation que le répertoire de stockage a été formaté, se terminant par un message du type « Storage directory /opt/hadoop/data/namenode has been successfully formatted. »
Démarrez les démons HDFS :
start-dfs.sh
Cela démarre le NameNode, le DataNode et le SecondaryNameNode. Vérifiez avec jps.
Vérification et diagnostic
Vérifiez que le cluster est sain à l'aide des outils en ligne de commande et de l'interface web.
Vérifiez les démons :
jps
Résultat attendu : identifiants de processus pour NameNode, DataNode et SecondaryNameNode (et Jps lui-même). Par exemple :
12345 NameNode
12456 DataNode
12567 SecondaryNameNode
12678 Jps
Listez la racine HDFS :
hdfs dfs -ls /
Si elle est vide, elle ne renvoie rien mais se termine avec le code 0.
Créez un répertoire et téléversez un fichier :
hdfs dfs -mkdir /test
hdfs dfs -put /etc/hosts /test/hosts
hdfs dfs -cat /test/hosts
Résultat attendu : le contenu de /etc/hosts s'affiche dans la console. Par exemple :
127.0.0.1 localhost
Exécutez une vérification du système de fichiers :
hdfs fsck / -files -blocks
Affiche les informations sur les blocs de fichiers et l'état de santé. Une sortie saine inclut une ligne comme « Status: HEALTHY » et « Total blocks (validated): 1 (avg. block size 134217728 B) ».
Interface web : accédez à http://localhost:9870 pour les informations du NameNode et à http://localhost:9864 pour les informations du DataNode. Ces interfaces fournissent des tableaux de bord pour la santé du cluster, les nœuds actifs et la navigation dans le système de fichiers.
Modes de défaillance et récupération
Comprendre les défaillances courantes aide à renforcer la résilience. Voici des problèmes potentiels et les étapes de récupération.
Le NameNode ne démarre pas
Consultez les journaux dans $HADOOP_HOME/logs/. Cause courante : JAVA_HOME mal configuré ou permissions de répertoire inadéquates.
Exemple d'extrait de journal :
ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: Failed to start namenode.
java.io.FileNotFoundException: /opt/hadoop/data/namenode (Permission denied)
Récupération :
- Vérifiez que
JAVA_HOMEest correctement défini dansetc/hadoop/hadoop-env.sh. - Assurez-vous que les répertoires de données existent et sont accessibles en écriture par l'utilisateur Hadoop :
sudo mkdir -p /opt/hadoop/data/namenode
sudo chown -R hadoopuser:hadoopuser /opt/hadoop/data
- Si le NameNode a déjà été formaté mais que les métadonnées sont corrompues, reformatez (après avoir sauvegardé toute donnée importante) :
hdfs namenode -format
Le DataNode ne se connecte pas
Vérifiez les paramètres réseau et de pare-feu. Le DataNode écoute sur le port 9866.
Récupération :
- Exécutez
hdfs dfsadmin -reportpour voir l'état du DataNode. Si aucun DataNode n'est répertorié, consultez les journaux du DataNode pour les erreurs de connexion. - Assurez-vous que le DataNode peut résoudre et se connecter au NameNode. En mode pseudo-distribué, ils communiquent via localhost ; vérifiez
/etc/hostspour la correspondance localhost correcte. - Vérifiez que le service DataNode est en cours d'exécution avec
jps. Sinon, démarrez-le manuellement :hdfs --daemon start datanode.
Bloc corrompu
Simulez en supprimant un fichier de bloc dans le répertoire du DataNode. Ensuite, exécutez :
hdfs fsck / -files -blocks -locations
Cela identifie la corruption, montrant des blocs manquants ou sous-répliqués. Par exemple :
/user/hadoop/testfile: Under replicated BP-123456789-127.0.0.1-1610000000000:blk_1073741825_1001. Target Replicas is 1 but found 0 live replica(s), 0 decommissioned replica(s), 0 decommissioning replica(s).
Récupération :
- Si vous disposez d'une sauvegarde, restaurez le fichier ou téléversez-le à nouveau.
- Si le bloc provient d'un fichier de test, vous pouvez supprimer le fichier et le recréer :
hdfs dfs -rm /test/hosts
hdfs dfs -put /etc/hosts /test/hosts
- Pour les données critiques, implémentez un facteur de réplication supérieur à 1 en production ; dans le laboratoire, vous pouvez augmenter
dfs.replicationpour simuler la réplication et tester la récupération automatique.
Retour en arrière (rollback)
Pour réinitialiser le cluster :
stop-dfs.sh
rm -rf /opt/hadoop/data/namenode /opt/hadoop/data/datanode
hdfs namenode -format
start-dfs.sh
Cela efface toutes les données HDFS et repart de zéro.
Liste de contrôle des opérations
Utilisez cette liste de contrôle pour vous assurer que votre laboratoire reste sain et utile.
| Tâche | Commande | Résultat attendu | Responsable | Fréquence |
|---|---|---|---|---|
| Démarrer HDFS | start-dfs.sh | Tous les démons démarrent | Vous (administrateur du labo) | À chaque session |
| Vérifier les démons | jps | Liste NameNode, DataNode, SecondaryNameNode | Vous | Après le démarrage |
| Lister la racine | hdfs dfs -ls / | Aucune erreur | Vous | Hebdomadaire |
| Téléverser un fichier de test | hdfs dfs -put file /test/ | Le fichier apparaît dans la liste | Vous | Lors des tests |
| Exécuter fsck | hdfs fsck / | État de santé OK | Vous | Hebdomadaire |
| Arrêter HDFS | stop-dfs.sh | Tous les démons s'arrêtent proprement | Vous | Fin de session |
Régulièrement également :
- Surveillez l'utilisation de l'espace disque avec
df -h /opt/hadoop/data. - Sauvegardez les métadonnées du NameNode si nécessaire. Pour un laboratoire, vous pouvez périodiquement copier le répertoire
namenodevers un emplacement sûr. - Nettoyez les fichiers de test inutilisés :
hdfs dfs -rm -r /test/*.
Pièges courants et comment les éviter
1. Utiliser le mauvais utilisateur Hadoop
Pourquoi cela arrive : exécuter des commandes HDFS en tant que root ou un autre utilisateur peut entraîner des erreurs de permission ou une propriété incohérente des répertoires de données.
Comment l'éviter : utilisez toujours l'utilisateur Hadoop dédié (par exemple, hadoopuser). Basculez avec su - hadoopuser ou exécutez les commandes avec sudo -u hadoopuser.
Récupération : si vous avez accidentellement exécuté une commande en tant qu'un autre utilisateur, rétablissez la propriété :
sudo chown -R hadoopuser:hadoopuser /opt/hadoop
2. Ne pas formater le NameNode avant le premier démarrage
Pourquoi cela arrive : les nouveaux utilisateurs oublient souvent l'étape hdfs namenode -format, ce qui entraîne des erreurs comme « NameNode is not formatted. »
Comment l'éviter : formatez toujours avant le premier démarrage, et ne formatez que lors de la configuration d'un nouveau cluster ou d'une réinitialisation intentionnelle. Le formatage supprime toutes les métadonnées et données !
Récupération : si vous avez oublié de formater, arrêtez HDFS, formatez et redémarrez.
3. Mauvaise configuration SSH
Pourquoi cela arrive : les scripts de démarrage de Hadoop utilisent SSH pour lancer les démons sur différents nœuds, même en mode pseudo-distribué. Si le SSH sans mot de passe n'est pas configuré, les scripts peuvent se bloquer ou échouer avec des erreurs d'authentification.
Comment l'éviter : testez le SSH sans mot de passe avec ssh localhost avant d'exécuter start-dfs.sh. Si un mot de passe est demandé, générez des clés et ajoutez-les à authorized_keys comme décrit précédemment.
Récupération : si le SSH est mal configuré, corrigez-le puis redémarrez HDFS avec stop-dfs.sh et start-dfs.sh.
4. Manque d'espace disque
Pourquoi cela arrive : HDFS accumule des données à partir de tests répétés et les métadonnées du NameNode augmentent. Dans un laboratoire, vous ne surveillez peut-être pas l'utilisation du disque.
Comment l'éviter : configurez une tâche cron pour vérifier l'espace disque chaque semaine et nettoyer les fichiers de test :
0 0 * * 0 du -sh /opt/hadoop/data && df -h /opt/hadoop
Récupération : supprimez les fichiers inutiles dans HDFS et les répertoires de données locaux. Si le disque est plein, envisagez de déplacer les données vers une partition plus grande ou d'augmenter la taille du disque.
5. Ignorer les fichiers journaux
Pourquoi cela arrive : lorsque quelque chose ne va pas, les nouveaux utilisateurs devinent souvent au lieu de lire les journaux.
Comment l'éviter : prenez l'habitude de consulter $HADOOP_HOME/logs/ pour les messages d'erreur détaillés. Le journal du NameNode est généralement hadoop-hadoopuser-namenode-<hostname>.log, et celui du DataNode est similaire.
Récupération : naviguez vers le répertoire des journaux et utilisez tail -f pour surveiller pendant que vous reproduisez le problème.
Conclusion
Vous disposez désormais d'un laboratoire HDFS local entièrement fonctionnel. Cet environnement vous permet d'expérimenter en toute sécurité, de simuler des pannes et de valider des configurations avant de toucher à la production. Utilisez la liste de contrôle des opérations pour maintenir la cohérence, et n'oubliez pas d'attribuer des responsabilités claires et des fréquences de révision à chaque tâche. Commencez par des expériences petites et mesurables, et laissez votre laboratoire devenir un bac à sable pour l'innovation et l'apprentissage.