Cinder System Architecture

Cinder System Architecture

The Cinder Block Storage Service is intended to be ran on one or more nodes.

Cinder uses a sql-based central database that is shared by all Cinder services in the system. The amount and depth of the data fits into a sql database quite well. For small deployments this seems like an optimal solution. For larger deployments, and especially if security is a concern, cinder will be moving towards multiple data stores with some kind of aggregation system.

Components

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

Cinder architecture
  • DB: sql database for data storage. Used by all components (LINKS NOT SHOWN).

  • Web Dashboard: potential external component that talks to the api.

  • api: component that receives http requests, converts commands and communicates with other components via the queue or http.

  • Auth Manager: component responsible for users/projects/and roles. Can backend to DB or LDAP. This is not a separate binary, but rather a python class that is used by most components in the system.

  • scheduler: decides which host gets each volume.

  • volume: manages dynamically attachable block devices.

  • backup: manages backups of block storage devices.

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.