Ceph : guide pratique d'optimisation des performances avec exemples concrets

L'optimisation des performances de Ceph n'est pas un réglage ponctuel ; c'est une pratique itérative et observable. Que vous utilisiez RBD pour des machines virtuelles sur Proxmox, RGW pour des charges de travail objet ou CephFS pour des fichiers partagés, le débit et la latence de votre grappe dépendent d'une chaîne complète : files d'attente client, réseau, comportement des disques OSD, placement CRUSH, récupération et scrubbing, et compactage en arrière-plan. Ce guide présente une méthode sûre pour inventorier versions, topologie et capacités matérielles ; identifier les goulots d'étranglement avec des vérifications concrètes ; appliquer des changements de configuration réversibles avec des exemples pratiques ; vérifier les résultats, comprendre les modes de défaillance et savoir annuler ; et maintenir une liste de contrôle courte et reproductible pour les opérations au jour le jour. Notre recommandation constante : prouver les améliorations par un essai pilote étroit et mesurable avant tout déploiement large. Les exemples ci-dessous utilisent des chiffres construits pour illustrer les attentes ; adaptez-les à votre environnement.

Inventaire des versions et de l'environnement

Avant d'optimiser, assurez-vous que la grappe est saine et que vous savez ce que vous modifiez.

Enregistrez les versions et la topologie :

ceph versions
ceph -s
ceph osd tree
ceph osd df tree
ceph mon stat
ceph osd pool autoscale-status

Confirmez le placement et les paramètres des pools :

• Pools répliqués ou codés par effacement.
• Mode de l'autoscaler de PG (on, off, warn) par pool.
• Classes de périphériques (HDD, SSD, NVME) et règles CRUSH associant les pools aux classes.

ceph osd crush tree
ceph osd crush class ls
ceph osd crush rule dump

Mesures de référence de latence et de débit (exemples construits) :

• Côté client : un petit test fio pour l'IOPS aléatoire 4k en lecture/écriture et le débit séquentiel 128k.
• Dans la grappe : rados bench pour les opérations au niveau objet.

Commandes d'exemple (utilisez un client hors production ou une fenêtre calme) :

# RADOS écriture puis lecture séquentielle sans nettoyage (synthétique, niveau objet)
rados bench -p <pool> 60 write --no-cleanup
rados bench -p <pool> 60 seq

# Test RBD niveau bloc avec un périphérique mappé (exemple construit)
rbd create --size 10G <pool>/tune-test
rbd map <pool>/tune-test
mkfs.xfs -f /dev/rbd/<id>
mount /dev/rbd/<id> /mnt/rbdtest
fio --name=randread --filename=/mnt/rbdtest/f --rw=randread --bs=4k \
 --iodepth=32 --numjobs=4 --size=2G --time_based=1 --runtime=60 --direct=1
fio --name=seqwrite --filename=/mnt/rbdtest/f2 --rw=write --bs=128k \
 --iodepth=32 --numjobs=2 --size=2G --time_based=1 --runtime=60 --direct=1
umount /mnt/rbdtest
rbd unmap /dev/rbd/<id>
rbd rm <pool>/tune-test

Vérifiez la latence des opérations OSD et les disques occupés :

ceph osd perf
ceph osd dump | grep noscrub -n || true

Si l'état de santé n'est pas OK, corrigez-le d'abord. Optimiser alors que la grappe est dégradée masque souvent le vrai problème.

Métriques clés et comment les collecter

Chemin de configuration sûr

Un chemin sûr évite les régressions à l'échelle de la grappe et préserve la capacité de revenir rapidement en arrière.

1. Formuler une seule hypothèse

Exemples :

• Augmenter la profondeur de file client augmentera le débit des écritures séquentielles jusqu'à saturation du disque OSD.
• Réduire les limites de récupération/backfill aux heures de pointe réduira la latence de queue client.
• Activer les trames géantes (jumbo frames) de bout en bout augmentera le débit RADOS pour les gros I/O.

1. Appliquer un changement à périmètre limité

• Préférez un seul client ou un seul OSD pour les changements pilotes.
• Pour les paramètres des démons Ceph, testez sur un OSD avec un remplacement temporaire ; seulement ensuite, persistez à l'échelle de la grappe.

Remplacement temporaire sur un seul OSD (exemple construit OSD.3) :

# Exemple : réduire les opérations de récupération actives pour diminuer la contention client
ceph tell osd.3 injectargs '--osd_recovery_max_active 1 --osd_max_backfills 1'

Persistance après pilote concluant :

# Persister à l'échelle de la grappe seulement si le pilote aide
ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_max_backfills 1

Annulation :

# Supprimer les clés persistantes ou restaurer les valeurs précédentes
ceph config rm osd osd_recovery_max_active
ceph config rm osd osd_max_backfills

1. Mesurer, comparer, décider

• Relancez exactement le même banc de test et la même tranche de charge.
• Vérifiez la santé Ceph et les latences OSD pour détecter les effets de bord.
• Si cela aide sans nuire, persistez ; sinon, annulez.

Exemples pratiques d'optimisation

Les exemples ci-dessous sont à périmètre limité et réversibles. Remplacez les espaces réservés par vos noms de pool, périphérique et hôte.

1) Limiter la récupération pour protéger la latence client aux heures de pointe

Lorsque la récupération/backfill et les I/O client concurrencent sur les mêmes OSD, la latence p95/p99 grimpe. Vous pouvez réduire l'intensité de récupération aux heures ouvrées et la relâcher hors pointe.

Pilote sur un OSD :

ceph tell osd.<id> injectargs '--osd_recovery_max_active 1 --osd_max_backfills 1 --osd_recovery_op_priority 1'

Observez pendant 15 à 30 minutes :

ceph osd perf
ceph -s
rados bench -p <pool> 60 seq

Résultat attendu (exemple construit) : la latence p99 client s'améliore de 20 à 40 % aux heures de pointe ; la récupération ralentit proportionnellement.

Si positif, persistez à l'échelle de la grappe :

ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_max_backfills 1
ceph config set osd osd_recovery_op_priority 1

Annulation :

ceph config rm osd osd_recovery_max_active
ceph config rm osd osd_max_backfills
ceph config rm osd osd_recovery_op_priority

Compromis : les fenêtres de récupération s'allongent ; prévoyez des limites plus hautes hors pointe ou une bascule planifiée.

2) Ajuster la cible mémoire OSD (BlueStore)

Sur BlueStore, le cache et RocksDB/BlueFS ont besoin de marge mémoire. Trop faible et vous thrash ; trop élevé et le OOM killer du noyau risque de terminer les démons.

Pilote sur un OSD (valeurs construites) :

# Exemple : 8 Gio par OSD sur un hôte 128 Gio exécutant 8 OSD
ceph tell osd.<id> injectargs '--osd_memory_target=8589934592'

Observez la taille résidente (RSS), les arrêts de compactage et la latence opération OSD :

ceph osd perf
ceph daemon osd.<id> perf dump | jq '.bluefs | .[]?'

Si stable et latence améliorée, persistez :

ceph config set osd osd_memory_target 8589934592

Annulation :

ceph config rm osd osd_memory_target

Notes :

• Évitez de fixer des cibles mémoire si hautes que la mémoire totale par hôte dépasse la RAM physique moins la marge OS.
• Gardez bluestore_cache_autotune activé sauf raison forte de micro-gestion.

3) Profondeur de file RBD côté client pour tests de débit

Pour le débit séquentiel, la profondeur de file client et le parallélisme comptent. Avec un périphérique RBD mappé :

# Exemple construit : tester une profondeur plus élevée pour écritures 128k
fio --name=seqwrite --filename=/mnt/rbdtest/f --rw=write --bs=128k \
 --iodepth=128 --numjobs=4 --size=4G --time_based=1 --runtime=120 --direct=1

Comparez avec iodepth=32 ou moins de jobs. Surveillez l'augmentation de latence sans gain de débit ; cela indique saturation disque ou réseau.

Annulation : aucune nécessaire ; ce changement est purement côté client pour le banc de test.

4) Ordonnanceur NVMe/HDD et gouverneur CPU

Les NVMe rapides bénéficient souvent de l'ordonnanceur none ou mq-deadline ; les HDD peuvent préférer mq-deadline.

Vérifiez et définissez (par périphérique) :

# Inspecter
cat /sys/block/nvme0n1/queue/scheduler

# Définir (test runtime ; persister via règle udev si souhaité)
echo none > /sys/block/nvme0n1/queue/scheduler

Définissez le gouverneur CPU performance pour minimiser la latence de changement de fréquence :

# Inspecter l'actuel
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# Définir pour tous les CPU (runtime)
for c in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance > "$c"; done

Vérifiez les latences OSD et le débit fio. Annulation en restaurant les valeurs précédentes (ex. gouverneur ondemand et ordonnanceur d'origine).

5) Validation MTU réseau et sysctls

Les gros I/O bénéficient d'une surcharge par paquet réduite si les trames géantes sont activées de bout en bout de façon cohérente.

Validez le MTU sur le chemin (exemple construit MTU 9000) :

ping -M do -s 8972 <ip-pair>

Si réussi sur toute la grappe, définissez le MTU d'interface sur tous les hôtes et commutateurs Ceph. Si un saut ne supporte pas les trames géantes, restez à 1500 pour éviter fragmentation et trous noirs.

Sysctls optionnels au runtime (testez d'abord) :

sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728
sysctl -w net.core.netdev_max_backlog=250000

Persistez en écrivant dans /etc/sysctl.d/99-ceph-net.conf seulement après pilote concluant. Annulation en restaurant le fichier précédent ou avec sysctl -w aux valeurs d'avant.

6) Autoscaling des PG de pool et classes de périphériques

Assurez-vous que les pools utilisent les classes de périphériques appropriées (ex. NVME pour RBD chaud) et des nombres de PG raisonnables.

Inspectez :

ceph osd pool autoscale-status
ceph osd crush class ls
ceph osd crush tree

Si un pool est sur la mauvaise classe, créez une règle CRUSH ciblant la bonne classe et appliquez-la lors d'une fenêtre à faible trafic. Cela déclenche un déplacement de données ; prévoyez la bande passante de récupération.

Activez l'autoscaling sur les pools dont la taille change fréquemment :

ceph osd pool set <pool> pg_autoscale_mode on

Désactivez l'autoscaling seulement si vous avez une raison précise et un plan manuel de PG.

Vérification et diagnostics

Vérifiez à la fois que la métrique visée s'est améliorée et qu'aucun nouveau problème n'est apparu.

1. Vérifications santé et latence

ceph -s
ceph osd perf
ceph health detail

1. Comparaison des bancs synthétiques

• Relancez les mêmes invocations rados bench et fio.
• Suivez les deltas de latence p95/p99 et de débit (exemple construit : +15 % débit écriture séquentielle avec latence stable).

1. Surveillez récupération et scrubbing

ceph -s | grep -E 'recovery|backfill|scrub'

Assurez-vous que la récupération n'est pas affamée indéfiniment. Si vous l'avez réduite, planifiez des fenêtres pour restaurer les valeurs par défaut hors pointe.

1. Vérifiez les signaux au niveau OSD

# Exemple : vérifier compactage et stats BlueFS sur un OSD
ceph daemon osd.<id> perf dump | jq '{bluefs: .bluefs, bluestore: .bluestore}'

Recherchez les arrêts de compactage ou latences kv_sync inhabituellement hautes ou transitions d'état coïncidant avec des régressions.

Résumé des paramètres ajustables en sécurité

Modes de défaillance et récupération

Savoir ce qui peut casser accélère la récupération.

1. Incompatibilités MTU

Symptômes : timeouts, débit variable, ou arrêts sur gros transferts.

• Détection : ping -M do -s 8972 échoue aléatoirement.
• Correction : standardiser MTU sur serveurs et commutateurs ; sinon, revenir à 1500 partout.

1. Récupération trop limitée

Symptômes : PGs restent en recovering/backfilling trop longtemps ; fenêtres prolongées de déplacement de données.

• Détection : ceph -s montre récupération persistante ; OSD inactifs pour I/O client mais données non rééquilibrées.
• Correction : augmenter osd_recovery_max_active et osd_max_backfills progressivement ; planifier rééquilibrage hors pointe.

1. Cible mémoire OSD trop basse

Symptômes : latence opération montante, arrêts compactage, ou OOM si mémoire surengagée ailleurs.

• Détection : ceph osd perf se dégrade ; dmesg montre pression mémoire.
• Correction : augmenter osd_memory_target ou réduire charge concurrente ; assurer marge RAM hôte.

1. Changements PG déclenchent backfill massif

Symptômes : gros déplacement de données, performance client dégradée.

• Détection : ceph -s indique remappage ; réseau/disque saturés par backfill.
• Correction : appliquer changements PG par étapes pendant fenêtres à faible trafic ; relâcher temporairement les limites de récupération pour finir plus vite, puis restaurer.

1. Bancs de test trompeurs

Symptômes : chiffres fio excellents au premier passage mais chutent ensuite.

• Détection : absence de --direct=1 cause effets cache page.
• Correction : toujours utiliser --direct=1 pour tests synthétiques disque ; vider caches seulement sur hôtes de test où c'est sûr.

Liste de contrôle annulation et récupération

• Clés config Ceph : ceph config rm pour supprimer ; ou restaurer valeurs connues bonnes.
• Sysctls : restaurer fichier /etc/sysctl.d précédent et sysctl --system, ou sysctl -w avec valeurs d'avant.
• Ordonnanceurs/gouverneurs : réécrire valeurs précédentes dans /sys ou annuler règles udev.
• Changements règle CRUSH ou pool : mettre en pause, planifier fenêtre à faible trafic, ou revenir à règle précédente (attendre déplacement données).
• Réactiver scrubbing si désactivé pour tests : ceph osd unset noscrub ; ceph osd unset nodeep-scrub.

Liste de contrôle opérations

Utilisez ceci comme procédure pratique et reproductible.

1. Inventaire et référence

• Capturez ceph versions, ceph -s, ceph osd perf.
• Notez types de pools, modes autoscale, classes de périphériques.
• Lancez un rados bench rapide et une petite suite fio avec direct=1.

1. Hypothétiser et cadrer

• Choisissez exactement une hypothèse de goulot (ex. contention récupération vs client, surcharge réseau, choix ordonnanceur).
• Prenez le plus petit pilote (un OSD ou un client) et une fenêtre d'observation de 30 à 60 minutes.

1. Changer en sécurité

• Appliquez un remplacement temporaire (ex. injectargs sur un OSD) ou paramètres de test côté client seulement.
• Évitez mises à jour grappe entière jusqu'au succès pilote.

1. Vérifier

• Relancez tests identiques ; comparez latence p95/p99 et débit.
• Vérifiez ceph -s, ceph osd perf, et états PG.

1. Décider et persister

• Si amélioration claire et effets de bord acceptables, persistez via ceph config set ou fichiers config OS.
• Documentez nouveaux défauts et quand basculer (ex. paramètres récupération pointe vs hors pointe).

1. Annuler si nécessaire

• Utilisez ceph config rm ou restaurez valeurs connues bonnes.
• Annulez sysctls et changements ordonnanceur/gouverneur.

1. Planifier revues régulières

• Relancez la référence trimestriellement ou après changements matériel/charge.
• Supprimez les réglages qui n'aident plus.

Conclusion

Les performances de Ceph s'améliorent le plus vite quand les changements sont petits, sûrs et mesurables. Commencez par inventorier vos versions, topologie et charges de travail ; établissez une référence de santé propre ; et testez un bouton à la fois sur un pilote étroit. Utilisez les remplacements temporaires pour prouver un gain, puis persistez seulement ce qui aide et documentez des étapes d'annulation claires. Avec le temps, votre grappe convergera vers des défauts bien compris pour votre matériel et vos charges de travail, et vous aurez une routine légère pour le maintenir ainsi. L'optimisation cohérente et pilotée par les preuves bat les changements spéculatifs à chaque fois, et la discipline pilote-puis-persiste protège les charges de production tout en livrant de vrais gains.