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

Introduction

Ceph prend en charge les services de blocs, de fichiers et d'objets dans les environnements Linux, les clusters Proxmox et les parcs hétérogènes. La mise à niveau et la migration de Ceph peuvent améliorer la stabilité, les performances et les fonctionnalités, mais elles doivent être chirurgicales : une erreur peut déclencher des tempêtes de rééquilibrage, des groupes de placement (PG) bloqués ou des arrêts d'E/S clients. Ce guide présente un parcours praticien à faible risque pour planifier, exécuter, valider et, si nécessaire, annuler les mises à niveau et migrations Ceph. Vous y trouverez des étapes concrètes, des vérifications, des modes de défaillance et des procédures de récupération réutilisables.

Inventaire des versions et de l'environnement

Établissez la réalité du terrain avant de toucher à la production. Capturez l'état du cluster dans une fiche de changement afin de planifier le chemin de mise à niveau et de comparer rapidement après l'opération.

Prérequis et commandes d'inventaire :

• La santé du cluster doit être propre ou n'afficher que des avertissements consultatifs. Enquêtez et résolvez tout état dégradé.
• ceph -s
• ceph health detail
• Enregistrez les versions actuelles des démons et la version cible.
• 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 MGR.
• ceph mon stat
• ceph -s (la carte MGR apparaît dans le statut)
• Contrôlez les comptes de pools et de PG, l'utilisation cible et les paramètres de l'autoscaler.
• ceph df
• ceph osd pool autoscale-status
• Enregistrez les drapeaux actuels de la carte OSD pour pouvoir les restaurer plus tard.
• ceph osd dump | grep flags
• Vérifiez la compatibilité clients (RBD, CephFS, RGW). Pour les nœuds Proxmox et Linux, assurez-vous que le noyau et librbd prennent en charge les fonctionnalités de la version Ceph cible que vous prévoyez d'utiliser.
• Sauvegardez les configurations et les cartes.
• Sauvegardez /etc/ceph/* depuis au moins un hôte d'administration.
• ceph mon getmap -o /root/monmap.backup
• Optionnel : monmaptool --print /root/monmap.backup (pour vérification humaine)
• Assurez-vous d'avoir accès aux dépôts de paquets ou aux images pour les versions Ceph actuelle et nouvelle afin qu'un downgrade soit possible pendant la fenêtre de changement.

Contraintes générales de parcours :

• Prévoyez de passer une version majeure à la fois, sauf si les notes de version officielles indiquent le contraire pour votre chemin.
• Reportez l'activation de tout indicateur de fonctionnalité (feature flag) à l'échelle du cluster jusqu'à ce que tous les démons soient sur la version cible et stables. Cela préserve les options de downgrade.

Chemin de configuration sécurisé

Utilisez une approche progressive et contrôlée qui limite le rayon d'impact et maintient la disponibilité des données.

Ordre de mise à niveau et justification :

• MON (1er) — Établit un plan de contrôle qui comprend la nouvelle OSDMap et les nouvelles fonctionnalités
• MGR (2e) — Les fonctionnalités de métriques et d'orchestration s'alignent sur la carte MON
• OSD (3e) — Mise à niveau du chemin de données après que le plan de contrôle est prêt
• MDS (CephFS) (4e) — Services de métadonnées après la stabilisation du chemin de données principal
• RGW (Objet) (5e) — Services API en dernier pour éviter la perturbation des clients
• Clients (RBD/CephFS) (6e) — Mettez à niveau les clients après la stabilisation du cluster

Contrôles de maintenance :

• Pendant les redémarrages OSD progressifs, réduisez le brassage :
• ceph osd set noout
• ceph osd set noscrub
• ceph osd set nodeep-scrub
• Pour les rotations OSD majeures, envisagez de réduire temporairement la concurrence de récupération ou de backfill si nécessaire pour la qualité de service. Revenez aux valeurs par défaut après.
• Supprimez toujours les drapeaux à la fin de l'étape :
• ceph osd unset nodeep-scrub; ceph osd unset noscrub; ceph osd unset noout

Pilote d'abord, puis généralisez :

• Commencez par une portée canari : un hôte avec un seul OSD et aucun service critique colocalisé. Observez pendant au moins un cycle de scrub ou une fenêtre de charge de travail client définie.
• Définissez un chemin de retour réaliste pour cette portée avant de l'appliquer.

Deux chemins d'exécution sont courants :

• Clusters cephadm/orchestrés : contrôlez les mises à niveau avec ceph orch.
• Clusters gérés par paquets (apt, yum, dnf) avec unités systemd.

Exemples pratiques de mise à niveau et migration

Les exemples ci-dessous utilisent des noms d'hôtes, identifiants et noms de pools construits. Adaptez-les à votre environnement.

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

Objectif : passer de 17.2.5 à 17.2.6 avec une perturbation minimale.

1. Pré-vérifications

• ceph -s doit être HEALTH_OK ou n'afficher que des avertissements sûrs.
• ceph versions doit montrer une seule ligne majeure (par exemple, tous les démons rapportent 17.2.x).

1. Préparez un hôte canari

• Choisissez l'hôte osd-03 avec 2 OSD.
• Mettez en pause les changements automatiques si vous les utilisez : ceph orch pause (optionnel)
• Placez en maintenance et drainez les charges de travail activement placées si possible : ceph orch host maintenance enter osd-03

1. Démarrez la mise à niveau mineure

ceph orch upgrade start --version 17.2.6

ceph orch upgrade status ceph -s

• Déclenchez la mise à niveau de l'orchestrateur :
• Surveillez l'état :

1. Vérifiez le canari

• ceph versions doit montrer les processus osd sur osd-03 maintenant en 17.2.6.
• ceph pg stat doit rester stable ; pas de backfill excessif.
• Sortez de maintenance en cas de succès : ceph orch host maintenance exit osd-03

1. Déployez sur le cluster

• Mettez à niveau les MON et MGR en premier s'ils ne l'ont pas déjà été par cephadm.
• Échelonnez les hôtes restants par zones de disponibilité ou baies.
• Vérifiez et sortez de maintenance pour chaque hôte avant de passer au suivant.

1. Nettoyage

• Assurez-vous que ceph osd unset noscrub; unset nodeep-scrub; unset noout.
• Confirmez que tous les démons affichent 17.2.6 via ceph versions.

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

Exemple B : Mise à niveau majeure avec paquets OS (construit)

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

1. Pré-vérifications et mise en scène

• Assurez-vous que le dépôt 17.x est disponible sur tous les nœuds. Mettez en cache les paquets 16.x localement.
• ceph -s est propre ; sauvegardez la monmap.

1. Mise à niveau des MON

ceph osd set noout; ceph osd set noscrub; ceph osd set nodeep-scrub

apt-get update && apt-get install -y ceph-mon (ou dnf/yum) systemctl restart ceph-mon@mon-1

• Sur mon-1, activez les drapeaux de maintenance OSD pour éviter tout déplacement de données accidentel pendant d'éventuels redémarrages OSD incidentels :
• Mettez à jour les paquets et redémarrez le MON sur mon-1 :
• Confirmez que le quorum reste sain : ceph mon stat
• Répétez pour mon-2, mon-3, un à la fois.

1. Mise à niveau des MGR

apt-get install -y ceph-mgr systemctl restart ceph-mgr@mgr-1

• Mettez à jour les paquets et redémarrez le mgr sur mgr-1, puis mgr-2 :
• Validez : ceph -s montre le mgr actif sur la version cible.

1. Mise à niveau des OSD (progressif)

apt-get install -y ceph-osd systemctl restart ceph-osd@<id> Attendez que osd.<id> soit up et in : ceph osd tree; ceph -s

• Pour chaque hôte OSD, un à la fois :
• Parcourez tous les hôtes OSD. Surveillez les états PG et les latences clients.

1. Mise à niveau des MDS et RGW

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

1. Post-mise à niveau

ceph osd require-osd-release reef (exemple seulement ; utilisez votre cible)

ceph osd unset nodeep-scrub; ceph osd unset noscrub; ceph osd unset noout

• Assurez-vous que tous les démons sont en 17.x : ceph versions
• Envisagez de passer require-osd-release à la nouvelle version majeure seulement si conseillé et après une période de stabilisation :
• Supprimez les drapeaux de maintenance et réactivez les scrubs :

Résultat attendu : quorum stable, versions de démons cohérentes, et aucun backfill forcé en dehors des redémarrages planifiés.

Exemple C : Migrer un pool vers des périphériques plus rapides via règles CRUSH (construit)

Objectif : déplacer le pool vmdata de HDD vers SSD sans temps d'arrêt.

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

1. Créez une règle CRUSH pour les SSD (la classe de périphérique ssd est supposée)

ceph osd pool set vmdata crush_rule ssd-rule

1. Appliquez la règle au pool

1. Surveillez le backfill et la récupération

• ceph -s; ceph pg stat
• Attendez-vous à ce que les PG se remappent progressivement vers les OSD SSD.

1. Vérifiez le placement

• ceph osd map vmdata (vérifications ponctuelles)
• ceph osd df tree (l'utilisation doit augmenter sur les OSD SSD)

Résultat attendu : migration progressive des données vers les SSD tandis que le pool reste disponible.

Exemple D : Remplacer les OSD FileStore legacy par BlueStore (construit)

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

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

1. Ajoutez un nouvel OSD BlueStore sur un périphérique libre

ceph osd out <old_id>

1. Marquez un ancien OSD FileStore comme out

ceph -s; ceph pg stat

1. Attendez la fin du backfill

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

1. Supprimez l'ancien OSD

1. Répétez pour les OSD FileStore restants, un à la fois

Résultat attendu : tous les OSD tournent sous BlueStore, avec données migrées via le backfill CRUSH normal.

Vérification et diagnostics

La validation n'est pas un contrôle unique ; combinez état, versions et tests d'E/S.

Contrôles essentiels :

ceph osd pool create testpool 32 32 rbd create testpool/testimg --size 64M

• Santé et PG
• ceph -s doit être HEALTH_OK ou n'afficher que des états de récupération transitoires pendant les déplacements contrôlés.
• ceph pg stat doit retourner tous active+clean après chaque étape.
• Convergence des versions
• ceph versions doit montrer uniquement les versions cibles pour chaque type de démon une fois terminé.
• Capacité et placement
• ceph df et ceph osd df tree doivent montrer une marge saine et une utilisation équilibrée.
• Comportement OSD
• ceph osd tree montre tous les OSD up et in.
• ceph osd perf peut révéler des valeurs aberrantes.
• Tests de fumée E/S client (RBD)
• Créez un pool et une image de test :
• Mappez sur un client Linux : rbd map testpool/testimg --pool testpool
• Écrivez/lisez un système de fichiers de données (mkfs.ext4, mount, dd 32M, md5sum)
• Démappez : rbd unmap /dev/rbd/testpool/testimg
• Supprimez les artefacts de test après validation.

Matrice de validation pilote (construite) :

• Santé — ceph -s — HEALTH_OK ou seulement récupération transitoire pendant le canari
• Versions — ceph versions — Les démons canari montrent la version cible uniquement
• PG — ceph pg stat — Pas d'augmentation des undersized+degraded au-delà de la fenêtre canari
• Redémarrage OSD — systemctl restart ceph-osd@<id> — L'OSD revient up+in en quelques minutes
• E/S RBD — rados bench -p testpool 30 write — Latence stable ; pas de timeouts client

Astuces de diagnostic :

• Si les PG sont lents à nettoyer, vérifiez les requêtes lentes dans les logs et ceph health detail.
• Si le rééquilibrage est trop agressif, réduisez temporairement le nombre de threads de récupération ou le backfill max.
• Si les clients voient des timeouts, vérifiez le réseau msgr2, la cohérence MTU et qu'un seul ensemble de fonctionnalités est actif entre librbd et les clients noyau.

Modes de défaillance et récupération

Les problèmes surviennent ; préparez une réversibilité réaliste.

Modes de défaillance courants et remèdes :

1. Perte de quorum MON après un redémarrage

systemctl stop ceph-mon@<id> monmaptool --inject /root/monmap.backup /var/lib/ceph/mon/ceph-<id> systemctl start ceph-mon@<id>

• Symptôme : ceph -s montre pas de quorum ou quorum dégradé.
• Actions :
• Assurez-vous qu'une majorité de MON tourne et est accessible.
• Redémarrez un MON bloqué : systemctl restart ceph-mon@<id>
• Si une corruption de la carte MON est suspectée, restaurez depuis la sauvegarde :

1. OSD qui flap ou ne démarre pas après mise à niveau

• Symptôme : ceph osd tree montre des OSD down, redémarrages répétés.
• Actions :
• Inspectez les logs pour erreurs BlueStore ou rocksdb.
• Si c'est un hôte canari sur une mise à niveau majeure et qu'un rollback mineur est possible, rétrogradez les paquets sur cet hôte et redémarrez l'OSD.
• Gardez l'OSD out jusqu'à stabilisation ; ne déclenchez pas de récupération à l'échelle du cluster.

1. PG bloqués en peering ou backfill

• Symptôme : ceph pg stat montre peering ou backfill_wait prolongé.
• Actions :
• Vérifiez la disponibilité des OSD sur toutes les cibles de réplication.
• Vérifiez les drapeaux full/nearfull ; reweight les OSD si l'un est saturé : ceph osd reweight <id> 0.9
• Assurez-vous que le chemin réseau et le MTU sont corrects entre les pairs OSD.

1. Incompatibilité client RBD après mise à niveau

• Symptôme : arrêts d'E/S VM, erreurs de mapping.
• Actions :
• Alignez librbd client et modules noyau sur des versions compatibles.
• Pour Proxmox ou autres hyperviseurs, migrez d'abord un hôte et testez un disque VM non critique avant le déploiement large.

Stratégie de rollback et de confinement :

• Préférez avancer dans la même version majeure vers un correctif mineur si des bugs sont découverts. Gardez les paquets du mineur précédent en cache.
• Entre versions majeures, n'activez pas et ne montez pas de fonctionnalités à l'échelle du cluster (par exemple, require-osd-release) avant que tous les démons soient mis à niveau et validés. Cela conserve une fenêtre limitée pour downgrader un sous-ensemble de nœuds si nécessaire.
• Pour les clusters gérés par paquets :
• Downgradez un nœud canari : réinstallez les paquets précédents ; redémarrez les services concernés.
• Validez la santé et l'E/S client localement.
• Si vous devez 롤백 plus large, procédez hôte par hôte, en maintenant le quorum et la santé majoritaire à chaque étape.
• Pour les clusters cephadm :
• ceph orch upgrade revert n'est pas toujours disponible entre majeures ; à la place, épinglez une image ou une version pour un hôte ou un démon donné et redémarrez-le.
• Gardez l'ancienne image disponible localement ou dans votre miroir de registre.

Vérifications de récupération après rollback :

• ceph -s retourne à HEALTH_OK.
• ceph versions montre un mélange cohérent et supporté (évitez les mélanges split-brain entre versions majeures trop longtemps).
• L'E/S client reprend sans timeouts.

Signaux de triage rapide (construits) :

• Flapping du quorum — Zone probable : MON — Premier contrôle : ceph mon stat; systemctl status ceph-mon@*
• Rééquilibrage soudain — Zone probable : drapeaux OSD — Premier contrôle : ceph osd dump | grep flags; vérifiez noout/noscrub
• Latence client élevée — Zone probable : récupération OSD — Premier contrôle : ceph -s; ajustez temporairement la concurrence recovery/backfill
• Échecs de mapping — Zone probable : fonctionnalités client — Premier contrôle : compatibilité librbd/noyau; chemin msgr2

Liste de contrôle opérationnelle

Utilisez ceci comme un runbook reproductible. Adaptez à votre environnement.

Planification

• Définissez la portée : version cible, démons concernés, et objectifs de migration.
• Inventoriez les versions, la topologie et la compatibilité client.
• Sauvegardez /etc/ceph, la monmap, et capturez des instantanés de ceph -s et ceph versions.
• Confirmez la disponibilité des paquets ou images pour les versions nouvelle et actuelle.
• Rédigez un plan pilote et de rollback pour le pilote.

Exécution (pilote)

• Activez les drapeaux de maintenance : ceph osd set noout; ceph osd set noscrub; ceph osd set nodeep-scrub.
• Mettez à niveau un hôte ou un ensemble minimal de démons.
• Vérifiez la santé, les versions, les PG et les tests de fumée client.
• En cas de problème, annulez le pilote et enquêtez.

Exécution (cluster)

• Mettez à niveau les MON un par un ; maintenez le quorum.
• Mettez à niveau les MGR.
• Déployez les hôtes OSD séquentiellement ; attendez up+in à chaque fois.
• Mettez à niveau les MDS et RGW si applicable.
• Mettez à niveau ou validez les hôtes clients après la stabilisation du cluster.

Post-changement

• Supprimez les drapeaux : ceph osd unset nodeep-scrub; ceph osd unset noscrub; ceph osd unset noout.
• Confirmez ceph versions et HEALTH_OK.
• Effectuez une brève validation de performance et d'E/S (rados bench ou pattern de charge connu).
• Envisagez de monter require-osd-release seulement après une période de stabilisation.
• Mettez à jour la documentation et les diagrammes pour refléter le nouvel état.

Conclusion

Une mise à niveau ou migration Ceph fiable commence par un inventaire précis, utilise un pilote étroit pour apprendre en sécurité, et progresse dans une séquence contrôlée avec des drapeaux de maintenance clairs et des portes de vérification. En validant après chaque étape et en préservant un rollback réaliste pour le changement scopé, vous réduisez les risques et maintenez les services de stockage disponibles. Utilisez les exemples et la liste de contrôle ici comme runbook de base, puis adaptez-le à vos versions, matériel et mélange de clients. Avec une approche mesurée, vous pouvez livrer les avantages des nouvelles versions Ceph tout en maintenant la confiance dans l'intégrité des données et la continuité de service.