PVE Sizer Ceph RBD/CephFS

Calculateur de capacité pour cluster Ceph, orienté RBD et CephFS. Il répond à une seule question : combien de données peut-on réellement promettre aux machines virtuelles, une fois retirés la réplication, la réserve nécessaire pour reconstruire un domaine de panne perdu, les métadonnées BlueStore et la marge de remplissage.

Page HTML autonome, sans dépendance ni serveur : le calcul tourne entièrement dans le navigateur, rien n'est transmis.

Démarrage

git clone <url-du-depot>
cd <depot>
xdg-open ceph-sizer.html      # ou : open ceph-sizer.html, ou double-clic

Aucune installation, aucune compilation, aucun paquet. Les polices IBM Plex sont chargées depuis Google Fonts ; hors ligne, le calcul fonctionne à l'identique avec les polices système.

Rien n'est enregistré entre deux sessions et rien ne sort du navigateur : l'export JSON est le seul mécanisme de sauvegarde.

Au premier chargement, le sizer présente un serveur générique à compléter. Saisissez vos disques, dupliquez le serveur autant de fois que nécessaire, puis déclarez vos pools.

Contenu du dépôt

Fichier	Rôle
`ceph-sizer.html`	L'outil — page autonome, à ouvrir dans un navigateur
`README.md`	Ce document : notice d'emploi, hypothèses de calcul, sources

Ce que l'outil calcule

Capacité — brute, exploitable, utile, stockable après compression, provisionnable en provisionnement fin, et une référence directement comparable au MAX AVAIL de ceph df.
Domaines de panne CRUSH — de osd à root, avec déclaration d'un bucket par niveau et par serveur, réserve d'auto-guérison calculée sur le plus gros domaine.
Pools — réplication et erasure coding, usage RBD ou CephFS, pools de métadonnées compagnons comptés, pg_num suggéré, contrôle du nombre de domaines requis.
Empreinte matérielle par hôte — cœurs en charge et cœurs à réserver, mémoire, bande passante sur les réseaux public et cluster, débit de reconstruction.
Contrôles — une vingtaine de vérifications de cohérence, des erreurs bloquantes aux avertissements d'exploitation.
Commandes — script pveceph / ceph de création des pools, adapté à chaque cas.
Export — configuration JSON réimportable, rapport Markdown, tableaux CSV, script shell.

Ce que l'outil ne calcule pas

IOPS, latence, pools système, DB/WAL déportés, instantanés et corbeille RBD, hiérarchies CRUSH imbriquées. Le détail est en §13.

Avertissement

Les hypothèses de compression, de provisionnement fin et de charge sont des paramètres de planification, pas des capacités garanties par un cluster. Ceph n'en tient aucun compte dans MAX AVAIL. Un ratio de compression non mesuré sur le pool réel n'est pas opposable. Toutes les valeurs par défaut sont adossées à la documentation Ceph ou à des constats de production, et leur origine est tracée en §10.

Sommaire

Les cinq chiffres à comprendre avant de saisir quoi que ce soit
Paramètres
Serveurs
Pools
Optimisations
Charge et matériel
Lecture des résultats
Recouper le calcul avec un cluster en production
Chaîne de calcul complète
Valeurs par défaut et leur origine
Générer les commandes Proxmox VE
Exporter, importer, archiver
Ce que le sizer ne fait pas

Contribuer

Le fichier est volontairement monolithique : un seul HTML, CSS et JavaScript compris, sans dépendance ni étape de construction. Toute modification se fait dans ce fichier et se teste en le rechargeant.

Les valeurs par défaut sont regroupées en tête de script (constantes MEDIA, ROLES, DOMAINS, objet P). Une modification de l'une d'elles doit s'accompagner de la mise à jour de la ligne correspondante en §10, avec sa source.

Licence

À définir par le dépôt hôte.

1. Les cinq chiffres à comprendre avant de saisir quoi que ce soit

Le bandeau de résultats affiche cinq valeurs. Elles ne sont pas interchangeables et confondre les deux dernières est la source d'erreur la plus fréquente.

Chiffre	Ce qu'il vaut	À quoi il sert
Capacité brute	Somme des disques, convertie en Tio	Commande matérielle, devis
Brut exploitable	Brut moins réserve, métadonnées et marge de remplissage	Base de tous les calculs de pools
Données stockables	Ce que les invités peuvent écrire, compression comprise	Le chiffre à engager auprès des équipes applicatives
Provisionnable aux VM	Volume de disques virtuels créables, en provisionnement fin	Dimensionnement d'une campagne de migration
Réf. `ceph df MAX AVAIL`	Plafond physique avant blocage des écritures	Recoupement seulement — voir §8

MAX AVAIL est ce que Ceph accepte d'écrire avant de bloquer, hôte mort compris. Ce n'est pas une capacité utilisable : s'appuyer dessus revient à dimensionner un cluster qui ne pourra pas se reconstruire.

2. Paramètres

2.0 Domaine de panne CRUSH

Valeur par défaut : host.

Niveau de l'arbre CRUSH auquel Ceph garantit qu'il n'y aura jamais deux copies d'un même objet. Le sélecteur couvre toute la hiérarchie standard :

Domaine	Ce qu'il protège
`osd`	Rien au-delà du disque — plusieurs copies peuvent atterrir sur le même serveur. Cluster de test à un nœud uniquement ; le sizer le signale en erreur
`host`	Une copie par serveur. Défaut Ceph et cas de très loin le plus courant
`chassis`	Lames partageant un même châssis
`rack`	Une copie par baie — protège d'une panne d'alimentation de baie ou de commutateur ToR
`pdu`	Serveurs partageant une même arrivée électrique
`row`, `pod`, `room`	Rangée, cellule, salle machine
`datacenter`, `zone`, `region`	Site, zone de disponibilité, région
`root`	Niveau le plus large de l'arbre

Dès que le domaine n'est plus host ni osd, chaque carte serveur affiche un champ de saisie nommé d'après le niveau choisi — « Baie — bucket CRUSH rack », « Salle — bucket CRUSH room », et ainsi de suite, avec un exemple de valeur en filigrane. Les serveurs partageant la même valeur forment un seul domaine.

Chaque niveau garde sa propre saisie. Passer de rack à room n'efface pas les noms de baies et ne les recycle pas comme noms de salles : chaque serveur mémorise un bucket par niveau CRUSH. Vous pouvez donc comparer deux hypothèses de domaine sans re-saisir quoi que ce soit.

Un bouton « Attribuer un bucket distinct à chaque serveur » apparaît tant que des serveurs sont sans emplacement. Il pré-remplit rack-01, rack-02… à raison d'un par serveur — le cas le plus favorable, à corriger ensuite pour refléter l'implantation réelle. C'est un point de départ, pas une déclaration.

Tant qu'aucun bucket n'est déclaré, les contrôles sont suspendus. Changer de domaine de panne ne déclenche pas une cascade d'erreurs sur un cluster qu'on n'a pas encore décrit : un unique avertissement signale que les serveurs sont provisoirement comptés comme un seul domaine et que les vérifications de capacité et de tolérance attendent la saisie. Les erreurs n'apparaissent qu'une fois au moins un emplacement renseigné — et là, elles sont réelles.

Les serveurs laissés vides alors que d'autres sont renseignés tombent dans un bucket « non déclaré » et comptent pour un seul domaine ; un contrôle les dénombre.

Tout le calcul bascule alors sur les domaines plutôt que sur les hôtes :

la réserve d'auto-guérison vaut la capacité du plus gros domaine, non du plus gros serveur — perdre une baie de quatre serveurs coûte quatre serveurs de réserve ;
le nombre minimum exigé par chaque pool (size ou k+m) se compte en domaines ;
la reconstruction répartit le volume perdu sur les hôtes survivants, en excluant ceux du domaine tombé ;
les contrôles de tolérance raisonnent en domaines.

L'effet est brutal et c'est normal. Quatre serveurs répartis en deux baies ne font que deux domaines : un pool répliqué ×3 devient impossible, et la réserve passe de 25 % à 50 % du cluster. Un domaine de panne large ne se décrète pas, il s'achète en matériel.

2.1 Hôtes réservés pour l'auto-guérison

Valeur par défaut : 1. Fourchette utile : 1, exceptionnellement 2. La valeur est bornée au nombre de domaines moins un : sur un cluster d'un seul nœud, la réserve tombe donc à zéro. Au-delà de la moitié du brut immobilisé, un contrôle signale qu'ajouter un domaine coûte moins cher que d'en réserver un de plus.

Capacité gelée pour que Ceph puisse recréer ailleurs les copies portées par un hôte tombé. Le calcul retient la capacité du plus gros hôte multipliée par le nombre réservé, et non un pourcentage forfaitaire : c'est le volume qu'il faudra réellement absorber le jour où ce nœud disparaît.

Valeur	Conséquence
`0`	Aucune reconstruction possible après la perte d'un hôte. Le cluster reste dégradé jusqu'au retour physique du serveur. Un contrôle le signale
`1`	Posture nominale : la plateforme survit à la perte d'un nœud et se répare seule
`2`	Deux pannes simultanées absorbées. Coûteux — sur un cluster de 4 nœuds, cela gèle la moitié de la capacité

Le curseur est plafonné à nombre d'hôtes − 1.

Sur un cluster à 4 nœuds, réserver 1 hôte gèle 25 % du brut. C'est le prix d'un parc court, pas un défaut du calcul : moins il y a de nœuds, plus la perte d'un seul pèse.

2.2 Taux de remplissage cible

Valeur par défaut : 80 %. Plafond raisonnable : 85 %.

Taux de remplissage visé du cluster en régime nominal. Ceph passe en HEALTH_WARN à 85 % (mon_osd_nearfull_ratio) et bloque les écritures à 95 % (mon_osd_full_ratio).

La documentation Ceph propose elle-même, dans sa référence de configuration des moniteurs, un jeu de seuils de production plus prudent que les défauts — full 0.80, backfillfull 0.75, nearfull 0.70 — et la pratique communautaire converge sur « ne jamais dépasser 70 à 80 % d'occupation ». Le sizer retenant par ailleurs une réserve d'hôte explicite (§2.1), 80 % constitue un compromis défendable ; descendre à 70 % revient à financer deux fois la même protection.

Dimensionner à 90 % revient à prévoir un cluster qui vivra en alerte permanente. Au-delà de 85 %, un contrôle le signale.

⛔ Relever nearfull_ratio ou full_ratio sur le cluster n'est pas un levier de capacité. Ces seuils protègent la capacité de reconstruction. Les relever, c'est retirer le filet.

2.3 Métadonnées BlueStore / RocksDB

Valeur par défaut : 2 %.

Part de la capacité brute consommée par les structures internes de BlueStore : base RocksDB, allocateur, checksums.

La documentation Ceph dimensionne le volume block.db entre 1 et 4 % du périphérique de données, en précisant 1 à 2 % pour une charge RBD et au moins 4 % pour RGW, qui sollicite lourdement les métadonnées. C'est le même volume qui est consommé sur l'OSD lorsque la DB n'est pas déportée : 2 % est donc la valeur haute du cas RBD.

Profil de charge	Valeur
Disques d'invités RBD, objets de 4 Mio	2 %
RGW, CephFS avec de nombreux fichiers, beaucoup de petits objets	4 à 5 %
DB/WAL déportés sur NVMe dédiés	0 à 1 % côté OSD, mais les NVMe de DB ne se saisissent pas comme disques OSD (§3.2)

2.4 Bascule To / Tio

Bouton en haut à droite du bloc Paramètres. Il ne modifie que l'affichage des résultats.

To — téraoctets décimaux (10¹²), l'unité des constructeurs et des devis.
Tio — tébioctets binaires (2⁴⁰), l'unité de ceph df et ceph osd df.

Conversion appliquée : 1 To = 0,909495 Tio.

La saisie des disques reste toujours en To constructeur, quelle que soit la position du bouton. Saisir 3,50 parce que ceph osd df affiche 3.5 TiB fausse le calcul de 10 %. Voir §3.2.

3. Serveurs

3.1 Structure

Un bloc par serveur. Chaque bloc contient un nom, puis autant de lignes « nombre de disques × taille unitaire » que nécessaire. C'est ce qui permet de décrire un nœud dont les disques ne sont pas tous identiques.

Bouton	Effet
`+ taille de disque`	Ajoute une ligne de disques au serveur — un second modèle, une seconde capacité
`⧉`	Duplique le serveur en incrémentant le numéro final du nom (`osd-node-01` → `osd-node-02`)
`✕` (en-tête)	Supprime le serveur
`✕` (ligne de disques)	Retire cette ligne de disques
`+ Ajouter un serveur`	Ajoute un nœud en reprenant la configuration disque du dernier saisi

Le pied de chaque bloc rappelle le nombre d'OSD et la capacité du nœud, dans l'unité affichée.

État initial. Le sizer s'ouvre sur un seul serveur générique — osd-node-01, 8 disques NVMe de 3,84 To, rôles MON et MGR, 32 cœurs, 256 Gio, un lien Ceph de 25 Gb/s. C'est un gabarit à corriger, pas une recommandation. Ajustez-le, puis dupliquez-le autant de fois que nécessaire.

Tant que le cluster compte moins de trois serveurs, les contrôles de tolérance sont suspendus et remplacés par un unique avertissement « Cluster incomplet ». Un cluster en cours de description n'est pas un cluster mal conçu.

3.2 Ce qu'il faut saisir, et ce qu'il ne faut pas

Saisir la taille commerciale en To décimaux. C'est ce qui figure sur la référence constructeur et sur le bon de commande.

Sur le disque	À saisir	Ce qu'affichera `ceph osd df`
800 Go	`0.8`	`745 GiB`
1,92 To	`1.92`	`1.7 TiB`
3,84 To	`3.84`	`3.5 TiB`
7,68 To	`7.68`	`7.0 TiB`
15,36 To	`15.36`	`14 TiB`

Recopier la colonne SIZE de ceph osd df tree, ou le poids CRUSH (WEIGHT, également en Tio), sous-estime le cluster de 9,05 %.

Ne pas saisir :

les disques système (BOSS M.2, RAID-1 d'amorçage) — ils ne portent aucune donnée Ceph ;
les NVMe dédiés aux DB/WAL — ils ne stockent pas de données, seulement des métadonnées. Compter plutôt 1 à 4 % de la taille de l'OSD par DB, à provisionner hors sizer.

3.3 Correspondance avec un cluster existant

ceph osd df tree | grep '^-' # capacité par hôte
ceph osd df tree             # colonne SIZE par OSD

Le total brut saisi doit retomber, en Tio, sur la ligne TOTAL de ceph df. Un écart de plus de 1 % signale une erreur de saisie — le plus souvent des Tio saisis à la place des To.

4. Pools

4.1 Nom et type

Le nom est purement documentaire ; il apparaît dans le tableau de résultats et dans les alertes.

Type	Champs	Facteur de surcoût
Réplication	`size` (nombre de copies)	`size` — chaque objet est écrit `size` fois
Erasure coding	`k` (fragments de données), `m` (fragments de parité)	`(k+m)/k`, augmenté de la réserve de métadonnées (§5.4)

À cela s'ajoute l'usage du pool — RBD ou CephFS (§4.4) — qui détermine s'il faut lui adjoindre un pool de métadonnées.

Repères de dimensionnement :

Schéma	Surcoût brut	Efficacité	Hôtes minimum	Hôtes pour l'auto-guérison
Réplication ×3	3,00×	33 %	3	4
Réplication ×2	2,00×	50 %	2	3 — proscrit (§4.4)
EC 2+2	2,00×	50 %	4	5
EC 3+2	1,67×	60 %	5	6
EC 4+2	1,50×	67 %	6	7
EC 6+2	1,33×	75 %	8	9
EC 8+3	1,38×	73 %	11	12

La colonne « hôtes pour l'auto-guérison » vaut k+m+1 (ou size+1) : il faut un domaine de plus que de fragments pour que Ceph puisse reconstruire ailleurs après une panne. Un pool qui sature exactement le cluster déclenche une erreur bloquante.

Ces colonnes se comptent dans l'unité du domaine de panne retenu (§2.0). Sous un domaine rack, « 3 hôtes minimum » devient « 3 baies minimum » — et l'interface change le libellé en conséquence.

4.2 Part de l'espace libre

Un seul pool : laisser 100 %. Plusieurs pools : la somme doit valoir 100 %.

Dans Ceph, un pool ne réserve rien. Tous les pools puisent dans le même espace libre au fil des écritures — c'est pourquoi ceph df affiche le même MAX AVAIL pour tous les pools d'une même règle CRUSH.

Ce champ n'est donc pas un quota, mais une hypothèse de remplissage : quelle fraction du brut ira dans quel pool. Elle est indispensable dès que deux pools ont des surcoûts différents — sans elle, aucune capacité utile globale n'est calculable.

Pour transformer cette hypothèse en contrainte réelle sur le cluster : ceph osd pool set-quota <pool> max_bytes <valeur>. Le sizer ne fait que planifier.

4.3 Compression lz4 · aggressive

Case à cocher par pool, la compression se réglant au pool dans Ceph. Elle applique le ratio défini en §5.1. Décocher pour un pool contenant des données déjà compressées ou chiffrées côté invité, sur lesquelles BlueStore ne gagnera rien.

4.4 Usage : RBD ou CephFS

Chaque pool porte un sélecteur RBD / CephFS, à droite de la case de compression. Il ne change ni le schéma de protection ni la part allouée : il déclare ce que le pool sert, et cela a une conséquence de capacité.

Un pool de données CephFS ne fonctionne pas seul. Il lui faut un pool de métadonnées répliqué, qui stocke l'arborescence et les inodes. Le sizer l'ajoute automatiquement en ligne fille du tableau, <nom>-metadata, et l'intègre au facteur de surcoût du pool :

facteur effectif = facteur de protection + %métadonnées_CephFS × 3
réplication ×3, métadonnées à 2 % → 3,00 + 0,06 = 3,06×

La réserve par défaut est de 2 %, contre 1 % pour un pool EC en RBD : les métadonnées CephFS sont sensiblement plus volumineuses — un inode par fichier, contre quelques en-têtes d'images pour du RBD. Montez cette valeur sur un système de fichiers à très nombreux petits fichiers. La documentation Ceph recommande par ailleurs de placer ce pool sur les périphériques les plus rapides du cluster.

Un pool CephFS sur erasure coding n'a besoin que d'un seul pool de métadonnées : le sizer retient alors la plus large des deux réserves plutôt que de les additionner.

Les prérequis d'exploitation — création du pool compagnon, allow_ec_overwrites, placement des métadonnées sur les périphériques rapides — ne sont pas des contrôles à corriger mais des commandes à exécuter. Ils figurent donc en commentaire dans le script généré (§11), au bon endroit et avec la commande exacte, plutôt que dans la section Contrôles.

Trois contrôles encadrent la saisie :

Situation	Niveau
Pool CephFS déclaré sans aucun rôle `MDS`	Erreur — un système de fichiers Ceph ne se monte pas sans démon de métadonnées
Un seul `MDS`	Avertissement — sa perte rend le système de fichiers indisponible ; deux est le minimum en production
Rôle `MDS` coché sans aucun pool CephFS	Avertissement — l'empreinte du démon est comptée, pas la capacité

4.5 Contrôles appliqués aux pools

Situation	Niveau	Motif
Somme des parts ≠ 100 %	Erreur	La capacité utile totale est fausse
Hôtes < `k+m` (ou < `size`)	Erreur	Le pool ne peut pas être créé avec un domaine de panne `host`
Hôtes = `k+m` exactement, en EC	Erreur	Aucune reconstruction possible après perte d'un hôte
`size` < 3	Erreur	Plus aucune tolérance pendant une reconstruction ; abaisser `size` déclenche en outre une réécriture massive
EC sur un cluster ≤ 5 nœuds	Avertissement	Pénalité read-modify-write sur les écritures aléatoires de 4 Kio — le profil exact d'une charge d'invités. À réserver aux données froides

5. Optimisations

Ce bloc modélise les leviers arbitrés dans SMSI-NOT-PVE-002. Ce sont des hypothèses de planification, pas des capacités garanties : Ceph n'en tient aucun compte dans MAX AVAIL.

5.1 Ratio de compression BlueStore

Valeur par défaut : 1,62×. Plafond du curseur : 2,5×. Ne dépassez pas ce que vous avez mesuré.

Multiplie la capacité utile des pools cochés « compression ». 1,62× correspond à une mesure réelle sur des disques d'invités mixtes Windows / Linux, en lz4 avec compression_mode aggressive.

Il existe un plafond structurel proche de 2×. BlueStore n'alloue jamais moins d'une unité d'allocation : avec min_alloc_size à 4 Kio, une écriture de 4 à 8 Kio compressée ne descendra jamais sous 4 Kio, quel que soit l'algorithme. Sur un pool RBD servant des écritures aléatoires de petite taille, annoncer un ratio supérieur à 2× relève de l'erreur de mesure, pas de la performance de l'algorithme. Le sizer alerte au-delà de 2×.

Le choix de lz4 plutôt que zstd est un arbitrage CPU : lz4 est le plus rapide pour un ratio modéré, zstd gagne quelques points de ratio contre une charge processeur sensiblement plus élevée. Les mesures publiées par Red Hat sur BlueStore en mode aggressive font état d'une perte d'IOPS à un chiffre et d'une légère hausse de latence moyenne — acceptable, mais non nulle, sur des OSD déjà chargés.

Réglages associés côté cluster :

ceph osd pool set <pool> compression_algorithm lz4
ceph osd pool set <pool> compression_mode aggressive
ceph osd pool set <pool> compression_required_ratio 0.85

compression_mode passive est inopérant sur RBD : il attend un indice du client, et rbd_compression_hint vaut none par défaut. Seul aggressive compresse effectivement.

Comment mesurer le ratio sur un pool existant, seule valeur opposable en planification :

ratio = (STORED × size) ÷ USED        # colonnes de `ceph df detail`

Le ratio par image n'est pas opposable : il est contaminé par tout objet étranger déposé dans le pool. Avant toute mesure, purger les objets de test :

rados -p <pool> ls | head            # repérer un préfixe benchmark_data_*
rados -p <pool> cleanup --run-name <run>   # --prefix laisse l'objet de métadonnées

Ces objets sont invisibles à rbd ls, rbd du et à tous les inventaires RBD : un pool peut porter des centaines de Gio de bench sans qu'aucun outil d'inventaire ne les montre, et le ratio affiché devient fantaisiste.

Au-delà de 2,2×, un contrôle exige une mesure sur le pool réel avant d'engager la capacité.

5.2 Occupation réelle des disques d'invités

Valeur par défaut : 100 %, c'est-à-dire aucune hypothèse de provisionnement fin.

Part d'un disque virtuel réellement écrite. À 60 %, un disque de 100 Gio n'en consomme que 60 dans le pool, et la carte « Provisionnable aux VM » apparaît.

Le défaut est volontairement neutre : ce taux ne se devine pas, il se mesure sur le parc existant. Rapporter la somme des tailles provisionnées (rbd du ou l'inventaire de la plateforme source) à la consommation réelle du pool donne le seul chiffre opposable. Une valeur reprise d'un autre contexte est une capacité inventée.

Ce chiffre n'est vrai que si l'espace libéré revient effectivement au pool :

Prérequis	Commande
`discard` sur chaque disque d'invité	`qm set <vmid> --scsi0 <storage>:<disk>,discard=on,ssd=1`
TRIM périodique dans l'invité Linux	`systemctl enable --now fstrim.timer` (hebdomadaire)
Invités Windows	TRIM automatique si le disque est présenté en `scsi` avec `ssd=1`

⛔ Ne pas activer le TRIM continu (discard en option de montage). La passe hebdomadaire de fstrim.timer couvre le besoin sans pénaliser les écritures.

Sans ces réglages, l'écart entre volume provisionné et volume réellement consommé ne se résorbe jamais, et le chiffre affiché devient une fiction. Un contrôle le rappelle dès que le curseur descend sous 100 %.

Points de fuite à surveiller, non modélisés ici : corbeille RBD (rbd trash ls), instantanés orphelins (rbd snap ls), clones liés (rbd children).

5.3 Balancer upmap

Valeur par défaut : actif, soit un abattement de 5 %.

Un cluster est aussi plein que son OSD le plus rempli : MAX AVAIL est dicté par cet OSD, jamais par la moyenne. La dispersion de placement CRUSH est donc une perte de capacité sèche.

Les ordres de grandeur retenus proviennent de constats de production convergents : à la cible documentée de 100 PG par OSD, les écarts à la moyenne dépassent couramment 20 % sans table upmap, et le phénomène s'aggrave sur les petits clusters et les parcs hétérogènes. Le balancer upmap réduit fortement cette dispersion sans l'annuler — une variance résiduelle supérieure à 5 % reste couramment observée, balancer actif.

Position	Abattement appliqué
Actif	−5 % — variance résiduelle du balancer `upmap`
Inactif	−20 % — dispersion CRUSH à 100 PG par OSD

Cet abattement porte sur la capacité de planification, pas sur la colonne « Réf. ceph df MAX AVAIL » : Ceph calcule déjà celle-ci sur la variance réelle du moment. Les deux colonnes restent donc directement comparables (§8).

Vérification et remise en service :

ceph balancer status          # attendu : active: true, mode: upmap
ceph osd df | sort -k17 -n    # colonne VAR — alerter au-delà de 1,10
ceph balancer on              # hors reconstruction en cours

⛔ Ne jamais corriger un déséquilibre à la main avec ceph osd reweight quand le balancer est actif : les deux mécanismes se combattent et la correction manuelle est perdue à la reconstruction suivante.

5.4 Pool de métadonnées EC

Valeur par défaut : 1 %, majoration prudente. Sans objet pour les pools répliqués.

Un pool erasure-coded utilisé en RBD ne peut pas fonctionner seul : les en-têtes d'images, rbd_directory et les object-map doivent résider dans un pool répliqué compagnon. Ce curseur définit la part de la capacité utile du pool EC à lui réserver.

Ce pool compagnon est toujours en réplication ×3 : chaque point de pourcentage coûte trois points de capacité brute. Le facteur de surcoût affiché sur la carte du pool intègre les deux :

facteur effectif = (k+m)/k + %métadonnées × 3
EC 4+2 à 1 %     = 1,50 + 0,03 = 1,53×

Le tableau de résultats fait apparaître le pool compagnon en ligne fille, avec sa capacité propre. Ramener le curseur à 0 % déclenche une erreur bloquante : la capacité affichée serait surévaluée.

La documentation Ceph impose ce pool compagnon sans en publier de règle de dimensionnement : son contenu réel — en-têtes d'images, rbd_directory, object-map — se compte en dizaines de Mio pour quelques centaines d'images. Le défaut de 1 % est donc une majoration délibérée, pas une mesure ; il absorbe la croissance du nombre d'images sans avoir à revenir sur le dimensionnement. Sur un parc d'images stable et inventorié, 0,25 % suffit.

Création côté cluster :

pveceph pool create <nom> --erasure-coding k=<k>,m=<m>
ceph osd pool set <nom>-data allow_ec_overwrites true

6. Charge et matériel

Ce bloc estime l'empreinte de Ceph sur chaque hôte : processeur, mémoire, et bande passante sur les deux réseaux. Il répond à une question distincte de la capacité — un cluster correctement dimensionné en volume peut être incapable de tenir la charge ou de se reconstruire dans un délai acceptable.

Le calcul part du média déclaré pour chaque groupe de disques (colonne « Média » dans la carte serveur). Trois constantes en découlent :

Média	Débit soutenu retenu	Cœurs par OSD
NVMe	3 000 Mo/s	4
SSD SATA / SAS	500 Mo/s	2
HDD	200 Mo/s	1

6.0 Deux chiffres de CPU, à ne pas confondre

La documentation Ceph donne deux règles de nature différente, et le tableau les affiche séparément.

Colonne	Nature	Règle
Cœurs en charge	Consommation attendue au régime demandé	Un cœur par tranche de 200 à 500 Mo/s réellement traités par les OSD
Cœurs à réserver	Provisionnement matériel pour la pointe	1 cœur par OSD minimum, 2 recommandés, davantage en NVMe

La seconde règle est une réserve, pas une consommation : elle borne l'achat, pas l'occupation permanente. Un nœud de 12 OSD SSD servant 1,8 Go/s consomme de l'ordre de 7 cœurs, tout en devant en réserver 26 pour absorber une reconstruction pendant que la production continue. Les deux chiffres sont justes et ne répondent pas à la même question.

Le verdict ok / ! du tableau porte sur le provisionnement. Un contrôle distinct se déclenche, en erreur cette fois, si les cœurs déclarés ne couvrent même pas la charge nominale.

6.0 bis Débit traité par cœur

Valeur par défaut : 350 Mo/s, milieu de la fourchette documentée de 200 à 500.

Descendez vers 200 Mo/s pour une charge de petits blocs, où le coût par octet est bien plus élevé — la même documentation chiffre d'ailleurs cette dimension autrement, à un cœur par tranche de 1 000 à 3 000 IOPS. Montez vers 500 Mo/s pour du séquentiel de grande taille.

Les cœurs par OSD du tableau de médias traduisent la règle de provisionnement par classe ; les retours de production sur clusters NVMe convergent sur quatre cœurs par OSD.

6.1 `osd_memory_target`

Valeur par défaut : 4 Gio.

Cible mémoire d'un OSD. C'est à la fois le défaut Ceph et le minimum documenté : en dessous de 4 Gio par OSD, la documentation annonce des performances dégradées, des plantages ou une intervention de l'OOM killer pendant les reconstructions. Six à huit Gio sont recommandés pour du NVMe rapide ou de gros jeux de données.

La documentation demande également de prévoir 20 % de mémoire système en plus de la somme des cibles, la gestion mémoire des OSD étant faite au mieux et pouvant dépasser ponctuellement. Cette marge est appliquée automatiquement.

Cœurs en charge   = débit_traité ÷ débit_par_cœur + cœurs des rôles portés
Cœurs à réserver  = Σ (nb_disques × cœurs_du_média) + cœurs des rôles portés
RAM Ceph par hôte = nb_OSD × osd_memory_target × 1,20 + RAM des rôles portés

Contrairement au CPU, la mémoire est réellement réservée par les OSD : osd_memory_target est une cible que les daemons occupent effectivement, pas une provision.

6.1 bis Rôles portés par chaque hôte

Chaque carte serveur porte une ligne de rôles. Le rôle OSD est implicite dès qu'un disque est déclaré ; les autres se cochent hôte par hôte et s'ajoutent à l'empreinte CPU et mémoire de cet hôte seulement.

Rôle	Cœurs	RAM	Rôle dans le cluster
`MON`	2	4 Gio (6-8 au-delà de 300 OSD)	Quorum, cartes du cluster
`MGR`	1	4 Gio	Métriques, autoscaler PG, balancer, tableau de bord
`MDS`	2	8 Gio	Métadonnées CephFS

Les commandes de déploiement correspondantes sont générées dans le script Proxmox VE (§11.1).

MON et MGR sont structurants : tout cluster Ceph en porte, quel que soit le type de stockage servi. MDS est là pour un cas précis et fréquent sur Proxmox — un petit CephFS pour les images ISO, les modèles de VM et les sauvegardes, colocalisé avec les OSD. Si vous le cochez, basculez aussi un pool en usage CephFS (§4.5) : le rôle ne dimensionne que le démon, le pool dimensionne la capacité. Les deux contrôles se répondent — un MDS sans pool CephFS déclenche un avertissement, un pool CephFS sans MDS une erreur.

Il n'y a pas de rôle RGW. La passerelle objet amène ses propres pools d'index et de bucket, un profil d'accès et un dimensionnement de métadonnées qui n'ont rien à voir avec du RBD — compter ses cœurs sans compter ses pools donnerait une fausse impression d'exhaustivité. Un cluster servant du RGW mérite son propre calcul.

Ces valeurs traduisent l'empreinte du démon seul en configuration hyperconvergée. La documentation Ceph, elle, raisonne au niveau de l'hôte pour des moniteurs dédiés : 32 Go suffisent pour un petit cluster, 64 Go jusqu'à 300 OSD, 128 Go au-delà. Le sizer bascule automatiquement les rôles sur leur valeur haute au-delà de 300 OSD.

Deux contrôles accompagnent cette saisie :

moins de trois moniteurs, ou un nombre pair — un quorum ne survit à la perte d'un hôte qu'à partir de trois moniteurs, et un nombre pair n'apporte rien de plus que l'impair inférieur ;
un seul manager — un second mgr en veille évite de perdre métriques, autoscaler et balancer à la panne d'un hôte.

La configuration chargée par défaut place trois MON et deux MGR sur les quatre nœuds.

6.2 Sollicitation simultanée des disques

Valeur par défaut : 30 %.

Part du débit cumulé des disques du nœud réellement consommée en pointe. À 100 %, le calcul correspond au plafond théorique — tous les OSD saturés en même temps, ce qui ne se produit jamais sous une charge de machines virtuelles mais reste le bon réglage pour dimensionner un cluster de sauvegarde ou un séquentiel massif.

C'est le curseur qui pilote toutes les valeurs réseau. Le débit disque cumulé du nœud est affiché dans le tableau pour rappel.

6.3 Part d'écritures dans la charge

Valeur par défaut : 30 %.

Un profil 70 % lecture / 30 % écriture est un point de départ courant pour de nombreux clusters. La distinction est structurante : seules les écritures génèrent du trafic sur le réseau cluster. Une lecture est servie par l'OSD primaire et ne traverse que le réseau public.

6.4 Délai de reconstruction

Valeur par défaut : 8 heures.

Délai visé pour recréer sur les hôtes restants les données portées par l'hôte perdu. Il fixe directement la bande passante à réserver :

volume à reconstruire = capacité du plus gros hôte × taux de remplissage
reconstruction (Gb/s) = volume_To × 8 000 ÷ (hôtes restants) ÷ (délai en secondes)

L'ordre de grandeur est documenté de longue date côté Red Hat : répliquer 1 To sur un lien à 1 Gb/s demande environ trois heures, contre une vingtaine de minutes à 10 Gb/s. Raccourcir le délai est toujours possible, mais se paie en bande passante disputée à la charge client.

6.5 Les deux réseaux

Ceph sépare un réseau public, qui porte le trafic client et les échanges avec les moniteurs, et un réseau cluster, qui porte les battements de cœur des OSD, la réplication, le backfill et la reconstruction. La documentation Ceph présente le second comme facultatif mais nettement bénéfique ; Red Hat recommande de lui allouer une bande passante multiple de celle du réseau public, en prenant osd pool default size comme facteur.

Le point de départ commun est le débit réellement traité par les OSD du nœud — et non le débit client, qui en est une fraction :

traité      = débit_disques_du_nœud × sollicitation
lectures    = traité × (1 − part_d_écritures)
écr_phys    = traité × part_d_écritures
écr_client  = écr_phys ÷ facteur_du_pool

La distinction est essentielle. Une écriture client de 1 Go devient 3 Go d'écritures physiques dans un pool répliqué ×3. Confondre les deux gonfle artificiellement le besoin réseau.

Réseau public

public (Gb/s) = (lectures + écr_client) × 8 ÷ 1000

Les lectures sont servies au client par l'OSD primaire ; les écritures client arrivent sur ce même OSD primaire. Le trafic de réplication, lui, n'y passe pas.

Réseau cluster

multiplicateur     = size − 1                  (réplication)
                   = (k + m − 1) ÷ k           (erasure coding)
réplication (Gb/s) = écr_client × multiplicateur × 8 ÷ 1000
cluster (Gb/s)     = réplication + reconstruction

La règle est directe en réplication : à trois réplicas, la première copie arrive sur l'OSD primaire par le réseau public, les deux suivantes partent de cet OSD vers les deux autres par le réseau cluster. Soutenir 1 Go/s d'écriture client réclame donc 2 Go/s sur le réseau cluster.

Le multiplicateur n'est pas « facteur d'amplification moins un ». En erasure coding, l'OSD primaire reçoit l'objet entier puis émet k+m−1 fragments valant chacun 1/k de l'objet. Un profil 4+2 amplifie l'écriture d'un facteur 1,50 sur les disques, mais envoie 1,25 octet sur le réseau cluster par octet client — pas 0,50. Confondre les deux sous-estime le besoin d'un facteur 2,5.

Tout le calcul réseau porte sur le pool dominant, celui qui détient la plus grosse part du cluster : c'est lui qui détermine le profil de trafic. Son nom, son facteur d'amplification et son multiplicateur sont rappelés sous le tableau.

Le tableau additionne délibérément réplication et reconstruction dans la colonne « Cluster » : c'est le cas de figure qui compte, celui où un domaine est tombé pendant que la production continue.

6.6 Déclarer les liens réseau

Le point qui prête le plus à confusion : le sizer ne demande pas le nombre d'interfaces physiques ni le détail des agrégats, mais le débit utile dont dispose le trafic Ceph, et comment les deux réseaux Ceph se répartissent dessus.

Le sélecteur « Réseaux Ceph » offre deux modes.

« public et cluster sur le même lien » — les deux VLAN Ceph transitent par le même agrégat. Un seul champ est demandé : le débit de cet agrégat. La colonne « Lien(s) Ceph » du tableau compare alors au débit déclaré la somme du trafic public, de la réplication et de la reconstruction. C'est le cas le plus fréquent, et le seul où le cumul compte.

« liens dédiés par réseau » — chaque réseau Ceph a son propre agrégat. Deux champs sont demandés, et chaque réseau est confronté au sien.

Exemple, sur un R740xd à 4 × 25 GbE. Les quatre ports sont répartis en deux agrégats LACP de 2 × 25 GbE. Si l'ensemble du trafic Ceph — VLAN public et VLAN cluster — passe par le premier agrégat, le mode est « même lien » et le débit à saisir est 50. Le second agrégat, qui porte le management, la migration à chaud ou le corosync, ne concerne pas ce calcul et ne doit pas être additionné.

Si en revanche le VLAN public Ceph était porté par bond0 et le VLAN cluster Ceph par bond1, le mode serait « liens dédiés » avec 50 dans chaque champ.

Le débit à saisir est celui de l'agrégat, pas celui d'un port : un LACP de 2 × 25 GbE offre 50 Gb/s agrégés. Attention toutefois — LACP répartit par flux : un flux unique reste plafonné à 25 Gb/s. Le trafic Ceph étant massivement multi-flux (un flux par paire d'OSD), l'agrégat se comporte bien en pratique, mais un test de recette mono-flux ne montrera jamais 50 Gb/s.

6.7 Colonnes déclaratives

Les champs cœurs, RAM (Gio) et les débits de lien sont facultatifs. Renseignés, ils font apparaître un verdict ok ou ! en regard de chaque besoin. Laissés vides, le tableau affiche le besoin seul, sans verdict.

7. Lecture des résultats

7.1 Où part la capacité brute

Barre empilée en cinq postes dont la somme fait exactement le brut installé :

Poste	Contenu
Données utiles	Capacité effectivement porteuse de données d'invités
Surcoût réplication, parité et métadonnées	Copies, fragments de parité et pools de métadonnées compagnons
Capacité non allouée	Part du brut exploitable qu'aucun pool ne réclame — nulle quand la somme des allocations vaut 100 %
Réserve auto-guérison	§2.1
Métadonnées BlueStore	§2.3
Marge de remplissage	Écart entre le taux cible et 100 %

Sous la barre, un bandeau signale les gains issus des optimisations : volume ramené par la compression, volume provisionnable, abattement du balancer inactif.

7.2 Détail par pool

Colonne	Signification
Compr.	Ratio appliqué à ce pool, ou `—` si la compression est décochée
Surcoût	Facteur effectif, métadonnées EC comprises
Brut	Capacité brute consommée par le pool
Utile	Capacité avant compression
Stockable	Capacité après compression — le chiffre à retenir
MAX AVAIL	Référence de recoupement, compression non comptée
pg_num	Suggestion à confronter à l'autoscaler : `(OSD × 100 × part) ÷ chunks`, arrondi à la puissance de 2 et borné à [16, 32768]
Hôtes	`ok`, ou le nombre d'hôtes requis

7.3 Empreinte par hôte

Colonne	Signification
Débit disques	Débit soutenu cumulé des OSD du nœud, à saturation
Cœurs en charge	Consommation attendue au régime demandé — ce que Ceph prend au système
Cœurs à réserver	Provisionnement recommandé pour la pointe, face aux cœurs déclarés
RAM	Mémoire requise par Ceph, marge de 20 % comprise, face à la RAM déclarée
Public	Bande passante client en pointe
Cluster	Réplication plus reconstruction
Reconstruction	Part de la colonne Cluster imputable au seul rattrapage d'un hôte perdu
Lien(s) Ceph	Confrontation au débit déclaré : cumul public + cluster sur un lien partagé, ou chaque réseau face à son propre lien

Ces chiffres portent sur ce que Ceph consomme. Sur une plateforme hyperconvergée, la mémoire et les cœurs restants sont ce dont disposent les machines virtuelles.

7.4 Topologie et simulation de panne

Chaque hôte est représenté avec ses disques, dont la largeur est proportionnelle à la capacité. Cliquer un hôte simule sa perte : la capacité stockable restante s'affiche et les pools qui n'ont plus assez d'hôtes basculent en erreur. Recliquer le remet en service.

Deux indicateurs accompagnent la topologie :

Sans perte de données — nombre d'hôtes pouvant tomber avant perte réelle : size−1 en réplication, m en erasure coding.
En restant inscriptible — nombre d'hôtes pouvant tomber avant d'atteindre min_size : size−2 en réplication, m−1 en erasure coding. Au-delà, le pool passe en lecture seule.

8. Recouper le calcul avec un cluster en production

C'est le contrôle qui valide la saisie. La colonne Réf. ceph df MAX AVAIL est construite pour être directement comparable à la sortie de Ceph.

ceph df detail    # colonne MAX AVAIL du pool

Les deux valeurs doivent coïncider à moins de 1 %. Si l'écart est plus grand :

Symptôme	Cause probable
Sizer inférieur de ~9 %	Tio saisis à la place des To (§3.2)
Sizer supérieur	Disques système ou NVMe de DB comptés comme OSD
Écart de quelques pourcents	Variance entre OSD — vérifier `ceph balancer status` et la colonne `VAR`

La colonne « Données stockables » intègre l'abattement de variance (§5.3), pas la colonne MAX AVAIL. C'est voulu : Ceph calcule MAX AVAIL à partir de l'OSD réellement le plus rempli, la variance y est donc déjà comptée. Sur un cluster quasi vide, où la dispersion ne s'est pas encore exprimée, les deux valeurs se recoupent au dixième de pourcent près.

Pourquoi « Données stockables » est très inférieur à MAX AVAIL : Ceph n'applique que le full_ratio de 0,95. Le sizer retire en plus la réserve d'auto-guérison, les métadonnées BlueStore et la marge de remplissage. Les deux chiffres sont justes, ils ne répondent pas à la même question.

9. Chaîne de calcul complète

brut_To          = Σ (nb_disques × taille_unitaire_To)
brut             = brut_To × 0,909495                          → Tio

réserve          = capacité_du_plus_gros_hôte × hôtes_réservés
après_réserve    = brut − réserve
métadonnées      = après_réserve × %BlueStore
coef_balancer    = 0,95 si le balancer upmap est actif · 0,80 sinon

exploitable      = (après_réserve − métadonnées) × taux_remplissage × coef_balancer

brut_pool        = exploitable × part_du_pool
facteur_protection = size                                      (réplication)
                   = (k+m)/k                                   (erasure coding)
%métadonnées     = max(%EC si erasure coding, %CephFS si usage CephFS)
facteur_effectif = facteur_protection + %métadonnées × 3

utile            = brut_pool ÷ facteur_effectif
stockable        = utile × ratio_compression
provisionnable   = stockable ÷ occupation_réelle

MAX AVAIL (réf.) = brut × 0,95 × part_du_pool ÷ facteur_protection
                   (sans coef_balancer : Ceph l'intègre déjà via la variance réelle,
                    et sans réserve de métadonnées, que ceph df ne connaît pas)

Empreinte matérielle, par hôte :

débit_disques    = Σ (nb_disques × débit_unitaire_du_média)          → Mo/s
cœurs_en_charge  = traité ÷ débit_par_cœur + cœurs des rôles portés
cœurs_à_réserver = Σ (nb_disques × cœurs_du_média) + cœurs des rôles portés
RAM              = nb_OSD × osd_memory_target × 1,20 + RAM des rôles portés

traité           = débit_disques × sollicitation                     → Mo/s
lectures         = traité × (1 − part_d_écritures)
écr_client       = traité × part_d_écritures ÷ facteur_du_pool
public           = (lectures + écr_client) × 8 ÷ 1000                → Gb/s
reconstruction   = capacité_plus_gros_hôte × remplissage × 8000
                   ÷ (hôtes − 1) ÷ (délai × 3600)                    → Gb/s
multiplicateur   = size − 1 · ou (k+m−1) ÷ k en erasure coding
cluster          = écr_client × multiplicateur × 8 ÷ 1000 + reconstruction

10. Valeurs par défaut et leur origine

Chaque défaut est adossé soit à la documentation Ceph, soit à un constat de production. Aucun n'est arbitraire, et chacun est modifiable.

Paramètre	Défaut	Origine
Conversion To → Tio	0,909495	Constante — rapport entre 10¹² et 2⁴⁰
`mon_osd_full_ratio`	0,95	Défaut Ceph. Sert à la seule colonne de recoupement
Taux de remplissage cible	80 %	Jeu de seuils de production proposé par la documentation Ceph (`full 0.80` / `backfillfull 0.75` / `nearfull 0.70`) ; pratique communautaire convergente à 70-80 %
Hôtes réservés	1	Recommandation matérielle Ceph : si un hôte pèse une part importante du cluster, sa perte fait dépasser le `full_ratio` pendant la reconstruction et provoque l'arrêt des écritures
Métadonnées BlueStore	2 %	`block.db` documenté entre 1 et 4 % du périphérique, 1 à 2 % pour RBD, ≥ 4 % pour RGW
Ratio de compression	1,62×	Mesure sur pool RBD réel (`lz4` / `aggressive`). Plafond structurel ≈ 2× imposé par `min_alloc_size` à 4 Kio
Balancer `upmap` actif	−5 %	Variance résiduelle couramment constatée en production, balancer actif
Balancer `upmap` inactif	−20 %	Écarts à la moyenne dépassant 20 % à 100 PG par OSD sans table `upmap`
Occupation réelle des invités	100 %	Défaut neutre — aucune hypothèse. Ce taux se mesure, il ne s'estime pas
Pool de métadonnées EC	1 %	Majoration prudente : Ceph impose le pool sans publier de règle de dimensionnement, le contenu réel se compte en dizaines de Mio
Pool de métadonnées CephFS	2 %	Plus volumineux qu'en RBD — un inode par fichier. À relever sur un système de fichiers à nombreux petits fichiers
Réplication du pool de métadonnées EC	×3	Contrainte : le pool compagnon d'un pool EC est nécessairement répliqué
`osd_memory_target`	4 Gio	Défaut Ceph et minimum documenté ; en dessous, performances dégradées, plantages ou OOM killer en reconstruction
Marge mémoire système	+20 %	Demandée par la documentation Ceph, la gestion mémoire des OSD étant au mieux
Empreinte des rôles	`MON` 2 c / 4 Gio · `MGR` 1 c / 4 Gio · `MDS` 2 c / 8 Gio · `RGW` 2 c / 4 Gio	Empreinte du démon seul en hyperconvergé, valeur haute au-delà de 300 OSD. Sur moniteurs dédiés, la documentation raisonne à 32 / 64 / 128 Go d'hôte selon la taille du cluster
Rôles pré-cochés	3 `MON`, 2 `MGR`	Quorum impair minimal et un manager en veille
Cœurs par OSD (réserve)	1 HDD · 2 SSD · 4 NVMe	Doc Ceph : 1 minimum, 2 recommandés, davantage pour SSD et NVMe ; retours de production à 4 par OSD NVMe
Débit traité par cœur	350 Mo/s	Milieu de la fourchette documentée de 200 à 500 Mo/s par cœur
Débit soutenu par disque	200 / 500 / 3 000 Mo/s	Ordres de grandeur usuels HDD / SSD SATA / NVMe employés dans les règles de dimensionnement réseau
Sollicitation simultanée des disques	30 %	Une charge de VM ne sature pas tous les OSD à la fois. 100 % = plafond théorique du nœud
Part d'écritures	30 %	Profil 70/30 lecture/écriture courant
Délai de reconstruction	8 h	Compromis entre bande passante réservée et durée d'exposition en mode dégradé
Domaine de panne	`host`	Défaut Ceph pour les règles répliquées
Cible PG par OSD (calcul `pg_num`)	100	Défaut Ceph `mon_target_pg_per_osd`. La documentation recommande 200 pour la plupart des déploiements et signale un trafic et une consommation mémoire excessifs au-delà de 500

Sources

Référence	Portée
`docs.ceph.com` — Monitor Config Reference	Seuils `full` / `backfillfull` / `nearfull`
`docs.ceph.com` — BlueStore Config Reference	Dimensionnement `block.db`, modes et algorithmes de compression, `compression_required_ratio`
`docs.ceph.com` — Hardware Recommendations	Part de capacité par hôte et risque de dépassement du `full_ratio` en reconstruction ; cœurs par OSD, RAM par démon, `osd_memory_target`, marge de 20 %, RAM des moniteurs
`docs.ceph.com` — Network Config Reference	Rôles respectifs des réseaux public et cluster
`docs.ceph.com` — Troubleshooting OSDs	4 Gio par OSD minimum, 6 à 8 recommandés, pics en reconstruction
Red Hat — Hardware Guide, Networking Recommendations	Réseau cluster dimensionné en multiple du public sur la base de `osd pool default size` ; durées de reconstruction par débit de lien
Liste `ceph-users` — dimensionnement du réseau cluster	Règle des (size − 1) copies émises par l'OSD primaire
`docs.ceph.com` — Placement Groups	`mon_target_pg_per_osd`, seuils de 200 et 500 PG par OSD
`docs.ceph.com` — Erasure code	`allow_ec_overwrites`, pool de métadonnées répliqué obligatoire pour RBD
`docs.ceph.com` — Balancer / Using pg-upmap	Fonctionnement du balancer, `upmap_max_deviation`
Liste `ceph-users`, forum Proxmox, retours d'exploitation	Plafond de compression lié à `min_alloc_size`, variance OSD résiduelle et sans balancer, pratique de remplissage
Red Hat — BlueStore compression performance	Coût en IOPS et latence du mode `aggressive`
Mesures sur la plateforme	Ratio de compression 1,62×, hétérogénéité du parc

11. Générer les commandes Proxmox VE

Une section Commandes Proxmox VE en bas de la colonne de résultats produit, en temps réel, le script de création des pools tels que configurés. Il vise Proxmox VE 9.2.x et Ceph Tentacle 20.2. Deux boutons : copier, ou télécharger en .sh.

Le script est un point de départ relu, pas un presse-bouton. Il commence par set -euo pipefail et par un contrôle HEALTH_OK qui interrompt l'exécution sur un cluster dégradé.

11.1 Démons de contrôle : MON, MGR, MDS

Le script commence par un bloc reprenant les rôles cochés sur chaque serveur. Toutes ces lignes sont commentées à dessein : pveceph échoue si le démon existe déjà, et set -e ferait alors avorter la création des pools qui suit. Décommentez uniquement ce qui manque.

pveceph agit sur le nœud local. Lancez chaque commande depuis le nœud concerné, ou depuis n'importe quel nœud du cluster en la préfixant par ssh <nœud> — c'est la forme générée.

Commande	Effet
`pveceph mon create`	Crée un moniteur. `--mon-address <ip>` force l'adresse quand plusieurs réseaux publics Ceph existent, `--monid <id>` le nom du démon (par défaut celui du nœud)
`pveceph mgr create`	Crée un manager. `--id <id>` pour le nommer autrement que le nœud
`pveceph mds create`	Crée un serveur de métadonnées CephFS. `--name <id>` pour le nom, `--hotstandby 1` pour un démon en veille active

Trois points que le script rappelle en commentaire :

Le premier moniteur crée aussi un manager sur son nœud. Le pveceph mgr create généré pour ce même nœud est donc redondant, et signalé comme tel.
Le premier MDS est actif, les suivants sont générés avec --hotstandby 1. Un démon en veille rejoue le journal du MDS actif, ce qui accélère la bascule au prix de ressources immobilisées en permanence. Sans cette option le standby existe quand même, mais reprend plus lentement.
Le nombre de moniteurs est rappelé, avec la cible d'un quorum impair — 3, 5 ou 7.

Vérification : ceph mon stat, ceph mgr stat, ceph fs status, pveceph status.

Retrait : pveceph mon destroy <id>, pveceph mgr destroy <id>, pveceph mds destroy <id>. Ne retirez jamais un moniteur sans vérifier d'abord que le quorum survivra — sur trois moniteurs, en détruire un laisse deux nœuds à égalité et un cluster figé au prochain incident.

11.2 Ce qui est généré selon le cas

Pool répliqué RBD — un pveceph pool create avec --size, --min_size (calculé à max(2, size−1)), --pg_num, --pg_autoscale_mode on, --application rbd et --add_storages 1, suivi des réglages de compression si la case est cochée.

Pool erasure-coded RBD — pveceph pool create <nom> --erasure-coding k=…,m=…. Une seule commande crée deux pools : <nom>-data (erasure-coded) et <nom>-metadata (répliqué ×3), ce dernier portant les omap RBD et les en-têtes d'images — sans lui, RBD refuse d'écrire. pveceph pose lui-même allow_ec_overwrites sur le pool de données : aucune commande à ajouter, et le script le dit explicitement plutôt que de laisser croire à un oubli.

Les options --size, --min_size et --crush_rule s'appliquent au pool de métadonnées, pas au pool EC — le script le rappelle en commentaire, c'est une source classique de confusion. Tous les réglages postérieurs visent <nom>-data.

Pool CephFS répliqué — pveceph fs create --name <nom> --pg_num … --add-storage 1, qui crée <nom>_data et <nom>_metadata. Cette commande n'accepte ni --size ni --crush_rule : le script les pose ensuite par ceph osd pool set.

Pool CephFS erasure-coded — pveceph fs create ne sait pas créer un pool de données EC. Le script crée donc le système de fichiers, puis un pool EC séparé, puis l'y rattache par ceph fs add_data_pool. Là encore allow_ec_overwrites est posé par pveceph à la création. Le script rappelle que seul un setfattr -n ceph.dir.layout.pool dirige un répertoire vers ce pool, et que les fichiers déjà écrits n'y sont pas déplacés.

Métadonnées CephFS sur périphériques rapides — pour les deux variantes CephFS, le script propose en commentaire une règle CRUSH dédiée et son application au pool <nom>_metadata, à décommenter sur un parc hétérogène.

Compression — trois lignes par pool coché, sur le pool de données : compression_algorithm lz4, compression_mode aggressive, compression_required_ratio 0.85.

target_size_ratio — la « part de l'espace libre » saisie dans le sizer est reportée telle quelle. C'est le mécanisme par lequel Ceph transmet à l'autoscaler la part attendue d'un pool : l'hypothèse de planification devient un réglage réel du cluster.

bulk true — posé sur les pools représentant 40 % ou plus du cluster, laissé en commentaire en dessous, avec le critère expliqué.

Règle CRUSH — générée dès que le domaine de panne n'est pas host ou que plusieurs classes de périphériques cohabitent. Le nom passe par une variable CRUSH_RULE : sur un parc mixte, une seule ligne à ajuster suffit à rendre le script exécutable. Un rappel signale que beaucoup de NVMe sont classés ssd par Ceph, à vérifier par ceph osd crush class ls.

11.3 Ce que le script signale sans le faire

min_size d'un pool EC. pveceph pose k+1. La documentation Ceph recommande la valeur conservatrice k+2 — mais elle n'a de sens qu'à partir de m ≥ 3 : à m = 2, k+2 égale size et le pool se bloquerait à la moindre perte. Le script émet la commande quand elle est pertinente, et l'explique quand elle ne l'est pas.
Optimisations EC de Tentacle. allow_ec_optimizations est proposé en commentaire, à évaluer sur un pool vide et hors production.
Pools sous-dimensionnés. Un pool exigeant plus de domaines que le cluster n'en compte est précédé d'un # ATTENTION … Ne pas exécuter en l'état.

Le script se termine par ceph osd pool ls detail, ceph osd pool autoscale-status, ceph df detail et ceph health detail, puis par le rappel que le ratio de compression n'est opposable qu'une fois mesuré sur le pool réel.

12. Exporter, importer, archiver

Quatre boutons en haut de page, sous le bandeau de synthèse.

Bouton	Contenu	Usage
Exporter la configuration (.json)	État complet — paramètres, serveurs, pools, unité	Archivage, versionnement, échange
Exporter le rapport (.md)	Synthèse rédigée : capacité, paramètres retenus, serveurs, pools, empreinte par hôte, contrôles	Pièce jointe d'un dossier de décision
Exporter les tableaux (.csv)	Trois blocs — capacité, serveurs, pools — en point-virgule, avec BOM UTF-8	Reprise dans un tableur
Exporter les commandes (.sh)	Script de création des pools (§11)	Exécution sur le cluster après relecture
Importer une configuration	Relit un `.json` produit par ce sizer	Reprendre une étude

Le rapport Markdown reprend les valeurs affichées au moment de l'export, unité comprise : basculez en Tio avant d'exporter si le document doit se comparer à une sortie ceph df. Il inclut les contrôles en clair, ce qui en fait une trace vérifiable de ce qui était signalé au moment de la décision.

Le CSV est séparé par des points-virgules et commence par un BOM UTF-8 : Excel en configuration française l'ouvre directement, colonnes séparées et accents corrects, sans passer par l'assistant d'importation.

L'import est strict : il vérifie la présence du marqueur format: "ceph-sizer" et refuse tout fichier qui n'en vient pas, plutôt que de charger une configuration partielle. Les paramètres absents d'un export plus ancien conservent leur valeur par défaut.

Si votre navigateur bloque les téléchargements — page ouverte dans un cadre restreint, par exemple — le contenu est automatiquement copié dans le presse-papier et un message le signale. Le fichier n'est jamais perdu.

Rien n'est enregistré entre deux sessions : fermer l'onglet perd la saisie. L'export JSON est le mécanisme de sauvegarde.

13. Ce que le sizer ne fait pas

IOPS et latence. L'empreinte matérielle (§6) estime des débits et des ressources, pas des temps de réponse. Aucune projection d'IOPS ni de latence. La compression aggressive coûte quelques points d'IOPS et un peu de latence, l'erasure coding beaucoup plus sur les écritures aléatoires : ces effets ne sont pas modélisés. Les débits par média sont des ordres de grandeur constructeur, à confronter à un fio sur le matériel réel.
Pools système. .mgr, pools CephFS ou RGW ne sont pas comptés — quelques dizaines de Gio.
DB/WAL déportés. À provisionner hors calcul, 1 à 4 % de la taille de l'OSD par DB.
Instantanés, clones liés, corbeille RBD. Consommateurs invisibles à surveiller séparément.
Hiérarchies CRUSH imbriquées. Le sizer traite un niveau de domaine à la fois (§2.0). Une règle qui combinerait plusieurs niveaux, ou des poids CRUSH modifiés à la main, sort du modèle.
Persistance. Aucune sauvegarde automatique : l'export JSON est le seul filet (§12).
Croissance. Le calcul est statique. Ajouter une hypothèse de croissance annuelle en abaissant le taux de remplissage cible.

Name		Name	Last commit message	Last commit date
README.md		README.md
ceph-sizer.html		ceph-sizer.html

Latest commit

History

Folders and files

Repository files navigation