openstack/manila
Code Issues Proposed changes
d2a022d64d
manila/doc/source/devref/architecture.rst
Ben Swartzlander 93718f2a30 Update challenges in the developer docs 
Based on work during Juno and plans for Kilo, update
the developer reference with very high level bullet
points.

Change-Id: Ibd05eeb72870249cccf7518f142ad170b45b6b59
2014-09-23 16:01:28 -04:00

3.2 KiB
Raw Blame History

Manila System Architecture

The Manila Shared Filesystem Management 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 -[ api ] -- < AMQP > -- [ scheduler ] -- [ 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
  • 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 will handle create share request.
  • share: manages shared filesystems.

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