90060722a9
This patch introduces a new directory layout in doc/source in conformance with the OpenStack manuals project migration spec [1], moves the existing content in manila/doc/source into the new directories, and adjusts index files accordingly. This is the first step in the migration process as outlined in the spec. [1] https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html Partial-Bug: #1706181 Needed-By: I7924d94b82e7c8d9716bad7a219fc38c57970773 Depends-On: Ifc80fc56648cef74c85464321d1850e8c68449a0 Depends-On: Ia750cb049c0f53a234ea70ce1f2bbbb7a2aa9454 Change-Id: Ieea33262101a1d2459492c1c8aaac5fe042279f6
3.1 KiB
3.1 KiB
Manila System Architecture
The Shared File Systems 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 )
|
|
|
[ Web Dashboard ]- manilaclient -[ manila-api ] -- < AMQP > -- [ manila-scheduler ] -- [ manila-share ] -- ( shared filesystem )
|
|
|
|
|
< REST >
- DB: sql database for data storage. Used by all components (LINKS NOT SHOWN)
- Web Dashboard: external component that talks to the api. Beta extended Horizon available here: https://github.com/NetApp/horizon/tree/manila
manila-api
- 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.
manila-scheduler
manila-share
Further Challenges
- More efficient share/snapshot size calculation
- Create a notion of "attached" shares with automation of mount operations
- Support for Nova-network as an alternative to Neutron
- Support for standalone operation (no dependency on Neutron/Nova-network)
- Allow admin-created share-servers and share-networks to be used by multiple tenants
- Support creation of new subnets for share servers (to connect VLANs with VXLAN/GRE/etc)
- Gateway mediated networking model with NFS-Ganesha
- Add support for more backends