Outil gratuit
Dimensionnez votre cluster Ceph en fonction de vos hôtes, de vos disques, de votre politique de réplication et de votre seuil de remplissage.
Ce calculateur fournit une estimation de dimensionnement. Les performances et la résilience réelles dépendent notamment du matériel, du réseau, de la topologie CRUSH, du type de charge et de la configuration des pools.
La capacité brute est la somme de tous vos disques (OSD). C'est le point de départ, mais ce n'est jamais la capacité que vous pourrez réellement stocker.
La capacité utile correspond aux données que vous pouvez réellement écrire. Ceph protège chaque donnée, ce qui consomme de l'espace : la capacité utile est donc toujours inférieure à la capacité brute.
La réplication conserve plusieurs copies complètes de chaque objet. Simple et robuste, mais coûteuse : avec un facteur x3, seul un tiers de la capacité brute est utile.
Le domaine de défaillance (OSD, hôte, châssis, rack) indique à CRUSH sur quels niveaux répartir les copies. Pour tolérer la perte d'un hôte entier, les copies doivent être placées sur des hôtes distincts.
Le seuil de remplissage : on ne remplit jamais un cluster Ceph à 100 %. Au-delà d'environ 85 % (nearfull), l'équilibrage et les reconstructions peuvent échouer. 75 à 80 % est un bon compromis.
La réserve de reconstruction (backfill) : après la perte d'un OSD ou d'un hôte, Ceph recrée les copies manquantes sur le matériel restant. Il faut donc conserver de l'espace libre pour absorber cette reconstruction.
Les OSD (Object Storage Daemons) gèrent chacun un disque. Leur nombre, leur taille et leur répartition déterminent la capacité, la performance et la granularité de la reconstruction.
Le réseau est déterminant : la réplication et le backfill génèrent un trafic important. Un réseau sous-dimensionné allonge les reconstructions et dégrade les performances.
Capacité n'est pas performance : ce calculateur estime la capacité et la résilience, pas les IOPS. Les performances réelles dépendent du matériel, de la charge et se valident par benchmark.
Avec size=3, Ceph conserve trois copies complètes de chaque objet : seul 1/3 de la capacité brute est donc réellement utile.
3 est le standard en production : trois copies complètes, bon équilibre entre résilience et coût. 2 est risqué pour les données critiques ; 1 n'offre aucune redondance.
3 est le standard en production : trois copies complètes, bon équilibre entre résilience et coût. 2 est risqué pour les données critiques ; 1 n'offre aucune redondance.
Ceph a besoin d'espace libre pour rééquilibrer et reconstruire après une panne. Au-delà du seuil nearfull ( environs 85 %), ces opérations peuvent bloquer.
Comptez environ 4 Go par OSD (osd_memory_target par défaut) plus une marge et davantage pour des OSD NVMe. Ajoutez la RAM de l'OS et des services.
Souvent oui pour des OSD HDD/SSD de taille modérée. Pour des OSD NVMe ou de gros volumes, 25 Gb/s ou plus est recommandé, avec réseaux public et cluster séparés.
Oui, Proxmox VE intègre nativement Ceph (RBD pour les VM, CephFS). C'est une combinaison courante pour l'hyperconvergence. Logexia accompagne ces déploiements.
Ceph détecte la panne et reconstruit automatiquement les copies ou fragments manquants sur le matériel restant, tant qu'il reste assez d'espace et de domaines de défaillance.
Non. Il fournit une estimation de dimensionnement (capacité, résilience). Les performances réelles dépendent du matériel, de la topologie et de la charge, et doivent être validées en amont
