CINDER : Block storage as a service

What is meant by a block storage?

In block level storage each block acts as an individual hard drive and is configured by the storage administrator. These blocks are controlled by the server-based operating system, and are generally accessed by Fibre Channel (FC), Fibre Channel over Ethernet (FCoE) or iSCSI protocols.

Since the volumes are treated as individual hard disks, block storage works well for storing a variety of applications such as file systems and databases. They also tend to be more flexible and provide better performance. But it tend to be more complex and expensive than file storage,

Types of Storage in OpenStack, and example use cases

What is Cinder?

Cloud instances are typically created with at least one ephemeral disk which is used to run the VM guest operating system and boot partition, an ephemeral disk is purged and deleted when an instance is terminated.  Swift was included as one of original OpenStack projects to provide durable, scale-out object storage.  Initially, block services was created as a component of Nova Compute, called Nova Volumes; that has since been broken out as its own project called Cinder.

Cinder provides instances with block storage volumes that persist even when the instances they are attached to are terminated. A single block volume can only be attached to a single instance at any one time but provides the flexibility to be detached from one instance and attached to another instance. The best analogy to this is of a USB drive which can be attached to one machine and moved to a second machine with any data on that drive staying intact across multiple machines. An instance can attach multiple block volumes.So in brief cinder is a persistent block level storage device for use with OpenStack compute instances. It manages the creation, attachment and detachment of block devices to servers. and its provides unified storage support for numerous other storage platforms, including Ceph, NetApp, Nexenta, SolidFire and Zadara. And It provides snapshot management functionality for backing up data stored on block storage volumes that can be restored or used to create new block storage volumes

Features and Use cases

Component based architecture: Quickly add new behaviors
Highly available: Scale to very serious workloads
Fault-Tolerant: Isolated processes avoid cascading failures
Recoverable: Failures should be easy to diagnose, debug, and rectify
Open Standards: Be a reference implementation for a community-driven api

In a Cloud platform such as OpenStack, persistent block storage has several potential use cases:

1. If for some reason you need to terminate and relaunch an instance, you can keep any “non-disposable” data on Cinder volumes and re-attached them to the new instance.
2. If an instance misbehaves or “crashes” unexpectedly, you can launch a new instance and attach Cinder volumes to that new instance with data intact.
3. If a compute node crashes, you can launch new instances on surviving compute nodes and attach Cinder volumes to those new instances with data intact.
4. Using a dedicated storage node or storage subsystem to host Cinder volumes, capacity can be provided that is greater than what is available via the direct-attached storage in the compute nodes (Note that is also true if using NFS with shared storage but without data persistence).
5. A Cinder volume can be used as the boot disk for a Cloud instance; in that scenario, an ephemeral disk is not required.

Whats inside Cinder?

Components

Cinder-api is an WSGI application that accepts and validates REST (JSON or XML) requests from clients and routes them to other Cinder processes as appropriate over AMQP.

Cinder-scheduler determines which backend should serve as the destination for a volume creation or movement request. It maintains non-persistent state for backends (e.g. available capacity, capabilities, and supported extra specs) that can be leveraged when making placement decisions. The algorithm utilized by the scheduler can be changed through cinder configuration.

Cinder-volume accepts requests from other Cinder processes and serves as the operational container for Cinder drivers. This process is multi-threaded and typically has one thread of execution per Cinder backend as defined in the Cinder configuration file.

Cinder-backup handles the interaction with potential backup targets (e.g. OpenStack Object Storage Service (Swift)) when a client requests a volume backup to be created or managed.

Cinder Architecture

How Cinder Works ?

Cinder comes into play in two scenarios one is while creating or deleting a volume and the other one is attaching a volume to an instance. Lets consider the first case. There are total 9 steps to fulfill that.

Cinder Workflow – Volume Creation

1. Client issues request to create volume through invoking REST API (client may use python- cinderclient CLI utility).
2. Cinder-api process validates request, user credentials; once validated, puts message onto AMQP queue for processing.
3. cinder-volume process takes message off of queue, sends message to cinder-scheduler to determine which backend to provision volume into.
4. Cinder-scheduler process takes message off of queue, generates candidate list based on current state and requested volume criteria (size, availability zone, volume type (including extra specs)).
5. Cinder-volume process reads response message from cinder-scheduler from queue; iterates through candidate list by invoking backend driver methods until successful.
6. Cinder/3rd Party driver creates requested volume through interactions with storage subsystem (dependent on configuration and protocol).
7. Cinder-volume process collects volume metadata and connection information and posts response message to AMQP queue
8. Cinder-api process reads response message from queue and responds to client.
9. Client receives information including status of creation request, volume UUID, etc.

Cinder & Nova Workflow – Volume Attach

1. Client issues request to attach volume through invoking Nova REST API (client may use python-novaclient CLI utility).
2. nova-api process validates request, user credentials; once validated, invokes Cinder API to get connection information for specified volume.
3. cinder-api process validates request, user credentials; once validated, posts message to volume manager over AMQP.
4. cinder-volume reads message from queue, invokes Cinder driver corresponding to volume to be attached.
5. Cinder driver prepares Cinder volume in preparation for attachment (specific steps dependent on storage
   protocol used).
6. cinder-volume process posts response information to cinder-api process via AMQP queue.
7. cinder-api process reads response message from cinder-volume from queue; passes connection information in RESTful response to Nova caller.
8. Nova creates the connection to the storage with the returned information from Cinder.
9. Nova passes the volume device/file to the hypervisor, who then attaches the volume device/file to the guest VM as an actual or virtualized block device (dependent on storage protocol)

Posted January 12, 2016 by bipin