Dépannage des pools et groupes de placement Ceph : guide d'implémentation pratique

La fiabilité de Ceph repose sur la façon dont les pools et les groupes de placement (PG, Placement Groups) associent les données aux OSD. Lorsque les PG sont dégradés ou sous-dimensionnés, le cluster continue de servir les E/S mais avec une durabilité réduite. Ce guide explique comment les pools et les PG fonctionnent ensemble, comment interpréter les états des PG, comment la taille de réplication (size) et le paramètre min_size affectent la disponibilité et la sécurité, et quelles commandes exécuter en priorité pour diagnostiquer et récupérer sans aggraver la situation. Il s'adresse aux développeurs, consultants DevOps et équipes de startups qui exploitent Ceph directement ou via des plateformes qui l'intègrent.

Ce que vous retiendrez :

• Un workflow clair pour trier et corriger les problèmes de PG en toute sécurité.
• Des vérifications pratiques qui font remonter la cause racine rapidement.
• Des playbooks tactiques pour les scénarios de récupération courants.

Vue d'ensemble du workflow

Utilisez un chemin reproductible pour réduire les risques et accélérer la résolution :

1. Lire l'état de santé et délimiter le périmètre d'impact

• Exécutez ceph -s et ceph health detail pour comprendre ce qui ne va pas et l'étendue du problème.
• Notez le nombre de PG dégradés/sous-dimensionnés et les pools affectés.

1. Associer pools, PG et OSD

• ceph osd pool ls detail pour voir les réglages des pools.
• ceph pg dump pgs_brief pour voir l'état et les ensembles d'OSD.

1. Vérifier la santé des OSD et des hôtes

• ceph osd tree et ceph osd df pour le statut et la capacité.
• systemctl status ceph-osd@<id> et journalctl -u ceph-osd@<id> -n 200 lorsqu'un OSD est down ou instable.

1. *Contrôler size et min_size de réplication*

• ceph osd pool get <pool> size et ceph osd pool get <pool> min_size.
• Confirmez que les réglages correspondent à votre domaine de panne et votre tolérance au risque.

1. Identifier les états exacts des PG

• ceph pg stat pour les totaux ; ceph pg ls-by-pool <pool> degraded pour cibler.
• ceph pg query <pgid> pour les détails sur les PG bloqués.

1. Choisir la correction la moins disruptive

• Privilégiez le rétablissement des OSD ou hôtes défaillants plutôt que le changement de réglages de pool.
• Si un changement s'impose, limitez-le à un périmètre étroit avec de la marge de capacité.

1. *Surveiller la récupération jusqu'à active+clean***

• Suivez ceph -s et ceph health detail jusqu'au retour des PG à active+clean.
• Surveillez la vitesse de backfill et de récupération ; vérifiez l'absence de conditions nearfull.

1. Prévenir la récurrence

• Validez l'auto-scaling ou les comptes de PG manuels par pool.
• Alignez size et min_size avec les pannes attendues et les SLA.

Pools et PG Ceph : concepts clés

• Pools : espaces de noms logiques avec leur propre taille de réplication, min_size et règle CRUSH. Différentes charges de travail devraient avoir des pools distincts.
• Groupes de placement (PG) : unité de placement, de peering et de récupération. Chaque PG correspond à un ensemble d'OSD selon la règle CRUSH du pool et son réglage de réplication.
• *Taille de réplication (size)* : nombre cible de répliques par PG. Plus de répliques augmentent la durabilité au coût de la capacité et du trafic de récupération.
• min_size : nombre minimal de répliques requis pour accepter les écritures en toute sécurité. Les écritures sont bloquées en dessous de min_size pour protéger l'intégrité des données.
• Nombre de PG : influence la distribution des données et le parallélisme de récupération. Trop peu de PG crée des points chauds ; trop en gaspille la mémoire et ralentit le peering et la récupération. Utilisez l'auto-scaling quand disponible, ou planifiez soigneusement les comptes manuels. Par exemple, un cluster de 100 OSD avec une cible de 100 PG par OSD donne environ 10 000 PG ; l'auto-scaling ajuste selon l'usage réel.

États courants des PG et actions

• active+clean : état souhaité. Aucune action.
• active+degraded : des répliques manquent mais le PG sert les E/S. Action : confirmez que les OSD concernés sont up et in ; laissez la récupération backfill les répliques manquantes.
• undersized+degraded : moins d'OSD que requis par size. Action : rétablissez les OSD ou hôtes. Changez size seulement si absolument nécessaire et après analyse d'impact.
• peering : les OSD échangent les cartes pour s'accorder sur l'historique du PG. Action : laissez finir ; si bloqué, inspectez les logs OSD et le réseau entre pairs.
• backfilling/recovering : les données se déplacent pour restaurer la redondance. Action : surveillez la progression ; évitez la maintenance lourde jusqu'à la fin.
• stale/inactive : les moniteurs ne reçoivent pas de rapports à temps. Action : rétablissez la communication ou les OSD qui hébergent ces PG.
• inconsistent : le scrubbing a trouvé des divergences. Action : planifiez ceph pg repair <pgid> en période de faible charge et surveillez.

Taille de réplication et min_size

size et min_size contrôlent directement durabilité et disponibilité :

• size : nombre de copies quand le cluster est sain. Augmenter size renforce la durabilité mais déclenche un backfill ; assurez capacité et bande passante d'abord.
• min_size : plancher pour servir les écritures. Baisser min_size peut restaurer la disponibilité en écriture pendant les pannes mais augmente le risque. Préférez le retour des OSD et n'ajustez min_size qu'avec des limites claires et un plan de retour arrière.

Ajustements sûrs :

• Lisez l'actuel : ceph osd pool get <pool> size et ceph osd pool get <pool> min_size.
• Planifiez la marge : vérifiez ceph osd df pour la capacité et la charge du cluster.
• Changez par périmètre étroit : ajustez un seul pool non critique d'abord, mesurez l'impact, puis continuez.

Commandes et vérifications sûres

Commencez par des diagnostics en lecture seule :

• Santé du cluster : ceph -s, ceph health detail
• Vue d'ensemble PG : ceph pg stat, ceph pg dump pgs_brief
• Cibler un pool : ceph pg ls-by-pool <pool> degraded, ceph pg query <pgid>
• Disposition et capacité OSD : ceph osd tree, ceph osd df
• Statut service et logs : systemctl status ceph-osd@<id>, journalctl -u ceph-osd@<id> -n 200
• Réglages pool et auto-scaling : ceph osd pool ls detail, ceph osd pool get <pool> size, ceph osd pool get <pool> min_size, ceph osd pool autoscale-status

Garde-fous de maintenance :

• Empêcher temporairement le rééquilibrage pendant l'investigation : ceph osd set noout
• Retirez le garde-fou immédiatement après : ceph osd unset noout

À éviter :

• Détruire ou supprimer des OSD pendant le dépannage.
• Changements larges et simultanés de size, min_size ou comptes PG sur plusieurs pools.

Playbooks de récupération

Un seul OSD down

1. Confirmez le périmètre : ceph -s et ceph osd tree. Notez les PG affectés.
2. Vérifiez le service : systemctl status ceph-osd@<id> ; lisez les logs récents avec journalctl -u ceph-osd@<id> -n 200.
3. Corrigez la cause : périphérique de stockage, montage, permissions ou réseau.
4. Vérifiez la récupération : ceph -s jusqu'au retour des PG à active+clean.

Plusieurs OSD ou un hôte down

1. Vérifiez l'alimentation de l'hôte, les liaisons NIC et la synchronisation horaire.
2. Si la panne est temporaire et que vous la corrigez activement, mettez ceph osd set noout pour éviter le churn ; retirez-le dès le retour de l'hôte.
3. Une fois les OSD de retour, surveillez la vitesse de backfill et l'impact client.

Dégradé après maintenance

1. Assurez-vous que ceph osd unset noout est appliqué.
2. Confirmez que tous les OSD prévus sont in et up.
3. Suivez ceph pg stat pour la fin du backfill.

Backfill ou récupération prolongée

1. Vérifiez la marge de capacité avec ceph osd df ; nearfull ralentit les mouvements.
2. Repérez les OSD surchargés dans ceph osd df et les logs de requêtes lentes.
3. Reportez les E/S clientes lourdes si possible pour laisser la récupération finir plus vite.

PG inconsistent après scrub

1. Planifiez la réparation en faible charge : ceph pg repair <pgid>.
2. Vérifiez le retour du PG à active+clean ; revérifiez health detail.

Alignement du nombre de PG

1. Préférez l'auto-scaling quand disponible : ceph osd pool autoscale-status.
2. Si des changements manuels sont nécessaires, ajustez les comptes PG progressivement et en faible charge seulement.

Plan pilote local

Gardez la première implémentation étroite, mesurable et facile à inspecter localement avant tout déploiement large.

Étapes du pilote :

1. Créez un pool de test non critique (ex. test-pool) avec un petit nombre de PG (ex. 32) et la réplication par défaut.
2. Écrivez des données d'exemple ; capturez les bases : ceph -s, ceph pg stat et débit E/S client.
3. En laboratoire ou en fenêtre de maintenance, arrêtez brièvement un seul processus OSD pour observer les transitions PG vers degraded et le retour à la récupération.
4. Augmentez le size du pool de test de +1 et confirmez que le backfill démarre et se termine sans impact inattendu.
5. Restaurez les réglages d'origine et vérifiez le retour du cluster à active+clean.

Critères de succès :

• Les états PG suivent les transitions attendues et récupèrent dans une fenêtre de temps définie.
• Aucun impact sur les pools critiques ni les SLA clients.
• Les opérateurs savent lire, exécuter et expliquer chaque étape en confiance.

Conclusion

La sécurité opérationnelle dans Ceph vient d'une séquence disciplinée : lire l'état de santé d'abord, cartographier l'impact pools et PG, corriger la plus petite chose qui restaure la sécurité, et vérifier la récupération jusqu'à active+clean. Maintenez size et min_size alignés avec la tolérance au risque, privilégiez les diagnostics en lecture seule avant tout changement, et validez tout ajustement dans un pilote étroit avant de l'appliquer plus largement. Cette approche réduit le retravail et renforce la confiance dans le comportement de votre cluster sous contrainte.