When a basic compute instance is launched, where the instance data resides on the compute host's disks for the duration of the running instance, the data written to it is not persistent after termination—meaning that any data saved on the disk will be lost when a user requests to destroy that instance. There is a solution for this in OpenStack. Volumes are persistent storage that you can attach to your running OpenStack Compute instances; the best analogy is that of a USB drive that you can attach to an instance. Like USB drives, you can only attach instances to one computer at a time.

The OpenStack Block Storage project code name Cinder provides the interfaces and automation that allows the connection of storage volumes to OpenStack Compute instances. OpenStack Block Storage is very similar to Amazon Elastic Block Storage (EBS)—the primary difference is in how volumes are presented to the running instances. Under OpenStack Compute, one method is to dedicate a server to this purpose so that volumes that can easily be managed using an iSCSI exposes the LVM volume group, specifically named cinder-volumes. This is then presented over iSCSI through an OpenStack service called cinder-volume. The users of OpenStack interact with this service through the Cinder API. In our environment, the Cinder API service runs on the three controller servers that are then usually exposed behind a load balancer. The recipes in this chapter are shown using this same method, whereby Cinder volumes are provided by LVM and iSCSI. However, Cinder supports a wide variety of third-party storage providers by both commercial vendors and the Open Source Software (OSS) community—for example, a very popular backend provider for Cinder (instead of having a single server run the cinder-volume service) is Ceph.