Skip to content

architecture.rst

Latest commit

 

History

History
102 lines (79 loc) · 3.96 KB

architecture.rst

File metadata and controls

102 lines (79 loc) · 3.96 KB
Raw

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 :doc:`api_microversion_dev`.
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 :doc:`drivers` and :doc:`new_driver_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.

Related documents

  • :doc:`repo-overview` for a repository layout map.
  • :doc:`rpc` for service communication concepts.
  • :doc:`threading` for Cinder's eventlet and green-thread model.
  • :doc:`api_conditional_updates` for race-safe database state updates.
  • :doc:`attach_detach_conventions` and :doc:`attach_detach_conventions_v2` for attachment flows.
  • :doc:`rolling.upgrades` for upgrade compatibility requirements.
  • :doc:`database-migrations` for schema and migration guidance.