HDFS : concepts avancés, commandes pratiques, diagnostics et récupération

Introduction

Le système de fichiers distribués Hadoop (HDFS) est l'épine dorsale du stockage de nombreuses plateformes de données. Savoir l'exploiter au-delà des bases distingue un cluster de production fiable d'un cluster fragile. Cet article parcourt des concepts HDFS avancés avec des exemples pratiques qui vous mènent d'un problème observé à un résultat vérifié. Vous apprendrez à identifier la version installée, inventorier la topologie de déploiement, effectuer des changements de configuration en toute sécurité, exécuter des diagnostics, gérer les pannes et suivre une liste de contrôle opérationnelle.

L'accent est mis sur la sécurité opérationnelle. Avant de modifier quoi que ce soit, observez l'état actuel. Limitez le rayon d'impact de chaque changement. Utilisez des espaces réservés plutôt que de vraies informations d'identification dans les scripts et la documentation. Vérifiez le résultat après chaque action et sachez comment récupérer si l'état attendu n'est pas atteint.

Ce guide s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui gèrent directement des clusters HDFS. Il relie les aspects internes, l'architecture, les sujets approfondis et des exemples concrets aux commandes, sorties attendues, signaux de défaillance et décisions de récupération.

Inventaire de la version et de l'environnement

Avant de toucher à HDFS, sachez exactement ce que vous exécutez. Cette section explique comment identifier la version installée, rassembler la topologie de déploiement et enregistrer l'état observable actuel à l'aide de commandes en lecture seule.

Vérification de la version HDFS

Les informations de version HDFS sont disponibles côté client et côté serveur. Côté client, exécutez :

hdfs version

Sortie attendue pour une distribution Hadoop 3.3.4 typique :

Hadoop 3.3.4
Source code repository https://github.com/apache/hadoop.git -r a585a73c3e02ac62350c136643a5e7f6095a3dbb
Compiled by ubuntu on 2022-08-03T20:09Z
Compiled with protoc 3.7.1
From source with checksum fb9dd0808f5efaf0b7af0e2b4d22242
This command was run using /opt/hadoop/share/hadoop/common/hadoop-common-3.3.4.jar

Notez la chaîne de version et la date de build. Si vous avez plusieurs installations Hadoop, assurez-vous d'exécuter hdfs version avec le même PATH et les mêmes variables d'environnement que ceux utilisés par les services.

Découverte de la topologie de déploiement

Comprenez où vivent les NameNodes et les DataNodes. Depuis l'interface web du NameNode (port par défaut 9870), cliquez sur l'onglet DataNodes pour voir la liste. Vous pouvez aussi utiliser la ligne de commande :

hdfs dfsadmin -report

Cela affiche un rapport avec la capacité du cluster, les nœuds vivants, les nœuds morts et les détails de stockage par nœud. Enregistrez la sortie dans un fichier horodaté :

hdfs dfsadmin -report > hdfs-report-$(date +%Y%m%d-%H%M%S).txt

Commandes d'observation en lecture seule

Commencez toujours par des commandes en lecture seule pour éviter toute modification accidentelle. Voici les plus essentielles :

• Vérifier la santé du système de fichiers :

hdfs fsck / -files -blocks -locations

• Lister tous les DataNodes avec leurs informations de stockage :

hdfs dfsadmin -printTopology

• Afficher les valeurs de configuration actuelles (remplacez dfs.replication par n'importe quel paramètre) :

hdfs getconf -confKey dfs.replication

Capturez la sortie et comparez-la aux valeurs attendues avant de faire des modifications.

Prérequis et rayon d'impact

Pour tout changement, identifiez les prérequis. Par exemple, pour mettre hors service un DataNode, assurez-vous que le cluster a assez de capacité pour gérer la re-réplication des données. Vérifiez d'abord le facteur de réplication et l'espace disponible :

hdfs dfsadmin -report | grep -A5 "Live datanodes"

Ensuite, estimez le rayon d'impact. La mise hors service d'un nœud contenant 10 To de données provoquera la re-réplication de ces données sur les nœuds restants. Vérifiez que le cluster peut absorber la charge supplémentaire sans dépasser 80 % de capacité sur un nœud.

Chemin sûr pour la configuration

Modifier la configuration HDFS peut avoir des effets étendus. Cette section présente un chemin sûr pour changer les paramètres de configuration, incluant l'observation, les changements ciblés, la vérification et le retour en arrière.

Observation avant le changement

Avant de modifier un paramètre de configuration, enregistrez la valeur actuelle et sa source. La configuration dans HDFS provient de plusieurs fichiers : hdfs-site.xml, core-site.xml et des scripts d'environnement. Utilisez :

hdfs getconf -confKey dfs.blocksize

Pour voir quel fichier définit la clé, exécutez :

hdfs getconf -confKey dfs.blocksize -source

La sortie peut ressembler à :

/opt/hadoop/etc/hadoop/hdfs-site.xml

Sauvegardez le fichier concerné avant de l'éditer :

cp /opt/hadoop/etc/hadoop/hdfs-site.xml /opt/hadoop/etc/hadoop/hdfs-site.xml.bak-$(date +%Y%m%d)

Changement le plus petit et justifié

Changez un paramètre à la fois. Par exemple, si vous devez augmenter la taille de bloc pour les nouveaux fichiers de 128 Mo à 256 Mo, modifiez hdfs-site.xml :

<property>
  <name>dfs.blocksize</name>
  <value>268435456</value>
  <description>Taille de bloc en octets (256 Mo).</description>
</property>

Remarque : la taille de bloc est spécifiée en octets. 256 Mo = 256 1024 1024 = 268 435 456.

Étape de vérification

Après avoir modifié hdfs-site.xml sur le NameNode et les DataNodes (si nécessaire), redémarrez les services concernés et vérifiez que la nouvelle valeur est active :

hdfs getconf -confKey dfs.blocksize

Sortie attendue :

268435456

Testez le changement avec un vrai fichier :

hdfs dfs -Ddfs.blocksize=268435456 -put /tmp/testfile /user/test/
hdfs fsck /user/test/testfile -files -blocks

La sortie de fsck doit montrer des blocs de taille 268435456 octets.

Retour en arrière et récupération

Si le changement cause des problèmes, revenez en arrière en restaurant le fichier de configuration sauvegardé et en redémarrant les services. Documentez les étapes de retour en arrière avant d'appliquer le changement. Pour l'exemple de la taille de bloc :

cp /opt/hadoop/etc/hadoop/hdfs-site.xml.bak-YYYYMMDD /opt/hadoop/etc/hadoop/hdfs-site.xml
# Redémarrez le NameNode et les DataNodes

Testez toujours le retour en arrière dans un environnement hors production d'abord.

Vérification et diagnostics

Diagnostiquer les problèmes HDFS nécessite une approche systématique. Cette section couvre les commandes de diagnostic courantes, l'interprétation de leur sortie et l'identification des causes profondes.

Commandes de diagnostic clés

• Vérifier l'état du NameNode :

hdfs haadmin -getAllServiceState

Sortie attendue dans une configuration haute disponibilité (HA) :

namenode1: active
namenode2: standby

• Vérifier la connectivité des DataNodes :

hdfs dfsadmin -report

Cherchez des lignes comme Decommission Status: Normal et Last contact: avec des horodatages récents.

• Inspecter les métadonnées du système de fichiers :

hdfs fsck / -list-corruptfileblocks

Si des blocs corrompus existent, la commande les liste. Enquêtez ensuite sur le fichier spécifique :

hdfs fsck /path/to/file -files -blocks -locations

Interprétation des signaux de défaillance

• Blocs sous-répliqués : Exécutez hdfs fsck / et cherchez Under-replicated blocks. Si le nombre est non nul, certains blocs ont moins de réplicas que le facteur de réplication. Cela peut être dû à des DataNodes morts, des problèmes réseau ou une charge élevée. Utilisez :

hdfs fsck / -under-replicated

• Blocs manquants : hdfs fsck / -missing montre les fichiers avec des blocs manquants. C'est un problème sérieux qui peut entraîner une perte de données. Identifiez les fichiers affectés et restaurez depuis une sauvegarde si disponible.

• Défaillances de volume DataNode : Vérifiez les journaux du DataNode pour des erreurs IOException ou des erreurs disque. Utilisez df -h sur chaque DataNode pour inspecter l'utilisation du disque et sa santé.

Exemple de flux de travail de diagnostic

Supposons que vous remarquiez des performances de lecture lentes sur certains fichiers. Suivez ces étapes :

1. Identifiez les fichiers lents en surveillant les journaux applicatifs ou en utilisant hdfs dfs -ls pour trouver les gros fichiers.
2. Vérifiez les emplacements des blocs pour un fichier suspect :

hdfs fsck /path/to/slowfile -files -blocks -locations

1. Si la sortie montre que la plupart des blocs sont situés sur un seul DataNode, cela peut indiquer un problème de localité des données ou un nœud lent. Comparez le débit réseau entre les nœuds avec iperf.
2. Vérifiez les métriques du DataNode via l'interface web (port 9864) pour voir les E/S disque et réseau.
3. Si un disque particulier est lent, envisagez de déplacer les données hors de ce disque ou de remplacer le matériel.

Modes de défaillance et récupération

HDFS est conçu pour gérer les pannes, mais les opérateurs doivent savoir comment réagir. Cette section décrit les modes de défaillance courants, leurs symptômes et les procédures de récupération.

Défaillance du NameNode

Symptôme : HDFS devient indisponible. Les clients ne peuvent ni lire ni écrire de fichiers. Le processus NameNode est peut-être arrêté ou la machine est injoignable.

Diagnostic :

hdfs haadmin -getAllServiceState

Si les deux NameNodes sont en standby ou si la commande échoue, le NameNode est probablement en panne.

Récupération (en configuration HA) : Passez le NameNode de secours en actif :

hdfs haadmin -transitionToActive namenode2

Sans HA, récupérez à partir des sauvegardes de métadonnées. Arrêtez le NameNode, restaurez le dernier fsimage et les journaux d'édition, puis redémarrez. Assurez-vous que le répertoire de métadonnées est intact.

Défaillance du DataNode

Symptôme : HDFS continue de fonctionner, mais les données sont sous-répliquées. hdfs dfsadmin -report montre des nœuds morts.

Diagnostic :

hdfs dfsadmin -report | grep -A5 "Dead datanodes"

Récupération : Si le nœud est définitivement mort, mettez-le hors service (s'il fonctionne encore) ou retirez-le du cluster. D'abord, marquez-le comme hors service en l'ajoutant au fichier dfs.hosts.exclude. Ensuite, exécutez :

hdfs dfsadmin -refreshNodes

Attendez que les blocs soient répliqués vers d'autres nœuds. Surveillez la progression avec hdfs dfsadmin -report jusqu'à ce que le nœud soit complètement hors service.

Corruption des données

Symptôme : Les applications signalent des erreurs de somme de contrôle lors de la lecture de fichiers. hdfs fsck / -list-corruptfileblocks montre les fichiers corrompus.

Diagnostic : Identifiez le fichier corrompu et ses blocs.

Récupération : Si le fichier a d'autres réplicas sains, HDFS réparera automatiquement en copiant un bon réplica. Forcez la re-réplication :

hdfs debug recoverLease -path /path/to/corruptfile -retries 3

Si aucun réplica sain n'existe, restaurez depuis une sauvegarde ou acceptez la perte de données.

Partitions réseau

Symptôme : Les DataNodes perdent la connectivité avec le NameNode, ce qui fait que les blocs sont marqués comme manquants. hdfs dfsadmin -report montre des nœuds avec des temps de dernier contact très anciens.

Récupération : Résolvez le problème réseau, puis redémarrez les processus DataNode si nécessaire. HDFS réconciliera automatiquement les rapports de blocs.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour les opérations HDFS de routine. Remplacez les espaces réservés par les valeurs réelles de votre environnement.

Vérifications quotidiennes

• [ ] Exécutez hdfs dfsadmin -report et confirmez qu'il n'y a pas de nœuds morts. Responsable : Administrateur Hadoop principal. Révision : quotidienne à 9 h.
• [ ] Vérifiez l'utilisation du tas JVM du NameNode via l'interface web ou JMX. Alertez si elle dépasse 80 %. Responsable : Équipe de surveillance. Révision : quotidienne.
• [ ] Exécutez hdfs fsck / -summary et notez tout bloc sous-répliqué ou manquant. Responsable : Opérateur Hadoop. Révision : quotidienne après génération du rapport.

Vérifications hebdomadaires

• [ ] Examinez l'utilisation du disque sur tous les DataNodes. Assurez-vous qu'aucun disque n'est plein à plus de 80 %. Responsable : Administrateur de stockage. Révision : lundi matin.
• [ ] Vérifiez les journaux d'audit HDFS pour les tentatives d'accès non autorisées. Responsable : Équipe de sécurité. Révision : hebdomadaire.
• [ ] Vérifiez que les sauvegardes des métadonnées du NameNode sont effectuées et restaurables. Responsable : Administrateur de sauvegarde. Révision : vendredi.

Vérifications mensuelles

• [ ] Testez le basculement du NameNode en environnement HA. Planifiez une fenêtre de maintenance et simulez une panne. Responsable : Architecte Hadoop. Révision : premier dimanche du mois.
• [ ] Validez la conformité du facteur de réplication des données pour tous les jeux de données. Exécutez un script pour comparer la réplication réelle et attendue. Responsable : Data Steward. Révision : fin de mois.
• [ ] Examinez et mettez à jour les paramètres de configuration HDFS pour l'optimisation des performances. Responsable : Ingénieur performance. Révision : mensuelle après la réunion de planification de capacité.

Avant les changements majeurs

• [ ] Prévenez les parties prenantes au moins 48 heures à l'avance. Responsable : Gestionnaire de changements.
• [ ] Effectuez une sauvegarde complète des métadonnées du NameNode et des données critiques. Responsable : Administrateur de sauvegarde.
• [ ] Effectuez le changement dans un environnement de préproduction d'abord. Responsable : Ingénieur DevOps.
• [ ] Préparez un plan de retour en arrière et testez-le. Responsable : Ingénieur DevOps.
• [ ] Après le changement, surveillez le cluster pendant au moins 24 heures. Responsable : Équipe d'exploitation.

Pièges courants et comment les éviter

Même les opérateurs expérimentés font des erreurs. Voici les pièges les plus courants dans les opérations HDFS et comment les éviter.

1. Modifier la configuration sans contrôle de version

Pourquoi cela arrive : Les corrections rapides sont souvent faites directement sur le serveur sans mettre à jour le dépôt central de configuration.

Comment l'éviter : Utilisez un système de gestion de configuration comme Ansible, Puppet ou Chef. Stockez les fichiers de configuration HDFS dans Git et exigez une revue par les pairs pour les changements.

Récupération : Si un changement est effectué hors contrôle de version, validez immédiatement l'état actuel avec une note, puis comparez avec la version précédente pour identifier les différences.

2. Ignorer les blocs sous-répliqués

Pourquoi cela arrive : Les équipes occupées peuvent ignorer les avertissements de fsck, pensant qu'ils sont temporaires.

Comment l'éviter : Configurez des alertes pour le nombre de blocs sous-répliqués. Si le compte reste supérieur à zéro pendant plus de quelques heures, enquêtez et résolvez.

Récupération : Si les données sont sous-répliquées depuis longtemps, certains réplicas peuvent être perdus. Exécutez hdfs fsck / -under-replicated pour lister les fichiers affectés, puis forcez la re-réplication avec hdfs dfsadmin -setrep 3 /path/to/file (où 3 est votre facteur de réplication souhaité).

3. Mettre hors service des nœuds trop rapidement

Pourquoi cela arrive : Les administrateurs peuvent retirer un nœud du cluster sans attendre la fin du processus de mise hors service, ce qui entraîne une perte de données.

Comment l'éviter : Utilisez toujours le processus de mise hors service via dfs.hosts.exclude. Surveillez la progression avec hdfs dfsadmin -report jusqu'à ce que le nœud affiche Decommission Status: Decommissioned.

Récupération : Si un nœud est retiré de force, exécutez hdfs fsck / pour identifier les blocs manquants et restaurez depuis une sauvegarde si nécessaire.

4. Ne pas tester le basculement

Pourquoi cela arrive : Le basculement HA est supposé fonctionner jusqu'à ce qu'il soit nécessaire en cas d'urgence.

Comment l'éviter : Planifiez des exercices de basculement réguliers. Utilisez hdfs haadmin -failover namenode1 namenode2 pour tester.

Récupération : Si le basculement échoue pendant un exercice, enquêtez immédiatement sur la cause. Vérifiez les JournalNodes, Zookeeper et la connectivité réseau entre les NameNodes.

5. Ignorer la santé des disques

Pourquoi cela arrive : Les défaillances de disque sont graduelles et peuvent ne pas déclencher d'alertes immédiates.

Comment l'éviter : Surveillez les attributs SMART et les taux d'erreur disque. Configurez des alertes pour toute augmentation des erreurs de lecture/écriture.

Récupération : Remplacez rapidement les disques défaillants. Utilisez hdfs dfsadmin -triggerBlockReport pour accélérer le rapport de blocs après le remplacement.

Conclusion

Les opérations HDFS avancées exigent une approche disciplinée. Chaque recommandation de cet article est délimitée par version, observable et réversible lorsque la technologie le permet. Copier une commande sans vérifier les prérequis et la sortie attendue n'est pas une procédure d'exploitation ; c'est une recette pour des incidents.

Commencez par une vérification à faible risque de la liste de contrôle : enregistrez l'état actuel, exécutez la vérification documentée, comparez le résultat avec le signal attendu et examinez les dépendances comme Apache Spark, NiFi ou Kafka s'ils interagissent avec HDFS dans votre environnement.

Un flux de travail technique fiable rend la défaillance visible, protège les valeurs sensibles, limite les changements à la ressource prévue et définit la vérification de récupération avant qu'un incident ne force la décision. Intégrez ces habitudes à votre routine quotidienne, et votre cluster HDFS restera stable et performant.