Cinder Documentation

WHAT IS CINDER?

Cinder is the OpenStack Block Storage service for providing volumes to Nova virtual machines, Ironic bare metal hosts, containers and more. Some of the goals of Cinder are to be/have:

• 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

FOR END USERS

As an end user of Cinder, youll use Cinder to create and manage volumes using the Horizon user interface, command line tools such as the python-cinderclient, or by directly using the REST API.

Tools for using Cinder 

• Horizon: The official web UI for the OpenStack Project.
• OpenStack Client: The official CLI for OpenStack Projects. You should use this as your CLI for most things, it includes not just nova commands but also commands for most of the projects in OpenStack.
• Cinder Client: The openstack CLI is recommended, but there are some advanced features and administrative commands that are not yet available there. For CLI access to these commands, the cinder CLI can be used instead.

Using the Cinder API

All features of Cinder are exposed via a REST API that can be used to build more complicated logic or automation with Cinder. This can be consumed directly or via various SDKs. The following resources can help you get started consuming the API directly.

• Cinder API
• Cinder microversion history

FOR OPERATORS

This section has details for deploying and maintaining Cinder services.

Installing Cinder

Cinder can be configured standalone using the configuration setting auth_strategy = noauth, but in most cases you will want to at least have the Keystone Identity service and other OpenStack services installed.

Cinder Installation Guide

The Block Storage service (cinder) provides block storage devices to guest instances. The method in which the storage is provisioned and consumed is determined by the Block Storage driver, or drivers in the case of a multi-backend configuration. There are a variety of drivers that are available: NAS/SAN, NFS, iSCSI, Ceph, and more. The Block Storage API and scheduler services typically run on the controller nodes. Depending upon the drivers used, the volume service can run on controller nodes, compute nodes, or standalone storage nodes. For more information, see the Configuration Reference.

Prerequisites

This documentation specifically covers the installation of the Cinder Block Storage service. Before fol- lowing this guide you will need to prepare your OpenStack environment using the instructions in the OpenStack Installation Guide.

Once able to Launch an instance in your OpenStack environment follow the instructions below to add Cinder to the base environment.

Adding Cinder to your OpenStack Environment

The following links describe how to install the Cinder Block Storage Service:

Cinder Block Storage service overview

The OpenStack Block Storage service (Cinder) adds persistent storage to a virtual machine. Block Storage provides an infrastructure for managing volumes, and interacts with OpenStack Compute to provide volumes for instances. The service also enables management of volume snapshots, and volume types. The Block Storage service consists of the following components:

cinder-api Accepts API requests, and routes them to the cinder-volume for action.

cinder-volume Interacts directly with the Block Storage service, and processes such as the cinder-scheduler. It also interacts with these processes through a message queue. The cinder-volume service responds to read and write requests sent to the Block Storage service to maintain state. It can interact with a variety of storage providers through a driver architecture.

cinder-scheduler daemon Selects the optimal storage provider node on which to create the volume. A similar component to the nova-scheduler.

cinder-backup daemon The cinder-backup service provides backing up volumes of any type to a backup storage provider. Like the cinder-volume service, it can interact with a variety of storage providers through a driver architecture.