OpenStack Cinder Storage Calculator

Convert Cinder volume demand into raw backend capacity including Ceph replication, snapshot deltas and a free-space reserve.

About OpenStack Cinder Storage Calculator

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.

Formula

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.

replication factor: Raw bytes stored per logical byte — 3 for replica size 3
change rate: Share of the volume each snapshot diverges by
full ratio: Utilisation at which Ceph stops accepting writes

Worked example

With the default values below, OpenStack Cinder Storage Calculator returns Raw Capacity Required of 44 TiB. Change any input above and every figure here is recalculated in your browser.

Inputs used

Volumes to provisionaccepts 1–100,000 volumes: 300 volumes
Size per volumeaccepts 1–65,536 GiB: 100 GiB
Actual data written per volumeaccepts 1–100 %: 40 %
Snapshots retained per volumeaccepts 0–64 snapshots: 3 snapshots
Change rate per snapshotaccepts 0–100 %: 8 %
Backend redundancyone of Ceph replica size 3 (3x raw), Ceph replica size 2 (2x raw), Erasure coded 4+2 (1.5x raw), Erasure coded 8+3 (1.375x raw), Single copy, array-protected: Ceph replica size 3 (3x raw)
Backend full ratioaccepts 50–99 %: 85 %
Raw backend capacity installedaccepts 0.1–10,000 TB: 200 TB

Results

Raw Capacity Required: 44 TiB
Logical Data Stored: 14,880.0 GiB
Raw Cost per Volume: 148.80 GiB
Volumes the Backend Supports: 1,063 volumes
Backend Utilisation: 28.2%
Capacity Verdict: Under-subscribed backend

Step by step

1Values used
2OpenStack Cinder Storage
3Raw Capacity Required= 47,931,835,023,360
4Logical Data Stored= 14,880.0 GiB
5Raw Cost per Volume= 148.80 GiB
6Volumes the Backend Supports= 1,063 volumes
7Backend Utilisation= 28.2
8Capacity Verdict= Under-subscribed backend

Assumptions and limits

The result is derived only from the 8 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is OpenStack Cinder Storage calculated?

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.

Why does OpenStack Cinder Storage matter?

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.

What values do I need to enter?

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.

Why is erasure coding not always the answer?

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.