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

Introduction

Ceph soutient des services bloc, fichier et objet sur Linux, dans des clusters Proxmox et des flottes mixtes. Une mise à niveau Ceph (Ceph upgrade) ou une migration bien conduite apporte stabilité, performance et nouvelles fonctionnalités. Mais l'opération doit être chirurgicale : une erreur peut déclencher des tempêtes de rééquilibrage, des PG bloquées ou des pauses d'I/O côté clients. Ce guide décrit une démarche pragmatique et à faible risque pour planifier, exécuter, valider et, si nécessaire, effectuer un retour arrière (Ceph rollback). Vous y trouverez des étapes concrètes, des contrôles de vérification, des modes de panne typiques et des procédures de récupération réutilisables.

Inventaire des versions et de l'environnement

Établissez la réalité du terrain avant toute action et consignez-la pour faciliter la comparaison après changement.

Prérequis et commandes d'inventaire :

La santé du cluster doit être propre (HEALTH_OK) ou au plus avec des avertissements non bloquants.
ceph -s
ceph health detail
Relevez les versions des démons et la cible de mise à niveau.
ceph versions
ceph -v
Confirmez la topologie, les classes de périphériques et la disposition CRUSH.
ceph osd tree
ceph osd crush tree
ceph osd df tree
Vérifiez le quorum MON et l'état du MGR.
ceph mon stat
ceph -s (mgr map visible dans le status)
Inspectez pools et PG, l'utilisation cible et l'autoscaler.
ceph df
ceph osd pool autoscale-status
Relevez les flags actuels de l'OSD map pour restauration ultérieure.
ceph osd dump | grep flags
Validez la compatibilité des clients (RBD, CephFS, RGW). Pour Proxmox et nœuds Linux, assurez-vous que le noyau et librbd supportent les fonctionnalités de la version cible.
Sauvegardez configurations et maps :
Sauvegardez /etc/ceph/* depuis au moins un hôte admin.
ceph mon getmap -o /root/monmap.backup
Optionnel : monmaptool --print /root/monmap.backup
Assurez la disponibilité des dépôts/images pour la nouvelle et l'ancienne version afin de permettre un downgrade pendant le créneau.

Contraintes générales :

Avancez d'une version majeure à la fois, sauf indication explicite dans les notes de version.
Retardez l'activation de nouveaux flags globaux jusqu'à ce que tous les démons soient sur la version cible et stables. Cela préserve les options de retour arrière.

Chemin de configuration sûr

Adoptez une approche progressive qui limite le rayon d'impact et préserve la disponibilité des données.

Ordre d'upgrade recommandé et raison d'être :

Composant	Séquence	Pourquoi cet ordre
MON	1	Assure un plan de contrôle compatible avec le nouvel OSDMap
MGR	2	Aligne métriques et orchestration sur le MON map
OSD	3	Met à jour le datapath une fois le contrôle prêt
MDS (CephFS)	4	Métadonnées après stabilisation du datapath
RGW (Objet)	5	Services API en dernier pour minimiser l'impact client
Clients (RBD/CephFS)	6	Une fois le cluster stabilisé

Contrôles de maintenance :

Pendant les redémarrages OSD en rolling, réduisez le churn :
ceph osd set noout
ceph osd set noscrub
ceph osd set nodeep-scrub
Pour de grosses rotations OSD, réduisez temporairement la concurrence de recovery/backfill si nécessaire. Revenez aux valeurs par défaut ensuite.
Toujours annuler les flags à la fin de l'étape :
ceph osd unset nodeep-scrub; ceph osd unset noscrub; ceph osd unset noout

Piloter d'abord, puis étendre :

Démarrez avec un canari : un hôte avec un seul OSD et sans services critiques collocés. Observez au moins un cycle de scrub ou une fenêtre de charge définie.
Définissez un chemin de rollback réaliste pour ce périmètre avant toute action.

Deux chemins d'exécution courants :

Clusters orchestrés (cephadm) : contrôlez l'upgrade avec ceph orch.
Clusters gérés par paquets (apt, yum, dnf) et unités systemd.

Exemples pratiques d'upgrade et de migration

Les exemples utilisent des noms/IDs construits ; adaptez-les à votre contexte.

Exemple A : mise à niveau mineure avec cephadm (construit)

Objectif : passer de 17.2.5 à 17.2.6 avec perturbation minimale.

Pré-vérifications

ceph -s : HEALTH_OK ou avertissements sûrs uniquement.
ceph versions : une seule ligne majeure (ex. 17.2.x).

Préparer un hôte canari

Choisissez l'hôte osd-03 avec 2 OSD.
Mettez en pause les changements automatiques si utilisés : ceph orch pause (optionnel)
Entrez en maintenance et drainez les workloads si possible : ceph orch host maintenance enter osd-03

Démarrer l'upgrade mineur

Déclenchez l'orchestrateur :
ceph orch upgrade start --version 17.2.6
Surveillez :
ceph orch upgrade status
ceph -s

Vérifier le canari

ceph versions : les OSD de osd-03 doivent être en 17.2.6.
ceph pg stat stable, pas de backfill excessif.
Sortie de maintenance si OK : ceph orch host maintenance exit osd-03

Dérouler sur le cluster

Mettez à jour MON et MGR d'abord si cephadm ne l'a pas déjà fait.
Échelonnez par zone/rack.
Vérifiez et libérez la maintenance pour chaque hôte avant d'avancer.

Nettoyage

Vérifiez : ceph osd unset noscrub; unset nodeep-scrub; unset noout.
Confirmez toutes les versions via ceph versions.

Résultat attendu : rotation fluide sans tempêtes de rebalance et une seule version mineure sur tous les démons.

Exemple B : mise à niveau majeure via paquets (construit)

Objectif : passer de 16.x à 17.x sur des hôtes gérés par paquets.

Pré-vérifications et staging

Dépôts 17.x disponibles partout ; mettez en cache les paquets 16.x.
ceph -s propre ; sauvegardez le monmap.

Upgrade des MON

Sur mon-1, posez des flags pour éviter des mouvements de données accidentels :
ceph osd set noout; ceph osd set noscrub; ceph osd set nodeep-scrub
Mettez à jour et redémarrez le MON :
apt-get update && apt-get install -y ceph-mon (ou dnf/yum)
systemctl restart ceph-mon@mon-1
Vérifiez le quorum : ceph mon stat
Répétez pour mon-2, mon-3, un par un.

Upgrade des MGR

Mettez à jour puis redémarrez mgr-1, puis mgr-2 :
apt-get install -y ceph-mgr
systemctl restart ceph-mgr@mgr-1
Validez : ceph -s montre un MGR actif sur la version cible.

Upgrade des OSD (rolling)

Pour chaque hôte OSD, un à la fois :
apt-get install -y ceph-osd
systemctl restart ceph-osd@<id>
Attendez que osd.<id> soit up+in : ceph osd tree; ceph -s
Surveillez états de PG et latences clients.

Upgrade MDS et RGW

MDS : apt-get install -y ceph-mds && systemctl restart ceph-mds@<fs>
RGW : apt-get install -y radosgw && systemctl restart ceph-radosgw@<zone>

Post-upgrade

Confirmez 17.x partout : ceph versions.
Envisagez require-osd-release seulement après stabilisation (exemple : ceph osd require-osd-release reef, adapter à votre cible).
Annulez les flags et réactivez les scrubs :
ceph osd unset nodeep-scrub; ceph osd unset noscrub; ceph osd unset noout

Résultat attendu : quorum stable, versions cohérentes, aucun backfill forcé hors redémarrages planifiés.

Exemple C : migrer un pool vers du SSD via règles CRUSH (construit)

Objectif : déplacer le pool vmdata de HDD vers SSD sans interruption.

Créer une règle CRUSH pour les SSD (classe ssd supposée)

ceph osd crush rule create-replicated ssd-rule default host ssd

Appliquer la règle au pool

ceph osd pool set vmdata crush_rule ssd-rule

Surveiller backfill et recovery

ceph -s; ceph pg stat
Attendez un remappage progressif des PG vers les OSD SSD.

Vérifier le placement

ceph osd map vmdata <pgid> (échantillonnage)
ceph osd df tree (montée d'utilisation sur OSD SSD)

Résultat attendu : migration progressive vers SSD tout en restant disponible.

Exemple D : remplacer des OSD FileStore par BlueStore (construit)

Objectif : déplacer les données des OSD FileStore vers de nouveaux OSD BlueStore sur le même hôte.

Ajouter un nouvel OSD BlueStore sur un disque libre

ceph-volume lvm create --bluestore --data /dev/nvme1n1

Marquer un ancien OSD FileStore en sortie

ceph osd out <old_id>

Attendre la fin du backfill

ceph -s; ceph pg stat

Retirer l'ancien OSD

systemctl stop ceph-osd@<old_id>
ceph osd purge <old_id> --force --yes-i-really-mean-it

Répéter pour les autres OSD FileStore, un par un

Résultat attendu : tous les OSD en BlueStore, migration via backfill CRUSH.

Vérification et diagnostics

La validation combine état, versions et tests d'I/O.

Contrôles clés :

Santé et PG
ceph -s : HEALTH_OK ou états transitoires pendant les mouvements contrôlés.
ceph pg stat : retour à active+clean après chaque étape.
Convergence des versions
ceph versions : uniquement les versions cibles par type de démon en fin d'opération.
Capacité et placement
ceph df, ceph osd df tree : marge saine et utilisation équilibrée.
Comportement OSD
ceph osd tree : tous les OSD up+in.
ceph osd perf : détecter les outliers.
Tests I/O clients (RBD)
Créez un pool et une image de test :
ceph osd pool create testpool 32 32
rbd create testpool/testimg --size 64M
Mapper : rbd map testpool/testimg --pool testpool
Écrire/lire (mkfs.ext4, mount, dd 32M, md5sum)
Unmap : rbd unmap /dev/rbd/testpool/testimg
Nettoyez après validation.

Matrice de validation (construite) :

Test	Commande (exemple)	Résultat attendu
Santé	`ceph -s`	HEALTH_OK ou recovery transitoire canari
Versions	`ceph versions`	Canari sur version cible uniquement
PG	`ceph pg stat`	Pas d'augmentation durable d'undersized/degraded
Redémarrage OSD	`systemctl restart ceph-osd@<id>`	Retour up+in en quelques minutes
I/O RBD	`rados bench -p testpool 30 write`	Latence stable, aucun timeout

Diagnostics :

Si les PG tardent à nettoyer : inspectez les slow requests et ceph health detail.
Rééquilibrage trop agressif : réduisez temporairement les threads de recovery ou le backfill max.
Timeouts clients : validez msgr2, cohérence MTU, et l'alignement des features entre librbd et clients noyau.

Modes de panne et reprise

Anticipez l'irréversible et gardez des options réalistes.

Perte de quorum MON après redémarrage

Symptôme : ceph -s sans quorum ou quorum dégradé.
Actions :
Assurez qu'une majorité de MON tournent et sont joignables.
Redémarrez un MON bloqué : systemctl restart ceph-mon@<id>
En cas de corruption du MON map, restaurez :
systemctl stop ceph-mon@<id>
monmaptool --inject /root/monmap.backup /var/lib/ceph/mon/ceph-<id>
systemctl start ceph-mon@<id>

OSD qui bat ou ne remonte pas après upgrade

Symptôme : ceph osd tree montre des OSD down, redémarrages répétés.
Actions :
Inspectez les logs pour erreurs BlueStore/rocksdb.
Si canari en upgrade majeur et rollback mineur possible, réinstallez les paquets précédents et redémarrez l'OSD.
Laissez l'OSD hors cluster jusqu'à stabilisation ; évitez un churn global.

PG bloquées en peering ou backfill

Symptôme : ceph pg stat en peering prolongé ou backfill_wait.
Actions :
Vérifiez la disponibilité des OSD cibles de répliques.
Contrôlez les flags full/nearfull ; répondez par reweight si saturation : ceph osd reweight <id> <0.9>
Validez le réseau (chemin msgr2, MTU) entre pairs OSD.

Incompatibilité client RBD après upgrade

Symptôme : I/O VM en pause, erreurs de mapping.
Actions :
Alignez versions librbd et modules noyau.
Sur Proxmox et hyperviseurs, mettez à jour un hôte d'abord et testez un disque de VM non critique avant déploiement large.

Stratégie de rollback et confinement :

Préférez avancer vers une mineure corrigée au sein de la même majeure si des bugs sont détectés. Conservez les paquets de la mineure précédente en cache.
Entre majeures, n'activez pas (ou ne montez pas) les features globales comme require-osd-release tant que tous les démons ne sont pas à niveau et validés.
Clusters gérés par paquets :
Rétrograder un nœud canari : réinstallez les paquets précédents ; redémarrez les services.
Validez la santé et l'I/O localement.
Si nécessaire, élargissez le rollback hôte par hôte en préservant le quorum et la majorité à chaque étape.
Clusters cephadm :
ceph orch upgrade revert n'est pas toujours disponible entre majeures ; épinglez plutôt une image/version pour un hôte ou un démon et redémarrez-le.
Conservez l'ancienne image localement ou dans votre miroir de registre.

Vérifications après rollback :

ceph -s revient à HEALTH_OK.
ceph versions montre un mix cohérent et supporté (évitez les mixes inter-majeures prolongés).
L'I/O client reprend sans timeout.

Signaux de triage rapide (construit) :

Signal	Zone probable	Premier contrôle
Fluctuations de quorum	MON	`ceph mon stat; systemctl status ceph-mon@*`

Checklist d'exploitation

Runbook réutilisable à adapter à votre environnement.

Planification

Définir le périmètre : version cible, démons concernés, objectifs de migration.
Inventorier versions, topologie et compatibilité des clients.
Sauvegarder /etc/ceph, le monmap, et capturer ceph -s/ceph versions.
Confirmer la disponibilité des paquets/images pour nouvelle et actuelle.
Rédiger un plan canari et un rollback réaliste.

Exécution (pilote)

Poser les flags : ceph osd set noout; ceph osd set noscrub; ceph osd set nodeep-scrub.
Mettre à niveau un hôte ou un ensemble minimal de démons.
Vérifier santé, versions, PG et tests I/O clients.
En cas de souci, rollback du pilote et analyse.

Exécution (cluster)

Mettre à niveau les MON un par un ; préserver le quorum.
Mettre à niveau les MGR.
Faire tourner les hôtes OSD séquentiellement ; attendre up+in à chaque fois.
Mettre à niveau MDS et RGW selon besoin.
Mettre à jour/valider les hôtes clients après stabilisation du cluster.

Post-changement

Lever les flags : ceph osd unset nodeep-scrub; ceph osd unset noscrub; ceph osd unset noout.
Confirmer ceph versions et HEALTH_OK.
Réaliser une validation performance/I/O (rados bench ou charge connue).
Envisager require-osd-release seulement après une période de stabilité.
Mettre à jour documentation et schémas.

Conclusion

Une mise à niveau ou migration Ceph fiable commence par un inventaire précis, s'appuie sur un canari étroit pour apprendre sans risque, et progresse selon un ordre contrôlé avec des portes de validation claires. En validant chaque étape et en préservant un retour arrière réaliste pour le périmètre touché, vous réduisez le risque et maintenez la disponibilité des services de stockage. Reprenez les exemples et la checklist comme base de runbook et adaptez-les à vos versions, matériels et clients. Avec cette approche mesurée, vous profitez des nouvelles versions Ceph tout en préservant l'intégrité des données et la continuité de service.