Dépanner Ceph : guide pratique avec exemples

Intro

Cette version française explique Ceph troubleshooting with practical examples avec le même objectif pratique que l article source : aider le lecteur à comprendre le contexte, les décisions à prendre et les points à vérifier avant de passer à l action.

Le dépannage Ceph (Ceph troubleshooting) n a rien d une loterie. Avec un inventaire précis, une approche de configuration sûre et une séquence de diagnostic bien ciblée, la plupart des incidents se localisent rapidement et se réparent avec un risque maîtrisé. Ce guide propose :

• Un inventaire rapide pour établir versions et topologie
• Un chemin de configuration et d exploitation sûr
• Des commandes de diagnostic avec signaux attendus et exemples construits
• Des workflows de récupération étape par étape pour les pannes fréquentes
• Des conseils de rollback et de vérification après chaque correctif
• Une checklist d exploitation concise à dérouler au quotidien ou en incident

Objectif : un flux pratique et reproductible qui réduit les arrêts et le rework tout en préservant les données. Nous utilisons des termes techniques courants (Ceph logs, Ceph commands, Ceph recovery) et nous illustrons avec des environnements Linux, Proxmox, RBD et OSD troubleshooting.

Inventaire des versions et de l environnement

Avant toute action, capturez l état actuel. Cela évite les angles morts et fournit un avant/après mesurable.

Prérequis

• Accès shell à tous les serveurs monitor, manager, OSD et metadata
• Droits sudo sur les nœuds qui exécutent des démons Ceph
• CLI Ceph configurée (keyrings sous /etc/ceph ou environnement)
• Fenêtre de maintenance si des mouvements de données sont possibles

Commandes d inventaire du cluster

• État global et versions :

ceph -s
ceph --version
ceph versions
ceph fsid

• Topologie et capacité :

ceph osd stat
ceph osd tree
ceph osd df tree
rados df
ceph osd pool ls detail

• Services cœur :

ceph mon stat
ceph mgr stat
ceph mds stat   # si vous utilisez CephFS

• Heure et fondamentaux système sur chaque nœud :

hostnamectl
chronyc sources -v  # ou : ntpq -p
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

Exemple construit : sortie type de ceph -s

cluster:
  id:     3c1a6c92-aaaa-bbbb-cccc-3f5c9a1d0001
  health: HEALTH_WARN 1 osds down; 2 pgs degraded

services:
  mon: 3 daemons, quorum mon-a, mon-b, mon-c (age 2h)
  mgr: mgr-a(active), standbys: mgr-b
  osd: 12 osds: 11 up, 11 in

data:
  pools:   3 pools, 128 pgs
  objects: 1.2M objects, 1.5 TiB used, 8.7 TiB / 10.2 TiB avail
  pgs:     2 degraded, 126 active+clean

Interprétation : un OSD est down, deux PG sont dégradées mais le cluster est globalement sain. La récupération devrait s achever après remise en ligne ou remplacement de l OSD.

Chemin de configuration sûr

Avec des données de production, la discipline de changement est essentielle :

• Changez une seule chose à la fois. Vérifiez entre chaque étape avec ceph -s et des contrôles ciblés.
• Utilisez les flags avec parcimonie et enlevez-les dès que possible :
• noout évite les mouvements de données lors de brèves maintenances. Retirez-le rapidement.
• norecover et norebalance mettent en pause respectivement la recovery et le rebalance ; n utilisez que pour protéger la latence pendant un correctif urgent et désactivez ensuite.
• Préférez un reweight ciblé à un out dur pour isoler un disque bruyant. Reweight est moins intrusif et réversible.
• N utilisez pas d outils destructifs sur BlueStore sans sauvegardes explicites et recommandations de l éditeur.
• Maintenez une dérive de temps < 50 ms entre nœuds ; corrigez l horloge d abord en cas de CLOCK_SKEW.

Référence rapide des flags de maintenance

Vérifications et diagnostic

Commencez par les signaux cluster, puis focalisez.

Santé et temps

ceph health detail
chronyc tracking && chronyc sources -v   # ou : ntpstat ; ntpq -p

• Attendu sain : pas de CLOCK_SKEW dans ceph health detail. Corrigez la synchro temps d abord si présent.

Placement groups et OSD

ceph pg stat
ceph pg dump pgs_brief | head -n 30
ceph osd perf
ceph osd df tree

• Attendu sain : majorité des PG en active+clean ; quelques remapped+backfill brièvement après changements.

Journaux

journalctl -u ceph-osd@<id> -n 200 --no-pager
journalctl -u ceph-mon@<name> -n 200 --no-pager
journalctl -u ceph-mgr@<name> -n 200 --no-pager
journalctl -u ceph-mds@<name> -n 200 --no-pager  # si CephFS

• Recherchez erreurs E/S disque, échecs d auth, sauts d horloge, crashs répétés.

Réseau

ip -br addr
ip -br link
ethtool -S <iface> | egrep 'err|drop'
ping -c3 <autre-noeud-IP-gestion>

• Attendu : pas d erreurs RX/TX ; MTU cohérente sur le réseau Ceph.

Introspection PG ciblée

ceph pg <pgid> query | jq '.state, .acting, .up, .info.last_scrub_stamp, .peering_blocked_by'

• Attendu : state en active+clean ou active+recovery ; peering_blocked_by vide si sain.

Exemple construit : taxonomie rapide de santé

Modes de panne et récupération

Les workflows ci-dessous couvrent des cas fréquents. À chaque fois : observer, agir, vérifier avant d avancer. Exemples construits.

1) OSD down ou qui flap

Symptômes

• ceph -s montre un ou plusieurs OSD down
• ceph osd tree indique des devices down ou out
• journalctl montre des redémarrages OSD répétés ou des erreurs E/S

Étapes

1. Identifier l OSD et l hôte

ceph osd tree
ceph osd find <id>

Attendu : hôte et chemin du device visibles.

1. Inspecter service et logs sur l hôte

sudo systemctl status ceph-osd@<id>
sudo journalctl -u ceph-osd@<id> -n 200 --no-pager
sudo smartctl -a /dev/<device> | egrep 'SMART overall|Reallocated|Pending|Error'

Attendu : si le disque faiblit, SMART en atteste ; sinon chercher des problèmes de FS ou permissions.

1. Courte fenêtre : éviter la tempête de données si redémarrage

ceph osd set noout

1. Tenter un redémarrage propre

sudo systemctl restart ceph-osd@<id>
sleep 10; ceph osd stat

Attendu : OSD up+in ; les PG commencent à récupérer. Si ça re-flap, poursuivre.

1. Si le device est bruyant mais pas mort, baisser le poids

ceph osd crush reweight osd.<id> 0.60

Surveiller ceph -s et ceph osd df tree. Si le device est défaillant, le sortir et planifier le remplacement.

1. Si le device est HS, out et retrait du CRUSH

ceph osd out <id>
# Après drainage et sécurité, retirer du CRUSH et du LVM/device selon votre déploiement

Vérification et rollback

• Après restart ou reweight : tendance vers active+clean. Si la perf chute, revenir à 1.00 ou ceph osd in <id>.
• Nettoyer les flags : ceph osd unset noout

2) PG bloquées dégradées/peering/inactive

Symptômes

• ceph pg stat avec degraded, peering, stale ou inactive
• ceph health detail liste des PG et raisons de blocage

Étapes

1. Inspecter le détail de la PG

ceph pg <pgid> query | jq '.state, .up, .acting, .peering_blocked_by, .recovery_state'

1. Vérifier que tous les OSD de l acting set sont up

ceph osd stat
ceph osd tree | grep -E 'osd\.(<id1>|<id2>|<id3>)'

1. Si peering bloqué par unfound, donner de l air à la recovery

ceph osd set norebalance
ceph osd dump | grep flags

1. Si un OSD est lent, reweight temporaire

ceph osd crush reweight osd.<id> 0.80

1. Pour une seule PG inconsistent, tenter un repair

ceph pg repair <pgid>

Attendu : active+recovering puis active+clean.

Rollback : revenir les poids à 1.00 si déséquilibre, et ceph osd unset norebalance.

3) Quorum MON ou dérive d horloge

Symptômes

• ceph -s montre des mon hors quorum
• ceph health detail signale CLOCK_SKEW

Étapes

1. Vérifier la synchro temps sur tous les MON

chronyc tracking; chronyc sources -v

1. Statut MON et logs

ceph mon stat
sudo journalctl -u ceph-mon@<name> -n 200 --no-pager

1. Si un MON est coincé, redémarrer

sudo systemctl restart ceph-mon@<name>

1. Si le quorum n est pas formé, vérifier réseau et mon_host.

Vérif/rollback : ceph -s doit montrer un quorum stable.

4) Cluster nearfull, backfillfull ou full

Symptômes

• HEALTH_WARN/ERR avec nearfull/backfillfull/full
• Écritures bloquées en full

Étapes

1. Confirmer l utilisation et la distribution par pool

rados df
ceph osd df tree
ceph osd pool ls detail | egrep 'size|min_size|pg_num'

1. Libérer de l espace prudemment

• Supprimer snapshots/objets inutiles dans des pools à faible risque.
• Réduire la pression des pools chauds côté application le temps d ajouter de la capacité.

1. Répartir en baissant légèrement quelques gros OSD

ceph osd crush reweight osd.<id> 0.95

1. Ajout de capacité comme correctif durable. Vérifier le backfill.

5) PG incohérentes et scrubbing

Symptômes

• ceph health detail liste des PG inconsistent
• Scrub/deep-scrub révèle des objets divergents

Étapes

1. Identifier les PG et OSD concernés

ceph health detail | grep -i inconsistent -A3

1. Lancer un repair ciblé en période creuse

ceph pg repair <pgid>

1. Si beaucoup de PG, échelonner le deep-scrub hors pics.

6) Erreurs clients RBD (timeouts / E/S)

Symptômes

• Clients (Proxmox ou Linux rbd map) avec erreurs E/S ou timeouts
• ceph -s peut montrer des slow ops ou PG dégradées

Étapes

1. Confirmer versions client et cluster

ceph versions
rbd --version

1. Vérifier l image et le pool

rbd info <pool>/<image>
ceph pg stat

1. Vérifier l accès aux mon et OSD (réseau/ports ms_bind).

1. Si un seul client est impacté, remapper après avoir validé la santé du cluster (exemple Linux) :

sudo rbd unmap /dev/rbd0
sudo rbd map <pool>/<image>

7) Problèmes CephFS MDS (laggy ou failover bloqué)

Symptômes

• ceph mds stat : moins de MDS actifs que prévu ou laggy
• Timeouts côté clients métadonnées

Étapes

1. Confirmer daemons MDS et standbys

ceph mds stat
journalctl -u ceph-mds@<name> -n 200 --no-pager

1. Si le MDS actif est malade, basculer en redémarrant le daemon concerné

sudo systemctl restart ceph-mds@<name>

1. Si pas de standby, en ajouter un avant maintenance planifiée.

Résultats attendus, contrôles et signaux d échec

Confirmations rapides après chaque action :

• Tendance de santé : ceph -s passe de WARN/ERR vers HEALTH_OK ou diminue les erreurs.
• Recovery PG : ceph pg stat montre une baisse des counts degraded/remapped.
• Stabilité service : systemctl en active (running) ; pas de restart répétés dans journalctl.
• Latence : IOPS/latences s améliorent ou ne régressent pas côté application.

Escaladez si :

• PG inactives > quelques minutes sans progrès de peering.
• PG inconsistent en hausse malgré repair.
• Quorum MON qui flap malgré temps et réseau stables.
• État full persistant après reclamation et reweights.

Rollback et récupération

Gardez la réversibilité :

• Reweights : notez l ancien poids ; rollback avec ceph osd crush reweight osd.<id> 1.00.
• Flags : lister et nettoyer en sortie de maintenance.

ceph osd dump | grep flags
ceph osd unset noout
ceph osd unset norecover
ceph osd unset norebalance

• Restarts : si un restart de daemon aggrave le quorum ou la stabilité, revenez en redémarrant un pair sain et revalidez l heure et le réseau.
• Repairs : si ceph pg repair augmente trop la charge, mettez en pause et reprenez en période creuse ; évitez les repairs massifs en cluster chargé.

Exemples pratiques (construits)

Exemple A : un OSD down après reboot hôte

1. Observer

ceph -s  # 1 osd down, 8 pgs degraded

1. Agir

ceph osd set noout
sudo systemctl restart ceph-osd@7
sleep 15; ceph osd stat
ceph osd unset noout

1. Vérifier

• ceph -s montre 0 osd down ; le compte des PG dégradées tombe à 0 en quelques minutes.

Exemple B : PG inconsistent après deep scrub

1. Observer

ceph health detail | grep inconsistent -A2

1. Agir

ceph pg repair 1.23a

1. Vérifier

• ceph -s nettoie l avertissement inconsistent ; l E/S applicative reste normale.

Checklist d exploitation

Quotidien

• ceph -s et ceph health detail sont propres ou en voie d assainissement.
• rados df montre une marge confortable ; planifier de la capacité sous 20 % de libre.
• chronyc sources -v : sources stables sur tous les nœuds.
• Échantillon court de journaux côté mon, mgr, osd, mds pour anomalies.

Pendant un incident

• Capturer la base : ceph -s, ceph versions, ceph osd tree.
• Localiser : pg query, osd perf, journaux pertinents.
• Protéger : noout uniquement si nécessaire et le retirer vite.
• Un seul changement réversible (restart, reweight, repair ciblé) puis vérification.
• Éviter de pauser la recovery trop longtemps ; unset des flags.

Hebdo ou après changements

• Vérifier que la planification des scrubs est échelonnée hors pics.
• Examiner les plus gros OSD et la distribution par pool ; corriger avec de petits reweights.
• Tester un failover pour un MDS ou un OSD non critique pour garder les procédures fraîches.

Conclusion

Vous disposez désormais d une approche pratique et défendable du dépannage Ceph : inventaire d abord, changements minimaux et réversibles, vérification avec des signaux clairs, rollback rapide si besoin. Démarrez par un périmètre mesurable - par exemple stabiliser un OSD qui flap sur un hôte -, confirmez l amélioration des indicateurs, puis étendez le workflow aux autres nœuds et services. Avec ce flux méthodique, vous réduisez les arrêts, diminuez le risque et gardez votre cluster de stockage prévisible sous pression, tout en traitant efficacement les Ceph errors grâce aux Ceph logs, aux Ceph commands adaptées et à des procédures de Ceph recovery éprouvées.