Learn OpenStack - Cinder (Block Storage Service) & Persistent Volumes

#Introduction

Up to episode 7, all of your instance data was stored on ephemeral disks — disks that disappear when the instance is deleted. In the cloud world, that's not enough. Databases, applications, and user data need storage that survives the instance lifecycle. That's the job of Cinder, OpenStack's Block Storage Service.

Episode 8 covers Cinder from concept to practice: what volumes are and why they're persistent, how to create and attach volumes to instances, detaching and moving volumes between instances, snapshots and backups for recovery, and the strategy for choosing a backend driver according to lab or production needs.

#The Block Storage Concept in the Cloud

#Volumes as Virtual Hard Disks

A volume is block-formatted storage presented to an instance like an external hard disk — inside the instance it appears as a device such as /dev/vdb. A volume's key characteristics:

• Persistent: data survives even if the instance is deleted.
• Portable: it can be detached from one instance and attached to another.
• Scalable: it can be grown as needed without recreating.

Cinder Volume (backend: LVM/Ceph)
        ↓  attach via virtio-scsi / iSCSI / RBD
Instance → /dev/vdb → mount /data

Think of a volume as a disk that can be moved from one computer to another — the data inside moves with it. That's what makes volumes the foundation for databases and stateful applications in the cloud.

#When to Use Volumes

The practical rule is simple: if the data is important and must survive an instance's lifecycle, store it on a volume. If the instance is temporary and can be rebuilt from an image, leave it on the ephemeral disk. Combining both is the most common pattern in production.

#Cinder Volume Operations

#Creating a Volume

openstack volume create --size 50 --name my-volume
openstack volume list

openstack volume create --size 50 asks Cinder to allocate 50 GB from the backend. The volume status changes from creating to available when it's ready. Watch the Attached to column — when it's empty, the volume isn't attached to any instance yet.

#Attaching a Volume to an Instance

openstack server add volume my-server my-volume
openstack volume show my-volume -c attachments

After openstack server add volume my-server my-volume, you can format and mount it inside the instance:

sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /data
sudo mount /dev/vdb /data

The pattern above uses the volume as separate data storage. To make the mount survive a reboot, add an entry to /etc/fstab inside the instance.

#Detaching and Moving Volumes

A volume can be detached from a running instance:

openstack server remove volume my-server my-volume

An available volume can then be attached to another instance — exactly like moving a physical hard disk between servers:

openstack server add volume my-server-2 my-volume

openstack server remove volume performs a safe detach. Make sure the data is unmounted inside the instance before detaching, so no data gets corrupted.

#Volume Snapshots & Backups

#Snapshots for Point-in-Time Recovery

A snapshot is a point-in-time copy of a volume. It serves two purposes: recovery when data is corrupted, and cloning when you need a duplicate volume.

openstack volume snapshot create --volume my-volume my-volume-snap
openstack volume create --snapshot my-volume-snap --size 50 my-volume-restore

openstack volume snapshot create records the volume's state at that moment. For recovery, simply create a new volume from the snapshot — the data returns to the state when the snapshot was taken. In DevStack, the LVM backend uses thin provisioning, so snapshots are fast and space-efficient.

#Backup vs Snapshot

It's important to distinguish the two:

A Cinder backup (openstack volume backup create) stores data on a separate backend such as Swift or Object Storage — protecting against failures of the primary backend, for example physical LVM disk damage. They complement each other; they don't replace each other.

#Cinder Backend Drivers

#Choosing the Right Backend

Cinder doesn't store data itself — it orchestrates the storage backends behind it. The backend choice determines performance, features, and scale:

• LVM (iSCSI): the DevStack lab default, lightweight and easy, great for learning.
• Ceph RBD: the primary production choice — distributed, no SPOF, integrated with Glance and Nova.
• NFS: leverages an existing fileserver.
• Vendor SAN (Dell, NetApp, HPE): for organizations that already have enterprise storage arrays.

openstack volume service list

The output of openstack volume service list shows the status of Cinder backends. The State column must be up and the Binary column should show cinder-volume. We'll dissect Ceph RBD integration in depth in episode 16.

#Summary

Episode 8 gives you full control over persistent storage: understanding volumes as persistent, portable virtual hard disks, creating and attaching volumes, detaching and moving them between instances, snapshots for recovery and cloning, backups for long-term protection, and choosing a backend from LVM to Ceph RBD.

Key takeaways:

• Volumes are persistent and portable, not tied to an instance's lifecycle.
• openstack volume create then openstack server add volume is the basic flow.
• Safe detach: unmount inside the instance first, then detach.
• Snapshots for quick recovery and cloning; backups for long-term protection.
• LVM for the lab, Ceph RBD for production.
• Important data always belongs on volumes, not ephemeral disks.

In episode 9, we'll cover Swift (Object Storage Service) — scalable storage for unstructured data, its comparison with block storage and shared filesystems, Swift's proxy and storage server architecture, and operations for creating containers, uploading objects, and accessing them via REST API and temporary URLs.