Introduction
Ceph récompense la planification rigoureuse. Bien dimensionné, il embarque les charges sans heurts, encaisse les pannes sereinement et évolue de façon prévisible. Mal dimensionné, vous subirez tempêtes de rebalancing, reconstructions interminables et états full inattendus.
Ce guide de Ceph capacity planning propose un parcours pratique pour estimer les Ceph resources, choisir entre réplication et erasure coding, définir des marges de sécurité, et poser des signaux de Ceph scaling pour savoir quand ajouter des nœuds. Vous apprendrez à convertir un objectif de capacité utilisable en capacité brute, à fixer un headroom sûr, à planifier les PG/pools et à valider le tout via un petit pilote local inspectable sur Linux, Proxmox ou tout autre environnement proche. L'objectif: garder vos Ceph limits sous contrôle tout en assurant des expansions prévisibles.
Vue d'ensemble du workflow
Utilisez ce processus répétable pour un nouveau cluster ou une extension:
- Définir la charge de travail
- Services de données: RBD (bloc), CephFS (fichiers), RGW (objet)
- Objectif de capacité utilisable (To) et horizon de croissance (mois)
- Profil IO: mix lecture/écriture, taille d'objet ou de bloc typique, priorité débit vs IOPS
- Choisir la protection des données
- Réplication (ex. 3x) pour simplicité et performances en petits blocs
- Erasure coding (k+m, ex. 8+2) pour meilleure efficacité de capacité sur gros objets/flux
- Domaine de défaillance: hôte ou rack, selon la tolérance souhaitée
- Poser un headroom opérationnel
- Espace libre brut de base: 20-40 %, avec un défaut pratique à 30 %
- Ajouter du headroom si maintenance fréquente ou pics d'écritures
- Convertir l'utilisable en brut
- Réplication: Raw = Usable × R / (1 − headroom)
- EC k+m: Raw = Usable × ((k+m)/k) / (1 − headroom)
- Cartographier vers nœuds et OSD
- Choisir taille et média des disques (HDD, SSD, NVMe)
- Planifier nombre d'OSD par nœud, CPU, RAM et réseau
- Garantir assez d'hôtes pour le domaine de défaillance et le schéma (R ou k+m)
- Planifier PG et pools
- Cible: 50-200 PG/OSD; 100 est un point de départ courant
- Répartir les PG entre les pools et arrondir à une puissance de deux (ex. 1024, 2048)
- Définir signaux d'échelle et seuils
- Ratios warn/nearfull/full et alerting
- SLO de temps de reprise après la perte d'un hôte
- Déclencheurs documentés pour ajouter de la capacité
- Valider via un petit pilote
- Déployer un cluster minimal exerçant votre schéma de protection
- Lancer des charges réalistes et un test de panne
- Mesurer l'impact de la reprise et ajuster les throttles de backfill/recovery
Formules de dimensionnement
Concepts clés
- Capacité brute (Raw): somme des capacités de tous les disques du cluster
- Capacité utilisable (Usable): ce que les applications peuvent stocker, après surcoûts de protection
- Headroom: espace brut réservé pour la croissance, le rebalancing et les pannes
Réplication R
- Usable = Raw / R
- Raw nécessaire = Usable_cible × R / (1 − headroom)
Erasure coding k+m
- Facteur d'overhead = (k+m)/k
- Usable = Raw × k/(k+m)
- Raw nécessaire = Usable_cible × ((k+m)/k) / (1 − headroom)
Exigences de domaine de défaillance
- Réplication R à travers des hôtes: prévoir au moins R hôtes
- EC k+m à travers des hôtes: prévoir au moins k+m hôtes pour placer chaque fragment sur un hôte distinct
Guides de headroom
- Démarrer à 30 % de headroom brut; augmenter pour des clusters HDD à fortes écritures ou des maintenances fréquentes
- Préserver de l'espace libre par OSD; des OSD très pleins rééquilibrent plus lentement et fragmentent davantage
Exemples pratiques
Exemple A: 100 To utilisables, RBD, réplication 3x, 30 % de headroom
- Raw nécessaire = 100 To × 3 / 0,70 = 428,6 To. Arrondir à 430+ To
- Option de layout: 6 nœuds, chacun 12 × 8 To HDD ≈ 96 To bruts par nœud, total 576 To
- Domaine de défaillance: hôte. Avec 3x et 6 hôtes, les réplicas atterrissent sur des hôtes distincts
- Plan PG: 72 OSD (6 × 12). Cible 100 PG/OSD => ~7200 PG totaux. Si vous avez 3 pools, ~2400 PG/pool; arrondir à 2048 ou 2560
- Ressources par nœud: HDD OSDs gagnent à utiliser un SSD pour RocksDB/WAL; planifier 2-4 Go de RAM par OSD plus la base pour les services; CPU: viser ~1 cœur pour 3-5 OSD HDD; réseau: double 25 GbE (ou mieux) pour les trafics public et cluster
Exemple B: 300 To utilisables, gros objets, EC 8+2, 30 % de headroom
- Overhead = (8+2)/8 = 1,25
- Raw nécessaire = 300 To × 1,25 / 0,70 = 535,7 To. Arrondir à 540+ To
- Domaine de défaillance: hôte. Pour placer 10 fragments sur des hôtes distincts, prévoir au moins 10 hôtes
- Option de layout: 10 nœuds, chacun 12 × 6 To HDD ≈ 72 To bruts, total 720 To. Le surplus couvre headroom et croissance
- Plan PG: 120 OSD (10 × 12), 100 PG/OSD => ~12 000 PG totaux. Pour 2 pools, ~6000 PG/pool; arrondir à 6144
- Note performance: EC augmente l'usage CPU (encodage/décodage); prévoir plus de CPU/OSD vs réplication. Conservez un tissu réseau rapide (25/40/100 GbE) et testez l'impact en reprise
Ces cas guident vos premiers pas; adaptez la taille des disques, la densité en OSD et les liens réseau selon vos objectifs, tout en restant dans des Ceph limits raisonnables (densité OSD, PG par OSD, plafond total de PG).
Signaux de montée en charge et limites
Ajoutez de la capacité ou rééquilibrez lorsque vous observez:
- Un headroom brut qui descend sous 30 % dans l'horizon de planification
- Des alertes nearfull ou full sur des OSD/pools
- Une reprise après perte d'hôte qui dépasse votre SLO (ex. impossibilité de restaurer la redondance dans votre fenêtre cible)
- Des PG/OSD qui s'éloignent fortement de la cible (bien au-delà de 100) ou un total de PG qui approche votre plafond de confort
- Une latence OSD qui grimpe en charge normale (I/O client en concurrence avec recovery/backfill incessants)
Limites et vérifications pratiques
- Hôtes: au moins R hôtes pour la réplication et k+m pour l'EC au domaine choisi; davantage d'hôtes fluidifie le rebalancing
- Densité d'OSD: 8-24 OSD par nœud HDD est courant; NVMe exige plus de CPU et de réseau
- CPU: budgéter plus pour EC et pour OSD SSD/NVMe
- Mémoire: base saine pour système/monitors/managers, puis 2-4 Go par OSD comme point de départ
- Réseau: bande passante est-ouest suffisante pour backfill/recovery sans affamer les clients; séparer ou prioriser le trafic cluster si nécessaire
- Compte de PG: éviter les extrêmes par OSD; rééquilibrer à chaque extension pour rester dans la plage
Marges opérationnelles de sécurité
Headroom
- Base à 30 % brut. Pour clusters HDD très écrits ou maintenances fréquentes, visez 35-40 %
Absorption de panne
- Visez la perte d'un hôte sans franchir nearfull. Test: retranchez un hôte de la capacité brute et vérifiez que l'« utilisable » restant demeure sous vos seuils d'alerte pendant la reconstruction
Rebalancing et maintenance
- Throttlez recovery/backfill pour protéger la latence client aux heures ouvrées; autorisez une reprise plus rapide en fenêtre de maintenance
- Gardez des poids OSD équilibrés et surveillez la santé disques; des poids inégaux créent hot spots et nearfull prématurés
Choix de protection
- Réplication pour petites écritures/latence et simplicité; EC pour efficacité sur gros objets/séquentiel. Les clusters mixtes sont courants: affectez les pools avec soin
Portée de placement
- Tolérance rack? Fixez le domaine à rack et assurez assez de racks pour R ou k+m
Mises à niveau et extensions
- Réservez de la capacité pour drainer un hôte lors d'un remplacement matériel ou d'une mise à jour OS sans entrer en nearfull
Plan pilote local
Objectif: valider sizing et comportement de reprise sur un périmètre réduit que vous pouvez inspecter localement (par exemple sur Proxmox ou des hôtes Linux).
Portée
- 3 ou 4 hôtes, chacun avec un nombre modeste de disques
- Protection: réplication 3x pour un premier essai. Si l'EC est prévu en production, ajoutez un second pilote avec un pool EC pour gros objets
- Cible: 5-10 To utilisables pour réaliser remplissage, régime stable et tests de panne en quelques heures
Étapes
- Fixer les cibles: utilisable, headroom (30 %), ratios warn/nearfull/full et SLO de reprise après perte d'un hôte
- Déployer le cluster avec domaine de défaillance « hôte »; créer un pool RBD pour petits blocs et, si nécessaire, un pool EC pour gros objets
- Régler les PG pour viser ~100 PG/OSD sur l'ensemble des pools
- Exécuter une charge d'écriture réaliste jusqu'à 60-70 % de l'utilisable et observer latence client et usage mémoire OSD
- Induire une panne: arrêter un hôte. Observer la recovery (débit, impact client) et ajuster les limites recovery/backfill pour respecter le SLO
- Revérifier les calculs de capacité avec un hôte absent pour confirmer que vous restez sous nearfull pendant la reconstruction
- Documenter les seuils et le déclencheur d'ajout de nœuds (par ex. headroom prévu < 30 % à 90 jours ou risque sur le SLO de reprise)
Critères de succès
- Temps de reprise et impact client conformes au SLO
- Alertes émises aux seuils attendus et actionnables
- Cibles de PG maintenues après ajout/retrait d'un hôte
Astuce exploitation: formalisez un protocole d'OSD troubleshooting pour isoler rapidement disques lents, pics de latence ou liens défaillants avant de conclure à un déficit de capacité.
Conclusion
La Ceph capacity planning devient simple avec un cadre clair: caractérisez les charges et choisissez la protection, convertissez l'utilisable en brut avec un headroom réaliste, mappez la capacité aux hôtes et OSD, fixez des PG adaptés et vérifiez les exigences de domaine de défaillance. Surveillez les bons signaux de Ceph scaling, définissez des déclencheurs nets pour ajouter de la capacité et validez l'ensemble via un pilote local mesurable. Prochaines étapes: bâtir une feuille de calcul avec les formules de ce guide, exécuter le pilote pour calibrer reprise et seuils, et planifier des revues régulières de capacité afin d'ajouter des nœuds avant que le headroom ne devienne critique.