Architecture HDFS expliquée avec des exemples pratiques

Introduction

Comprendre l'architecture HDFS est essentiel pour quiconque gère du stockage de données à grande échelle dans l'écosystème Hadoop. Ce guide s'adresse aux développeurs, aux ingénieurs DevOps et aux équipes de startups qui doivent aller au-delà des schémas conceptuels et passer à des opérations pratiques et vérifiables. Nous allons parcourir les composants principaux — NameNode, DataNodes et les mécanismes qui assurent la sécurité et la disponibilité des données — à l'aide de commandes concrètes, de sorties attendues et de procédures de récupération.

L'objectif de cet article est la sécurité opérationnelle. Nous suivons un schéma : observer l'état actuel avec des commandes en lecture seule, définir le résultat attendu avant de modifier quoi que ce soit, limiter le rayon d'impact de toute intervention, et toujours savoir comment vérifier le succès ou revenir en arrière. Tous les exemples utilisent des espaces réservés comme </path/to/directory> et </namenode/hostname> ; n'utilisez jamais de véritables identifiants ou identifiants de production dans vos propres scripts.

Inventaire de la version et de l'environnement

Avant de pouvoir raisonner sur l'architecture HDFS, vous devez savoir exactement ce que vous exécutez. La première étape consiste à inventorier la version installée, la topologie de déploiement et les valeurs de configuration clés. Ces informations déterminent quelles commandes sont valides, quels signaux de défaillance sont importants et comment planifier les changements en toute sécurité.

Commencez par vérifier la version de Hadoop. Cette commande fonctionne sur n'importe quel nœud du cluster :

hadoop version

Sortie attendue sur une installation Apache Hadoop 3.3.6 typique :

Hadoop 3.3.6
Source code repository https://github.com/apache/hadoop.git -r 1be78238728da9266a4f88195058f08fd012bf9c
Compiled by ubuntu on 2023-06-18T15:43Z
Compiled with protoc 3.7.1
From source with checksum 3b6a6f8279cd9e6d4a40a4e2b1b1b7
This command was run using /opt/hadoop/share/hadoop/common/hadoop-common-3.3.6.jar

Notez la version en haut. De nombreuses procédures opérationnelles diffèrent entre les versions majeures (par exemple, le passage de Hadoop 2.x à 3.x a introduit le codage d'effacement et modifié les ports par défaut). Si vous utilisez une distribution spécifique à un fournisseur telle que Cloudera ou Hortonworks, la commande peut être encapsulée par un outil de gestion, mais la version de Hadoop sous-jacente reste critique.

Ensuite, identifiez la topologie de déploiement. HDFS a deux rôles principaux :

• NameNode : gère l'espace de noms du système de fichiers et régule l'accès des clients.
• DataNode : stocke les blocs de données réels sur les disques locaux.

En production, vous avez souvent une configuration haute disponibilité (HA) avec deux NameNodes (actif et standby) et un ensemble de JournalNodes pour la synchronisation des journaux de modifications. Pour trouver les adresses des NameNodes, inspectez hdfs-site.xml sur un nœud de configuration :

grep -A 1 'dfs.namenode.rpc-address' /etc/hadoop/conf/hdfs-site.xml

Sortie attendue (pour un cluster HA simple avec le service de noms mycluster) :

<property>
  <name>dfs.namenode.rpc-address.mycluster.nn1</name>
  <value>namenode1.example.com:8020</value>
</property>
<property>
  <name>dfs.namenode.rpc-address.mycluster.nn2</name>
  <value>namenode2.example.com:8020</value>
</property>

Si la sortie est vide, vous êtes peut-être en présence d'une configuration non-HA ou d'un mauvais répertoire de configuration. Dans ce cas, vérifiez l'emplacement par défaut /etc/hadoop/conf ou la valeur de HADOOP_CONF_DIR.

Pour voir tous les DataNodes actuellement signalés au NameNode, utilisez la commande hdfs dfsadmin :

hdfs dfsadmin -report

Cherchez la section commençant par Live datanodes. Un cluster sain avec trois DataNodes affiche :

Live datanodes (3):

Name: 10.0.0.11:9866 (datanode1.example.com)
Hostname: datanode1.example.com
Decommission Status : Normal
Configured Capacity: 1099511627776 (1 TB)
DFS Used: 219902325555 (200 GB)
Non DFS Used: 10995116277 (10 GB)
DFS Remaining: 867583393944 (790 GB)
...

Le rapport donne également l'utilisation du pool de blocs, la version et d'autres métriques utiles. Si un DataNode est manquant, le compte sera inférieur à ce qui est attendu, et c'est un signal d'alarme immédiat.

Maintenant que vous avez la version et la topologie, vous pouvez définir vos résultats attendus et vos signaux d'échec pour tout changement. Par exemple, si vous prévoyez d'ajouter un nouveau DataNode, le signal de succès est que hdfs dfsadmin -report montre le nouveau nœud dans la liste Live datanodes avec la capacité attendue. L'échec peut être un délai d'attente ou l'apparition du nœud sous Dead datanodes.

Ainsi, l'inventaire de la version et de l'environnement vous donne la base. Sans lui, toutes les autres procédures de cet article sont des conjectures.

Chemin de configuration sûr

La configuration HDFS est régie par hdfs-site.xml et core-site.xml. De nombreux paramètres affectent directement l'architecture, tels que dfs.replication, dfs.blocksize et la sensibilisation aux racks. Apporter des modifications sans comprendre le rayon d'impact peut entraîner une indisponibilité des données ou une dégradation des performances. Cette section présente une approche structurée des changements de configuration, à l'aide d'un exemple concret.

Supposons que vous souhaitiez réduire le facteur de réplication de 3 à 2 pour économiser de l'espace. C'est un changement courant mais risqué. Voici le chemin sûr :

1. Prérequis : Identifiez tous les fichiers avec le facteur de réplication actuel. Le changement n'affecte que les fichiers écrits après le changement de configuration, sauf si vous définissez explicitement la réplication sur les fichiers existants. Les nouvelles écritures utiliseront la valeur par défaut de dfs.replication. Les fichiers existants conservent leur facteur de réplication jusqu'à ce qu'une ré-réplication ou une commande manuelle soit émise.

1. Observation en lecture seule : Avant de changer quoi que ce soit, capturez le paramètre actuel et la distribution de réplication d'un répertoire d'échantillonnage.

Vérifiez le facteur de réplication par défaut actuel dans la configuration :

   hdfs getconf -confKey dfs.replication

Sortie attendue : 3

Vérifiez la réplication sur un répertoire spécifique, disons /user/hive/warehouse :

   hdfs dfs -ls /user/hive/warehouse | head -n 5

La deuxième colonne dans la sortie ls est le facteur de réplication pour chaque fichier. Par exemple :

   -rw-r--r--   3 hdfs supergroup    123456789 2024-01-05 12:34 /user/hive/warehouse/table1

Ici, le 3 après les permissions est le facteur de réplication.

1. Plus petit changement justifié : Au lieu de modifier immédiatement la valeur par défaut globale, changez le facteur de réplication sur un répertoire de test spécifique en utilisant une commande d'exécution. Cela évite de modifier le fichier de configuration pour l'ensemble du cluster.

   hdfs dfs -setrep -R 2 /user/testdir

Sortie attendue : Waiting for /user/testdir to replicate... suivie d'une confirmation. Vous pouvez vérifier avec hdfs dfs -ls /user/testdir que la colonne du facteur de réplication affiche maintenant 2.

1. Vérification : Après la configuration, vérifiez l'état de réplication réel sur un fichier dans ce répertoire.

   hdfs fsck /user/testdir -files -blocks -replicaDetails | grep -A 3 'Replication'

La sortie montrera la réplication attendue par rapport à la réplication réelle. Un fichier sain avec un facteur de réplication 2 montre quelque chose comme :

   Status: HEALTHY
   Total blocks: 1
   Replication factor: 2
   Average block replication: 2.0

1. Changement de configuration permanent (si nécessaire) : Une fois que vous avez validé que la réplication plus faible est acceptable, modifiez hdfs-site.xml sur tous les NameNodes et DataNodes (ou poussez via la gestion de configuration). Définissez :

   <property>
     <name>dfs.replication</name>
     <value>2</value>
   </property>

Ensuite, redémarrez les services HDFS ou exécutez hdfs dfsadmin -refreshNodes si seule la liste des nœuds a changé. Cependant, dfs.replication nécessite un redémarrage du NameNode pour prendre effet sur les nouveaux fichiers. Soyez conscient du processus de redémarrage roulant.

1. Chemin de récupération : Si vous constatez que des fichiers sont sous-répliqués après le changement (par exemple, en raison de contraintes de capacité), vous pouvez revenir en arrière en rétablissant le facteur de réplication à 3, soit avec hdfs dfs -setrep 3 sur les fichiers affectés, soit en restaurant la configuration et en redémarrant les services.

Une note sur le rayon d'impact : Changer dfs.replication ne supprime pas immédiatement les répliques excédentaires ; le NameNode planifiera la suppression des blocs sur-répliqués au fil du temps. Réduire la réplication réduit la redondance ; si un DataNode tombe en panne pendant cette période, certains blocs peuvent devenir indisponibles car le facteur de réplication cible n'est pas encore atteint. Surveillez donc hdfs dfsadmin -report pour les blocs sous-répliqués.

Un autre changement de configuration courant est l'activation de la sensibilisation aux racks. Cela affecte le placement des blocs et peut améliorer la tolérance aux pannes. Le chemin sûr implique de définir un script de topologie et de définir net.topology.script.file.name dans core-site.xml. Le script mappe les adresses IP ou les noms d'hôtes aux identifiants de rack. Par exemple :

#!/bin/bash
# topology.sh
HOSTNAME=$1
if [[ $HOSTNAME == datanode1* ]]; then
  echo "/rack1"
elif [[ $HOSTNAME == datanode2* ]]; then
  echo "/rack2"
else
  echo "/default-rack"
fi

Définissez net.topology.script.file.name sur le chemin du script, et testez avec hdfs dfsadmin -printTopology pour voir l'affectation des racks. Le signal de vérification est un arbre de topologie qui regroupe correctement les DataNodes en racks.

N'oubliez pas de ne jamais modifier les fichiers de configuration sans d'abord comprendre la portée et tester sur un nœud canari ou un répertoire.

Vérification et diagnostics

Après tout changement ou pendant les opérations régulières, vous devez vérifier la santé et la correction des composants HDFS. Cette section fournit un ensemble de commandes de diagnostic avec leurs sorties attendues et leurs signaux d'échec.

1. Contrôle de santé du système de fichiers

hdfs fsck est l'outil principal pour vérifier la cohérence du système de fichiers. Exécutez-le sur le répertoire racine pour obtenir un résumé :

hdfs fsck /

La sortie saine comprend :

Status: HEALTHY
Total size: 1234567890123 B
Total dirs: 450
Total files: 12000
Total blocks (validated): 36000 (avg. block size 134217728 B)
Minimally replicated blocks: 36000 (100.0 %)
Over-replicated blocks: 0 (0.0 %)
Under-replicated blocks: 0 (0.0 %)
Mis-replicated blocks: 0 (0.0 %)
Default replication factor: 3
Average block replication: 3.0
Corrupt blocks: 0
Missing replicas: 0
Number of data-nodes: 3
Number of racks: 2

Signaux d'échec à surveiller :

• Status: CORRUPT indique des blocs corrompus. Exécutez hdfs fsck / -list-corruptfileblocks pour les lister.
• Under-replicated blocks > 0 signifie que certains blocs ont moins de répliques que souhaité. Cela peut être transitoire pendant le rééquilibrage ou persistant en raison de pannes de DataNodes.
• Missing replicas > 0 indique que des répliques attendues sur des nœuds spécifiques ne sont pas trouvées. Enquêtez sur les DataNodes.

2. Santé des DataNodes

Utilisez hdfs dfsadmin -report pour voir les DataNodes vivants et morts. Déjà décrit, mais recherchez :

• Le nombre de Live datanodes correspond à ce qui est attendu.
• La liste des Dead datanodes est vide ou ne contient que des nœuds intentionnellement mis hors service.

Si un DataNode est mort, vérifiez les journaux sur ce nœud : /var/log/hadoop-hdfs/hadoop-hdfs-datanode-*.log. Recherchez les messages ERROR ou FATAL, en particulier liés aux pannes de disque ou aux problèmes réseau.

3. Interface utilisateur et JMX du NameNode

L'interface web du NameNode (port par défaut 9870 sur Hadoop 3.x) fournit un tableau de bord avec le résumé du cluster, l'état des DataNodes et la santé des blocs. Pour une vérification programmatique, interrogez JMX :

curl -s http://namenode1.example.com:9870/jmx | jq '.beans[] | select(.name=="Hadoop:service=NameNode,name=NameNodeStatus")'

La sortie attendue inclut "State":"active" ou "standby" pour HA. C'est crucial pour diagnostiquer les problèmes de basculement.

4. Analyse des journaux

La surveillance centralisée des journaux est essentielle. Les motifs de défaillance typiques dans les journaux du NameNode :

• java.io.IOException: Cannot lock storage signifie généralement qu'un autre NameNode est en cours d'exécution ou que le répertoire de stockage est corrompu.
• FATAL org.apache.hadoop.hdfs.server.namenode.NameNode: Failed to start namenode indique souvent une erreur de configuration ou des métadonnées manquantes.

Utilisez grep sur les journaux récents :

grep -i "fatal\|error\|exception" /var/log/hadoop-hdfs/hadoop-hdfs-namenode-namenode1.example.com.log | tail -n 20

5. Vérification des blocs

Pour vérifier les emplacements des blocs d'un fichier spécifique, utilisez hdfs fsck <path> -files -blocks -locations. Cela montre quels DataNodes détiennent chaque réplique, vous aidant à évaluer la diversité des racks. Par exemple :

hdfs fsck /user/test/file.txt -files -blocks -locations

Extrait de sortie :

0. BP-123456789-10.0.0.1-1616500000000:blk_1073741825_1001 len=134217728 Live_repl=3
  [DatanodeInfoWithStorage[10.0.0.11:9866,DS-xxx,DISK],
   DatanodeInfoWithStorage[10.0.0.12:9866,DS-yyy,DISK],
   DatanodeInfoWithStorage[10.0.0.13:9866,DS-zzz,DISK]]

Si les trois DataNodes sont tous sur le même rack, c'est un problème pour la tolérance aux pannes. La sensibilisation aux racks devrait placer au moins une réplique sur un rack différent.

Avec ces diagnostics, vous pouvez identifier la plupart des problèmes opérationnels avant qu'ils ne causent des temps d'arrêt.

Modes de défaillance et récupération

HDFS est conçu pour gérer les pannes, mais vous devez savoir comment réagir. Cette section couvre les scénarios de défaillance courants et les procédures de récupération étape par étape.

Scénario 1 : Panne d'un DataNode

Mode de défaillance : Un DataNode plante ou devient indisponible. Le NameNode le détectera après un délai d'attente (par défaut 10 minutes + 30 secondes) et marquera le nœud comme mort. Les blocs sur ce nœud deviennent sous-répliqués, et le NameNode commence la ré-réplication vers d'autres nœuds si la capacité le permet.

Étapes de récupération :

1. Vérifiez que le nœud est mort :

   hdfs dfsadmin -report | grep -A 5 'Dead datanodes'

Si le nœud y apparaît, continuez.

1. Vérifiez la connectivité réseau du nœud et la santé du disque. Si le nœud peut être restauré, redémarrez le service DataNode :

   systemctl restart hadoop-hdfs-datanode

1. Attendez que le nœud se rejoigne. Surveillez hdfs dfsadmin -report jusqu'à ce qu'il apparaisse sous Live datanodes.
2. Le NameNode réduira automatiquement la réplication sur le nœud restauré s'il avait été sur-répliqué en raison de la ré-réplication. Vous pouvez forcer un rééquilibrage si nécessaire.
3. Si le nœud est définitivement perdu, suivez les procédures de mise hors service pour le retirer du cluster.

Vérification : Après la récupération, vérifiez que le système de fichiers est sain :

hdfs fsck / | grep 'Under-replicated blocks'

Attendez-vous à Under-replicated blocks: 0 après que la réplication se stabilise.

Scénario 2 : Corruption des métadonnées du NameNode

Mode de défaillance : Les métadonnées du NameNode (fsimage ou journaux de modifications) deviennent corrompues, souvent à cause d'une panne de disque ou d'un arrêt brutal. Le NameNode ne démarre pas et lève des exceptions.

Étapes de récupération (pour non-HA) :

1. Identifiez les répertoires de stockage corrompus en vérifiant la propriété dfs.namenode.name.dir (typiquement /hadoop/hdfs/namenode).
2. Arrêtez le NameNode.
3. Choisissez une sauvegarde de fsimage et des journaux de modifications à partir d'un point connu bon. Si vous avez un NameNode secondaire, il peut avoir des points de contrôle.
4. Restaurez la meilleure fsimage disponible dans le répertoire de noms actif et supprimez les journaux de modifications périmés ; le point de contrôle inclut tout jusqu'à ce point.
5. Redémarrez le NameNode et acceptez que les données écrites après le point de contrôle puissent être perdues.
6. Exécutez hdfs fsck / pour garantir la cohérence du système de fichiers.

Vérification : Le NameNode démarre et le statut fsck n'est pas CORRUPT. Il peut y avoir des fichiers manquants ; identifiez-les via hdfs fsck / -files -blocks et restaurez-les à partir de sauvegardes si nécessaire.

Pour les clusters HA, le basculement vers le NameNode standby est la récupération principale. Le standby a suivi les journaux de modifications et peut être promu rapidement.

Scénario 3 : Mauvaise configuration de la sensibilisation aux racks

Mode de défaillance : Si le script de topologie de rack est erroné ou non défini, les répliques de blocs peuvent toutes se retrouver sur le même rack, ce qui réduit la tolérance aux pannes. Une panne de rack pourrait causer une indisponibilité des données.

Étapes de récupération :

1. Vérifiez la topologie actuelle :

   hdfs dfsadmin -printTopology

Si tous les DataNodes affichent le même rack ou le rack par défaut, enquêtez.

1. Corrigez le script de topologie et définissez net.topology.script.file.name.
2. Redémarrez le NameNode pour recharger le script.
3. Rééquilibrez le cluster si nécessaire : hdfs balancer -threshold 10 déplace les blocs pour satisfaire la politique et améliorer la distribution.
4. Vérifiez que les emplacements des blocs des fichiers incluent désormais les racks souhaités en utilisant hdfs fsck avec -locations.

Vérification : hdfs dfsadmin -printTopology montre un regroupement de racks correct, et hdfs fsck sur les fichiers critiques montre des répliques sur différents racks.

Scénario 4 : Épuisement de la capacité

Mode de défaillance : Le cluster manque d'espace disque, ce qui fait échouer les écritures avec DiskOutOfSpaceException et les DataNodes rapportent des volumes pleins.

Étapes de récupération :

1. Identifiez les DataNodes pleins avec hdfs dfsadmin -report et recherchez DFS Remaining proche de zéro.
2. Ajoutez plus de stockage aux DataNodes ou ajoutez de nouveaux DataNodes.
3. Si l'espace est temporairement critique, vous pouvez définir une limite basse sur certains répertoires ou supprimer des données inutiles après coordination avec les utilisateurs.
4. Exécutez l'équilibreur après l'ajout de nœuds pour redistribuer les données : hdfs balancer -threshold 5.
5. Surveillez jusqu'à ce que hdfs dfsadmin -report montre une capacité restante saine.

Vérification : Les écritures réussissent et aucun DataNode ne reste au-dessus de 90 % d'utilisation.

Ayez toujours un plan de récupération testé avant une panne. Simulez des exercices de panne dans un environnement de préproduction pour vous assurer que votre équipe sait quoi faire.

Liste de contrôle opérationnelle

Utilisez cette liste de contrôle pour les tâches opérationnelles quotidiennes, hebdomadaires et mensuelles afin de garder votre architecture HDFS saine et les pannes anticipées sous contrôle.

Contrôles quotidiens

• [ ] Exécutez hdfs dfsadmin -report et confirmez que tous les DataNodes attendus sont vivants et que la capacité est dans la plage normale. Recherchez tout nœud avec DFS Remaining inférieur à 10 % du total.
• [ ] Vérifiez l'état du NameNode : curl -s http://namenode1:9870/jmx | jq '.beans[] | select(.name=="Hadoop:service=NameNode,name=NameNodeStatus") | .State' devrait renvoyer active ou standby comme prévu.
• [ ] Consultez le résumé hdfs fsck / pour les blocs sous-répliqués ou corrompus. Agissez immédiatement si présent.
• [ ] Inspectez les journaux pour les erreurs : grep -i "error\|fatal" /var/log/hadoop-hdfs/hadoop-hdfs-namenode-*.log | tail -n 5.
• [ ] Surveillez l'utilisation du disque sur les DataNodes avec df -h sur chaque nœud, en vous assurant qu'aucun volume n'est à plus de 80 % plein.

Contrôles hebdomadaires

• [ ] Examinez la distribution de la réplication des blocs avec hdfs fsck / -files -blocks -locations | grep 'Live_repl' | awk '{print $3}' | sort | uniq -c pour repérer les fichiers avec une réplication != 3.
• [ ] Validez la sortie du script de sensibilisation aux racks : exécutez le script manuellement pour chaque nom d'hôte de DataNode et confirmez les identifiants de rack.
• [ ] Vérifiez le journal d'audit HDFS pour une activité inhabituelle : /var/log/hadoop-hdfs/hdfs-audit.log (ou emplacement configuré). Recherchez des suppressions inattendues ou des changements de permission.
• [ ] Exécutez hdfs dfsadmin -refreshNodes après tout changement de nœud planifié.

Contrôles mensuels

• [ ] Effectuez une mise à niveau roulante des fichiers de configuration si des changements sont en attente ; assurez-vous que tous les nœuds ont des hdfs-site.xml et core-site.xml cohérents.
• [ ] Testez la récupération après panne dans un environnement de préproduction : simulez une panne de DataNode et assurez-vous que le NameNode ré-réplique correctement.
• [ ] Passez en revue les tendances de planification de capacité : utilisez hdfs dfsadmin -report pour suivre l'utilisation au fil du temps et planifier des ajouts de stockage avant d'atteindre 80 %.
• [ ] Exécutez un hdfs fsck / -files -blocks -locations > fsck-report.txt complet et archivez-le pour la conformité.
• [ ] Vérifiez la stratégie de sauvegarde : vérifiez que les instantanés ou distcp vers un cluster secondaire fonctionnent, et testez la restauration d'un petit ensemble de fichiers.

Chaque élément doit avoir un propriétaire et un chemin de remédiation défini. Par exemple, si des blocs sous-répliqués sont trouvés, l'ingénieur de garde doit d'abord vérifier l'état des DataNodes, puis envisager d'ajouter des nœuds ou d'ajuster la réplication.

Conclusion

L'architecture HDFS est robuste, mais sa santé opérationnelle dépend de pratiques délibérées et vérifiables. Ce guide a couvert l'inventaire de votre environnement, la réalisation de changements de configuration en toute sécurité, le diagnostic des problèmes et la récupération après des pannes, le tout avec des commandes concrètes et des sorties attendues.

Le point clé à retenir est de ne jamais apporter un changement sans d'abord observer l'état actuel et définir le signal de succès. Utilisez libéralement les commandes en lecture seule ; restreignez les modifications à la plus petite portée possible ; et ayez toujours un plan de retour en arrière.

Commencez par une vérification à faible risque : exécutez hdfs dfsadmin -report et hdfs fsck / sur votre cluster, enregistrez les sorties et comparez-les aux exemples sains présentés ici. À partir de là, adoptez progressivement le chemin de configuration sûr et la liste de contrôle opérationnelle. N'oubliez pas qu'un flux de travail fiable rend les pannes visibles, protège les données sensibles et garantit que la récupération est un processus contrôlé plutôt qu'une course d'urgence.