Ceph Storage Capacity Calculator

Projected Usable Capacity

{{ formatCap(rawEffectiveTB) }} {{ unit }} Raw (post-overhead) {{ protectionLabel }} {{ (100 * totalEfficiency).toFixed(1) }} % Protected Eff.

Total nodes:

Capacity per node:

Define each node manually (heterogeneous):

Per-node capacities:

Node {{ i }}

Filled: {{ manualValidCount }} / {{ Math.max(0, Math.floor(Number(nodeCount) || 0)) }} nodes, {{ formatCap(rawTB) }} {{ unit }} total (before overhead).

Data protection:

OSD nearfull ratio :

{{ (nearfull * 100).toFixed(0) }} %

Failure domain for headroom :

OSDs / node

Cap {{ unit }}

Domains to tolerate (fail) :

OSD/metadata overhead :

{{ (osdOverhead*100).toFixed(1) }} %

CRUSH imbalance skew :

{{ (skew*100).toFixed(1) }} %

Accept degraded PGs (override recommended nearfull) :

Recommended nearfull ≤ {{ (recommendedNearfull * 100).toFixed(0) }}% to recover after {{ failNodes }} {{ failureDomain }} failure{{ failNodes===1?'':'s' }}. Using {{ (effectiveNearfull * 100).toFixed(0) }}%.

Metric	Value
Nodes	{{ nodes.length }}
Raw storage ({{ unit }})	{{ formatCap(rawTB) }}
Overhead ({{ unit }})	{{ formatCap(rawTB - rawEffectiveTB) }}
Raw post-overhead ({{ unit }})	{{ formatCap(rawEffectiveTB) }}
OSD nearfull (used)	{{ (effectiveNearfull*100).toFixed(0) }} %
Recommended nearfull	{{ (recommendedNearfull*100).toFixed(0) }} %
Protection	{{ protectionLabel }}
Protected efficiency	{{ (100*totalEfficiency).toFixed(2) }} %
Efficiency @ min_size	{{ (100*minEfficiency).toFixed(2) }} %
Usable capacity ({{ unit }})	{{ formatCap(usableTB) }}
Redundancy overhead ({{ unit }})	{{ formatCap(redundantRawTB) }}
Reserved / free raw ({{ unit }})	{{ formatCap(reservedRawTB) }}

Categories: Calculator , Networking , Storage , System Administration

Export to PDF Fullscreen

Embed:

Ceph storage capacity is the amount of application data a cluster can hold after accounting for redundancy and operational headroom. A Ceph capacity planning calculator helps you translate node sizes and protection choices into a realistic estimate you can act on. Results reflect the balance between usable data space, redundancy, and reserved room for recovery so you can plan growth with fewer surprises.

Describe your nodes and choose the unit you prefer, then select replication or erasure coding. Set the nearfull ratio that you are willing to approach so daily writes continue and recovery remains possible. If hardware varies, enter per node values and adjust for filesystem and metadata overhead or for placement imbalance in mixed or uneven clusters.

When resilience matters, allocate headroom for the largest failure domains that match your placement rule and specify how many simultaneous losses you want to tolerate. The calculator compares your chosen nearfull level to the minimum needed to rebuild after those losses so you can trade capacity for safety with eyes open.

A practical example is six nodes with 10 TB each using triple replication. With a nearfull level of 85 percent the outcome is about 17 TB of usable space while roughly 34 TB is consumed by redundancy and about 9 TB remains free for recovery. Raising protection or reserving more headroom will reduce usable space which is expected in a durable design.

Capacity estimates guide planning and do not certify pool settings or account status. Use realistic inputs and revisit the calculation when hardware or policies change.

Technical Details:

The calculation models protected storage capacity for a Ceph cluster by combining raw node capacity, efficiency from the protection scheme, and a fullness limit that preserves recovery room. It reports the split between data, redundancy, and reserved raw space in the unit you select.

Protection efficiency summarizes how much of the stored raw becomes user data. Replication uses a factor of the inverse of replica count. Erasure coding uses the data shard share of the stripe. A second metric, minimum efficiency, reflects behavior at min_size when the system is degraded but still accepts writes.

Recovery headroom is handled through a nearfull ratio that caps how much post‑overhead raw can be used. A recommended nearfull is derived from the capacity required to rebuild after losing one or more failure domains. If you choose to accept degraded placement groups temporarily, the effective nearfull can exceed that recommendation at increased risk.

Comparisons assume a single protection policy, consistent units across inputs, and a cluster‑wide nearfull target. Per‑pool placement rules, device classes, and time‑varying behavior are outside scope; treat results as planning guidance rather than operational guarantees.

\begin{matrix} C = \sum C_{i} & Raw capacity as the sum of node capacities \\ C_{eff} = C \cdot (1 - o) \cdot (1 - s) & Post‑overhead raw after OSD/metadata overhead o and imbalance skew s \\ H_{dom} = capacity to rebuild f failure domains & (largest hosts, average OSDs, or custom capacity) \\ β_{rec} = 1 - \frac{H_{dom}}{C_{eff}} & Recommended nearfull (clamped to [0,1]) \\ α_{eff} = min (ρ, β_{rec}) & Effective nearfull αefffrom chosen ρ unless degraded writes are allowed \\ η = replication : \frac{1}{r}; erasure coding : \frac{k}{k + m} & Protected efficiency \\ U_{usable} = C_{eff} \cdot α_{eff} \cdot η & Projected usable capacity \end{matrix}

Symbols and units
Symbol	Meaning	Unit/Datatype	Source
Ci	Capacity of node i	MB \| GB \| TB \| PB / MiB \| GiB \| TiB \| PiB	Input
C	Raw capacity across nodes	same as input unit	Derived
Ceff	Post‑overhead raw	same as input unit	Derived
o	OSD/metadata overhead fraction	0 to 0.15 in UI	Input
s	CRUSH imbalance skew fraction	0 to 0.15 in UI	Input
ρ	Chosen OSD nearfull ratio	0.50 to 0.95 in UI	Input
βrec	Recommended nearfull ratio	0 to 1	Derived
αeff	Effective nearfull ratio	0 to 1	Derived
r	Replication size	integer ≥ 1	Input
k, m	Erasure coding data and parity shards	k ≥ 1, m ≥ 0	Input
η	Protected efficiency	0 to 1	Derived
Uusable	Projected usable capacity	same as input unit	Derived

Worked example. Six nodes at 10 TB each; replication size 3; min_size 2; nearfull 0.85; overhead 0; skew 0.

\begin{matrix} C = 60 TB \\ C_{eff} = 60 TB \\ α_{eff} = 0.85 \\ η = \frac{1}{3} \approx 0.3333 \\ U_{usable} = 60 \cdot 0.85 \cdot 0.3333 = 17.00 TB \end{matrix}

Protected efficiency is 33.33 percent; minimum efficiency at min_size 2 is 50 percent.

Units, precision & rounding:

Capacity values display with two decimal places; percentages display with zero or two as shown in the table.
Inputs and outputs follow the unit you select (decimal or binary); no hidden conversion is applied.

Validation & bounds (from the package):

Validation rules
Field	Type	Min	Max	Step/Pattern	Notes
Total nodes	number	1	—	1	Counts storage hosts.
Capacity per node	number	0	—	0.01	Used when not defining nodes manually.
Per‑node capacity	number	0	—	0.01	Empty inputs count as 0.
Unit	select	—	—	MB, GB, TB, PB, MiB, GiB, TiB, PiB	Applies globally.
Mode	select	—	—	rep \| ec	Replication or erasure coding.
Replication size	number	1	—	1	Protected efficiency is 1/size.
Replication min_size	number	1	—	1	Minimum active copies to accept writes.
EC k	number	1	—	1	Data shards.
EC m	number	0	—	1	Parity shards.
EC min_size	number	k	—	1	Clamped to ≥ k.
OSD nearfull	range	0.50	0.95	0.01	Often 80 to 90; 95 is an upper safety bound.
Failure domain	select	—	—	host \| osd \| custom	Used for recommended nearfull.
OSDs per node	number	1	—	1	Average OSD size inferred.
Custom domain capacity	number	0	—	0.01	Capacity per domain.
Domains to tolerate	number	0	—	1	Number of failures to absorb.
OSD/metadata overhead	range	0	0.15	0.005	Typical 2 to 5.
CRUSH skew	range	0	0.15	0.005	Typical 0 to 10.
Accept degraded PGs	checkbox	—	—	—	Allows writes above recommendation.

I/O formats & encoding:

Inputs and outputs
Input	Accepted Families	Output	Encoding/Precision	Rounding
Numeric entries and toggles	Integers and decimals	Table metrics and breakdown	Capacities in chosen unit	Two decimals for capacities
—	—	CSV and JSON for export	JSON keys: inputs, metrics	CSV mixes numbers and labels

Performance & complexity:

Aggregation is linear in node count.
Host‑domain headroom sorts node capacities which is O(n log n).
Charting and formatting costs are negligible at typical sizes.

Diagnostics & determinism:

Identical inputs yield identical outputs.
Results appear once raw capacity, efficiency, and nearfull are all positive.

Security & privacy:

No data is transmitted or stored server‑side; calculations and copies happen in the browser.
Clipboard actions require user permission in some environments.

Assumptions & limitations:

One protection policy and one nearfull target are applied cluster‑wide.
Per‑pool rules, device classes, and tiering are not modeled.
OSD/metadata overhead and CRUSH skew are scalar penalties, not per‑bucket analyses.
OSD‑domain headroom uses average OSD size which may understate extremes.
Host‑domain headroom sums the largest nodes only; mixed device internals are not inspected.
Manual node inputs treat empty fields as zero capacity.
Units are taken at face value; conversions between decimal and binary prefixes are not inferred.
Heads‑up Allowing degraded writes increases risk if another failure occurs before recovery finishes.

Edge cases & error sources:

Very large totals can expose floating‑point rounding in displays.
Setting nearfull to zero or raw to zero suppresses results.
EC min_size lower than k is clamped to k.
Replication min_size larger than size does not change protected efficiency.
Failure counts greater than available domains reduce recommendation to zero.
OSD per node set unrealistically low or high skews average OSD size.
Mixed units mid‑calculation are not supported; switch units before entering values.
Clipboard copy can fail where system policies block programmatic writes.
JSON rendering is cosmetic; the underlying numbers drive CSV and metrics.
Chart rendering requires the charting layer to be available.

Scientific & standards backing:

Erasure coding efficiency follows the proportion of data shards in a stripe (e.g., Reed–Solomon families).
Replication overhead is the reciprocal of copy count, a basic redundancy relation.
Recovery headroom reflects capacity reserved to reconstruct lost data before resuming normal writes.
CRUSH concepts inform the choice of host or OSD as failure domains for planning.

Privacy & compliance:

No data is transmitted or stored server‑side. CSV and JSON are produced locally for your use.

Step‑by‑Step Guide:

Ceph usable capacity planning, from node inventory to a clear breakdown.

Enter the number of nodes Total nodes.
Provide a per node capacity or switch to manual entries.
Select the capacity unit MB/GB/TB/PB or MiB/GiB/TiB/PiB.
Choose replication or erasure coding and set parameters.
Set the nearfull ratio you aim not to exceed.
Open Advanced to pick failure domain and tolerated losses.
Adjust overhead and skew to reflect metadata and imbalance.
Review the table and breakdown, then copy CSV or JSON if needed.

Example. Six nodes × 10 TB, replication 3, nearfull 0.85 → about 17 TB usable, 34 TB redundancy, 9 TB reserved.

Typical nearfull is 80 to 90; higher values leave little room to rebuild.
Match the failure domain to your placement rule for realistic headroom.

FAQ:

Is my data stored?

No. Inputs are used locally to compute results, and copies you make stay on your device.

How accurate is the estimate?

It captures protection efficiency, overhead, imbalance, and recovery headroom. It does not model per‑pool rules or device classes, so treat it as planning guidance.

Which units can I use?

Decimal MB/GB/TB/PB or binary MiB/GiB/TiB/PiB. Calculations and displays follow the unit you choose.

Can I work offline?

Yes. The computation runs in your browser. Copy and download actions also work without a network connection.

How do I model 4+2 EC?

Select erasure coding, set k to 4 and m to 2, and choose a nearfull that leaves enough headroom to rebuild two shard losses.

What does “borderline” nearfull mean?

When your chosen nearfull meets the recommendation, recovery is just possible. Pushing beyond this raises the risk of running out of room during rebuild.

What does it cost to use?

The package does not declare pricing or licensing. Treat it as an informational calculator unless stated otherwise in your environment.

How do I copy results?

Use the copy controls for CSV or JSON. You can also download files to share with teammates.

Why is usable capacity zero?

Raw capacity, efficiency, and nearfull must all be positive. Check that nodes and units are set, and that the nearfull slider is above zero.

Troubleshooting:

Usable shows zero: confirm node count, capacities, and nearfull are all set.
Breakdown chart missing: ensure the chart tab is active and the charting layer is available.
CSV or JSON copy fails: allow clipboard access or use the download option.
Recommended nearfull is 100%: increase failure domains or verify domain selection.
Numbers look off by unit: switch units first, then enter values consistently.
Manual entries ignored: ensure “define each node manually” is enabled.

Blocking: If chart rendering fails repeatedly, switch to the Table tab to view and export the numeric results.

Advanced Tips:

Tip Model heterogeneity by enabling manual nodes and varying a few large hosts.
Tip Use skew to capture uneven weights and partial imbalances after reweights.
Tip Reserve extra headroom when adding many objects quickly to cover transient duplication.
Tip Compare protected and minimum efficiency to understand degraded write costs.
Tip Keep units consistent across teams to avoid miscommunication when reporting totals.
Tip Revisit nearfull after growth or topology changes to sustain recovery guarantees.

Typical nearfull choices are 80 to 90 to leave breathing room for recovery.

Glossary:

OSD: Object Storage Daemon that stores data on a node.
CRUSH: Controlled Replication Under Scalable Hashing placement algorithm.
Replication: Multiple full copies of each object across failure domains.
Erasure coding: Data split into data and parity shards for space‑efficient protection.
nearfull: Fullness ratio at which further writes should slow or halt.
Failure domain: Unit of independent failure such as a host or an OSD.