Manila/SAP enterprise team
< Manila
使命
SAP Manila 企业团队致力于解决使 Manila 具备企业级能力的相关问题。所列主题可能是缺陷、特性，甚至是长期任务。
待处理主题
| 否 | 问题 | 描述 | 优先级 | 回溯移植 | 分配者 | 参考资料 | 发布 | 状态 |
|---|---|---|---|---|---|---|---|---|
| 1 | 快照: 使用户能够指定“完全复制克隆”或“写时复制克隆” |
为了加快部署速度，该概念需要“克隆模板”，其中模板是主卷的快照，克隆解析为快照（manila create --snapshot） | A | NetApp | NetApp cDOT 驱动程序可配置的克隆拆分。 定义一个 NetApp 附加规范，用于定义选择初始克隆拆分作为创建快照工作流程一部分的共享类型。 NetApp cDOT 驱动程序可配置的克隆拆分 NetApp cDOT 驱动程序在创建快照时可配置的克隆拆分 |
Newton | OK | |
| 2 | 快照: 使用户能够将其“写时复制克隆”与其源快照分离 |
基于快照的共享绑定到源池。在项目的生命周期中，可能需要将共享迁移到其他后端。朝着这个方向迈出的第一步是打破对源的依赖，即打破“写时复制克隆”。 | C | ? | 实施第 1、4、5 和 6 项可能会消除此问题。 | |||
| 3 | Manila-share 主动-主动 HA | Manila 服务 manila-share 应该具有主动-主动 HA。这意味着至少有两个服务管理后端。 | A | ? | 请参阅 cinder 示例：“使用 Tooz 替换本地文件锁” | |||
| 4 | 迁移: 在同一个共享服务器 / 共享网络内的共享 |
随着项目规模的增长，容量以及性能可能需要将共享移动到同一个共享服务器 / 共享网络中的不同池。迁移应该支持此功能，最好作为后端特定驱动程序内的函数，以最大限度地减少开销 | A | NetApp | Newton | 已开始 | ||
| 5 | 迁移: 到不同的共享服务器的共享 |
如果共享服务器的容量达到其限制，或者需要更改共享网络（从 QA 迁移到生产网络），则需要允许迁移到不同的共享服务器/网络。如果可能，调度器可以选择目标。驱动程序可以处理此迁移。 | B | ? | ||||
| 6 | 迁移: 到不同可用区的共享 |
在可用区之间移动共享。如果可能，调度器可以选择目标。 | C | ? | ||||
| 7 | 时间表: 使用虚拟资源来调度共享创建 |
大型企业应用程序不仅需要共享的容量，还需要依赖其他属性，例如 I/O、网络带宽，这些属性定义了特定资源-'池'的限制。虚拟资源可以帮助指导调度器根据共享类型消耗这些虚拟资源，从而限制基于这些限制的共享创建。 | C | ? | ||||
| 8 | Manila 创建 Manila create --snapshot --schedule，通过调度器创建克隆 |
使用快照创建克隆将从相同的池/资源分配共享。由于资源或其他限制，这可能需要后续迁移。使用调度器逻辑优化创建过程以选择目标资源，应将所有这些步骤结合在一个步骤中，如果可能，将繁重的工作留给驱动程序。 | C | ? | ||||
| 9 | 指定 NFS 协议 | 设置活动 NFS 协议（对于后端 / 共享服务器）NFSV3，NFSV4.0，NFSV4.1 | A | Mitaka | NetApp | 可以在 manila.conf 中使用 f.e. 选择网络协议 netapp_enabled_share_protocols = nfs3 netapp_enabled_share_protocols = nfs4.0 netapp_enabled_share_protocols = nfs3, nfs4.0, nfs4.1 必须重新启动 manila。 然后在 manila create 时使用所选协议 请参阅：NetApp cDOT 多 SVM 驱动程序可配置的 NFS 版本 建议 如果您只想使用 NFS3 创建共享：在 manila.conf 中创建一个第二个后端，使用 nfs3。创建一个使用此附加后端的附加类型，使用 key share_backend_name。使用此新的共享类型创建 manila 共享。因此，新定义的 nfs_protocols 将用于此共享。即使在同一个共享网络上，也会创建额外的共享服务器。 |
Newton | OK |
| 10 | MTU 大小必须可定义 | 目前没有定义广播域设置（NetApp 驱动程序）的 MTU 大小的方法 | A | Mitaka | SAP & NetApp | 错误报告：ML2 插件未为多个提供商网络设置正确的 MTU 提供的修复程序可以在创建共享服务器时动态评估 neutron 中设置的 MTU 大小。为了使用此功能，用于 VLAN 的 NetApp 端口需要位于允许此 MTU 大小的广播域中。VLAN LIF 上的较小 MTU 大小是可能的。 已合并修复：修复传递 get_mtu 的物理网络错误 |
Newton | OK |
| 11 | HPB Manila 分层端口绑定支持 |
具有多段支持的端口绑定 | A | SAP | 请参阅蓝图：Manila 网络支持分层端口绑定 | Newton | ||
| 12 | 根卷 允许使用参数“netapp_root_volume _aggregate” 多个 aggr |
当前问题：如果节点发生故障，所有 SVM 都会受到影响，接管/回退将需要很长时间。 | B | NetApp 现场 | 在标准操作指南中，建议将 SVM 的根卷分布在整个集群中。目前 OpenStack Manila 不支持此功能。为什么不使用为第一个卷选择的聚合来放置根卷，除非设置了 netapp_root_volume_aggregate 选项。在这种情况下，“遵循第一个聚合”假定所选聚合上留有足够的空间来放置 SVM 根卷。 | 建议 | ||
| 13 | LSMirror: 为低于 V4.1 的 NFS 版本实现 LS-Mirror |
如果使用 NFS V4.1，我们不需要 LS-mirror 功能，但如果使用较低版本，我们必须拥有它，并且必须注意驱动程序脚本中不断变化的配置行为 | C | NetApp 现场 | 需要重新验证业务场景。似乎无效 160920：由于仅使用 NFS V3 的可能性，需要提供 LS-Mirror 配置以获得更好的性能。 请参阅 NetApp 文档：ONTAP 使用负载共享镜像 |
重新审视 | ||
| 14 | 添加资源：在集群中添加控制器时自动调整资源 | 扩展现有集群时使用托管共享服务器，应自动扩展已存在的服务器，即向控制器添加 LIF，添加共享所需的元数据，以便可以使用新资源。 | B | |||||
| 15 | 额外规范列表: 列出额外规范的 API 扩展 |
目前文档是查找可用额外规范的唯一位置。列出基于可用/已配置驱动程序的所有规范的 API 调用将对配置提供很大的帮助 | B | 请参阅：功能和额外规范 另请参阅：共享类型定义 请参阅额外规范：NetApp 支持的额外规范 |
||||
| 16 | 复制: 使用托管共享服务器时可用区之间的复制 |
经典的 DR 要求 | C | |||||
| 17 | 调度器: 调度器未使用所有池 |
似乎 manila 调度器未利用所有可用池来分配共享。相反，如果共享服务器持有 2 个池（即聚合），则在第二个池用于新共享的放置之前，第一个池将被填满 | A | NetApp 本地 | 为了确保调度器识别更新的容量，我们需要在“manila create”调用之间至少间隔 2 分钟。这可能会对为 SAP 系统创建共享产生重大影响，因为通常需要多个共享。在 m-sch.log 中显示了可用容量。只要使用具有最高可用容量的池，就可以正常工作。 | Newton | OK | |
| 18 | ||||||||
| 19 | ________________ | __________________________________ | __ | ________ | ________ | __________________________________________________________ | ________ | ___ |
