La planification de capacité dans Ceph est une discipline opérationnelle qui aligne les méthodes de durabilité, les domaines de panne, les profils de charge de travail, le dimensionnement des groupes de placement et les marges d'utilisation sécuritaires. Il ne s'agit pas simplement de compter les disques. Ce guide montre comment estimer la capacité utilisable, choisir une marge de sécurité, lire les signaux d'évolutivité, vérifier les résultats avec des commandes en direct et récupérer en toute sécurité lorsque les limites sont atteintes. Vous parcourrez des exemples construits avec des calculs clairs que vous pouvez adapter à votre environnement. ## Ce que vous obtiendrez - Un inventaire clair à rassembler avant le dimensionnement. - Des décisions sûres, étape par étape, pour la durabilité, les groupes de placement et la marge de tête. - Deux exemples construits (répliqué et codage d'effacement) avec des calculs exacts. - Des commandes de vérification et les résultats attendus pour confirmer le plan. - Les modes de défaillance courants avec des conseils de restauration et de retour arrière. - Une liste de contrôle simple et reproductible pour les opérations courantes. ## Inventaire de version et d'environnement Avant le dimensionnement, rassemblez les faits sur lesquels vous vous appuierez pendant les calculs et la vérification. Prérequis : - Administration Linux de base. - Accès shell à un nœud moniteur Ceph avec l'interface CLI ceph . - Permissions d'administration du cluster. Liste de contrôle d'inventaire : - Version de Ceph. - Tissu réseau (1/10/25/40/100 GbE). - Nombre de nœuds et domaines de panne (châssis, rack, hôte). - Médias OSD (HDD, SSD, NVMe) et tailles ; placement BlueStore DB/WAL. - Usage cible (RBD, CephFS, RGW) et distribution typique de la taille des objets. - Durabilité de données attendue (réplication 3x, réplication 2x pour le développement, ou codage d'effacement k+m). - Pools et mélange de données attendu par pool. - SLO de service (temps de récupération après perte d'hôte, fenêtres de mise à niveau). Commandes utiles pour capturer l'inventaire : ceph versions ceph status ceph osd tree ceph osd crush tree ceph df detail ceph osd df tree ceph osd pool ls detail ceph osd pool autoscale-status ## Parcours de configuration sécuritaire Utilisez un parcours progressif et délimité qui évite de surengager la capacité et qui limite les risques. ### Étape 1. Choisir la durabilité et le domaine de panne - Pools répliqués : Simples, bons pour les petits objets et les charges de travail à forte écriture. La taille de réplication courante est 3. - Pools à codage d'effacement : Efficacité supérieure pour les gros objets et les données d'archivage. Exemple : 8+2 (k=8 données, m=2 parité). Les écritures nécessitent un niveau de cache répliqué ou un réglage client soigné pour les petits objets. - Domaine de panne : Utilisez l'hôte comme minimum. Pour le codage d'effacement, assurez-vous que les bandes k+m peuvent être réparties sur le domaine de panne de sorte que la perte d'un hôte ne prenne pas plusieurs bandes du même ensemble. ### Étape 2. Convertir le brut en capacité utilisable - Réplication R : fraction_utilisable = 1 / R . Exemple : 3x => 0,333. - Codage d'effacement k+m : fraction_utilisable = k / (k + m) . Exemple : 8+2 => 0,8. - Appliquez la surcharge du système de fichiers et de BlueStore. Prévoyez une réserve de 10 % pour les métadonnées, WAL/DB et l'alignement. ### Étape 3. Réserver une marge opérationnelle - Remplissage cible en régime permanent : 60–75 %. Cela préserve les performances et laisse de la place pour absorber les pannes et la récupération. De nombreux opérateurs choisissent ~70 % comme limite de planification. - Ne dimensionnez pas les clusters de sorte que la perte d'un seul hôte pousse un OSD au-dessus des seuils nearfull. ### Étape 4. Groupes de placement (PG) - Activez l'autoscaler PG pour les nouveaux clusters et pools. ceph osd pool set pg_autoscale_mode on - Pour les pools mixtes, définissez des parts relatives avec target_size_ratio . ceph osd pool set target_size_ratio <0.0-1.0> - Un total sain de PG par OSD se situe généralement dans une fourchette modérée. Pour la planification, visez environ 50–150 PG totaux par OSD sur tous les pools, en laissant l'autoscaler choisir les détails. Évitez les extrêmes qui créent des tempêtes de peering. ### Étape 5. Configurer des seuils full-ratio sécuritaires et l'alerting - Inspectez les ratios actuels : ceph config get mon mon_osd_nearfull_ratio ceph config get mon mon_osd_backfillfull_ratio ceph config get mon mon_osd_full_ratio - Planifiez votre capacité pour que le régime permanent reste bien en dessous de nearfull. Si les valeurs par défaut sont trop serrées pour votre posture de risque, définissez des seuils d'alerte dans votre pile de surveillance plutôt que de modifier prématurément les limites dures du cluster. ### Étape 6. Valider les budgets réseau et de récupération - Choisissez un temps de récupération cible après une perte d'hôte (par exemple, récupérer à l'état clean en 4–8 heures). - Assurez-vous que la bande passante réseau, le débit disque et les limites de backfill peuvent atteindre cet objectif à votre utilisation planifiée. Si les estimations de récupération sont marginales, augmentez la marge ou ajoutez de la capacité avant la charge. ## Exemples pratiques de dimensionnement Ce sont des exemples construits et hypothétiques pour montrer les mathématiques que vous pouvez adapter. ### Exemple A : Petit cluster RBD répliqué 3 hôtes - Hôtes : 3 - OSD par hôte : 6 × 8 To HDD (brut 48 To/hôte) - Brut total : 3 × 6 × 8 To = 144 To - Surcharge de planification (métadonnées, BlueStore) : 10 % => brut effectif 129,6 To - Réplication : 3x => utilisable = 129,6 / 3 = 43,2 To - Marge opérationnelle : cible de remplissage 70 % => budget données au repos = 43,2 × 0,70 = 30,24 To Interprétation : Prévoyez stocker environ 30 To de données pour garder le cluster rapide et sûr, même si un calcul naïf pourrait suggérer 48 To. Et si un hôte tombe ? Vous perdez temporairement 48 To brut. Assurez-vous que la capacité restante à 70 % de remplissage peut accepter le backfill sans franchir les seuils nearfull. Simulez en estimant l'impact du backfill de la plus grande part de pool et vérifiez la marge avant la mise en production. ### Exemple B : Cluster 6 hôtes avec pool archivage codé d'effacement (8+2) et petit pool métadonnées répliqué - Hôtes : 6 - OSD par hôte : 10 × 12 To HDD (brut 120 To/hôte) - Brut total : 6 × 10 × 12 To = 720 To - Surcharge de planification : 10 % => brut effectif 648 To - Pools : - Pool EC (8+2) pour gros objets, 90 % des données attendues - Efficacité 0,8 => utilisable = 648 × 0,9 × 0,8 = 466,56 To - Pool répliqué (taille 3) pour métadonnées, 10 % des données - Efficacité 0,333 => utilisable = 648 × 0,1 × 0,333 = 21,58 To - Utilisable combiné = 488,14 To - Marge opérationnelle : cible de remplissage 70 % => budget données au repos = 488,14 × 0,70 = 341,70 To Interprétation : Avec des pools mixtes, pesez toujours selon la part de données attendue et l'efficacité de durabilité de chaque pool. Si votre part réelle dérive, revoyez target_size_ratio et la planification de capacité. ### Comparaison des schémas de durabilité (repères de planification)
SchémaEfficacité (utilisable/brut)Utilisable To par 100 To brutNotes
Réplication taille 20,550Durabilité inférieure, dev/test seulement
Réplication taille 30,33333,3Opérations simples, défaut courant
EC 4+20,66766,7Bon pour gros objets, ensemble tolérance 6 pannes
EC 8+20,880Efficace pour charges archivage/débit
### Signaux d'évolutivité et limites de planification (repères construits)
MétriqueCible saineAction ou mise à l'échelle
Remplissage cluster (régime permanent)≤ 70 %Ajouter OSD/nœuds avant 75 %
Alertes OSD nearfull0Rééquilibrer ou ajouter capacité
Temps récupération après 1 hôte perdu< 8 heuresAugmenter marge ou débit
PG par OSD (total)50–150Utiliser autoscaler ; éviter extrêmes
Requêtes lentes ou latence op élevéeAucune soutenueVérifier réseau, files OSD, pics clients
Saturation throttling backfillPas continueAjuster limites récupération prudemment
Dépassement BlueFS sur média lentAucun ou minimalAjouter/redimensionner DB/WAL sur média rapide
### Résumé de capacité pour les exemples
ClusterBrut effectif ToEfficacité mixMarge planifiéeBudget données net To
Exemple A (3x repl)129,60,33370 %30,24
Exemple B (EC+repl)6480,72 (pondéré)70 %341,70
## Vérification et diagnostics Après la planification et l'implémentation initiale, vérifiez vos hypothèses avec des données en direct. Ces vérifications sont sûres à exécuter en ligne. ### Vérifier versions, santé et utilisation ceph versions ceph status ceph health detail ceph df detail rados df ### Inspecter capacité OSD, remplissage et distribution ceph osd df tree ceph osd perf ceph osd tree ### Confirmer durabilité des pools et réglages autoscaling ceph osd pool ls detail ceph osd pool autoscale-status # Exemple : assurer que l'autoscaler est actif ceph osd pool set mypool pg_autoscale_mode on # Exemple : définir part de données relative pour l'autoscaler ceph osd pool set bigobjects target_size_ratio 0.8 ceph osd pool set metadata target_size_ratio 0.2 ### Inspecter seuils de remplissage et confirmer l'alerting ceph config get mon mon_osd_nearfull_ratio ceph config get mon mon_osd_backfillfull_ratio ceph config get mon mon_osd_full_ratio ### Résultats attendus quand dans le plan - ceph status affiche HEALTH_OK ou seulement des avertissements transitoires pendant les scrubs. - ceph df montre le total utilisé en dessous de votre cible de régime permanent (par exemple, ≤ 70 %). - Aucun OSD n'est nearfull ; la distribution sur les hôtes est uniforme (surveillez les valeurs aberrantes dans ceph osd df tree ). - Les pools ont le profil size ou k+m prévu, et le statut de l'autoscaler ne suggère pas de changements PG extrêmes. - Aucune requête lente persistante ; les opérations de récupération ne sont pas throttlées pendant les périodes calmes. Si une vérification échoue, priorisez : remplissage et durabilité d'abord, puis latence, puis équilibre PG. ## Modes de défaillance et récupération Modes de défaillance courants, risques et actions de récupération sûres. ### 1. OSD nearfull ou full - Signal : ceph health detail affiche des avertissements nearfull/full. - Risques : Écritures bloquées, redondance dégradée, fenêtres de récupération prolongées. - Actions (dans l'ordre) : - Mettre en pause la croissance : arrêter l'intégration de données. - Ajouter de la capacité : option la plus sûre ; ajouter OSD/nœuds et laisser le backfill restaurer l'équilibre. - Créer des alertes high-water temporaires plus basses que nearfull pour gagner du temps. - En dernier recours, déplacer les pools lourds ou définir target_size_ratio pour pousser l'autoscaler/CRUSH à rééquilibrer. - Éviter : abaisser les ratios full durs pour masquer les symptômes. ### 2. Défaillance d'un seul hôte prolonge la récupération au-delà du budget - Signal : ceph status reste DEGRADED/RECOVERING trop longtemps ; la latence client augmente. - Risques : Exposition à une seconde panne, timeouts client. - Actions : # Augmenter temporairement la bande passante backfill si sûr pour les clients ceph config set osd osd_recovery_max_active 4 ceph config set osd osd_max_backfills 2 - Surveiller l'impact client (latence, IOPS) pendant la récupération. - Long terme : ajouter OSD ou réduire la cible de remplissage en régime permanent (par exemple, de 75 % à 65 %). - Retour arrière : remettre les limites de récupération aux valeurs par défaut après guérison pour éviter la contention chronique. ### 3. Mauvais dimensionnement PG ou pools déséquilibrés - Signal : Le statut de l'autoscaler suggère de fortes augmentations de PG ; certains OSD portent trop de PG. - Risques : Tempêtes de peering pendant les changements, déplacement de données inégal. - Actions : - Activer l'autoscaler sur tous les pools et définir des target_size_ratio réalistes par pool. - Étaler les changements PG pendant les périodes calmes ; surveiller ceph -w . - Retour arrière : si les changements dépassent, réduire target_size_ratio graduellement et laisser l'autoscaler se stabiliser. ### 4. Objets chauds ou placement de données biaisé - Signal : Quelques OSD affichent une utilisation ou une latence beaucoup plus élevée. - Risques : OSD full localisés malgré la marge globale. - Actions : - Rééquilibrer légèrement les poids CRUSH pour uniformiser l'utilisation ; vérifier avec ceph osd df tree . - Pour RGW ou CephFS, revoir le sharding et la structure des répertoires. - Retour arrière : restaurer les poids CRUSH précédents si le déséquilibre s'inverse. ### 5. Dépassement BlueStore DB/WAL sur média lent - Signal : ceph health detail mentionne un dépassement BlueFS ; la latence OSD augmente. - Risques : Pools sensibles à la latence ralentissent sous charge. - Actions : - Ajouter ou redimensionner DB/WAL sur média plus rapide ; migrer les OSD sélectionnés. - Réduire la pression de compactage et de récupération pendant les fenêtres de migration. - Retour arrière : si la performance ne s'améliore pas, remettre les OSD affectés à la disposition antérieure et examiner les profils de charge avant de réessayer. ### Garde-fous pour tout changement risqué - Ne faire qu'une seule étape significative à la fois. - Garder les drapeaux noout et norebalance désactivés par défaut ; si vous devez les utiliser brièvement, documenter l'heure de début et les effacer immédiatement après le travail. - Vérifier la santé après chaque étape ; continuer seulement quand le cluster se stabilise. ## Liste de contrôle des opérations Utilisez cette liste de contrôle reproductible mensuellement ou avant les événements de croissance majeurs. ### Planifier et réviser - Recalculer la capacité utilisable avec le nombre d'OSD actuel, le mélange de pools et la marge choisie (par exemple, 70 %). - Confirmer que la perte d'un seul hôte ne pousse aucun OSD près des seuils nearfull. - Réviser le mélange de données attendu par pool ; ajuster target_size_ratio si les parts dérivent. ### Valider santé et performance - ceph status et ceph health detail sont propres ; enquêter sur les avertissements récurrents. - ceph df detail montre le remplissage en dessous de la cible de planification ; la distribution OSD est uniforme. - ceph osd df tree ne montre pas de valeurs aberrantes dans le remplissage ou la latence. - Vérifier la performance de récupération en simulant des contraintes pendant une fenêtre à faible trafic (par exemple, régler temporairement des throttles de récupération plus bas et observer). ### Vérifier les signaux d'évolutivité - Si le remplissage en régime permanent > 70 % ou la récupération dépasse votre budget temps, planifier l'ajout de nœuds ou d'OSD. - Si les PG par OSD approchent des valeurs extrêmes, laisser l'autoscaler converger ou répartir les charges sur plusieurs pools. ### Documenter et décider - Enregistrer les calculs, hypothèses (durabilité, marge, budget récupération) et métriques observées. - Décider : ajouter de la capacité, réduire temporairement le taux de croissance, ou re-tier certaines données vers un pool plus efficace. ## Conclusion La planification de capacité Ceph est une pratique continue : choisissez un schéma de durabilité qui correspond aux caractéristiques de la charge de travail, convertissez le brut en utilisable avec une surcharge réaliste, réservez une marge opérationnelle et surveillez les signaux d'évolutivité qui indiquent quand ajouter de la capacité. Commencez par un pilote étroit et mesurable pour valider vos calculs, puis grandissez par incréments. Vérifiez avec ceph df , le statut de l'autoscaler et le temps de récupération après une perte d'hôte. En cas de doute, privilégiez la sécurité : ajoutez de la capacité avant d'atteindre nearfull et gardez assez d'espace libre pour guérir rapidement. Avec ces pratiques et les calculs d'exemple de ce guide, vous pouvez faire évoluer Ceph de manière prévisible tout en protégeant la performance et la durabilité.