Manila/Networking/Gateway mediated
架构
本文档概述了一种使用Manila OpenStack实现多租户的方法，以及与使用这种方法在云中启用多租户相关的架构/设计考虑因素。该模型基于 Manila Networking的网关介导方法。这里，“网关”应理解为存储网关，即是存储后端所在永久网络的成员，并管理/调解租户机器对存储后端的访问。
采用的方法是基于网关的，其中是否允许租户访问预期的Manila共享的决定是在网关中做出的。通常，每个网关可以有多个客户机实例，每个实例都被视为一个租户。 建议的设计是在网关上运行一个用户空间NFS服务器。租户依赖于NFS客户端连接到此NFS服务器并使用任何导出的共享。反过来，假设NFS服务器足够强大，可以与不同的存储后端通信并服务于其客户端发出的请求。
我们建议在此架构中使用nfs-ganesha[1][2]作为用户空间NFS守护进程。这是基于以下原因：nfs-ganesha易于扩展到各种文件系统后端，并具有模块化/基于插件的架构。 在NFS-Ganesha术语中，插件通常被称为文件系统抽象层（FSAL）。 目前，nfs-ganesha支持各种FSAL，包括CephFS、GlusterFS、Lustre、ZFS、VFS、GPFS等。nfs-ganesha还支持各种NFS协议版本，如NFSv2、v3、v4、v4.1、v4.2和pNFS。 这使其非常适合未来的用例可扩展性，以及从适应尽可能多的文件系统后端（包括任何新的供应商开发的后端）的角度来看。
当nfs-ganesha服务器收到挂载请求时，它会检查客户端/租户是否允许访问相关的导出或共享。 基于NFS共享ACL配置，导出的共享操作将成功或失败。 如果挂载成功，则从客户端执行的所有后续操作都将成功，并且Ganesha将通过相应的文件系统FSAL将这些请求路由到存储后端。 因此，基于NFS ACL和访问权限可以实现租户共享分离。 此外，nfs-ganesha还支持基于Kerberos的身份验证，以防需要在Openstack计算集群中的节点之间导出和使用Manila共享，并且nfs-ganesha将以多头配置安装在集群中的每个网关上。
优点
- 适用于内置nfs客户端的所有客户机操作系统。 经过良好标准化且提供广泛的支持。
- 不需要任何VM/客户机插件安装，也不需要修改任何Openstack组件才能使其与这种方法一起工作。
- 适用于大多数流行的文件系统后端和/或存储阵列，无需修改。
- 这种方法最能反映客户机与Cinder中的存储控制器交互的方式。 存储控制器只需要了解计算节点，而网关负责向客户机呈现存储的问题。
- 安全性由网关强制执行。 后端不需要支持任何安全性来保护租户数据免受其他租户的侵害（甚至不需要强制执行同一租户的实例之间的保护）。
- 进一步的租户分离基于基于NFS ACL和身份验证的共享权限。 这很容易强制执行。
- 不依赖或与Neutron交互
- 网关上的NFS服务器执行缓存。 因此，并非所有来自实例的请求都需要由存储层提供服务。 因此，数据访问有时会更快，并且存储层的负担减轻了。
- 作为一个用户空间服务器，nfs-ganesha的缓存-inode层可以任意增长，主要（仅）受底层硬件的限制。 这支持在支持更大数量的计算实例和共享操作/请求方面具有更大的可扩展性。
- 可扩展到支持其他多租户用例，如共享预留、QoS要求等。
缺点
- 由于nfs-ganesha在网关上运行，因此会消耗资源。 在一般工作负载中，ganesha的资源消耗已被证明是适度的，因此我们目前认为这不会对整体架构产生重大影响。 如果有任何影响，则需要进行进一步的测试以确定。
- 通过nfs-ganesha实现租户共享访问的高可用性可能需要额外的配置和状态维护。 但是，这种可用性支持/基础设施主要作为针对不同文件系统后端的单独Ganesha解决方案提供。
参考文献
[1] https://github.com/nfs-ganesha/nfs-ganesha/wiki
[2] https://forge.gluster.org/nfs-ganesha-and-glusterfs-integration/pages/Home
