OpenStack Cloud Storage Services: First Look at Folsom’s Cinder project

Introduction

After the April Essex release, there’s big change in planned for OpenStack‘s volume management; it is now called Cinder.

Cinder is a new service for OpenStack, one that separates storage management logic. Until now, in the Essex release, this logic was a part of Nova, and was called the nova-volume component. But, as often happen in software, logical interdependencies between components within Nova became more and more complex, so the project developers decided to make storage management logic separate from Nova and create Cinder.

In fact, this is one of the first instances  of OpenStack’s recent development policy of breaking all Nova components into smaller building blocks. Nova had become a bulky piece of software;  development in one area was too often contingent on knowledge of others. By decoupling Nova into smaller chunks and interfacing them, developers can focus on developing these chunks as long as they provide the proper API for other services to plug in. This allows a better focus on different areas of OpenStack.

OpenStack Cinder: feature list

For Cinder, the separation from Nova is mainly organizational in nature—the project is now literally a copy-paste version of old nova-volume code with a separate database. The main goal for Cinder in the Folsom release is to provide the same API and features as in the current nova-volume, plus prepare for further focused work on the topic  in future releases.

The bottom line is: in Folsom we are just getting our old buddy nova-volume; at the same time, the developers managed to put some cool new features in this release and also lay some groundwork for the future:

• “volumes from images” — this feature is addressed in the following two blueprints accepted for Folsom: creating volumes from images and efficient volumes from images. This feature allows for the creation of bootable volumes directly from glance images and is further used by the “boot from volume” feature of Nova.
• Still TBD:  “multi volume backend”, which will allow users to take advantage of different storage providers with a single installation of Cinder. It is addressed in this blueprint and is still undergoing code review.

One of the Cinder project’s main roles is serving as the abstraction layer for different storage devices. Currently the following list of storage backends is supported, directly through their respective native APIs:

• IBM Storwize V7000 unified storage system
• IBM XIV Storage System series
• NetApp onTap devices. Both the volume as a block device and the volume as a file on NFS are supported.
• SheepDog storage system
• SolidFire high performance SSD storages
• NexentaStor Appliance

Cinder structure

Cinder consists of three basic services—Cinder API, Cinder scheduler, and Cinder volume, plus the underlying dedicated database.

Cinder API is a web service (providing a RESTful interface) responsible for handling user requests. In an OpenStack cluster, there can be many hosts that run the Cinder volume component. In order to load-balance volume creation between Cinder volumes, there is a Cinder scheduler component that implements this logic. The Cinder volume service is basically an abstraction layer to the different storage backends listed above.

Connection with the old nova-volume API

Despite migrating volume functionality to the separate project, Nova still supports volume management as originally implemented in the nova-volume component. Which approach to use is up to you when you install, but keep in mind that the plan is to completely remove volume management from Nova. By default Nova will use nova-volume, but it can be easily switched to Cinder by setting a flag:

The user is free to use the old, familiar “nova volume-*” commands, or can switch to the brand new “python-cinderclient.” These commands provide exactly the same behavior:

Final observations

In sum, Cinder offers stability with respect to nova-volume features, but simplifies code maintainability. While that may be a disappointment to some who expect constant activity in new features, it’s really an important sign of maturity, as it opens the code base to broader innovation with greater depth in storage functionality.

Stay tuned for our upcoming post which will deal with high availability of API services in Openstack.