WavebreakmediaMicro - Fotolia
OpenStack Cinder: Block storage on the open-source cloud platform
OpenStack Cinder 101: The fundamentals of Cinder, how it is implemented, how to provision it, how it works with third-party storage arrays, its features and more
The OpenStack platform is an open-source collaboration to develop a private cloud ecosystem, delivering IT services at web scale.
OpenStack is divided into a number of discrete projects, each with a code name with parallels to the purpose of the project itself.
Virtual machines – or compute – are delivered through a project called Nova. In early OpenStack implementations, Nova virtual machines were stateless, that is they were not kept on persistent storage, and a Nova virtual machine would lose its contents when it was shut down.
As Nova developed, a feature called nova-volume was introduced to store virtual machines on persistent media, similar to the way Amazon Web Services Elastic Cloud Compute (EC2) stores instances on persistent media known as Elastic Block Store (EBS). The nova-volume feature was eventually superceded by a separate project called Cinder that delivers persistent block-level storage to OpenStack environments.
How Cinder works
Cinder performs a number of operations in OpenStack environments. In the first instance it acts as a piece of middleware, providing application programming interfaces (APIs) that allow Cinder volumes to be created through use of the Cinder client software. A single Cinder volume is associated with a single Nova compute instance or virtual machine. Cinder keeps track of the volumes in use within OpenStack using a MySQL database created on the Cinder services controller.
Through the use of a common interface and APIs, Cinder abstracts the process of creating and attaching volumes to Nova compute instances. This means storage can be provided to OpenStack environments through a variety of methods.
By default, Cinder volumes are created on a standard Linux server that runs Logical Volume Manager (LVM). This allows physical disks to be combined to implement redundant array of independent disks (Raid) data protection and to carve out logical volumes from a physical pool of space, called a volume group. Cinder volumes are created from a volume group called cinder-volumes, with the OpenStack administrator assigned the task of deciding exactly how this LVM group is mapped onto physical disk.
Cinder and external storage
Cinder can also manage external storage resources, either from a physical external storage array or from software-based storage implementations. This is achieved through the use of a Cinder driver that maps Cinder requests to the commands required on the external storage platform – in fact, the default LVM implementation is simply another Cinder driver. Support is available for iSCSI and Fibre Channel protocols, with specific support based on the capabilities of the supplier’s storage hardware (see the support matrix described later).
Storage suppliers have been quick to provide Cinder support for their platforms, enabling a wide range of storage hardware to be used in OpenStack deployments. Depending on the specific implementation, the driver allows OpenStack to automate the process of creating volumes and assigning them to Nova virtual machines.
Some hardware platforms require storage administrators to create a pool – or pools – of storage for OpenStack to use – traditional arrays that use pools of RAID groups, for example.
A list of supported platforms is available but this isn’t exhaustive and many suppliers are not mentioned. You should check with your storage supplier for specific information on Cinder support and the features their drivers offer.
The use of external storage for OpenStack provides the ability to take advantage of native features on the storage platform where available, such as data deduplication, compression, thin provisioning and quality of service.
External storage isn’t limited to physical hardware appliances; block storage can be assigned to OpenStack from a variety of software-based systems, both commercial and open-source. This includes Ceph and GlusterFS. Ceph, for example, is implemented through the use of Rados Block Device (RBD), a device driver in the Linux kernel that talks natively with a Ceph storage cluster.
OpenStack Cinder features
With each successive release of OpenStack (the most recent being Kilo – versions are named after successive letters of the alphabet), new features have been added to Cinder. Some of these have been implemented through a second version of the Cinder API, as version one didn’t have support for the newer features.
Version one and two APIs provide commands to create, update, delete and extend volumes, as well as attach and detach them to instances – Nova virtual machines. Volumes can be assigned volume types, allowing them to be matched to a specific storage provider, where an OpenStack deployment takes storage from multiple providers. Alternatively, volume types can be used to differentiate between different classes of storage, based on, for example, physical characteristics such as RAID protection or performance.
Read more about OpenStack storage
- OpenStack Manila is the file level access method in development by the open source cloud platform. What is it, how does it work and when will it be ready?
- VMware vs OpenStack: The opportunities and challenges presented by the two virtualisation environments when it comes to storage, backup and disaster recovery
Cinder provides the ability to take snapshots of Nova instances. For external storage platforms this is achieved by using the native snapshot process of the underlying storage platform. The Juno release of OpenStack introduced the ability to group Cinder volumes into a consistency group, allowing all the volumes to be taken as a single snapshot. To date, only a few suppliers support this functionality.
Cinder also supports the ability to take Nova instance backups. Unfortunately, this process is limited to using an object store as the backup target, with restores that require restoration of the entire volume. This may prove limiting in many circumstances and is one reason why Manila – the OpenStack file services project – could provide a more appropriate way to manage application data.
Cinder in OpenStack distributions
OpenStack distributions are available from a wide range of suppliers – well over 20 at last count. Each supplier provides support for a specific release of OpenStack and for each of the core OpenStack components. Cinder is a core component and ships with each distribution. The OpenStack marketplace provides a list of suppliers and their offerings. This also lists each of the projects and their supported levels as well as the supported level of the APIs. Today almost all suppliers support the version two API for Cinder.
Cinder provides great flexibility to add storage to OpenStack environments, whether through native LVM support or via an external appliance or software. However, as with all components of OpenStack, Cinder requires time and effort to understand and configure correctly. This is especially true for the process of fault diagnosis, such as volumes getting out of sync in the Cinder database.
In addition, users should remember that Cinder drivers could be removed as well as added to new OpenStack distributions if suppliers don’t meet the specifications or requirements set by the OpenStack project. This could cause problems for future upgrades and so it is always worthwhile checking the commitment of your storage supplier to supporting Cinder features and future OpenStack releases.