Ceph cluster sizing for licensing, raw against usable.

Red Hat Ceph Storage is sold as Red Hat Ceph Storage under a raw terabyte metric for the standalone subscription and as a node level entitlement under bundled variants. The raw terabyte count is the physical capacity attached to OSD daemons across the cluster. The node entitlement covers a fixed node footprint at a contract negotiated size and is more common where Ceph is bundled alongside OpenShift Data Foundation or OpenShift Plus1. The audit reads the cluster against whichever metric the contract names.

The raw terabyte count is straightforward to measure. The Ceph cluster reports total raw capacity through the ceph status command and through the cluster monitoring dashboard. The cluster reports the count regardless of whether the buyer subscribed for it. The audit can request a status snapshot and read the raw figure directly. The buyer who sized for one hundred terabytes raw and deployed one hundred and forty terabytes raw reads at forty terabytes over the contract.

The node level entitlement is more forgiving in the moment because the contract names the node count and the audit reads that count against the running node list. The forgiveness is procedural rather than financial: the bundle still has a maximum capacity per node, and a cluster that scales the per node capacity beyond the bundle envelope reads at audit as having exceeded the named bundle size2.

Ceph protects data by replication or by erasure coding. The default replication profile in production clusters is three way replication: every block is stored three times across separate OSDs. A three way replicated pool of one hundred terabytes usable consumes three hundred terabytes raw. The licensing count reads the raw figure, not the usable figure. A buyer who sized the contract against the application's usable requirement of one hundred terabytes and ordered one hundred terabytes raw is short by two hundred terabytes the moment the application fills its expected footprint.

Erasure coding changes the arithmetic but not the principle. A four plus two erasure coded pool stores six chunks for every four chunks of data, a one and a half times multiplier on raw. An eight plus three profile is closer to one point three eight times. The usable to raw ratio favours erasure coding for cold storage and replication for hot storage; production clusters often run a mixed profile across pools. The licensing line reads the aggregate raw across all pools, not the usable per pool3.

Two further capacity drains sit on top of replication. The mon, mgr, and metadata daemons consume capacity for cluster bookkeeping; this is small in percentage terms but real. The recovery reserve, the headroom Ceph holds back to absorb a failed OSD without filling, typically sits between fifteen and twenty percent of raw. A cluster that runs at ninety percent raw is at higher operational risk and is likely also reading near the contracted ceiling, which makes the audit posture worse simultaneously.

The first trap is sizing the contract against the application's usable figure and assuming Red Hat will read at usable. The contract reads at raw or at node count, depending on the variant. A buyer who quotes usable to the procurement function and signs raw against that quote ships a misaligned contract from the first day.

The second trap is changing the protection profile after the contract is signed. A cluster that began at four plus two erasure coding and migrated to three way replication for performance reasons doubles its raw consumption for the same usable footprint. The contract did not change. The audit reads the raw and the buyer reconciles the change at the next true up cycle. The mitigation is a profile change ticket that flows through the procurement function, not just the storage operations queue4.

The third trap is the OSD daemon count outside the planned node footprint. A buyer who runs Ceph on dense storage nodes scales raw capacity by adding disks to existing OSD hosts. The disk additions do not show up on a node count metric but they do show up on a raw terabyte metric. The buyer who scales by adding disks to existing nodes can quietly exceed the raw subscription envelope without ever changing the node count visible in routine inventory. The mitigation is a quarterly ceph status snapshot stored as evidence and reconciled against the contract raw line.

The sizing exercise begins with the workload, not with the bill of materials. The buyer's storage team profiles the application's data volume, the access pattern, the durability target, and the latency budget. The durability target chooses the protection profile, the access pattern chooses replication versus erasure coding, the latency budget chooses media tier. The output of the workload profile is a usable capacity per pool and a protection profile per pool. The raw capacity follows from the two through the multiplier table.

The procurement function should see the raw figure, the usable figure, and the protection profile in the same document. A bill of materials that quotes only the raw figure invites a procurement decision that does not understand the constraint. A bill of materials that quotes only the usable figure is a signed contract waiting for the audit reconciliation. The buyer who quotes both, with the protection profile explicit, signs a contract that reads cleanly against any future cluster snapshot5.

For the broader cross product reading, see the storage practice hub, the ODF versus raw Ceph read for the bundled variant detail, the OpenShift Data Foundation pricing read for the container storage stack, the Ceph Storage subscription read for the entitlement model, and the RHEL Resilient Storage add on read for the cluster file system alternative. For the engagement protocol, see subscription assessment and contact.

Ceph cluster sizing for licensing turns on raw capacity, the protection profile, and the daemon count that the audit reads against the contract. The buyer who sizes against the workload at the contract table pays the line once; the buyer who sizes against optimistic usable assumptions pays the line at signature and again at the next true up. The sizing exercise belongs in procurement, not in audit response.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.