Mise à niveau et migration HDFS avec exemples pratiques : guide d'implémentation

Introduction

HDFS est l'épine dorsale de nombreuses plateformes data. Sa mise à niveau ou sa migration doit donc être prédictible, observable et réversible. Ce guide fournit une approche éprouvée sur le terrain, avec des étapes concrètes, des commandes et des vérifications. Vous allez :

• Réaliser l'inventaire des versions, de la topologie et des dépendances.
• Choisir un chemin sûr : rolling upgrade, redémarrage (offline) ou migration vers un nouveau cluster.
• Exécuter des étapes gardées par des garde-fous avec des exemples concrets.
• Valider l'exactitude et la performance.
• Gérer les pannes et effectuer un rollback ou une reprise propre.
• Réutiliser une checklist opérationnelle.

Commencez par un pilote étroit, mesurable et facilement observable localement avant un déploiement sur tout le parc. Choisissez un répertoire contenu ou un locataire non critique pour dérouler de bout en bout, éprouver vos runbooks et réduire le risque.

Inventaire des versions et de l'environnement

Avant toute action, capturez l'état actuel et cible et confirmez les prérequis.

• Versions HDFS actuelles et cibles (et distribution Hadoop si applicable).
• Topologie NameNode : NN unique ou HA (active/standby), JournalNodes, ZKFC.
• DataNodes : nombre, capacité, taux d'utilisation moyen.
• Sécurité : royaume Kerberos, keytabs, principaux de service ; paramètres TLS.
• Services dépendants : YARN, Spark, Hive, HBase, NiFi, connecteurs Kafka, ingestion custom. Identifiez tout ce qui écrit vers HDFS à mettre en pause pendant les bascules.
• Réseau : bande passante et latence inter-baies ; bande passante inter-clusters pour les migrations.
• Supervision : endpoints de métriques, logs, règles d'alerte.
• Sauvegardes et snapshots : emplacements fsimage/edits, politiques de snapshots.

Exemple d'inventaire (à adapter) :

Checklist de prérequis :

• Confirmez que la version cible supporte vos fonctionnalités (snapshots, zones chiffrées...).
• Assurez un espace libre suffisant sur les disques de métadonnées du NameNode (au moins 2× fsimage/edits) et sur les DataNodes.
• Vérifiez la santé HA si vous prévoyez un rolling upgrade.
• Vérifiez la disponibilité de DistCp pour une migration inter-clusters.
• Assurez-vous de pouvoir mettre en pause ou drainer les écrivains (Spark Streaming, NiFi, Kafka HDFS sinks) et de les relancer après validation.

Chemin de configuration sûr

Choisissez l'approche adaptée à votre topologie, votre appétence au risque et votre budget d'indisponibilité.

Garde-fous pour toute approche

• Sauvegardez la métadonnée : fsimage et edits.
• Prenez des snapshots sur les chemins critiques.
• Quiescez les gros écrivains.
• Conservez anciens binaires et configurations pour un rollback rapide.
• Ne finalisez l'upgrade qu'après validation.

Sauvegarder la métadonnée et préparer les snapshots

À exécuter sur un hôte NameNode avec privilèges admin.

# Entrer en safe mode pour une image cohérente
hdfs dfsadmin -safemode enter

# Sauver un fsimage récent sur le stockage local du NameNode
hdfs dfsadmin -saveNamespace

# Récupérer le fsimage vers un emplacement externe
BACKUP_DIR=/var/backups/hdfs/$(date +%F)
mkdir -p "$BACKUP_DIR"
hdfs dfsadmin -fetchImage "$BACKUP_DIR/fsimage"

# Sortir du safe mode
hdfs dfsadmin -safemode leave

# Optionnel : archiver aussi les répertoires de noms (adapter dfs.namenode.name.dir)
# tar -czf "$BACKUP_DIR/name-dirs.tgz" /data/nn1 /data/nn2

Créez des filets de sécurité en lecture seule sur les répertoires métiers critiques : les snapshots sont peu coûteux et protègent des suppressions accidentelles.

# Activer les snapshots (une seule fois par répertoire)
hdfs dfs -allowSnapshot /data/projects

# Créer un snapshot de référence avant tout changement
hdfs dfs -createSnapshot /data/projects pre-upgrade-$(date +%F)

Exemple de rolling upgrade (HA)

À utiliser avec NameNodes Active/Standby et JournalNodes.

1. Préparer le rolling upgrade (crée des checkpoints spéciaux pour rollback) :

hdfs dfsadmin -rollingUpgrade prepare
hdfs dfsadmin -rollingUpgrade query

1. Mettre à niveau d'abord le NameNode Standby :

• Arrêtez le service NN Standby.
• Installez les nouveaux binaires HDFS et configurations.
• Redémarrez le NN Standby, vérifiez qu'il reste Standby et rattrape les edits.

# Sur l'hôte NN Standby
export HADOOP_HOME=/opt/hadoop-3.3.6
# Redémarrer uniquement le processus NN Standby via votre outillage
# systemctl restart hadoop-hdfs-namenode

# Vérifier l'état Standby
hdfs haadmin -getServiceState nn2

1. Basculer et mettre à niveau l'ancien Active :

# Bascule contrôlée vers le Standby mis à niveau
hdfs haadmin -failover nn1 nn2

# Mettre à niveau l'ancien Active (devenu Standby)
# systemctl stop hadoop-hdfs-namenode sur nn1
# Installer les nouveaux binaires/configs sur nn1
# systemctl start hadoop-hdfs-namenode sur nn1

1. Redémarrer les DataNodes par petits lots :

# Sur chaque DataNode, drainer puis redémarrer
# systemctl restart hadoop-hdfs-datanode

# Après chaque lot, vérifier la santé du cluster
hdfs dfsadmin -report | grep -E "Live datanodes|Dead datanodes"
hdfs fsck / -blocks -locations -racks | tail -n 10

1. Finaliser uniquement après validation complète (voir Vérification) :

hdfs dfsadmin -rollingUpgrade finalize

Si la validation échoue avant finalisation, vous pouvez revenir en redémarrant avec les anciens binaires ; le checkpoint préparé rend l'opération sûre.

Exemple d'upgrade par redémarrage (offline)

À utiliser avec un seul NameNode ou si un arrêt est acceptable.

1. Arrêtez les écrivains et services dépendants : mettre en pause les processeurs NiFi HDFS, arrêter les jobs Spark, mettre en pause les sinks Kafka HDFS.

1. Arrêtez HDFS proprement (ordre important) :

# Arrêter les clients (services YARN qui écrivent, si besoin)
# Arrêter HBase/Hive Metastore si couplés

# Arrêter d'abord les DataNodes
$HADOOP_HOME/sbin/hadoop-daemons.sh stop datanode

# Puis NameNode(s), ZKFC, JournalNodes
$HADOOP_HOME/sbin/hadoop-daemon.sh stop namenode
$HADOOP_HOME/sbin/hadoop-daemons.sh stop zkfc
$HADOOP_HOME/sbin/hadoop-daemons.sh stop journalnode

1. Sauvegardez la métadonnée (fsimage, edits, répertoires de noms).

1. Installez les nouveaux binaires/configs HDFS sur tous les nœuds.

1. Démarrez JournalNodes, ZKFC, NameNode, puis DataNodes :

$HADOOP_HOME/sbin/hadoop-daemons.sh start journalnode
$HADOOP_HOME/sbin/hadoop-daemons.sh start zkfc
$HADOOP_HOME/sbin/hadoop-daemon.sh start namenode
$HADOOP_HOME/sbin/hadoop-daemons.sh start datanode

1. Validez en profondeur. Ne supprimez pas anciens binaires ou backups avant décision finale.

Exemple de migration vers un nouveau cluster (DistCp)

À privilégier pour nouveau matériel, grand saut de version ou refonte. Le risque est réduit car la source reste intacte jusqu'au cutover.

Hypothèses :

• Source : hdfs://src-nn:8020
• Cible : hdfs://dst-nn:8020
• Kerberos activé des deux côtés, avec trust inter-domaines ou principaux équivalents.

1. Préparer les répertoires et permissions cibles :

# Créer le répertoire racine et définir l'appartenance sur la cible
hdfs dfs -fs hdfs://dst-nn:8020 -mkdir -p /data/projects
hdfs dfs -fs hdfs://dst-nn:8020 -chown -R analytics: analytics /data/projects

1. Prendre un snapshot de base et lancer le DistCp initial :

# Sur le cluster source
hdfs dfs -allowSnapshot /data/projects || true
hdfs dfs -createSnapshot /data/projects snap0

# Copie de base avec préservation et limitation de bande passante
hadoop distcp \
  -prbugp -m 50 -bandwidth 100 \
  hdfs://src-nn:8020/data/projects \
  hdfs://dst-nn:8020/data/projects

Options :

• -p rbugp préserve réplication, taille de bloc, user, groupe, permissions.
• -m 50 règle 50 tâches map (adapter à votre cluster).
• -bandwidth 100 limite à 100 Mo/s par map (exemple).

1. Synchronisation incrémentale pendant la fenêtre de cutover :

# Nouveau snapshot sur la source
hdfs dfs -createSnapshot /data/projects snap1

# Si DistCp supporte snapshot diff
hadoop distcp -prbugp -m 25 \
  -diff snap0 snap1 \
  hdfs://src-nn:8020/data/projects \
  hdfs://dst-nn:8020/data/projects

# Sinon, passer en update+delete
hadoop distcp -prbugp -m 25 -update -delete \
  hdfs://src-nn:8020/data/projects \
  hdfs://dst-nn:8020/data/projects

1. Vérification et cutover :

• Contrôlez checksums et/ou décomptes par chemin critique.
• Pointez les clients vers le nouveau cluster (core-site.xml fs.defaultFS, configs services).
• Conservez la source en lecture seule sur une période de repli définie.

Vérification et diagnostics

Des signaux clairs sont nécessaires avant finalisation.

Santé du cluster et stockage

# Liveness des DataNodes
hdfs dfsadmin -report | egrep "Live datanodes|Dead datanodes|Under replicated blocks"

# Santé du système de fichiers (résumé)
hdfs fsck / -blocks -locations -racks | tail -n 20

# État NameNode (HA)
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

Attendus (exemples) :

• Live datanodes = nombre d'hôtes attendu ; Dead datanodes = 0.
• Under replicated blocks = 0 ou en décrue stable vers 0.
• Rôles Active/Standby corrects ; pas de bascules automatiques répétées.

Progression du rolling upgrade

hdfs dfsadmin -rollingUpgrade query

Attendu : état "prepared" pendant l'upgrade ; après finalisation, plus d'upgrade en cours.

Intégrité de la métadonnée

# Confirmer l'existence des snapshots
hdfs lsSnapshottableDir

# Valider les zones de chiffrement (si utilisées)
hdfs crypto -listZones

Vérification DistCp

# Contrôles ponctuels (tailles et comptes)
hdfs dfs -du -s -h hdfs://src-nn:8020/data/projects/teamA
hdfs dfs -du -s -h hdfs://dst-nn:8020/data/projects/teamA

# Échantillonnage de checksums au niveau fichier
for f in $(hdfs dfs -ls -R hdfs://src-nn:8020/data/projects/teamA | awk '{print $8}' | head -100); do
  hdfs dfs -checksum "$f";
  hdfs dfs -checksum "hdfs://dst-nn:8020${f#hdfs://src-nn:8020}";
done

Tests de fumée côté clients

• Spark : lire 10 fichiers représentatifs et compter les lignes ; écrire un petit parquet et relire.
• NiFi : faire passer un flux unique sur un chemin bac à sable et confirmer les permissions.
• Connecteurs Kafka : produire un petit lot vers le sink HDFS et vérifier la réplication attendue.

Logs et métriques

• Logs NN et DN : surveiller FATAL/ERROR au démarrage et durant les block reports.
• Métriques : temps de file d'attente RPC, pauses GC, latences de tail des edit logs, taux de sous-réplication, heap NN.

Modes de panne et reprise

Attendez-vous à ces cas et planifiez la détection précoce.

1. NameNode ne démarre pas après upgrade

• Symptôme : échec au démarrage avec incompatibilité de layout version.
• Correctif : aligner versions NN et JournalNodes. En offline, restaurer anciens binaires et répertoires de noms, puis reprendre avec versions cohérentes.

1. DataNodes bloqués en upgrade ou se réenregistrant en boucle

• Symptôme : DataNodes signalent un mismatch de version/namespace ID.
• Correctif : vérifier le clusterID dans /dfs/dn/current/VERSION ; ne supprimez pas les données DN sauf reformat total souhaité. Redémarrez avec binaires cohérents.

1. Sous-réplication après redémarrages DN

• Symptôme : spike d'under-replication qui ne retombe pas.
• Correctif : laisser le temps à la réplication ; si persistant, inspecter partitions réseau ou pannes disques ; utiliser le balancer si besoin.

1. Échecs Kerberos

• Symptôme : GSSException, tickets expirés.
• Correctif : rafraîchir keytabs et principaux. klist -k, kinit -kt, vérifier la dérive NTP (< 5 minutes).

1. DistCp se bloque ou échoue

• Symptôme : mappers figés, débit quasi nul.
• Correctif : réduire -m, ajuster -bandwidth, segmenter les répertoires ; vérifier throttling réseau et latences RPC NN.

Stratégies de rollback

• Rolling upgrade : si non finalisé, redémarrer NN et DN avec les anciens binaires. Le checkpoint préparé permet le downgrade automatique. Vérifiez hdfs dfsadmin -rollingUpgrade query avant.
• Upgrade offline : arrêter HDFS, restaurer binaires/configs précédents et, si nécessaire, fsimage/edits depuis la sauvegarde.
• Migration : repointer les clients vers la source. Si la cible a reçu des écritures, réconcilier par DistCp inverse ou considérer la cible comme jetable et relancer une copie propre.

Contrôles après rollback

• hdfs dfsadmin -report : Live datanodes attendu, Dead = 0.
• hdfs fsck / : aucun bloc manquant.
• Tests de fumée applicatifs OK (lecture/écriture).

Roll-forward vs rollback

• Avancez si le cluster est sain et que les erreurs se résorbent (réplication, caches).
• Revenez en arrière si le NameNode ne démarre pas, si la métadonnée est incohérente ou si des applis critiques ne lisent plus les données existantes.

Checklist d'exploitation

À utiliser pour upgrade et migration. Adaptez à votre contexte.

1. Planifier et inventorier

• Noter versions et topologie actuelles/cibles.
• Identifier services dépendants et plan de communication.
• Définir un pilote avec objectifs mesurables.

1. Préparer

• Sauvegarder fsimage et edits ; archiver les name dirs.
• Créer des snapshots sur les chemins critiques.
• Valider Kerberos/TLS ; rafraîchir les keytabs.
• Quiescer/drainer les gros écrivains (Spark, NiFi, sinks Kafka).

1. Exécuter (un seul chemin)

• Rolling : prepare, upgrade Standby, failover, upgrade ex-Active, DN par lots, query.
• Offline : arrêter dans l'ordre, déployer binaires/configs, redémarrer dans l'ordre.
• Migration : DistCp initial, sync incrémentale, cutover.

1. Vérifier

• hdfs dfsadmin -report et hdfs fsck / OK.
• Rôles HA corrects ; failover manuel fonctionne.
• Tailles DistCp alignées ; échantillons de checksums OK.
• Tests de fumée clients réussis bout en bout.

1. Finaliser

• Rolling : finaliser seulement après tous les feux verts.
• Offline : marquer le changement, conserver les sauvegardes un temps défini.
• Migration : basculer les clients, mettre la source en lecture seule sur la fenêtre de repli.

1. Post-ops

• Réactiver plannings de snapshots et jobs de compaction.
• Clore le changement avec métriques : temps de reprise, sous-réplication, erreurs clients.
• Mettre à jour les runbooks avec les enseignements.

Exemples pratiques et extraits

Vérifier HA et failover

hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2
hdfs haadmin -failover nn1 nn2
hdfs haadmin -getServiceState nn1
hdfs haadmin -getServiceState nn2

Attendu : les rôles s'échangent une seule fois, sans erreurs ; les clients continuent sans échecs significatifs.

Équilibrer le cluster après redémarrage DN

# Lancer le balancer avec un seuil modéré (ex. 10 %)
hdfs balancer -threshold 10

Laissez tourner jusqu'à stabilisation ; surveillez réseau et IO disques.

Mettre à jour la config client lors d'un cutover

# Dans core-site.xml
<property>
  <name>fs.defaultFS</name>
  <value>hdfs://dst-nn:8020</value>
</property>

# Distribuer la config et redémarrer les services clients

Conclusion

Réussir une mise à niveau ou une migration HDFS repose sur la préparation, l'exécution gardée par des garde-fous et des résultats visibles. Démarrez par un pilote mesurable, puis appliquez le même schéma à l'échelle : inventorier, sauvegarder, snapshotter, exécuter avec un plan réversible, vérifier avec des checks explicites, et finaliser seulement ensuite. Que vous choisissiez un rolling in-place, un court arrêt offline ou une migration avec DistCp, les exemples et checklists ci-dessus offrent un chemin reproductible avec des options claires de reprise.

Prochaines étapes :

• Complétez l'inventaire de votre environnement et choisissez un répertoire pilote.
• Préparez dès maintenant les sauvegardes de métadonnées et les snapshots.
• Exécutez à blanc les commandes de vérification sur une zone non critique.
• Planifiez une fenêtre pilote et répétez les étapes de rollback avant la production.