Dépannage Ceph avec exemples pratiques

Le dépannage Ceph n'a pas à être du travail d'investigation hasardeux. Avec un inventaire clair, une approche de configuration sécurisée et une séquence de diagnostic ciblée, la plupart des problèmes peuvent être localisés rapidement et récupérés avec un risque minimal. Ce guide fournit :

• Un inventaire rapide pour établir une base de référence des versions et de la topologie
• Un parcours sécurisé pour les changements de configuration et opérationnels
• Des commandes de diagnostic avec signaux attendus et exemples construits
• Des workflows de récupération étape par étape pour les pannes courantes
• Des conseils de restauration et vérification après chaque correction
• Une liste de contrôle opérationnelle concise à exécuter quotidiennement ou lors d'incidents

L'objectif est un flux pratique et reproductible qui réduit les temps d'arrêt et le travail répété tout en gardant les données en sécurité.

Inventaire des versions et de l'environnement

Avant d'agir, capturez ce que vous avez maintenant. Cela vous protège des angles morts et vous donne un avant/après mesurable.

Prérequis

• Accès shell à tous les serveurs monitor, manager, OSD et metadata
• Privilèges sudo sur les nœuds qui exécutent les démons Ceph
• CLI Ceph configurée (keyrings présents sous /etc/ceph ou dans l'environnement)
• Une fenêtre de maintenance si un déplacement de données peut survenir

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 principaux :

ceph mon stat
ceph mgr stat
ceph mds stat  # si utilisation de CephFS

Temps et bases 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és mais le cluster est globalement sain. La récupération se terminera probablement après la remise en service de l'OSD ou son remplacement. Notez l'utilisation à 15 % -- bien en dessous du seuil nearfull par défaut de 85 %.

Parcours de configuration sécurisé

Lorsque des données de production sont en jeu, la discipline du changement est essentielle. Utilisez ces garde-fous :

• Changez une seule chose à la fois. Vérifiez entre les étapes avec ceph -s et des vérifications ciblées.
• Utilisez les drapeaux du cluster avec parcimonie et nettoyez-les rapidement :
• noout évite le déplacement de données pendant de brèves fenêtres de maintenance. Levez-le dès que possible.
• norecover et norebalance mettent en pause la récupération et le rééquilibrage ; utilisez-les seulement pour protéger la latence pendant une correction urgente et désactivez-les une fois terminé.
• Privilégiez le reweight ciblé plutôt qu'un out dur lors de l'isolation d'un disque bruyant. Le reweight réduit l'impact et s'annule facilement.
• N'exécutez pas d'outils destructifs sur les chemins de données BlueStore sans sauvegardes explicites et recommandations du fournisseur.
• Maintenez un budget de synchronisation temporelle sous 50 ms entre les nœuds ; corrigez d'abord la dérive d'horloge si présente.

Référence rapide des drapeaux de maintenance

Vérification et diagnostics

Commencez par les signaux au niveau du cluster, puis affinez vers les composants. Confirmez chaque hypothèse avec une vérification spécifique.

Santé du noyau et temps

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

• Sain attendu : Aucune dérive d'horloge rapportée dans ceph health detail. Si vous voyez CLOCK_SKEW, corrigez la synchronisation temporelle en premier.

Placement Groups et OSDs

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

• Sain attendu : La majorité des PGs en active+clean ; petit nombre brièvement en remapped+backfill après les changements.
• Surveillez ceph osd perf : La latence de commit et apply doit rester sous 10 ms sur SSD sains ; des valeurs soutenues au-dessus de 20 ms précèdent souvent le flapping.

Logs

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

• Cherchez les erreurs d'E/S disque, échecs d'authentification, sauts d'horloge et crashs répétés.

Vérification réseau

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

• Attendu : Aucune erreur RX/TX ; MTU constant (généralement 1500 ou 9000) 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 : L'état affiche active+clean ou active+recovery ; peering_blocked_by vide quand sain.

Exemple construit : Taxonomie rapide de la santé

Modes de défaillance et récupération

Les workflows suivants couvrent les problèmes courants. Pour chacun : observez, agissez, et vérifiez avant de passer au suivant. Tous les exemples sont construits.

1) OSD down ou flapping

Symptômes

• ceph -s montre 1 ou plusieurs OSDs down
• ceph osd tree indique des périphériques en état down ou out
• journalctl montre des redémarrages OSD répétés ou erreurs E/S

Étapes

1. Identifier l'OSD id et l'hôte

   ceph osd tree
   ceph osd find <id>

Attendu : Vous voyez l'hôte et le chemin du périphérique pour l'OSD (ex: osd.7 sur host3 utilisant /dev/nvme1n1).

1. Inspecter le service et les logs sur cet hôte

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

Attendu : Si le disque faillit, SMART montre Reallocated_Sector_Ct ou Current_Pending_Sector > 0 ; sinon, cherchez des problèmes de système de fichiers ou permissions.

1. Fenêtre de maintenance courte : prévenir le churn si vous devez redémarrer

   ceph osd set noout

1. Tenter un redémarrage propre

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

Attendu : L'OSD revient à up+in ; les PGs commencent à récupérer. S'il flappe à nouveau, continuez.

1. Si le périphérique est bruyant mais pas mort, réduisez son poids pour décharger la charge

   ceph osd crush reweight osd.<id> 0.60

Observez : ceph -s et ceph osd df tree pour confirmer le mouvement. Si le périphérique faillit, marquez-le out et planifiez le remplacement.

1. Si le périphérique a échoué, marquez out et retirez du CRUSH

   ceph osd out <id>
   # Après que les données sont drainées et sûres, retirez du CRUSH et du mapping LVM/périphérique selon votre déploiement

Vérification et restauration

• Après redémarrage ou reweight : ceph -s doit tendre vers active+clean. Si la performance se dégrade, annulez le reweight (ex: 1.00) ou réactivez l'OSD avec ceph osd in <id>.
• Levez les drapeaux une fois stable : ceph osd unset noout

2) PGs bloqués en degraded, peering ou inactive

Symptômes

• ceph pg stat montre des PGs dans des états comme degraded, peering, stale ou inactive
• ceph health detail liste des PG ids spécifiques et raisons de blocage du peering

Étapes

1. Inspecter le détail du PG

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

1. Vérifier que tous les OSDs du acting set sont up

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

1. Si le peering est bloqué par des objets unfound, donnez de l'espace à la récupération et évitez les plafonds de bande passante que vous contrôlez

   # Mettre en pause le rééquilibrage temporairement seulement s'il concurrence la récupération
   ceph osd set norebalance
   # Assurez-vous que norecover n'est PAS activé sauf si vous l'avez mis en pause intentionnellement
   ceph osd dump | grep flags

1. Si un OSD spécifique est lent, réduisez temporairement son poids pour débloquer le peering

   ceph osd crush reweight osd.<id> 0.80

1. Pour un PG inconsistent unique, tentez une réparation

   ceph pg repair <pgid>

Attendu : Le PG passe à active+recovering, puis active+clean.

Restauration

• Annulez les reweights à 1.00 s'ils causent un déséquilibre.
• Levez norebalance : ceph osd unset norebalance

3) Problèmes de quorum MON ou dérive d'horloge

Symptômes

• ceph -s montre les démons mon pas dans le quorum
• ceph health detail montre des avertissements CLOCK_SKEW

Étapes

1. Vérifier la synchronisation temporelle sur tous les hôtes MON

   chronyc tracking; chronyc sources -v

Attendu : Le décalage reste dans les dizaines de millisecondes. Un Last offset au-dessus de 50 ms justifie une correction immédiate.

1. Vérifier le statut MON et les logs

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

1. Si un MON est bloqué, redémarrez ce MON

   sudo systemctl restart ceph-mon@<nom>

1. Si le quorum ne se forme toujours pas, assurez la connectivité réseau entre MONs et que les adresses mon_host sont correctes pour votre environnement.

Vérification et restauration

• ceph -s doit montrer un quorum stable (ex: mon: 3 daemons, quorum mon-a, mon-b, mon-c). Si le redémarrage d'un MON dégrade la stabilité, annulez le redémarrage et investiguez le réseau ou l'heure d'hôte plus loin.

4) Cluster nearfull, backfillfull ou full

Symptômes

• HEALTH_WARN ou HEALTH_ERR avec drapeaux nearfull/backfillfull/full
• Écritures bloquées en condition full (le cluster cesse d'accepter les écritures à 95 % par défaut)

Étapes

1. Confirmer l'utilisation et la distribution des pools

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

1. Libérer de l'espace en toute sécurité

• Supprimer les snapshots ou objets inutiles dans les pools à faible risque.
• Réduire temporairement la pression sur les pools chauds (throttling côté application) pendant que vous ajoutez de la capacité.
• Réduire le poids de quelques gros OSDs pour répartir les données si le déséquilibre est la cause :

     ceph osd crush reweight osd.<id> 0.95  # petits ajustements sur plusieurs OSDs

1. Ajouter de la capacité comme correction durable. Après l'ajout d'OSDs, vérifiez que le backfill progresse et que les drapeaux se lèvent.

Vérification et restauration

• ceph -s lève nearfull/backfillfull/full ; l'espace libre des pools augmente.
• Remettez les reweights à 1.00 après la restauration de l'équilibre.

5) PGs inconsistants et scrubbing

Symptômes

• ceph health detail liste des PG inconsistent
• Le scrub ou deep-scrub révèle des objets décalés

Étapes

1. Identifier les PGs et OSDs concernés

   ceph health detail | grep -i inconsistent -A3

1. Déclencher une réparation ciblée pendant une fenêtre à faible trafic

   ceph pg repair <pgid>

1. Si de nombreux PGs sont inconsistants, revoyez l'ordonnancement du scrub pour éviter la contention bursty de deep-scrub. Échelonnez les deep-scrubs pendant les heures creuses (ex: définissez osd_scrub_begin_hour = 22 et osd_scrub_end_hour = 4 avec décalages aléatoires par OSD).

Vérification et restauration

• ceph -s ne montre plus de PGs inconsistants. Si la réparation augmente trop la latence, mettez en pause et reprenez pendant une fenêtre plus calme.

6) Erreurs client RBD (timeouts ou échecs IO)

Symptômes

• Les clients (ex: Proxmox ou Linux rbd map) rapportent des erreurs IO ou timeouts
• ceph -s peut montrer des slow ops ou PGs dégradés

Étapes

1. Confirmer les versions client et cluster

   ceph versions
   rbd --version

1. Vérifier la santé de l'image et du pool spécifiques

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

1. Confirmer que le client peut atteindre les monitors et OSDs

• Valider le réseau ms_bind et les ports firewall (6789 pour monitors, 6800-7300 pour OSDs).
• Tester avec ceph -s depuis le nœud client en utilisant son keyring.

1. Si un seul chemin client est impacté, remappez l'image sur ce client après avoir confirmé que le cluster est sain.

Exemple construit : Remap sur un client Linux

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

Vérification et restauration

• L'IO applicative reprend sans timeouts. Si le remap n'aide pas, annulez et continuez les diagnostics côté serveur.

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

Symptômes

• ceph mds stat montre moins de MDS actifs que prévu ou des états laggy
• Les clients voient des timeouts de métadonnées

Étapes

1. Confirmer les démons MDS et standbys

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

1. Si le MDS actif est malsain, basculez vers un standby en redémarrant le démon malsain

   sudo systemctl restart ceph-mds@<nom>

1. Si aucun standby n'existe, ajoutez-en un avant la maintenance planifiée pour éviter les points de défaillance uniques.

Vérification et restauration

• ceph mds stat montre un actif et au moins un standby (ex: mds.fs-a:1 {0=mds-host1=up:active} 1 up:standby-replay mds-host2). Si le redémarrage empire le comportement, annulez et examinez l'hôte et le réseau sous-jacents.

Résultats attendus, vérifications et signaux d'échec

Utilisez ces confirmations rapides après chaque changement :

• Tendance santé : ceph -s passe de WARN/ERR à HEALTH_OK ou moins d'erreurs.
• Récupération PG : ceph pg stat montre une diminution des compteurs degraded/remapped dans le temps.
• Stabilité service : systemctl status reste active (running) ; pas de redémarrages répétés dans journalctl.
• Latence : Les métriques côté application (IOPS/latence) s'améliorent ou au minimum ne régressent pas.

Éscalez si vous voyez :

• PGs bloqués inactive plus de quelques minutes sans progression du peering.
• PGs inconsistants en augmentation après tentatives de réparation.
• Quorum MON qui flappe malgré temps et réseau stables.
• Condition full qui persiste après récupération et reweighting.

Guide de restauration et récupération

Gardez la récupération réversible là où c'est possible :

• Reweights : Notez toujours la valeur précédente ; restaurez avec ceph osd crush reweight osd.<id> 1.00.
• Drapeaux : Listez et levez à la sortie de maintenance.

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

• Redémarrages : Si un redémarrage de démon dégrade le quorum ou la stabilité, annulez en redémarrant un pair précédemment sain et revérifiez temps et réseau.
• Réparations : Si ceph pg repair augmente la charge, mettez en pause et réessayez dans une fenêtre plus calme ; ne réparez pas par lots de nombreux PGs simultanément dans un cluster occupé.

Exemples pratiques (construits)

Exemple A : OSD unique down après redémarrage d'hôte

1. Observer

   ceph -s  # montre 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 osds down ; les PGs dégradés tombent à 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 lève l'avertissement inconsistent ; l'IO applicative non affectée.

Liste de contrôle opérationnelle

Quotidien

• ceph -s et ceph health detail sont propres ou tendent vers propre.
• rados df montre une marge confortable (>20 % libre) ; planifiez la capacité quand en dessous de 20 % libre.
• chronyc sources -v révèle des sources temporelles stables sur tous les nœuds (décalage < 50 ms).
• Revoyez un petit échantillon de logs sur chaque rôle (mon, mgr, osd, mds) pour anomalies.

Pendant les incidents

• Capturez la base : ceph -s, ceph versions, ceph osd tree.
• Localisez : pg query, osd perf, et logs du démon concerné.
• Protégez : mettez noout seulement quand nécessaire et levez-le promptement.
• Faites un seul changement réversible (redémarrage, reweight, réparation ciblée) et vérifiez.
• Évitez de mettre en pause la récupération plus que nécessaire ; levez les drapeaux.

Hebdomadaire ou après changements

• Confirmez que l'ordonnancement du scrub est échelonné et ne collisionne pas avec les heures de pointe.
• Revoyez les plus gros OSDs et la distribution des pools ; corrigez les déséquilibres avec de petits reweights (±0.05 incréments).
• Testez le basculement pour un MDS ou OSD non-critique pour assurer que les procédures sont à jour.

Conclusion

Vous avez maintenant une approche pratique et défendable du dépannage Ceph : inventaire d'abord, changements minimaux et réversibles, vérification avec signaux clairs, et restauration rapide si nécessaire. Commencez par un pilote étroit et mesurable comme la stabilisation du flapping OSD sur un hôte, confirmez que les indicateurs de santé s'améliorent, puis étendez le workflow aux nœuds et services supplémentaires. Avec ce flux méthodique, vous pouvez réduire les temps d'arrêt, baisser le risque, et garder votre cluster de stockage prévisible sous pression.