容量限制宿主机检查机制¶

https://blueprints.launchpad.net/cinder/+spec/inspection-mechanism-for-capacity-limited-host

Cinder 现在有一个调度器过滤器，名为 CapacityFilter，它允许用户在容量限制下创建卷。但是，一些不经过 cinder-scheduler 的 API 会破坏目标宿主机的容量。

问题描述¶

一些后端现在支持稀疏配置能力。但只有 Cinder 在 cinder-scheduler 的过滤器中获取并检查此能力：CapacityFilter。这意味着一些直接访问后端的 API，而没有经过 cinder-scheduler，不会获取和检查后端的 reserved_percentage 和 max_over_subscription_ratio。然后，它可能会破坏后端的容量。例如“扩展卷”、“从快照创建卷”、“复制卷”等等。

用例¶

通常，当 Cinder 使用 CapacityFilter 时，容量是指定后端的一个硬性限制（它是 Cinder 中的默认过滤器之一）。这意味着对这种后端的每个操作都应该保持其容量。我们不应该破坏支持稀疏配置的后端的capability。

提议的变更¶

在 cinder-volume 层添加一些通用函数来检查后端的容量。补丁[1]是一个解决卷创建问题的 POC。
那些 1) 改变后端容量，并且 2) 不经过 cinder-scheduler 的 API，应该被直接检查。这包括
- POST /v3/{project_id}/volumes/{volume_id}/action (os-extend) (已解决)[2]
- POST /v3/{project_id}/volumes (从快照、卷或副本创建)
- POST /v3/{project_id}/groups/action (create_from_src)
- POST /v3/{project_id}/snapshots

注意

为快照、卷或副本创建卷的请求会改变后端的容量，因此会导致卷的状态切换为“error”。
Cinder 管理员不需要使用 CapacityFilter，因为不需要在驱动层检查卷容量限制。

备选方案¶

对于那些会改变后端容量且不经过 cinder-scheduler 的 API，我们可以将它们路由到调度器，而不是直接跳转到 volume-service。

扩展 API 的问题最近通过一个 bug fix[2] 解决。在补丁中，它传递了一个“volume”参数，其中包含主机名到 cinder-scheduler，以指示指定了目标主机。然后 cinder-scheduler 将仅使用 backend_passes_filters 函数检查指定的宿主机。如果未引发错误，则表示允许 POST 操作。

注意

我们需要升级 cinder-api 和 cinder-scheduler 之间的 RPC 调用版本，以保持与每个相关 API 的向后兼容性。
即使指定了目标主机，创建操作也将始终通过 cinder-scheduler 调用。如果 cinder-scheduler 无法匹配新的 RPC 版本，则保留旧行为。

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

无

通知影响¶

与其发送通知，不如在操作失败时发送用户消息。

其他最终用户影响¶

将超出后端容量的创建请求会使卷的状态变为“error”。

性能影响¶

无

其他部署者影响¶

无

开发人员影响¶

无

实现¶

负责人¶

主要负责人: wangxiyuan <wangxiyuan@huawei.com> Huang Zhiteng <winston.d@gmail.com> Erlon R. Cruz <sombrafam@gmail.com> tommylikehu<tommylikehu@gmail.com>

工作项¶

添加一些通用检查函数并在其中调用
- 从卷、快照或副本创建卷
- 从源创建 cg
- 从源创建组
- 创建快照
添加和更新单元测试。

依赖项¶

无

测试¶

将添加和更新单元测试。

文档影响¶

无

参考资料¶

[1] Huang Zhiteng: https://review.openstack.org/#/c/437677/ [2] Erlon R.Cruz: https://review.openstack.org/#/c/405578/

容量限制宿主机检查机制