Cinder System Architecture

The Cinder Block Storage service provides persistent block storage for OpenStack clouds. A deployment is composed of several cooperating services that share a database and communicate through RPC.

Cinder uses a SQL-based central database that is shared by all Cinder services in the system. Services use the database for durable resource state and use RPC to coordinate work that must be performed by another service.

Components

Below you will find a brief explanation of the different components.

Cinder architecture
DB

SQL database for durable resource state. It is used by all Cinder services, though not every relationship is shown in the diagram.

API

The cinder-api service receives HTTP requests, validates input, applies policy, records initial state, and coordinates work with other Cinder services. API contract changes may require a new microversion; see API Microversions.

Scheduler

The cinder-scheduler service selects a suitable backend for operations such as volume creation. It considers backend capabilities, filters, and weighers.

Volume

The cinder-volume service manages volumes on storage backends through Cinder volume drivers. Driver changes should follow Drivers and New Driver Review Checklist.

Backup

The cinder-backup service manages volume backups independently from volume drivers. Backup drivers provide access to backup repositories.

Dashboard and clients

Horizon, command-line clients, SDKs, and other services call the Cinder API. These are external to the Cinder service deployment.

Auth

Authentication and authorization are integrated with Keystone and Cinder policy. Policy definitions live under cinder/policies/.

Service interaction example

A typical volume creation request crosses several services:

  1. A user or service sends a volume create request to cinder-api.

  2. The API service validates the request, applies policy, and creates an initial database record.

  3. The API service asks cinder-scheduler to choose a backend.

  4. The scheduler evaluates backend state and sends the request to a selected cinder-volume service.

  5. The volume service calls the storage backend through the configured driver.

  6. The volume service updates the database with the final volume state.

This example is intentionally simplified. Many operations also involve quotas, conditional database updates, versioned objects, attachment records, or rolling upgrade compatibility constraints. See the focused contributor documents for those topics.