Cinder

What is Cinder in cloud hosting?

Cinder is the block storage service in OpenStack. It provides persistent storage volumes that you can attach to instances (virtual machines) to store data that survives instance reboots, shutdowns, and even termination.

When you need storage that behaves like a physical hard drive attached to your server, Cinder creates and manages these volumes for you. The volumes exist independently of any instance, which means you can detach a volume from one instance and attach it to another without losing your data.

Related Terms

• Volume: A unit of block storage that Cinder creates, such as a 100GB disk you attach to an instance for database files.
• Instance: A virtual machine that Cinder volumes attach to, such as a web server that needs persistent storage for uploaded files.
• Image: A template used to boot instances, such as an Ubuntu or CentOS base that Cinder volumes supplement with additional storage.
• Snapshot: A point-in-time copy of a volume that Cinder creates, such as a backup taken before a major application upgrade.

Why Cinder Exists

Without Cinder, instances would only have ephemeral storage that disappears when the instance is deleted. This creates several problems.

First, any data stored on the instance root disk vanishes when you terminate or rebuild the instance. Database files, application logs, and user uploads would all be lost.

Second, you would have no way to resize storage independently of compute resources. If you needed more disk space, you would have to migrate to a larger instance even if you did not need more CPU or RAM.

Third, moving data between instances would require manual copying through network transfers. You could not simply detach a disk from one server and plug it into another.

Cinder solves these problems by separating storage from compute. Volumes persist independently, can be resized, and can be moved between instances as needed.

What Does Cinder Actually Do?

• Creates block storage volumes of specified sizes that appear as raw disk devices to instances.
• Attaches volumes to running instances so they appear as additional disks (such as /dev/vdb on Linux).
• Detaches volumes from instances without data loss, allowing the volume to be reattached elsewhere.
• Creates snapshots of volumes for backup purposes or to create new volumes from an existing state.
• Manages different storage backends such as iSCSI targets, Ceph RBD, NFS shares, and vendor-specific arrays.
• Extends volume sizes while preserving existing data, though this may require filesystem expansion within the instance.
• Encrypts volumes at rest using configurable encryption keys for data security.

When Would I Use Cinder?

Use Cinder when you need storage that outlives your instance lifecycle. Databases are the most common use case. MySQL, PostgreSQL, and MongoDB all store data in files that must survive instance replacement.

Use Cinder when you need to scale storage separately from compute. A file server might need 2TB of storage but only 2 vCPUs. Without block storage, you would pay for compute resources you do not need.

Use Cinder when you need to move data between instances. If you rebuild a web server with a new operating system, you can detach its data volume, terminate the old instance, launch a new one, and reattach the same volume.

Use Cinder when you need point-in-time backups. Taking a snapshot before a risky deployment gives you a restore point if something goes wrong.

When Would I NOT Use Cinder?

Do not use Cinder for data that should be shared simultaneously across multiple instances. Block storage volumes typically attach to one instance at a time. If multiple servers need to read and write the same files, use object storage or a shared filesystem instead.

Do not use Cinder for static assets that need web delivery. Images, videos, and downloadable files served to many users work better in object storage, which includes built-in HTTP access.

Do not use Cinder if your application is stateless and stores nothing on disk. A containerized microservice that processes data and writes results to a database does not need block storage attached.

Do not over-provision Cinder volumes "just in case." You pay for allocated space whether you use it or not. Start with what you need and expand later.

Real-World Example

Company A runs an e-commerce platform on OpenStack. They deploy their application across multiple instances for redundancy, but all instances connect to a single PostgreSQL database server.

The database instance has a 500GB Cinder volume attached at /dev/vdb, mounted as /var/lib/postgresql. The database files reside on this volume.

Before each major deployment, Company A takes a Cinder snapshot of the database volume. This gives them a restore point that takes seconds to create.

When the database needs more space, Company A extends the Cinder volume from 500GB to 750GB without stopping PostgreSQL. They then expand the filesystem inside the instance to use the new space.

When they need to upgrade the database server operating system, they detach the data volume, terminate the old instance, launch a new instance with the updated OS, attach the same volume, and start PostgreSQL. The database files remain intact throughout this process.

Frequently Asked Questions

Can I attach one Cinder volume to multiple instances?

Standard Cinder volumes attach to one instance at a time. If you need shared storage, look at multi-attach volumes (requires specific backend support) or use a shared filesystem service instead of block storage.

What happens if I delete an instance with an attached volume?

By default, volumes persist when instances are deleted. The volume detaches automatically and remains available for attachment to another instance. You can configure volumes to delete with their instance if you prefer.

How do I resize a Cinder volume?

You can extend a volume through the API or Horizon dashboard. The volume size increases, but you must also expand the filesystem inside the instance to use the new space. Shrinking volumes is generally not supported.

What storage backends does Cinder support?

Cinder supports many backends including LVM over iSCSI, Ceph RBD, NFS shares, and enterprise storage arrays from vendors like NetApp, Pure Storage, and Dell EMC. Your cloud provider determines which backends are available.

How do Cinder snapshots differ from full backups?

Snapshots are fast point-in-time references that often share data blocks with the original volume, making them quick to create. Full backups copy all data to separate storage, taking longer but providing independent copies. Use snapshots for quick restore points and backups for disaster recovery.

Summary

• Cinder is the OpenStack block storage service that creates and manages persistent volumes.
• Volumes attach to instances as raw disk devices and persist independently of instance lifecycle.
• Cinder enables separate scaling of storage and compute resources, volume mobility between instances, and point-in-time snapshots.
• Use Cinder for databases, application data, and any storage that must survive instance changes.
• Different storage backends (iSCSI, Ceph, NFS) can power Cinder, determined by your cloud provider configuration.