Free tool
Size your Ceph cluster based on your hosts, your disks, your replication policy and your fill threshold.
This calculator provides a sizing estimate. Actual performance and resilience depend on factors such as hardware, network, CRUSH topology, workload type and pool configuration.
Raw capacity is the sum of all your disks (OSDs). It is the starting point, but it is never the capacity you can actually store.
Usable capacity is the data you can actually write. Ceph protects every piece of data, which consumes space: usable capacity is therefore always lower than raw capacity.
Replication keeps several full copies of each object. Simple and robust, but costly: with a factor of x3, only a third of the raw capacity is usable.
The failure domain (OSD, host, chassis, rack) tells CRUSH across which levels to spread the copies. To tolerate the loss of an entire host, copies must be placed on separate hosts.
The fill threshold: you never fill a Ceph cluster to 100%. Beyond around 85% (nearfull), rebalancing and rebuilds can fail. 75 to 80% is a good compromise.
The rebuild reserve (backfill): after the loss of an OSD or a host, Ceph recreates the missing copies on the remaining hardware. You therefore need to keep free space to absorb this rebuild.
OSDs (Object Storage Daemons) each manage one disk. Their number, size and distribution determine capacity, performance and rebuild granularity.
The network is decisive: replication and backfill generate significant traffic. An undersized network lengthens rebuilds and degrades performance.
Capacity is not performance: this calculator estimates capacity and resilience, not IOPS. Actual performance depends on hardware and workload, and is validated through benchmarking.
With size=3, Ceph keeps three full copies of every object, so only 1/3 of the raw capacity is actually usable.
3 is the production standard: three full copies, a good balance between resilience and cost. 2 is risky for critical data; 1 offers no redundancy.
3 is the production standard: three full copies, a good balance between resilience and cost. 2 is risky for critical data; 1 offers no redundancy.
Ceph needs free space to rebalance and rebuild after a failure. Beyond the nearfull threshold (around 85%), these operations can stall.
Allow around 4 GB per OSD (the default osd_memory_target) plus a margin, and more for NVMe OSDs. Add the RAM for the OS and services.
Often yes for moderately sized HDD/SSD OSDs. For NVMe OSDs or large volumes, 25 Gb/s or more is recommended, with separate public and cluster networks.
Yes, Proxmox VE integrates Ceph natively (RBD for VMs, CephFS). It is a common combination for hyperconvergence. Logexia supports these deployments.
Ceph detects the failure and automatically rebuilds the missing copies or fragments on the remaining hardware, as long as enough space and failure domains remain.
No. It provides a sizing estimate (capacity, resilience). Actual performance depends on the hardware, topology and workload, and must be validated beforehand.
