openstack/cinder
Code Issues Proposed changes
6c46c0c3fe
cinder/doc/source/contributor/architecture.rst
Sean McGinnis d5b539be36
Doc8: Stop skipping D001: Line too long 
This cleans up the cases where we had D001 violations so we can stop
skipping that check in doc8 runs.

Change-Id: Ie52f6ecac1a645fcbcc643b9ca63e033b622d830
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
2019-02-19 16:51:56 -06:00

2.7 KiB
Raw Blame History

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.

/- ( LDAP )
[ Auth Manager ] ---
|            \- ( DB )
|
|
cinderclient     |
/             \   |                   /- [ scheduler ] -- [ volume ] -- ( iSCSI )
[ Web Dashboard ]-               -[ api ] -- < AMQP > --
\             /   |                   \- [ backup ]
novaclient       |
|
|
|
< REST >
  • 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.