Liste de contrôle des opérations de production HDFS avec exemples pratiques

Introduction

Exploiter le système de fichiers distribué Hadoop (HDFS) en production exige des pratiques opérationnelles disciplinées. Une seule mauvaise configuration ou une tâche de maintenance oubliée peut entraîner une perte de données, une indisponibilité ou une dégradation des performances. Cet article fournit une liste de contrôle pratique pour les opérations HDFS en production, tirée de l'expérience terrain et des bonnes pratiques. Il couvre l'inventaire de l'environnement, la configuration sûre, la vérification, la reprise après incident et les opérations courantes, avec des commandes concrètes et des sorties attendues. Utilisez cette liste pour réduire les risques, rationaliser la maintenance et garantir que votre déploiement HDFS reste sain et fiable.

HDFS est l'épine dorsale du stockage de nombreuses plateformes de mégadonnées, notamment Apache Spark, NiFi et Kafka (via le connecteur HDFS de Kafka Connect). Son architecture, avec un NameNode gérant les métadonnées et des DataNodes stockant les blocs, nécessite une attention particulière à la configuration, à la surveillance et à la maintenance.

Ce guide s'adresse aux développeurs, consultants DevOps et équipes techniques de startups qui gèrent des clusters HDFS. Il suppose une compréhension de base des concepts HDFS mais se concentre sur des pratiques prêtes pour la production. Chaque section fournit des étapes concrètes, des commandes et des méthodes de vérification. Nous soulignons également les pièges courants et comment les éviter.

Inventaire de la version et de l'environnement

Avant toute modification, vous devez savoir exactement ce que vous exécutez. Un inventaire précis est la base d'opérations sûres.

Vérifier la version de Hadoop et HDFS

Utilisez la commande hdfs version pour afficher la version et les informations de build.

hdfs version

Sortie attendue (exemple pour Hadoop 3.3.6) :

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

Notez la version, car les chemins de mise à niveau et la compatibilité en dépendent.

Documenter la topologie du cluster

Enregistrez les éléments suivants :

• Nombre de NameNodes (actif et standby si la haute disponibilité est activée)
• Nombre de DataNodes
• Configuration de la sensibilisation aux racks
• Capacité de stockage par DataNode
• Disposition du réseau

Vous pouvez obtenir un aperçu rapide depuis l'interface web du NameNode (généralement le port 9870) ou via la commande :

hdfs dfsadmin -report

Ce rapport montre les nœuds actifs et morts, la capacité et les informations sur les blocs. Conservez une copie pour le suivi des changements.

Extrait de sortie attendue :

Live datanodes (3):

Name: 192.168.1.101:9866 (datanode1)
Hostname: datanode1
Decommission Status : Normal
Configured Capacity: 107374182400 (100 GB)
DFS Used: 21474836480 (20 GB)
Non DFS Used: 10737418240 (10 GB)
DFS Remaining: 75161927680 (70 GB)
...

Identifier les dépendances et les clients

Listez les applications qui lisent ou écrivent dans HDFS. Cela inclut les jobs Spark, les flux NiFi, les connecteurs Kafka et les applications personnalisées. Vérifiez leur compatibilité avec votre version HDFS, surtout lors de la planification de mises à niveau.

Exemple de matrice de dépendances :

Liste de vérification préalable

Assurez-vous que les éléments suivants sont en place :

• Version Java compatible avec Hadoop (par exemple, Java 8 ou 11, selon la version Hadoop)
• Espace disque adéquat pour les journaux et les métadonnées
• Synchronisation de l'heure (NTP) sur tous les nœuds (critique pour les opérations HDFS)
• Permissions utilisateur et groupe appropriées pour les répertoires HDFS
• Procédures de sauvegarde et de restauration testées

Responsable : Administrateur du cluster (par exemple, Priya Shah, responsable de l'ingénierie). Passez en revue cet inventaire avant tout changement majeur et mettez-le à jour trimestriellement.

Chemin de configuration sûre

Les changements de configuration doivent être incrémentaux, testés et réversibles. Évitez les modifications massives.

Comprendre les fichiers de configuration

La configuration HDFS se trouve principalement dans hdfs-site.xml et core-site.xml. Les paramètres clés incluent :

• dfs.namenode.name.dir : répertoires pour les métadonnées du NameNode
• dfs.datanode.data.dir : répertoires pour les blocs des DataNodes
• dfs.replication : facteur de réplication par défaut
• dfs.blocksize : taille de bloc en octets
• dfs.namenode.handler.count : threads de gestion RPC

Utiliser un système de gestion de configuration

Conservez les fichiers de configuration dans un contrôle de version (par exemple, Git). Utilisez des outils comme Ansible, Puppet ou Chef pour déployer les changements de manière cohérente.

Exemple de workflow Git :

git clone [email protected]:myorg/hadoop-config.git
cd hadoop-config
# éditer hdfs-site.xml
git commit -am "Augmenter le facteur de réplication à 3"
git push
# puis exécuter le playbook Ansible pour déployer

Effectuer d'abord les changements dans un environnement de préproduction

Avant d'appliquer en production, testez les changements dans un cluster de préproduction qui reflète la production. Cela permet de détecter les problèmes tôt.

Exemple : Augmenter le facteur de réplication en toute sécurité

Supposons que vous souhaitiez augmenter le facteur de réplication par défaut de 2 à 3 pour une meilleure durabilité.

1. Dans hdfs-site.xml, modifiez :

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

1. Redémarrez HDFS (ou utilisez un redémarrage roulant pour la haute disponibilité). Vérifiez le nouveau paramètre :

hdfs getconf -confKey dfs.replication

Sortie attendue :

3

1. Pour les fichiers existants, le nouveau facteur de réplication ne s'applique pas automatiquement. Vous devez définir explicitement la réplication ou exécuter un job d'équilibrage/ré-réplication. Pour un fichier spécifique :

hdfs dfs -setrep -w 3 /chemin/vers/fichier

L'option -w attend que la réplication soit terminée.

1. Vérifiez avec :

hdfs dfs -stat %r /chemin/vers/fichier

Sortie attendue si la réplication est terminée :

3

Changements de configuration en mode roulant

Pour les clusters à haute disponibilité, utilisez des redémarrages roulants pour éviter les interruptions. Par exemple, pour redémarrer les DataNodes un par un :

hdfs dfsadmin -rollingUpgrade prepare
# puis redémarrer progressivement les DataNodes

Consultez la documentation Hadoop pour la procédure exacte.

Pièges de configuration à éviter

• Modifier les répertoires du NameNode pendant son fonctionnement : Ne changez jamais dfs.namenode.name.dir sans une sauvegarde appropriée et des procédures hors ligne.
• Nombre insuffisant de threads de gestion : Trop peu de gestionnaires peut provoquer une congestion RPC. Augmentez progressivement dfs.namenode.handler.count et surveillez.
• Ignorer les paramètres de mémoire : La taille du tas du NameNode doit accueillir les métadonnées. Utilisez HADOOP_NAMENODE_OPTS pour définir un -Xmx approprié.

Responsable : Les changements de configuration doivent être approuvés par le propriétaire du cluster (par exemple, Priya Shah) et examinés chaque semaine lors de la réunion des opérations.

Vérification et diagnostics

Après tout changement, vérifiez la santé du cluster. Utilisez plusieurs outils pour des vérifications croisées.

Vérifier le résumé du cluster

Utilisez hdfs dfsadmin -report pour obtenir une vue d'ensemble.

Exemple d'extrait :

Live datanodes (3):

Name: 192.168.1.101:9866 (datanode1)
Hostname: datanode1
Decommission Status : Normal
Configured Capacity: 107374182400 (100 GB)
DFS Used: 21474836480 (20 GB)
Non DFS Used: 10737418240 (10 GB)
DFS Remaining: 75161927680 (70 GB)

Vérifiez la présence de nœuds morts ou en cours de déclassement.

Vérifier la santé du NameNode

Accédez à l'interface web du NameNode (http://namenode:9870) et vérifiez :

• Statut du mode sans échec (doit être désactivé en fonctionnement normal)
• Nombre de DataNodes actifs
• Capacité et blocs
• Toute alerte dans le journal

Alternativement, utilisez JMX ou la commande hdfs haadmin pour les clusters à haute disponibilité :

hdfs haadmin -getServiceState nn1

Sortie attendue :

active

Vérifier la santé des DataNodes

Sur chaque DataNode, vérifiez que le processus est en cours d'exécution et que les journaux sont propres.

Utilisez jps pour lister les processus Java :

jps

La sortie attendue inclut DataNode et NodeManager (si YARN est utilisé).

Vérifications du système de fichiers

Exécutez fsck pour détecter les blocs manquants ou corrompus :

hdfs fsck / -files -blocks -locations

La sortie montre la santé du système de fichiers. Recherchez « Health is GOOD ». Pour un rapport de blocs détaillé :

hdfs fsck / -blockId blk_1073741825

Diagnostics de performance

Surveillez les métriques clés :

• Longueur de la file RPC du NameNode
• Entrées/sorties disque des DataNodes
• Débit réseau
• Pauses de garbage collection de la JVM

Utilisez des outils comme Prometheus avec le récepteur de métriques Hadoop, ou Cloudera Manager/Ambari si disponible.

Exemple de métriques à suivre avec Prometheus :

Analyse des journaux

Vérifiez les journaux pour les erreurs :

tail -f /var/log/hadoop-hdfs/hdfs-audit.log

Recherchez ERROR ou FATAL dans hadoop-hdfs-namenode-*.log.

Responsable : Les tâches de vérification sont effectuées par l'ingénieur d'astreinte (par exemple, Alex Chen) et examinées quotidiennement.

Modes de défaillance et reprise

Même avec une planification minutieuse, des pannes surviennent. Sachez comment récupérer.

Modes de défaillance courants

Corruption des métadonnées du NameNode

Si le NameNode ne démarre pas en raison d'une corruption des métadonnées, vous devrez peut-être restaurer à partir d'un point de contrôle ou d'une sauvegarde. Pour les clusters à haute disponibilité, basculez vers le standby.

Étapes de récupération (sans haute disponibilité) :

1. Arrêtez le NameNode.
2. Restaurez fsimage et edits à partir de la sauvegarde (par exemple, à partir d'un point de contrôle du NameNode secondaire).
3. Redémarrez le NameNode.

Exemple de commande de restauration :

# En supposant que la sauvegarde est stockée dans /backup/namenode
cp /backup/namenode/current/fsimage_* /data/namenode/current/
cp /backup/namenode/current/edits_* /data/namenode/current/
# redémarrer le NameNode

Panne de disque d'un DataNode

Une panne de disque sur un DataNode peut provoquer une corruption de blocs. HDFS réplique les blocs, donc les données peuvent encore être disponibles. Remplacez le disque et réintégrez le DataNode.

Étapes :

1. Décommissionnez le DataNode :

hdfs dfsadmin -refreshNodes

1. Attendez que le déclassement soit terminé (vérifiez dfsadmin -report).
2. Remplacez le disque et redémarrez le DataNode.
3. Recommissionnez le nœud.

Partition réseau

Si une partition réseau se produit, certains DataNodes peuvent devenir inaccessibles. HDFS les marque comme morts après un délai. Assurez une redondance réseau.

Problèmes de basculement en haute disponibilité

Dans les configurations à haute disponibilité, le basculement automatique peut ne pas se déclencher. Utilisez hdfs haadmin -failover manuellement si nécessaire.

hdfs haadmin -failover nn1 nn2

Procédures de retour en arrière

Retour en arrière de configuration

Si un changement de configuration cause des problèmes, revenez à la version précédente dans votre système de gestion de configuration et redémarrez les services affectés.

Exemple :

git revert <hash-de-commit>
# redéployer la configuration

Retour en arrière de mise à niveau

Hadoop prend en charge les mises à niveau roulantes pour HDFS. Pour les mises à niveau majeures, vous pouvez revenir en arrière en utilisant :

hdfs dfsadmin -rollingUpgrade rollback

Cela ramène le système de fichiers à la version précédente si une mise à niveau roulante est en cours. Assurez-vous d'avoir une sauvegarde avant toute mise à niveau.

Stratégies de sauvegarde et de restauration

Des sauvegardes régulières sont cruciales. Options :

• DistCp : Copier les données vers un autre cluster ou stockage cloud.

hadoop distcp hdfs://source/chemin hdfs://cible/chemin

• Snapshots : Les snapshots HDFS fournissent des copies à un instant donné des répertoires.

Activez les snapshots sur un répertoire :

hdfs dfs -createSnapshot /data snap1

Restaurez à partir d'un snapshot :

hdfs dfs -cp /data/.snapshot/snap1/fichier /data/fichier

• Sauvegardes des métadonnées du NameNode : Utilisez dfs.namenode.name.dir avec plusieurs répertoires sur différents disques, ou utilisez les points de contrôle du NameNode secondaire.

Vérification de la reprise

Après toute reprise, exécutez fsck et vérifiez la santé du cluster pour garantir l'intégrité.

Responsable : Les procédures de reprise appartiennent à l'ingénieur d'astreinte, mais le propriétaire du cluster examine les rapports d'incident mensuellement.

Liste de contrôle des opérations

Ceci est une liste de contrôle récapitulative pour les opérations courantes. Adaptez-la à votre environnement.

Vérifications quotidiennes

• [ ] Vérifier l'interface web du NameNode pour les alertes
• [ ] Exécuter hdfs dfsadmin -report et examiner les nœuds actifs/morts
• [ ] Surveiller l'espace disque sur les DataNodes
• [ ] Examiner les journaux pour les erreurs
• [ ] Vérifier les journaux d'audit HDFS pour les accès non autorisés

Responsable : Ingénieur d'astreinte (par exemple, Alex Chen)

Vérifications hebdomadaires

• [ ] Exécuter hdfs fsck / pour détecter les problèmes de blocs
• [ ] Vérifier les blocs sous-répliqués : hdfs fsck / | grep 'Under replicated'
• [ ] Examiner l'utilisation du tas du NameNode et les journaux de garbage collection
• [ ] Vérifier que les sauvegardes sont terminées (le cas échéant)

Responsable : Administrateur du cluster (par exemple, Priya Shah)

Vérifications mensuelles

• [ ] Tester la restauration à partir d'une sauvegarde dans un environnement de préproduction
• [ ] Examiner la configuration pour les paramètres obsolètes
• [ ] Vérifier les tendances de capacité et planifier l'expansion
• [ ] Vérifier le basculement en haute disponibilité (le cas échéant)

Responsable : Administrateur du cluster et responsable de l'ingénierie

Tâches trimestrielles/annuelles

• [ ] Effectuer des tests de mise à niveau roulante
• [ ] Examiner les politiques de sécurité et les tickets Kerberos
• [ ] Effectuer un exercice de reprise après sinistre
• [ ] Mettre à jour la documentation et les procédures

Responsable : Responsable de l'ingénierie et responsable de la sécurité

Exemple : Automatiser les vérifications avec un script

Créez un script simple pour exécuter les vérifications quotidiennes et envoyer les résultats par courriel :

#!/bin/bash
# daily_hdfs_check.sh
DATE=$(date +%Y-%m-%d)
REPORT=$(hdfs dfsadmin -report)
echo "$REPORT" | mail -s "HDFS Daily Report $DATE" [email protected]

Ajoutez ceci à cron :

0 7 * * * /chemin/vers/daily_hdfs_check.sh

Métriques clés à surveiller

Utilisez un système de surveillance pour alerter sur :

• Utilisation du tas du NameNode > 80 %
• Utilisation du disque des DataNodes > 85 %
• Blocs sous-répliqués > 0 pendant une période prolongée
• Temps de traitement RPC > 100 ms en moyenne
• Latence de synchronisation du JournalNode (haute disponibilité)

Pièges courants et comment les éviter

Même les administrateurs expérimentés tombent dans des pièges. Voici les plus courants et comment les contourner.

Ignorer la planification de capacité

Pourquoi cela arrive : Les équipes se concentrent sur les besoins immédiats et ne projettent pas la croissance des données.

Comment éviter : Surveillez les tendances de capacité mensuellement. Définissez des alertes lorsque l'utilisation dépasse 70 % pour planifier l'expansion.

Récupération : Si un DataNode atteint sa pleine capacité, ajoutez de nouveaux DataNodes ou rééquilibrez le cluster avec hdfs balancer.

Négliger la vérification des sauvegardes

Pourquoi cela arrive : Les sauvegardes sont configurées mais jamais testées, ce qui conduit à une fausse confiance.

Comment éviter : Planifiez des tests de restauration mensuels dans un environnement de préproduction.

Récupération : Si les données de sauvegarde sont corrompues, examinez le pipeline de sauvegarde et réparez-le. Envisagez d'utiliser des snapshots pour une récupération à un instant donné.

Mal configurer le facteur de réplication

Pourquoi cela arrive : Réduire le facteur de réplication pour économiser de l'espace sans tenir compte de la durabilité.

Comment éviter : Maintenez toujours au moins un facteur de réplication de 3 pour les données critiques. Utilisez le codage d'effacement pour les données moins critiques afin d'économiser de l'espace.

Récupération : Si les données sont sous-répliquées, exécutez hdfs fsck / -replicate pour déclencher la réplication des blocs manquants.

Négliger les mises à jour de sécurité

Pourquoi cela arrive : Les correctifs de sécurité ne sont pas appliqués régulièrement, laissant les clusters vulnérables.

Comment éviter : Abonnez-vous aux annonces de sécurité Hadoop et planifiez des revues trimestrielles des correctifs.

Récupération : Appliquez les correctifs de sécurité dans un environnement de préproduction d'abord, puis déployez en production en utilisant des redémarrages roulants.

Ne pas documenter les changements

Pourquoi cela arrive : Les changements sont effectués à la volée sans mettre à jour la documentation, ce qui conduit à la confusion.

Comment éviter : Exigez la documentation dans le cadre du processus de gestion des changements. Utilisez le contrôle de version pour les fichiers de configuration.

Récupération : Si des changements non documentés causent des problèmes, comparez la configuration actuelle avec l'historique des versions pour identifier les différences.

Conclusion

Exploiter HDFS en production nécessite une approche systématique. En suivant la liste de contrôle de cet article, vous pouvez minimiser les risques et garder votre cluster sain. Commencez par un inventaire complet de l'environnement, effectuez les changements de configuration en toute sécurité avec des tests et un contrôle de version, vérifiez chaque changement avec des commandes concrètes et préparez-vous aux pannes avec des procédures de récupération documentées.

N'oubliez pas d'adapter cette liste de contrôle à votre environnement spécifique et de la mettre à jour à mesure que votre cluster évolue. Des révisions et des exercices réguliers garantiront que votre équipe est prête pour tout incident.

Pour mettre en œuvre cette liste de contrôle, commencez par la première étape étroite et mesurable : exécutez dès aujourd'hui les commandes de version et d'inventaire et documentez la topologie de votre cluster. Ensuite, planifiez les vérifications quotidiennes et configurez des alertes de surveillance. Au fil du temps, étendez aux tâches hebdomadaires et mensuelles, et effectuez un exercice de reprise après sinistre. Cette approche incrémentale réduit les retouches et renforce la confiance opérationnelle.