Skip to content
Calcrivo

OpenStack Cinder Storage Calculator

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

Inputs

volumes
GiB
%

Thin-provisioned RBD volumes only consume written objects.

snapshots
%
%

Ceph blocks writes at the full ratio, so never plan past it.

TB

Raw Capacity Required

44 TiB

Logical Data Stored

14,880.0GiB

Raw Cost per Volume

148.80GiB

Volumes the Backend Supports

1,063volumes

Backend Utilisation

28.2%

Capacity Verdict

Under-subscribed backend

Step by step

  1. Values used

    Volumes to provision = 300 volumes; Size per volume = 100 GiB; Actual data written per volume = 40 %; Snapshots retained per volume = 3 snapshots; Change rate per snapshot = 8 %; Backend redundancy = Ceph replica size 3 (3x raw); Backend full ratio = 85 %; Raw backend capacity installed = 200 TB

  2. 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.

  3. Raw Capacity Required

    = 47,931,835,023,360

  4. Logical Data Stored

    = 14,880.0 GiB

  5. Raw Cost per Volume

    = 148.80 GiB

  6. Volumes the Backend Supports

    = 1,063 volumes

  7. Backend Utilisation

    = 28.2

  8. Capacity Verdict

    = Under-subscribed backend

How it works

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

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.

You might also need