Planning for new workloads

Intermediate⏱ ~17 minceph

What you'll learn

Recognise the limits of trend-based forecasting
Gather requirements from workload owners
Model a step change in demand
Build an onboarding process that includes capacity

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

A trend forecast extrapolates the past. A new tenant arriving with 200 TB is not in the past, and no amount of statistical care will find it in the data.

Where trend forecasting fails

Event	Trend forecast
Steady organic growth	accurate
A new tenant onboarding	misses entirely
A workload migration from another system	misses entirely
A retention policy change	misses entirely
A team doubling its backup frequency	misses until it happens

The common property is that each is a decision made elsewhere in the organisation, visible to someone before it reaches the cluster.

Gathering requirements

The questions worth asking any incoming workload:

1. How much data initially?
2. What growth rate thereafter?
3. What retention?
4. Replicated or erasure coded — and is the workload latency-sensitive?
5. What IOPS and throughput?
6. When does it start, and does it ramp or arrive at once?

Question 6 matters more than it looks: 200 TB arriving over a month is a capacity plan, and 200 TB arriving over a weekend is also a throughput and backfill plan.

# what the answers become
ceph osd pool create tenant-x 256 256 replicated
ceph osd pool set-quota tenant-x max_bytes 200T
ceph osd pool set tenant-x recovery_priority 5

The quota is the mechanism that makes the stated requirement enforceable rather than aspirational.

Modelling a step change

current:        420 TB used, 140 TB MAX AVAIL, +1.2 TB/day
new tenant:     200 TB initial, +0.5 TB/day, arriving 1 October

before 1 Oct:   140 TB / 1.2 = 117 days → exhaustion mid-December
after 1 Oct:    (140 − 200) TB → already exceeded

The model shows the tenant cannot be accommodated without expansion, and it shows this before the tenant arrives rather than during onboarding.

Onboarding that includes capacity

Step	Purpose
Capacity requirement gathered	the forecast can be updated
Forecast updated and reviewed	expansion triggered if needed
Quota set on the pool	the requirement is enforced
Growth monitored against the stated rate	drift is caught early
Review at 30 and 90 days	the estimate is corrected

ceph osd pool get-quota tenant-x
ceph df detail | grep tenant-x

The 30-day review is where most estimates are corrected, because workload owners routinely underestimate by a factor of two.

Quiz

Knowledge check · 4 questions

Q1. Why does a trend-based forecast miss a new tenant onboarding?

It extrapolates past data, and the tenant is a decision made elsewhere that has not yet touched the cluster Linear regression over a 14-day window is too coarse to resolve a change that happens inside a single week The scrape interval is longer than the onboarding window, so the step change is smoothed away before it reaches the series New tenants typically start small enough that their arrival stays inside the forecast's confidence band
Q2. A pool quota enforces a hard byte-level limit that cannot be exceeded.

True False
Q3. Onboard a new tenant onto an existing cluster.

A team wants to migrate 200 TB from an existing system onto the cluster over one weekend, then grow at 0.5 TB/day. The cluster has 140 TB of MAX AVAIL and is growing at 1.2 TB/day.
Q4. Why does the question "does the data arrive at once or ramp" matter?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Ask incoming workloads for initial size, growth rate, retention, and whether the data arrives at once or ramps; the last determines whether it is a capacity plan or also a throughput plan. Set a quota on every tenant pool sized to the stated requirement plus margin, so an underestimate surfaces as their limit rather than the cluster’s.

Cross-course references

Kubernetes: namespace ResourceQuotas serve exactly this enforcement role
Linux: per-user filesystem quotas make shared capacity estimates enforceable