亲和性和反亲和性调度器过滤器¶

https://blueprints.launchpad.net/cinder/+spec/affinity-antiaffinity-filter

为 Cinder 添加调度器过滤器，允许调度器根据现有卷和新卷（正在调度的卷）之间的亲和性关系做出放置决策。这里的亲和性关系指的是卷的位置（卷的‘host’）。

问题描述¶

Cinder 通过使用卷类型，很好地隐藏了存储后端细节，避免了对最终用户的暴露。然而，存在一些用例，构建在卷之上的应用程序的用户希望能够“选择”卷创建的位置。Cinder 如何在不损害我们一直保持的简洁性的前提下提供这种能力？亲和性/反亲和性是我们可以在不暴露后端细节的情况下提供的灵活性之一。

这里的亲和性/反亲和性是指在位置方面两组卷之间的关系。为了限制范围，我们描述一个卷只有在它们位于相同的卷后端时（如果 Cinder 支持卷池，这个概念可以扩展到卷池）才与另一个卷具有亲和性；相反，两组卷之间的“反亲和性”关系仅仅意味着它们位于不同的 Cinder 后端（池）。

此亲和性/反亲和性过滤器根据最终用户指定的提示过滤 Cinder 后端。该提示表达了新卷和现有卷之间的亲和性或反亲和性关系。这允许最终用户提供诸如“请将此卷放置在与 Volume-XYZ 位于不同位置的地方”之类的提示。以下是此新过滤器可用的两个用例。

DB 团队在单个卷上构建 MySQL 主服务器，他们希望将用于从库 DB 的新卷放置在与主 DB 不同的后端，以提高可用性。
日志处理项目希望尽可能拥有快速的存储，因此它们跨多个卷创建软 RAID。他们希望将这些卷尽可能地靠近彼此，理想情况下位于相同的存储后端，以提高性能。

用例¶

提议的变更¶

为 Cinder 添加两个新的过滤器 - AffinityFilter 和 AntiAffinityFilter。这两个过滤器将查看最终用户提供的调度器提示（通过调度器提示扩展），并通过检查旧卷和新卷的‘host’来过滤后端，以查看后端是否满足要求（位于与现有卷相同的后端，或者不位于与现有卷相同的后端）。

备选方案¶

之前有一个提议允许管理员用户直接指定新卷的后端。它并没有真正提供与亲和性过滤器类似的功能，因为它仅限于管理员，并且本身也存在一些缺点（例如安全问题）。

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

虽然此更改涉及使用或解析用户提供的 - 调度器提示，但这已经是 Cinder 的一部分。这不会给 Cinder 带来任何额外的风险。

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

新过滤器将每次请求查询 DB 一次，它只会给系统增加轻微的延迟，并且延迟与系统的大小无关。

其他部署者影响¶

无

开发人员影响¶

无

实现¶

负责人¶

主要负责人: zhiteng-huang (winston-d on IRC)

工作项¶

过滤器实现
内部 DB API 修改

依赖项¶

无

测试¶

针对 AffinityFilter 的测试

创建卷 A；
使用 A 的 uuid 和 ‘same_backend’ 作为提示创建另一个卷 B；
检查 B 是否创建在与 A 相同的后端；

针对 AntiAffinityFilter 的测试

创建卷 A；
使用 A 的 uuid 和 ‘different_backend’ 作为提示创建另一个卷 C；
检查 C 是否创建在与 A 不同的后端；

文档影响¶

需要记录新过滤器的用法。

参考资料¶

Nova 自 Diablo 以来一直提供名为 SameHostFilter 和 DifferentHostFilter 的类似功能。

https://github.com/openstack/nova/blob/master/nova/scheduler/filters/affinity_filter.py

亲和性和反亲和性调度器过滤器