Manila/design

组件 / 阶段

1) 文件共享服务

最初，该服务被设想为在 Cinder（OpenStack 块存储）项目中交付的独立文件共享服务，考虑到可以利用通用代码的机会。然而，在 2013 年 6 月，决定建立一个独立的开发项目，以适应

创建文件系统共享（例如，create API 需要支持“协议”和“权限”掩码和“所有权”参数）
删除文件系统共享
列出、显示、提供和拒绝访问，以及列出文件系统共享的访问规则
创建、列出和删除文件系统共享的快照/克隆
协调文件系统共享的挂载
卸载文件系统共享

实施状态：开发正在进行中，在 [[1]]

Manila API 文档 Manila API 路线图 Manila 数据库规范

注意：Manila 最初是 Cinder 的一个分支，因为它提供了文件共享服务所依赖的许多概念。 Cinder 目前的容量、目标（在 NAS 术语中为服务器）、发起者（同样，在引用共享文件系统时为客户端）的概念在概念上（如果并非完全语义上）都是通用的，并且广泛适用于基于块和基于文件的存储。 Cinder 的特定功能（例如过滤器调度器、类型概念和额外的规范）同样适用于共享文件系统的配置。因此，文件共享服务的初始原型是基于 Cinder 的演进。然而，Manila 解决了 Cinder 操作中不相关的一系列其他问题。在 Cinder 社区内部讨论并咨询技术委员会成员后，确定建立一个专门设计和开发用于提供共享/分布式文件系统服务的独立项目是最可行的方案。计划将 Cinder 和文件共享服务之间的任何通用性迁移到 Oslo 中，如果合理的话。

2) Manila 参考提供者

为在提议的扩展 API 下用于共享文件系统创建参考 Manila 提供者（通常也称为驱动程序）。例如，NetApp 提供者能够通告、接受和响应对 NFSv3、NFSv4、NFSv4.1（带有 pNFS）和当代 CIFS / SMB 协议（例如版本 2、2.1、3）的请求。将需要修改 python-cinderclient 以提供扩展的请求参数数组。供应商独立的参考和 NetApp 特定的后端都是上述原型的一部分，并且是提交的一部分。 实施状态：已完成。

3) 使用过滤器调度器和多后端支持对共享进行智能调度

允许一个 Manila 节点管理多个共享后端。后端可以同时运行共享和卷服务。在过滤器调度器中支持共享允许云管理员通过基于预定义参数过滤后端来管理大规模共享存储。

实施状态：已完成。

4) 端到端体验（自动挂载）

关于处理注入/更新挂载到在 Nova 上下文中实例化的客户机的方案。与之直接交互或更有可能轮询或接收来自实例元数据更改更新的侦听器/代理将代表一种可能的解决方案。也可以考虑使用 cloud-init 或 VirtFS（这将以类似于 Cinder 块存储的方式将共享文件系统附加到实例）。

此处有更多讨论： Manila 存储集成模式

实施状态：范围确定中。

5) 最后一段距离的问题

关于连接从共享到实例的各种用例/网络拓扑（从扁平网络到 Neutron SDN 到超visor 介导的选项）的讨论，请参见： Manila 网络

实施状态：尚未开始。

6) 租户和管理界面

Manila 必须公开管理和租户 Horizon 界面。

实施状态：正在设计阶段……初始 Horizon UI 将大量借鉴现有的 Cinder 面向租户和管理界面。