OpenStack Series: Part 6 – Cinder – Block Storage Service

Compute, Storage and Networking are the main building block of any cloud environment.

image source: http://regmedia.co.uk/2012/07/19/openstack_block_diagram.jpg

Types of Storage
Storage can be broadly categorize into three (3) types:

• Block Storage
• File Storage
• Object Storage

Click on the link if you want a more detailed description of each type of storage.

Cinder

Cinder was part of Nova (nova-volume) and was broken out to be a separate project in the Folsom release.  Cinder can be deployed standalone without other OpenStack services.

Cinder is similar to Amazon Web Services S3 (Simple Storage Service) offering in which it provide persistent block storage for the compute engine.

OpenStack wiki has this description for Cinder:
Cinder is a Block Storage service for OpenStack. It's designed to allow the use of either a reference implementation (LVM) to present storage resources to end users that can be consumed by the OpenStack Compute Project (Nova). The short description of Cinder is that it virtualizes pools of block storage devices and provides end users with a self service API to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device. 

As with other OpenStack services, self service API is used to interface with the Cinder service.  The main idea of Cinder is to provide an abstraction layer for the user against the block storage devices. User or consumer of Cinder does not need to know the details/management of the physical block storage devices.

Cinder Architecture

image source: http://varchitectthoughts.files.wordpress.com/2013/11/screen-shot-2013-11-18-at-11-00-24-am.png

Cinder-api

• A WSGI app that authenticates and routes requests throughout the Block Storage service
• Request is sent to the cinder-scheduler for dispatching to the appropriate cinder-volumes

Cinder-scheduler

• Based on the request dispatch the request to the appropriate Cinder Volume Service via the AMPQ (RabbitMQ or Qpid)
• Can be configured to use round-robin
• Filter Scheduler is the default mode- determines where to send the volume based on Capacity, Availability Zone, Volume Types, and Capabilities as well as custom filters

Cinder-volume

• Manages the different storage back-ends
• Interacts directly with the hardware or software that provides the block storage
• Provides the the view of a volume to the user

Cinder-backup

• Provides backup services of the Cinder volumes to OpenStack Swift

Cinder Components

Back-end Storage Devices

• Default is to use LVM (Logical Volume Manager) on a local volume group named "cinder-volumes"
• Also support for other devices such as external RAID arrays or storage appliances
• Block size is adjustable when using KVM or QEMU as the hypervisor

Users and Tenants/Projects

• Uses Role-based Access Control (RBAC) for multi-tenants.
• Uses "policy.json" to maintain the rule for each roles
• Volume access is per user
• Quotas to control resource consumption across available hardware resources are per tenant
• Quota can be used to control: number of volume and snapshots that can be created as well as the total number of GBs allowed per tenant (shared between volumes and snapshots).

Volumes, Snapshots and Backups 

Basic resources offered by the Block Storage service are volumes and snapshots 

• Volumes. Allocated block storage resources that can be attached to instances as secondary storage or they can be used as the root store to boot instances. Volumes are persistent R/W block storage devices most commonly attached to the compute node through iSCSI.   
• Snapshots. A read-only point in time copy of a volume. The snapshot can be created from a volume that is currently in use (through the use of --force True) or in an available state. The snapshot can then be used to create a new volume through create from snapshot.  
• Backups: An archived copy of a volume currently stored in OpenStack Object Storage

The physical storage for Cinder can be physical disk or SSD.  It can also be external storage systems offered by third party storage solutions such as NetApps or EMC.

Related Post:
OpenStack Series Part 1: How do you look at OpenStack?
OpenStack Series Part 2: What's new in the Juno Release?
OpenStack Series Part 3: Keystone - Identity Service
OpenStack Series Part 4: Nova - Compute Service
OpenStack Series Part 5: Glance - Image Service
OpenStack Series Part 7: Swift - Object Storage Service
OpenStack Series Part 8: Neutron - Networking Service
OpenStack Series Part 9: Horizon - a web based UI Service
OpenStack Series Part 10: Heat - Orchestration Service
OpenStack Series Part 11: Ceilometer - Monitoring and Metering Service
OpenStack Series Part 12: Trove - Database Service
OpenStack Series Part 13: Docker in OpenStack
OpenStack Series Part 14: Sahara - Data Processing Service
OpenStack Series part 15: Messaging and Queuing System in OpenStack
OpenStack Series Part 16: Ceph in OpenStack
OpenStack Series Part 17: Congress - Policy Service
OpenStack Series Part 18: Network Function Virtualization in OpenStack
OpenStack Series Part 19: Storage Polices for Object Storage
OpenStack Series Part 20: Group-based Policy for Neutron
Reference:
"Cinder." - OpenStack. N.p., n.d. Web. 06 Nov. 2014.