Introduction
La planification de la capacité pour HDFS est une responsabilité essentielle pour les ingénieurs plateforme, les ingénieurs de données et les équipes DevOps qui gèrent des clusters Hadoop. Se tromper conduit soit à un surprovisionnement coûteux, soit à des pannes douloureuses lorsque le cluster manque de stockage. Ce guide fournit des méthodes pratiques et des exemples concrets pour dimensionner la capacité HDFS, depuis l'évaluation de l'utilisation actuelle jusqu'à la prévision de la croissance et l'ajustement sécurisé des ressources.
Nous mettons l'accent sur la sécurité opérationnelle : comprenez votre situation de référence avant de faire des changements, utilisez des commandes en lecture seule pour l'évaluation, limitez la portée des interventions et vérifiez chaque changement avec un plan de retour en arrière. Les exemples utilisent des valeurs génériques comme /datalake, hdfsuser et 2024-03-31 pour illustrer les commandes sans exposer de données de production réelles. Tous les chiffres sont indicatifs, vous devez les remplacer par les valeurs de votre environnement.
Évaluer la capacité et l'utilisation actuelles
Avant de planifier, vous avez besoin d'une image précise de la capacité et de la consommation actuelles. Commencez par identifier votre distribution Hadoop et sa version, car la syntaxe des commandes peut varier. Vérifiez la version avec :
hdfs version
Exemple de sortie :
Hadoop 3.3.6
Ensuite, collectez les métriques de stockage du cluster avec la commande hdfs dfsadmin -report. Cette commande est en lecture seule et peut être exécutée à tout moment sans risque.
hdfs dfsadmin -report
La sortie résume l'état de tous les DataNodes. Les lignes clés incluent :
Configured Capacity: capacité de stockage brute totale disponible.DFS Used: stockage consommé par les données HDFS.Non DFS Used: stockage utilisé par le système de fichiers local en dehors de HDFS.DFS Remaining: stockage disponible pour les données HDFS.
Extrait d'exemple :
Configured Capacity: 10995116277760 (10 TB)
DFS Used: 3298534883328 (3 TB)
Non DFS Used: 1099511627776 (1 TB)
DFS Remaining: 6597069766656 (6 TB)
Calculez le taux d'utilisation actuel avec :
Utilisation = DFS Used / Configured Capacity
Dans cet exemple : 3 TB / 10 TB = 0,30 soit 30 %.
Suivez l'évolution de l'utilisation dans le temps en exécutant ce rapport régulièrement, par exemple chaque semaine, ou utilisez un outil de surveillance comme Prometheus avec l'exportateur HDFS. Un taux de croissance de 0,5 TB par mois, par exemple, signifierait un doublement de l'utilisation en 14 mois ; il est donc essentiel de collecter au moins trois mois d'historique avant de faire des prévisions.
Prévoir les besoins futurs en capacité
La planification de la capacité consiste à anticiper la demande future, pas seulement l'utilisation actuelle. Estimez la croissance en analysant la consommation historique sur une période de 3, 6 ou 12 mois. Une méthode simple consiste à calculer le taux de croissance mensuel moyen.
Par exemple, si l'utilisation passe de 2,5 TB à 3 TB en 3 mois, la croissance linéaire mensuelle est d'environ 0,17 TB par mois. Vous pouvez aussi calculer un taux de croissance mensuel composé (CMGR) avec :
CMGR = (Utilisation finale / Utilisation initiale)^(1/n) - 1
En appliquant les chiffres : (3 / 2,5)^(1/3) - 1 = 0,0627, soit environ 6,3 % par mois.
Choisissez le modèle de croissance qui correspond à votre profil de données. Pour des clusters avec une ingestion régulière, un modèle linéaire comme 0,2 TB par mois peut être plus précis. Pour des charges pilotées par les utilisateurs ou variables, un modèle en pourcentage comme 5 % mensuel peut être meilleur. Ajoutez toujours une marge de sécurité à votre prévision, par exemple 20 %, pour absorber les pics imprévus.
Exemple de calcul pour les 12 prochains mois avec un taux de croissance de 5 % par mois et une marge de 20 % :
Utilisation actuelle : 3 TB Taux de croissance mensuel : 5 % Période cible : 12 mois
Utilisation projetée sans marge = 3 TB x (1 + 0,05)^12 = 3 TB x 1,7959 = 5,39 TB Marge = 5,39 TB x 0,20 = 1,08 TB Capacité totale projetée nécessaire = 5,39 TB + 1,08 TB = 6,47 TB
Arrondissez et ajoutez une surcharge pour le facteur de réplication et l'espace temporaire.
Tenir compte de la réplication et des surcharges
HDFS réplique chaque bloc pour la tolérance aux pannes. Le facteur de réplication par défaut est 3, ce qui signifie que chaque octet de données occupe 3 octets de stockage brut. La sortie de hdfs dfsadmin -report peut montrer la réplication par fichier, mais vous pouvez vérifier la valeur par défaut avec :
hdfs getconf -confKey dfs.replication
Sortie typique :
3
Si vos données ne sont pas hautement critiques, vous pourriez réduire la réplication à 2, ce qui réduit considérablement les besoins de stockage. Cependant, pesez le risque de perte de données.
Les surcharges dues aux fichiers temporaires et aux données intermédiaires doivent également être prises en compte. Les sources courantes de surcharge incluent :
- Les données intermédiaires MapReduce, consommant souvent 10 à 20 % de la taille des données d'entrée du job.
- La corbeille HDFS (période de rétention généralement de 7 jours).
- Les fichiers journaux.
Une règle empirique courante est d'ajouter 25 % de surcharge en plus de la taille des données projetées. Pour notre exemple :
Utilisation projetée pour les données seules : 5,39 TB Facteur de réplication à 3 : 5,39 TB x 3 = 16,17 TB Surcharge (25 % des données répliquées) : 16,17 TB x 0,25 = 4,04 TB Capacité brute totale requise : 16,17 TB + 4,04 TB = 20,21 TB
Ainsi, pour stocker 5,39 TB de données logiques au cours de l'année à venir avec réplication et surcharge, vous auriez besoin d'environ 20,21 TB de capacité configurée.
Il est également important de considérer la capacité utilisable après la surcharge du système de fichiers. Le Non DFS Used affiché dans dfsadmin -report est l'espace réservé au système de fichiers local et ne peut pas être utilisé par HDFS. Vous devez le soustraire de la capacité configurée pour calculer l'espace utilisable.
Exemple : Capacité configurée : 20 TB Non DFS Used : 2 TB Capacité HDFS utilisable = 20 TB - 2 TB = 18 TB
Assurez-vous que vos besoins en capacité brute projetée ne dépassent pas 80 % de la capacité utilisable pour garder une marge pour les pannes de nœuds et le rééquilibrage.
Configurer les quotas d'espace et les limites
Les quotas HDFS empêchent une utilisation incontrôlée par des répertoires ou des utilisateurs particuliers. Deux types principaux :
- Quota d'espace : limite l'espace total (en octets) qu'un répertoire peut consommer.
- Quota de noms : limite le nombre de fichiers et de répertoires dans une arborescence.
Définissez un quota d'espace avec :
hdfs dfsadmin -setSpaceQuota 5T /user/hdfsuser/project
Vérifiez les quotas avec :
hdfs dfs -count -q /user/hdfsuser/project
Exemple de sortie :
none inf 5497558138880 5497558138880 1 2 2000 /user/hdfsuser/project
Cela indique qu'un quota d'espace de 5 TB (5497558138880 octets) a été défini et que le répertoire est actuellement vide.
Pour modifier ou supprimer un quota, utilisez :
# Changer le quota à 6 TB
hdfs dfsadmin -setSpaceQuota 6T /user/hdfsuser/project
# Supprimer le quota
hdfs dfsadmin -clrSpaceQuota /user/hdfsuser/project
Définissez un quota de noms (par exemple, 100 000 fichiers) :
hdfs dfsadmin -setQuota 100000 /user/hdfsuser/project
Il est également utile d'activer la corbeille pour récupérer les suppressions accidentelles. Configurez fs.trash.interval dans core-site.xml :
<property>
<name>fs.trash.interval</name>
<value>1440</value> <!-- minutes = 1 jour -->
</property>
Après avoir modifié la configuration, redémarrez le NameNode ou rechargez la configuration selon le cas.
Faire évoluer HDFS en ajoutant des DataNodes
Lorsque les besoins en stockage augmentent, le remède typique est d'ajouter des DataNodes. La procédure sur la plupart des distributions est :
- Installez le logiciel Hadoop sur les nouveaux nœuds en respectant la version existante.
- Configurez
hdfs-site.xmlavec les mêmes paramètres de cluster, en particulier l'adresse du NameNode. - Démarrez le service DataNode.
- Vérifiez que le nouveau nœud s'enregistre et contribue au stockage.
Vérifiez l'état avec :
hdfs dfsadmin -report
Après avoir ajouté un nœud de 2 TB de capacité, vous devriez voir une augmentation de Configured Capacity et DFS Remaining.
Exemple : avant l'ajout, Configured Capacity était de 20 TB ; après l'ajout, elle passe à 22 TB.
Un piège est d'ajouter des nœuds avec des capacités de stockage hétérogènes, ce qui peut entraîner un déséquilibre des données. L'équilibreur HDFS peut redistribuer les données :
hdfs balancer -threshold 10
Cette commande s'exécute jusqu'à ce que le cluster soit équilibré avec un écart maximal de 10 % dans l'utilisation du stockage entre les DataNodes. Cela peut prendre des heures et consommer de la bande passante réseau, planifiez-le donc pendant les périodes de faible activité.
Si vous devez décommissionner un nœud, utilisez :
# Ajouter le nœud au fichier d'exclusion (par exemple, /etc/hadoop/conf/dfs.exclude)
echo "datanode5.example.com" >> dfs.exclude
hdfs dfsadmin -refreshNodes
Surveillez l'état de la décommission avec dfsadmin -report jusqu'à ce que l'état du nœud indique Decommissioned.
Surveiller et alerter sur la capacité
Une surveillance proactive prévient les urgences. Métriques clés à surveiller :
- Pourcentage de capacité HDFS utilisée.
- Espace restant.
- Pannes de DataNodes.
- Blocs de réplication en attente.
Utilisez les points de terminaison JMX intégrés pour l'intégration avec les outils de surveillance. Par exemple, récupérez les métriques du NameNode avec :
curl -s http://namenode:9870/jmx?qry=Hadoop:service=NameNode,name=FSNamesystem
Analysez le JSON pour obtenir CapacityUsed, CapacityRemaining, PercentUsed, etc.
Pour les alertes, définissez des seuils :
- Avertissement à 80 % de capacité utilisée.
- Critique à 90 % de capacité utilisée.
Lorsque la capacité dépasse 90 %, une action immédiate telle que la suppression de données obsolètes, l'ajout de nœuds ou l'augmentation des quotas est requise.
Surveillez également UnderReplicatedBlocks et MissingBlocks via :
hdfs fsck / -blocks -files -locations | grep -E "Under-replicated|Missing"
Exemple de sortie :
Status: HEALTHY
Total size: 5497558138880 B (Total open files size: 0 B)
Total dirs: 10000
Total files: 50000
Total blocks (validated): 40000 (avg. block size 134217728 B)
Minimally replicated blocks: 40000 (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
Missing blocks: 0
Corrupt blocks: 0
Missing replicas: 0
Pièges courants et comment les éviter
- Sous-estimer la croissance : beaucoup d'équipes basent la capacité sur l'utilisation actuelle sans tenir compte des pics saisonniers ou des nouvelles sources de données. Utilisez toujours les tendances historiques et incluez une marge.
- Pourquoi cela arrive : manque de données historiques ou ignorance des changements métier.
- Comment l'éviter : collectez au moins 3 mois de métriques d'utilisation et révisez trimestriellement.
- Ignorer la réplication et les surcharges : planifier uniquement la taille des données logiques conduit à manquer d'espace physique.
- Pourquoi cela arrive : simplification des calculs de capacité.
- Comment l'éviter : multipliez toujours par le facteur de réplication et ajoutez 25 % de surcharge.
- Ne pas définir de quotas : sans quotas, un seul utilisateur ou job peut remplir tout le cluster, provoquant des échecs pour tous.
- Pourquoi cela arrive : surcharge administrative perçue ou absence d'application.
- Comment l'éviter : définissez des quotas sur tous les répertoires partagés et appliquez-les par politique.
- Négliger la santé des DataNodes : un cluster peut avoir une capacité globale suffisante mais de nombreux nœuds sous-performants ou en panne, entraînant une indisponibilité des données.
- Pourquoi cela arrive : se concentrer sur les chiffres globaux en ignorant les nœuds individuels.
- Comment l'éviter : surveillez les métriques par nœud et alertez sur tout nœud avec une utilisation supérieure à 90 % ou des pannes fréquentes.
- Surprovisionnement : acheter trop de stockage gaspille de l'argent. Équilibrez performance et coût en dimensionnant correctement sur la base des prévisions.
- Pourquoi cela arrive : peur de manquer d'espace sans plan solide.
- Comment l'éviter : utilisez la méthode de prévision ci-dessus, achetez par incréments et ajoutez de la capacité selon les besoins.
- Ne pas tester les procédures de récupération : si vous ne testez jamais l'ajout ou la décommission de nœuds, vous risquez des retards lors d'une urgence réelle.
- Pourquoi cela arrive : supposer que les procédures fonctionnent sans pratique.
- Comment l'éviter : effectuez régulièrement des exercices de reprise après sinistre et documentez toutes les étapes.
Liste de contrôle opérationnelle
Utilisez cette liste de contrôle comme revue mensuelle pour garder la capacité HDFS sur la bonne voie. Le responsable est l'administrateur de la plateforme HDFS, et la liste est examinée par le gestionnaire de la plateforme de données lors de la réunion mensuelle d'infrastructure.
| # | Tâche | Commande ou outil | Résultat attendu | Responsable | Fréquence |
|---|---|---|---|---|---|
| 1 | Vérifier la capacité totale et les pourcentages d'utilisation | hdfs dfsadmin -report | DFS Used% inférieur à 80 % | Admin plateforme HDFS | Hebdomadaire |
| 2 | Surveiller la tendance de croissance | Exportateur Prometheus HDFS, graphique sur 30 jours | Croissance linéaire ou en pourcentage conforme aux prévisions | Ingénieur données | Hebdomadaire |
| 3 | Vérifier les quotas sur les répertoires critiques | hdfs dfs -count -q /chemin | La valeur du quota correspond à la politique | Admin plateforme HDFS | Mensuel |
| 4 | Vérifier la santé des DataNodes | hdfs dfsadmin -report et métriques JMX | Tous les DataNodes Live et utilisation équilibrée | Admin plateforme HDFS | Quotidien |
| 5 | Examiner les prévisions par rapport à l'utilisation réelle | Tableur ou outil BI | Écart inférieur à 10 % par rapport aux prévisions | Gestionnaire plateforme données | Mensuel |
| 6 | Tester le processus de décommission en staging | Ajouter un nœud de test à la liste d'exclusion et rafraîchir | Nœud décommissionné sans perte de données | Admin plateforme HDFS | Trimestriel |
| 7 | Auditer les fichiers et répertoires les plus consommateurs | hdfs dfs -du -h / | Identifier les principaux consommateurs ; agir si anormal | Admin plateforme HDFS | Mensuel |
| 8 | Valider la conformité du facteur de réplication | hdfs fsck / -files -blocks -locations | Aucun bloc sous-répliqué | Admin plateforme HDFS | Hebdomadaire |
| 9 | Vérifier la vidange de la corbeille | hdfs dfs -du -h /user/hdfsuser/.Trash | Taille de la corbeille dans les limites attendues | Admin plateforme HDFS | Mensuel |
| 10 | Planifier les ajouts de capacité si les prévisions l'indiquent | Document de prévision de capacité | Acheter ou ajouter des nœuds au moins 2 mois avant le besoin | Gestionnaire plateforme données | Trimestriel |
Conclusion
Une planification efficace de la capacité HDFS combine une évaluation systématique, des prévisions prudentes et des pratiques opérationnelles disciplinées. En mesurant régulièrement l'utilisation, en projetant la croissance avec des marges, en tenant compte de la réplication et des surcharges, et en appliquant des quotas, vous pouvez éviter à la fois un surprovisionnement coûteux et des pénuries critiques.
Commencez par exécuter hdfs dfsadmin -report aujourd'hui pour établir votre référence. Ensuite, mettez en place un processus de suivi hebdomadaire simple, et en un mois vous aurez les données nécessaires pour prévoir avec précision. Rappelez-vous que la planification de la capacité n'est pas une tâche ponctuelle mais un cycle continu de mesure, planification, action et revue.
Avec les commandes, les exemples et les listes de contrôle de ce guide, vous pouvez gérer en toute confiance la croissance du stockage HDFS tout en minimisant les risques pour votre environnement de production.