Jump to: navigation, search

Manila/Networking/Gateway mediated

< Manila‎ | Networking
Revision as of 19:52, 4 December 2013 by Ramana Raja (talk | contribs) (Created page with "=== Hypervisor mediated storage access for NFS shares === This is one of the approaches to achieve multi-tenancy in Manila, where the decision to access a share is made in th...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Hypervisor mediated storage access for NFS shares

This is one of the approaches to achieve multi-tenancy in Manila, where the decision to access a share is made in the hypervisor. Typically, each hypervisor can have multiple guest instances belonging to different tenants. The proposed scheme involves running an userspace NFS server on the hypervisors. Tenants can make use of NFS clients to connect to this NFS server. The NFS server in turn will talk to different storage backends to serve requests made by its clients. We propose to use NFS-Ganesha as the userspace NFS daemon in this scheme.

NFS-Ganesha is very extensible and has a plugin based architecture. A plugin is commonly referred to as File System Abstraction Layer (FSAL) in NFS-Ganesha parlance. Currently, NFS-Ganesha has support for a variety of FSALs including ones for CephFS, GlusterFS and GPFS.

When a mount request is received by the NFS Ganesha server, it checks whether the client/tenant is allowed to access the related export or share. This can be determined by looking at the tenant’s network endpoint. Based on the share’s ACL, the mount operation can succeed or fail. If the mount succeeds, all further operations performed from the client will succeed and Ganesha would route such requests to the storage backend through the appropriate FSAL.

Advantages:

  • Works with all guest operating systems that have a nfs client built in.
  • This approach most closely mirrors how guests interact with storage controllers in Cinder. The storage controller only needs to know about compute nodes and the hypervisor deals with the problem of presenting the storage to the guest.
  • Security is enforced by the hypervisor. Backends need not support any security to protect tenant data from other tenants (or even enforce protection between instances of one tenant).
  • No dependence or interaction with Neutron
  • NFS server on the hypervisor performs caching. So not all requests from the instances need to be served by the storage layer. Thereby data access is sometimes faster, and the storage layer is less burdened.

Disadvantages:

  • Resources are consumed by NFS-Ganesha on the hypervisor.
  • HA for NFS Ganesha would necessitate additional configuration and state maintenance.