Tu as un cluster Ceph qui « rame ». Les VM mettent trois plombes à booter, les IOPS s’effondrent, les latences explosent, et forcément c’est toujours « depuis ce matin » sans autre détail. Classique.
L’objectif ici est simple et réaliste : en 30 minutes, tu dois être capable d’identifier où ça bloque (réseau, disques, OSD, PG, scrubbing, recovery, CPU, config) et de sortir un diagnostic exploitable. Pas un audit de 3 jours. Un plan d’action.
Je te propose une méthode chronométrée, avec les commandes à lancer, ce que tu dois regarder, et comment interpréter vite. C’est le genre de check-list que tu peux réutiliser en TP ou en prod. Et si tu es en BTS SIO SISR, garde ça sous le coude, clairement. D’ailleurs sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/), je publie souvent ce genre de procédures terrain, tu peux y revenir quand tu veux.
Avant de commencer : deux règles qui sauvent des clusters
- Ne lance pas 15 trucs « pour voir ». Sur Ceph, certaines actions augmentent la charge (deep-scrub, recovery, backfill). On observe d’abord, on agit ensuite.
- Garde une trace. Un simple fichier de log de session suffit.
bash script -a diag_ceph_lent_$(date +%F_%H%M).log
Vue d’ensemble (minute 0 à 3) : santé du cluster et symptômes
1) État global
bash ceph -s ceph health detail
Ce que tu cherches immédiatement :
HEALTH_WARNouHEALTH_ERRslow ops(le mot magique)degraded,undersized,peering,inactivebackfill,recovery,remappedpgs not active+clean
Si tu vois slow ops, note :
- combien (
X slow ops) - sur quels daemons (souvent un OSD)
- depuis combien de temps (
oldest one blocked for ... sec)
2) Image utile à insérer (aperçu état cluster)
Ajoute un screenshot de ton ceph -s (en masquant les noms si besoin).
Minute 3 à 8 : latence côté clients ou côté cluster ?
Ici, on veut savoir si le problème est « ressenti » par les clients (RBD/CephFS) ou si le cluster lui-même est en vrac.
1) Performance en temps réel
bash ceph perf ceph df rados df
Pas toujours parlant, mais si tu vois des valeurs aberrantes ou un pool plein, tu prends note.
2) Ciblage RBD (si tu es sur Proxmox/OpenStack)
Sur un client (hyperviseur) :
bash rbd perf image iostat --pool --image --interval 1
Si la latence est déjà énorme côté client, ça confirme. Sinon, parfois le souci est réseau client, multipath, ou CPU côté hyperviseur.
Minute 8 à 14 : les PG font-elles n’importe quoi ?
Les PG, c’est souvent le « thermomètre » du cluster. Si ça peering, remap, backfill… tu as ta piste.
bash ceph pg stat ceph pg dump_stuck inactive ceph pg dump_stuck unclean ceph pg dump_stuck stale
Si tu vois beaucoup de PG non active+clean, ce n’est pas « un peu lent ». C’est une instabilité.
Ensuite :
bash ceph osd tree ceph osd stat
Ce que tu veux repérer :
- un host down
- un OSD down / out
- des weights bizarres
- un rack ou un nœud qui concentre trop de PG
Image utile (topologie OSD)
Une capture ceph osd tree est très visuelle.
Minute 14 à 20 : trouver l’OSD « coupable » (ou le groupe coupable)
On va chercher les OSD lents, ceux qui ont des queues de requêtes, ou qui saturent.
1) Latences et commits
bash ceph osd perf
Tu obtiens des latences commit et apply par OSD. En général :
- si 1 ou 2 OSD explosent, tu as un problème disque, contrôleur, ou saturation locale
- si tous montent, c’est plutôt réseau, scrubbing/recovery massif, ou cluster sous-dimensionné
2) Requêtes bloquées et slow ops
bash ceph health detail | grep -i slow -n
Puis sur l’OSD suspect (exemple osd.12) :
bash ceph daemon osd.12 dump_ops_in_flight ceph daemon osd.12 perf dump | head -n 50
Si dump_ops_in_flight montre des opérations bloquées sur filestore (ancien) ou bluestore, tu peux souvent relier à un disque à la traîne.
3) Regarder les logs, vite et propre
Sur le nœud qui héberge l’OSD :
bash journalctl -u ceph-osd@12 --since "30 min ago" | tail -n 200
Cherche des motifs :
- erreurs disque, timeouts
slow requestbluefswarningsheartbeatlatency
Minute 20 à 24 : le réseau, l’ennemi silencieux
Ceph est extrêmement sensible au réseau, surtout en réplication. Si ton réseau backend est congestionné ou instable, tu vas le sentir en latence, en peering, en slow ops.
1) Vérifier l’interface, les erreurs, la saturation
Sur chaque nœud (ou au moins ceux qui semblent suspects) :
bash ip -s link ethtool -S | egrep -i 'err|drop|crc|miss|timeout' | head
Tu traques :
- drops
- CRC
- erreurs RX/TX
- débit qui plafonne
2) Vérifier la latence inter-nœuds
Simple et bête, mais utile :
bash ping -c 20 <ip_backend_peer>
Si tu vois de la perte, même faible, Ceph peut devenir horrible.
3) MTU incohérent (classique)
Si certains sont en 9000 et d’autres en 1500, tu peux avoir des symptômes « bizarres ». Vérifie :
bash ip link show | grep -E "mtu|state"
Minute 24 à 27 : scrubbing, recovery, backfill… ou le cluster qui travaille trop
Parfois Ceph est « lent » parce qu’il fait ce qu’on lui a demandé, mais au pire moment. Un disque a lâché, tu as remis un OSD, et maintenant recovery/backfill saturent tout.
1) Voir si ça reconstruit
bash ceph -s ceph tell osd.* heap stats 2>/dev/null | head
Bon, la deuxième commande n’est pas toujours nécessaire. Le plus parlant reste le ceph -s avec recovery, backfill, degraded.
2) Scrub / deep-scrub
bash ceph pg dump | egrep 'scrub|deep' | head
Si tu vois du deep-scrub en pleine journée et que ton cluster est juste en perf, ça peut suffire à le plomber.
Sans tout casser, tu peux temporairement réduire l’impact en jouant sur les paramètres (avec prudence, et idéalement en change management). Par exemple limiter recovery :
bash ceph tell osd.* injectargs '--osd-max-backfills=1 --osd-recovery-max-active=1'
Note bien : c’est du dépannage. L’idée n’est pas de laisser ces valeurs à vie.
Minute 27 à 30 : le stockage local, le vrai nerf de la guerre
Si tu as identifié un ou plusieurs OSD lents, tu veux confirmer côté OS : disque, latence, queue, erreurs.
Sur le nœud concerné :
bash lsblk -o NAME,SIZE,TYPE,ROTA,MODEL,SERIAL iostat -x 1 10
Ce que tu surveilles dans iostat -x :
%utilproche de 100 %awaittrès élevésvctm(selon version)- des pics sur un disque précis
Puis :
bash smartctl -a /dev/ dmesg | egrep -i 'error|timeout|reset|nvme|scsi' | tail -n 50
Si tu vois des reset ou timeout, tu as probablement ton coupable. Ça peut être :
- disque fatigué
- câble / backplane
- contrôleur RAID/HBA
- firmware
- throttling NVMe
Image utile (iostat ou graph latence)
Une capture d’un iostat -x avec await qui explose parle instantanément.
Interprétation rapide : un mini tableau mental
Cas 1 : 1 OSD a des latences énormes
Probable : disque en fin de vie, NVMe qui throttle, problème HBA, OSD qui swap, journal saturé, DB/WAL sur mauvais support.
Actions : vérifier SMART, dmesg, iostat. Envisager de mettre l’OSD out si ça met le cluster à genoux, mais seulement après avoir évalué l’impact.
Cas 2 : tous les OSD ont des latences élevées
Probable : réseau backend saturé, recovery/backfill massif, scrubbing agressif, CPU saturé, ou un paramétrage trop « optimiste ».
Actions : vérifier liens réseau, drops, saturation, ceph -s (recovery), limiter temporairement recovery.
Cas 3 : beaucoup de PG en peering / inactive
Probable : instabilité réseau, OSD flapping, clocks désynchronisées, ou un nœud qui décroche.
Actions : logs OSD, ceph osd tree, ping inter-nœuds, NTP/chrony.
Cas 4 : le cluster est clean mais les clients sont lents
Probable : réseau client, hyperviseurs saturés, map RBD, queue côté VM, ou application.
Actions : tester depuis client, regarder latence sur hyperviseur, vérifier le chemin réseau client, vérifier que ce n’est pas un pool trop plein (nearfull/full).
Bonus : une check-list « copier coller » pour ton lab
Tu peux littéralement coller ça dans ton terminal, ça te sort un diagnostic brut rapide.
bash echo "### ceph -s"; ceph -s echo "### health detail"; ceph health detail | head -n 80 echo "### pg stat"; ceph pg stat echo "### osd tree"; ceph osd tree echo "### osd perf"; ceph osd perf echo "### df"; ceph df
Puis tu pivotes selon ce qui ressort.
Et après ? rédiger un diagnostic qui sert vraiment
Au lieu de dire « Ceph est lent », écris comme ça :
- Symptôme : latence RBD moyenne à X ms, pics à Y ms, impact VM (boot, IO)
- État cluster :
HEALTH_WARN,slow ops,recovery/backfillactif, PG pas clean (si oui) - Cause la plus probable :
osd.12commit/apply très élevé, erreurs disque dans dmesg - Preuves : commandes + extraits logs
- Actions immédiates : limiter recovery, sortir OSD si nécessaire, déplacer VM critiques
- Correctifs : remplacement disque, équilibrage, tuning, séparation réseau client/backend, etc.
C’est con mais… c’est ça qui fait pro.
Pour aller plus loin (et garder ça sous la main)
Si ce format « procédure terrain » t’aide, fais un tour sur BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/). L’idée du site, c’est exactement ça : des labs et des fiches pratiques orientées sysadmin, réseau, sécu, cloud, et tout ce qui tombe en BTS SIO SISR.
Récap en une phrase
En 30 minutes, tu peux diagnostiquer un Ceph lent en enchaînant : ceph -s (symptômes) → PG/OSD (où ça casse) → ceph osd perf (qui ralentit) → réseau (drops/MTU) → disque (iostat/smart/dmesg). Et tu sors avec une cause probable + des preuves.
Questions fréquemment posées
Quels sont les premiers signes indiquant que mon cluster Ceph rencontre des problèmes de performance ?
Les premiers signes incluent des VM qui mettent beaucoup de temps à booter, une chute importante des IOPS (entrées-sorties par seconde), des latences qui explosent, et dans le statut du cluster, la présence de messages comme 'HEALTH_WARN' ou 'HEALTH_ERR', 'slow ops', ou encore des PGs (placement groups) en état 'degraded', 'undersized', 'peering' ou 'inactive'.
Quelle est la méthode rapide pour diagnostiquer un cluster Ceph lent en moins de 30 minutes ?
La méthode consiste à suivre une check-list chronométrée : d'abord vérifier l'état global du cluster avec 'ceph -s' (minutes 0-3), ensuite analyser la latence côté client et cluster avec 'ceph perf' et outils clients (minutes 3-8), examiner l'état des PGs avec 'ceph pg stat' et commandes associées (minutes 8-14), puis identifier les OSD lents via 'ceph osd perf' et inspection des opérations bloquées (minutes 14-20). Cette approche permet d'isoler rapidement la source du problème sans lancer d'opérations lourdes.
Pourquoi ne faut-il pas lancer plusieurs actions simultanées comme le deep-scrub ou recovery lors d'un diagnostic ?
Parce que certaines actions comme le deep-scrub, recovery ou backfill augmentent considérablement la charge sur le cluster Ceph. Lancer plusieurs opérations en même temps peut aggraver les problèmes de performance. Il est conseillé d'observer d'abord l'état du cluster avant d'agir, afin d'éviter de surcharger inutilement les ressources.
Comment identifier si le problème vient du réseau, des disques ou des OSD dans un cluster Ceph ?
On commence par vérifier les performances globales et la latence côté client et cluster. Si tous les OSD montrent une latence élevée, cela peut indiquer un problème réseau ou une opération massive comme un scrubbing. Si seulement quelques OSD présentent des latences anormales ou des files d'attente bloquées ('dump_ops_in_flight'), cela suggère un problème localisé au disque, contrôleur ou à l'OSD lui-même.
Quels outils utiliser pour surveiller l'état des PGs dans Ceph ?
Les commandes utiles sont : 'ceph pg stat' pour un aperçu rapide, puis 'ceph pg dump_stuck inactive', 'ceph pg dump_stuck unclean' et 'ceph pg dump_stuck stale' pour identifier les PGs problématiques. Ces informations aident à détecter les PGs non actives+clean, signe d'une instabilité du cluster.
Comment garder une trace efficace lors du diagnostic d'un cluster Ceph lent ?
Il est recommandé de lancer toutes vos commandes dans un fichier log de session pour garder une trace précise. Par exemple, utiliser : bash script -a diag_ceph_lent_$(date +%F_%H%M).log permet d'enregistrer toute la session diagnostique. Cela facilite le suivi, la comparaison et le partage du diagnostic.
0 Commentaires