This episode covers integrating Ceph as production storage: the unified storage concept with RBD for block, RGW for object, and CephFS for shared filesystem in a single cluster, integration with Glance, Cinder, and Nova, and sizing a cluster with a minimum of three nodes.

In episode 8, you met Cinder with LVM and Ceph backends. In episode 14, production deployment was orchestrated by Kolla-Ansible. Episode 16 brings the two together on the layer that most determines cluster reliability: storage. In production, OpenStack's answer for storage isn't three separate clusters — it's one: Ceph.
Episode 16 covers why Ceph has become the dominant choice, how it provides block, object, and filesystem from a single cluster (unified storage), how to integrate it with Glance, Cinder, and Nova on RBD, and the sizing and deployment principles for a minimum three-node cluster.
Ceph provides three storage services from the same single cluster:
Ceph Cluster (single RADOS pool)
├── RBD → Cinder, Glance, Nova (block)
├── RGW → Object storage S3 API (object)
└── CephFS → Manila shared filesystem (file)One infrastructure for three needs means one capacity to manage, one replication mechanism, and one team that understands it.
Ceph is designed to be distributed and self-healing: every piece of data is replicated to several OSDs, data is spread evenly (CRUSH algorithm), and when one OSD fails, the cluster automatically reconstructs replicas elsewhere without downtime. That's what makes Ceph and OpenStack the standard production pairing.
Putting Glance images on Ceph makes images directly available on all nodes — Nova doesn't need to download an image to local disk every time:
glance_backend_ceph: "yes"
glance_ceph_pool: "images"glance_ceph_pool: "images" points to the Ceph pool that stores images. With this, cloning an image into an instance disk is done by Ceph instantly — no large file transfers between nodes.
The primary Cinder backend in production is RBD:
openstack volume service list -f table
openstack volume type list -f value -c NameThe output of openstack volume service list shows the backend state. Cinder creates volumes as RBD images in the Ceph pool and attaches them to instances without iSCSI — the instance maps RBD directly through librbd.
Instances using Ceph no longer need a large local disk — the instance's ephemeral disk lives on RBD. Migrating instances between hosts becomes easy because the disk can be opened anywhere:
nova_ceph_pool: "vms"
nova_images_type: "rbd"
cinder_backend_ceph: "yes"
cinder_ceph_pool: "volumes"nova_images_type: "rbd" makes the instance's ephemeral disk live in the vms pool. Live migration and resizing between hosts run smoothly because there's no physical disk transfer.
A production Ceph cluster minimally consists of:
| Component | Role | Minimum Count |
|---|---|---|
| Monitor | Maintains the cluster map and health | 3 |
| Manager | Dashboard and telemetry | 2-3 |
| OSD | Stores the actual data | 3+ |
Verify cluster status from a Ceph node:
ceph -s
ceph osd treeThe output of ceph -s shows a cluster health summary — the HEALTH_OK column is the target. The ceph osd tree command shows each OSD and its state.
Ceph sizing rules of thumb:
Warning
Never run production Ceph without an odd number of monitors. Two monitors or fewer means the cluster loses quorum when one node fails, and all storage is affected.
Ceph can be deployed as part of the Kolla-Ansible stack itself:
enable_ceph: "yes" > /etc/kolla/globals.yml
kolla-ansible -i multinode deployWith enable_ceph: "yes", Kolla-Ansible deploys monitors, managers, and OSDs as containers, then configures Glance, Cinder, and Nova to use the RBD pools — integrating the entire storage layer in one deployment process.
Episode 16 brings production storage together in a single architecture: Ceph as unified storage providing RBD for block, RGW for object, and CephFS for shared filesystem in one cluster, integrated with Glance, Cinder, and Nova on RBD pools, plus a minimum three-node cluster of OSDs, monitors, and managers.
Key takeaways:
ceph -s should show HEALTH_OK.In episode 17, we'll cover Security Hardening, TLS & RBAC Policies — securing API endpoints with TLS and HAProxy SSL termination, separating internal and public APIs, customizing policy.yaml for granular RBAC, and protecting the metadata service and preventing spoofing with port security.