A blog to share security, networking and cloud related technology information as @vCloudernBeer picked up on his search for his destiny in the cloud. (LinkedIn: https://www.linkedin.com/in/chowanthony)

Thursday, November 6, 2014

OpenStack Series: Part 6 – Cinder – Block Storage Service

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

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-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.