2.5 KiB
2.5 KiB
Manila System Architecture ========================
The Manila Block Storage Service is intended to be ran on one or more nodes.
Manila uses a sql-based central database that is shared by all Manila 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, manila 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 )
|
|
manilaclient |
/ \ |
[ 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.