Tenant isolation for RBD: pools and namespaces

Advanced⏱ ~17 mincephrbd

What you'll learn

Isolate RBD tenants with a pool per tenant
Isolate RBD tenants with namespaces in a shared pool
Weigh the PG and management cost of each
Choose the mechanism appropriate to tenant count

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

Both mechanisms produce a real, OSD-enforced boundary. They differ entirely in overhead, and choosing the wrong one for your tenant count either wastes a large fraction of your PG budget or gives you less operational separation than you needed.

Pool per tenant

ceph osd pool create tenant-a-rbd
ceph osd pool application enable tenant-a-rbd rbd
rbd pool init tenant-a-rbd

ceph auth get-or-create client.tenant-a \
    mon 'profile rbd' \
    osd 'profile rbd pool=tenant-a-rbd'

What this buys beyond access control:

Property	Available per pool
Separate `size` / `min_size`	yes
Separate CRUSH rule and device class	yes
Separate quota	yes
Separate snapshot policy	yes
Independent `ceph df` accounting	yes

The cost is PGs. Every pool needs a minimum PG allocation, and the cluster-wide budget is roughly 100 PGs per OSD. On a 100-OSD cluster — about 10,000 PGs — fifty tenant pools at 128 PGs each consumes 6,400 PGs before the shared pools get any, and per-OSD PG counts climb into the range where restart and memory costs become visible.

Namespace per tenant

rbd namespace create rbd-shared/tenant-a
rbd namespace ls rbd-shared

ceph auth get-or-create client.tenant-a \
    mon 'profile rbd' \
    osd 'profile rbd pool=rbd-shared namespace=tenant-a'

rbd create --size 100G --namespace tenant-a rbd-shared/vol1
rbd ls --namespace tenant-a rbd-shared

The access boundary is enforced identically — the OSD checks the namespace on every operation, exactly as it checks the pool. What you give up is everything in the table above: all tenants share the pool’s replication, CRUSH rule, and quota.

Choosing

Situation	Mechanism
Few tenants (under ~10), differing requirements	pool per tenant
Many tenants with identical requirements	namespaces
Tenants needing different durability or hardware	pool per tenant
Per-tenant capacity accounting required	pool per tenant
Tenant count expected to grow substantially	namespaces

A common and effective hybrid: pools by service tier — rbd-gold on NVMe at size 3, rbd-standard on HDD — with namespaces for tenants inside each. Tiers get their own properties; tenants get isolation without PG cost.

Quiz

Knowledge check · 4 questions

Q1. A platform expects to onboard 200 RBD tenants with identical storage requirements. Which isolation mechanism fits?

Namespaces within a shared pool, since 200 pools would consume most of the PG budget A pool per tenant, because only a pool boundary is enforced by the OSD on every operation A single shared credential, with the platform enforcing separation above RADOS One pool per ten tenants, so the PG budget and the boundary are both preserved
Q2. Billing tenants by consumption is on its own a reason to give each one a pool rather than a namespace.

True False
Q3. Design isolation for a mixed tenant population.

A service offers RBD to 60 internal teams. Five require NVMe-backed storage with size 3 and enforced quotas for billing; the other 55 use standard HDD storage with no individual quota requirement. The cluster has 140 OSDs.
Q4. Why do namespaces scale to arbitrary tenant counts while pools do not?

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

Production discipline

Choose the mechanism from whether the tenant needs pool-level properties, not from a general preference for stronger separation — both boundaries are enforced identically by the OSD. Where namespaces are used, be explicit that per-tenant capacity accounting is not available, so nobody plans a billing model around it.

Cross-course references

Kubernetes: namespaces versus separate clusters is the same overhead-versus-separation trade
Linux: per-user directories with quotas versus separate filesystems mirrors the choice