Convert Cinder volume demand into raw backend capacity including Ceph replication, snapshot deltas and a free-space reserve.
Cinder reports logical volume sizes, but the backend pays the replication multiplier on every written byte, and RBD snapshots keep changed objects alive rather than the whole volume. Ceph also refuses writes once the full ratio is crossed, so the planning ceiling is installed raw capacity times the full ratio, not installed raw capacity. Thin provisioning plus a 3x replica factor makes it very easy to sell twelve terabytes of volumes against four terabytes of real space, and the discovery point is a cluster-wide write freeze rather than a single volume failing.
OpenStack Cinder Storage
raw = volumes × (written data + snapshots × change rate) × replication factor; usable = installed raw × full ratio, so volumes supported = usable ÷ raw cost per volume.
raw = volumes × (written data + snapshots × change rate) × replication factor; usable = installed raw × full ratio, so volumes supported = usable ÷ raw cost per volume. Cinder reports logical volume sizes, but the backend pays the replication multiplier on every written byte, and RBD snapshots keep changed objects alive rather than the whole volume. Ceph also refuses writes once the full ratio is crossed, so the planning ceiling is installed raw capacity times the full ratio, not installed raw capacity.
Thin provisioning plus a 3x replica factor makes it very easy to sell twelve terabytes of volumes against four terabytes of real space, and the discovery point is a cluster-wide write freeze rather than a single volume failing.
This calculator takes 8 inputs: Volumes to provision, Size per volume, Actual data written per volume, Snapshots retained per volume, Change rate per snapshot, Backend redundancy, Backend full ratio, Raw backend capacity installed. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
A 4+2 profile stores 1.5x instead of 3x, which is a large saving, but every write becomes a read-modify-write across six OSDs. That raises latency and CPU cost, so erasure coding suits capacity pools and object storage more than latency-sensitive boot volumes.