John Griffith 922fdd0bdc Update dev docs

* Quick pass at implementing the basics for cinder dev docs
  * Remove the N/A compute related stuff
  * Clean up the architecture a bit to only show cinder related
  * Remove various modules form TOC's that aren't applicable

Change-Id: I0089c388524c9def7494658e836f4ed03a61f5b5

2012-09-03 17:18:10 -06:00

2.5 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 a brief explanation of the different components.

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

2.5 KiB Raw Blame History

Components

2.5 KiB

Raw Blame History