Manila 过分配增强

https://blueprints.launchpad.net/manila/+spec/manila-oversubscription-enhancements

关于 allocated_capacity_gb 和 provisioned_capacity_gb，allocated_capacity_gb 对应于通过 manila 在存储池上创建的 shares_gb。provisioned_capacity_gb 等于 allocated_capacity_gb 加上在相同存储池上手动创建的 shares_gb（或通过另一个 manila 创建的 shares_gb）。这意味着 provisioned_capacity_gb 大于或等于 allocated_capacity_gb。管理员了解这两个值对于获取后端分配容量信息非常重要。

对于支持稀疏配置的存储后端，以下描述了报告的容量信息。

total_capacity_gb = Manila 使用的存储池的总物理磁盘容量。

free_capacity_gb = total_capacity_gb - 存储池已使用的物理磁盘容量。

provisioned_capacity_gb = 存储池中所有 shares 分配的总容量（包括手动创建的 shares 或其他 manila 创建的 shares）。

allocated_capacity_gb = 当前 manila 创建的所有 shares 分配的总容量。

问题描述

问题一：举例说明。存储池 pool_A 的物理磁盘容量为 10G。该池中有四个 shares。Share A 由 openstack O_A（当前 manila）创建，share 大小为 5G。该 share 中有一个 124MB 的文件。Share B 由 openstack O_A（当前 manila）创建，share 大小为 4G。该 share 中有一个 0MB 的文件。Share C 由 openstack O_B 创建，share 大小为 3G。该 share 中有一个 400MB 的文件。Share D 手动创建，share 大小为 2G。该 share 中有一个 500MB 的文件。

实际使用的总物理容量为 1G（124MB+0MB+400MB+500MB），结果如下：total_capacity_gb = 10G free_capacity_gb = 9G provisioned_capacity_gb = 14G (5G+4G+3G+2G) allocated_capacity_gb = 9G (5G+4G，只有 share A 和 B 由当前 manila 创建)

事实上，存储后端不知道有多少 Manila 服务正在使用存储池，也不知道管理员是否在池中手动创建了 shares。因此，后端存储驱动程序报告的 allocated_capacity_gb 不正确。只有后端存储驱动程序报告的 provisioned_capacity_gb 是正确的。

目前，一些驱动程序（inspur、huawei、netapp、qnap、zadara）报告 allocated_capacity_gb，而另一些驱动程序（infinibox、hpe_3par、nexenta）报告 provisioned_capacity_gb，这造成了混乱。

问题二：关于调度服务支持 Active/Active HA，每次创建或扩展 share 时都会执行 consume_from_share 函数，在此函数中必须更新 allocated_capacity_gb 和 free_capacity_gb。假设创建了 100 个 1gb shares，其中 50 个在节点 1 上执行，30 个在节点 2 上执行，20 个在节点 3 上执行。由于 allocated_capacity_gb 存储在调度服务的内存中。因此，三个调度节点的 allocated_capacity_gb 值不一致。这是一个问题。我们需要定期校准 allocated_capacity_gb。

用例

  • 管理员可以通过 allocated_capacity_gb 和 provisioned_capacity_gb 查看后端存储的容量分配。

  • Manila 调度器使用 provisioned_capacity_gb 来过滤和加权后端。

提议的变更

本规范建议

  • 如果驱动程序能够准确跟踪，则驱动程序报告的 allocated_capacity_gb 可能是正确的，但从数据库计算的 allocated_capacity_gb 必须是正确的。因此，为了统一性，allocated_capacity_gb 将使用数据库计算的值，而不是驱动程序报告的值。

  • 我们强烈建议驱动程序报告 provisioned_capacity_gb，如果未报告，Manila 将被视为专用存储池，并将 allocated_capacity_gb 作为 provisioned_capacity_gb 值使用。

  • 对于问题二，在 Manila Share 中添加一个定期任务，以定期从数据库收集 allocated_capacity_gb 统计信息，并将其记录在 self._allocated_capacity_gb（ShareManager 类的一个成员变量）中。在执行 _report_driver_status 时，读取 self._allocated_capacity_gb 并更新 share_stats[pools] 中的 allocated_capacity_gb。由于 Manila 不需要非常实时的 allocated_capacity_gb 数据，因此可以将定期任务的间隔设置为 5 分钟，以降低系统和数据库压力。

备选方案

当前模型是一种替代方案，但是，调度器中发生的计算存在问题，因为它发生在每个后端和每个池的每个调度器进程中，效率低下且错误。

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

我们将从调度服务中删除一个巨大的性能瓶颈！

其他部署者影响

无

开发人员影响

驱动程序应更新为报告 provisioned_capacity_gb 而不是 allocated_capacity_gb。

实现

负责人

主要负责人

haixin <haix09@chinatelecom.cn>

工作项

  • 更新 share manager 和 scheduler 的 host manager。

  • 更新单元测试。

  • 更新相关文档。

依赖项

无

测试

  • 添加单元测试

文档影响

以下 OpenStack 文档将被更新以反映此更改

  • OpenStack 贡献者指南

参考资料

无