Ceph pools et placement groups : dépannage expliqué

Intro

Cette version française explique Ceph pools and placement groups troubleshooting explained 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.

La fiabilité de Ceph repose sur la façon dont les Ceph pools et les placement groups (PGs) répartissent les données sur les OSD. Quand des PGs sont dégradés ou undersized, le cluster peut encore servir des IO, mais avec une durabilité réduite. Ce guide explique comment pools et PGs fonctionnent ensemble, comment interpréter les états de PG, comment la Ceph replication (size et min_size) influence la disponibilité et la sécurité, et quelles commandes exécuter en premier pour diagnostiquer et récupérer sans empirer la situation. Il s'adresse aux développeurs, consultants DevOps et équipes startup qui opèrent un Ceph storage cluster directement ou via des plateformes qui l'intègrent, comme Proxmox Ceph.

Ce que vous allez retenir:

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

Workflow de dépannage

Adoptez un chemin répétable pour réduire le risque et accélérer la résolution:

1. Lire la santé et cadrer l'impact

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

1. Cartographier pools, PGs et OSD

• ceph osd pool ls detail pour voir les réglages de chaque pool.
• ceph pg dump pgs_brief pour 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 quand un OSD est down ou flap.

1. Contrôler replication size et min_size

• ceph osd pool get <pool> size et ceph osd pool get <pool> min_size.
• Confirmez l'alignement avec votre domaine de défaillance et votre tolérance au risque.

1. Identifier précisément les états des PG

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

1. Choisir le correctif le moins perturbant

• Préférez restaurer les OSD ou hôtes en panne plutôt que de modifier les réglages des pools.
• Si vous devez changer des paramètres, faites-le à portée étroite et avec marge de capacité.

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

• Suivez ceph -s et ceph health detail jusqu'à active+clean.
• Surveillez la vitesse de backfill/recovery; vérifiez l'absence d'états nearfull.

1. Prévenir les récidives

• Validez l'autoscaling ou les comptes de PG manuels par pool.
• Alignez size et min_size sur les défaillances attendues et vos SLA.

Ceph Pools et PGs : notions clés

• Pools: espaces logiques avec leur propre replication size, min_size et règle CRUSH. Séparez les workloads par pool.
• Placement groups (PGs): unité de placement, de peering et de recovery. Chaque PG est mappé à un ensemble d'OSD selon la règle CRUSH du pool et la réplication.
• Replication size: nombre de réplicas visé par PG. Plus de réplicas augmentent la durabilité mais consomment plus de capacité et génèrent davantage de trafic de recovery.
• min_size: nombre minimal de réplicas requis pour accepter des écritures en sécurité. En dessous, les écritures sont bloquées pour préserver l'intégrité.
• PG count: impacte la distribution des données et le parallélisme de recovery. Trop peu de PGs = hotspots; trop = mémoire gaspillée et peering/recovery ralentis. Utilisez l'autoscaling quand disponible ou planifiez les comptes de PG avec soin.

États de PG courants et actions

• active+clean: État souhaité. Aucune action.
• active+degraded (Ceph PG degraded): Des réplicas manquent mais le PG sert les IO. Action: vérifiez que les OSD concernés sont up et in; laissez le backfill restaurer les réplicas.
• undersized+degraded: Moins d'OSD que requis par size. Action: restaurer les OSD/hôtes. Ne changer size qu'en dernier recours et après analyse d'impact.
• peering: Les OSD échangent leurs cartes pour s'accorder sur l'historique du PG. Action: laissez terminer; si bloqué, inspectez les journaux OSD et le réseau entre pairs.
• backfilling/recovering: Déplacement de données pour rétablir la redondance. Action: surveiller la progression; éviter la maintenance lourde.
• stale/inactive: Les moniteurs ne reçoivent pas de rapports à temps. Action: rétablir la communication ou les OSD hébergeant ces PGs.
• inconsistent: Le scrubbing a trouvé des écarts. Action: planifier ceph pg repair <pgid> en charge faible et surveiller.

Replication size et min_size

Size et min_size pilotent directement durabilité et disponibilité:

• size: nombre de copies en bonne santé. L'augmenter renforce la durabilité mais déclenche du backfill; vérifiez d'abord la capacité et la bande passante.
• min_size: plancher pour accepter des écritures. Abaisser min_size peut rétablir la capacité d'écriture lors de défaillances mais augmente le risque. Préférez remettre des OSD en service et n'ajustez min_size qu'avec des limites claires et un retour arrière prêt.

Ajustements sûrs:

• Lire l'état actuel: ceph osd pool get <pool> size et ceph osd pool get <pool> min_size.
• Planifier la marge: vérifiez ceph osd df pour la capacité et la charge du cluster.
• Changer à portée étroite: ajustez d'abord un pool non critique, mesurez l'impact, puis poursuivez si nécessaire.

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 <pgid> query
• Disposition OSD et capacité: ceph osd tree, ceph osd df
• Statut de service et journaux: systemctl status ceph-osd@<id>, journalctl -u ceph-osd@<id> -n 200
• Réglages de pool et autoscaling: 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 rebalancing pendant une panne connue: ceph osd set noout
• Lever le garde-fou immédiatement après: ceph osd unset noout

À éviter:

• Détruire ou retirer des OSD pendant le dépannage.
• Appliquer de gros changements simultanés de size, min_size ou PG count sur plusieurs pools.

Playbooks de récupération

Single OSD down

1. Confirmer la portée: ceph -s et ceph osd tree. Notez les PG affectés.
2. Vérifier le service: systemctl status ceph-osd@<id>; lire les journaux récents avec journalctl.
3. Corriger la cause: périphérique de stockage, montage, permissions ou réseau.
4. Vérifier la récupération: suivre ceph -s jusqu'à retour en active+clean.

Multiple OSDs ou un hôte down

1. Vérifier l'alimentation, les liens NIC et la synchro temps.
2. Si l'incident est temporaire et en cours de résolution, ceph osd set noout pour éviter le churn; unset dès que l'hôte revient.
3. Une fois les OSD up, surveiller la vitesse de backfill et l'impact client.

Dégradé après maintenance

1. S'assurer que ceph osd unset noout est appliqué.
2. Confirmer que tous les OSD prévus sont up et in.
3. Suivre ceph pg stat jusqu'à complétion du backfill.

Backfill ou recovery de longue durée

1. Vérifier la marge de capacité avec ceph osd df; l'état nearfull ralentit les mouvements.
2. Chercher des OSD surchargés dans ceph osd df et des requêtes lentes dans les logs.
3. Reporter si possible les IO clientes lourdes pour accélérer la fin de recovery.

PG incohérents après scrub

1. Planifier la réparation en période creuse: ceph pg repair <pgid>.
2. Vérifier que le PG repasse active+clean; recontrôler ceph health detail.

Alignement du nombre de PG

1. Préférer l'autoscaling quand disponible: ceph osd pool autoscale-status.
2. Si des changements manuels s'imposent, ajuster progressivement et seulement en charge faible.

Plan pilote local

Garder une première mise en œuvre étroite, mesurable et simple à inspecter en local avant tout déploiement large.

Étapes du pilote

1. Créer un pool de test non critique avec un petit nombre de PG et la replication size par défaut.
2. Écrire des données d'exemple; capturer des baselines: ceph -s, ceph pg stat et le débit IO côté client.
3. En labo ou en fenêtre de maintenance, arrêter brièvement un processus ceph-osd pour observer la transition vers degraded puis le retour lors de la récupération.
4. Augmenter la size du pool de test de +1 et confirmer que le backfill démarre et se termine sans impact inattendu.
5. Restaurer les réglages initiaux et vérifier le retour global en active+clean.

Critères de succès

• Les états de PG suivent les transitions attendues et reviennent à la normale dans une fenêtre définie.
• Aucun impact sur les pools critiques ni sur les SLA clients.
• Les opérateurs savent lire, exécuter et expliquer chaque étape avec assurance.

Conclusion

La sécurité opérationnelle dans Ceph vient d'une séquence disciplinée: lire la santé d'abord, cartographier l'impact des pools et PG, corriger l'élément le plus petit qui restaure la sécurité, puis vérifier le retour en active+clean. Gardez replication size et min_size alignés avec votre tolérance au risque, privilégiez les diagnostics en lecture seule avant tout changement, et validez chaque ajustement via un pilote étroit avant de l'appliquer plus largement. Cette approche réduit les retours en arrière et renforce la confiance dans le comportement de votre cluster sous stress.