区分调度器中的厚配置和薄配置逻辑¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/cinder/+spec/differentiate-thick-thin-in-scheduler
目前在调度器的容量过滤器和称重器中，我们使用逻辑来评估后端是否有足够的容量来薄配置一个卷，如果驱动程序报告 thin_provisioning_support 为 True。然而，驱动程序可能能够支持薄配置和非薄配置。该逻辑没有检查用户是否希望将卷配置为薄配置。本蓝图建议通过检查卷类型附加规格中的 thick_provisioning_support 来解决此问题。
问题描述¶
如果驱动程序报告一个池既能支持薄 LUN 又能支持厚 LUN，并且 thin_provisioning_support 和 thick_provisioning_support 都为 True，而用户希望创建一个厚 LUN，那么调度器中的逻辑将错误地使用薄配置的逻辑来做出决策。它将基于 provisioned_capacity_gb 和 max_over_subscription_ratio 做出决策。这可能会导致过度配置。
在本规范中，我们试图通过检查新卷是薄配置还是厚配置，然后相应地使用逻辑来做出决策来解决此问题。
用例¶
目前，如果驱动程序有一个可以支持薄配置和厚配置的池，它可以报告 thin_provisioning_support 为 True 和 thick_provisioning_support 为 True。但是，调度器中的逻辑检查薄配置容量，如果驱动程序报告 thin_provisioning_support 为 True，即使卷类型指定卷为厚配置也是如此。拟议的规范希望解决此问题。
提议的变更¶
该规范建议对容量过滤器和容量称重器中的逻辑进行以下更改。
将检查要配置的卷的卷类型。如果卷类型附加规格中将 provisioning_type 设置为 thick，它将使用厚配置逻辑进行评估。请注意，这仅在驱动程序报告 thin_provisioning_support 和 thick_provisioning_support 都为 True 时才影响逻辑。
否则，逻辑将与之前相同。
备选方案¶
无。
数据模型影响¶
无。
REST API 影响¶
无。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
无。
其他部署者影响¶
当管理员设置卷类型时，需要在厚配置卷类型的附加规格中设置以下内容
{'thick_provisioning_support': <is> True>} or
{'capabilities:thick_provisioning_support': <is> True>}
开发人员影响¶
驱动程序开发者应该意识到此附加规格，并在卷创建中相应地处理它。
实现¶
负责人¶
- 主要负责人
<xing-yang>
- 其他贡献者
<launchpad-id 或 None>
工作项¶
修改容量过滤器以检查 thick_provisioning_support。
修改容量称重器以检查 thick_provisioning_support。
依赖项¶
无。
测试¶
将为此更改添加单元测试。
文档影响¶
需要更改文档以包含此信息。
参考资料¶
- Manila 中提出了一项补丁来解决类似的问题
请注意，Manila 中薄配置和厚配置的功能报告与 Cinder 不同。在 Manila 中，驱动程序报告 thin_provisioning = [True, False] 如果它同时支持薄配置和厚配置；在 Cinder 中，驱动程序报告 thin_provisioning_support = True 和 thick_provisioning_support = True 如果它同时支持薄配置和厚配置。因此，本规范中的提议与 Manila 补丁中的解决方案不同。
