资源提供者 - 数据库中的调度器过滤器¶
https://blueprints.launchpad.net/nova/+spec/resource-providers-scheduler-db-filters
此蓝图旨在让调度器调用 placement API 以获取可以允许在 select_destinations() 期间预过滤计算节点以供评估的资源提供者列表。
问题描述¶
目前，每次调用调度器的 select_destinations() RPC 方法时，调度器都会检索一个 ComputeNode 对象列表，对于部署中的每个计算节点都包含一个对象。调度器会为每个计算节点构建一组 nova.scheduler.host_manager.HostState 对象。一旦构建了主机状态对象，调度器就会循环遍历它们，将主机状态对象传递给为部署启用的 nova.scheduler.filters.Filter 对象集合。
其中许多调度器过滤器所做的仅仅是计算计算节点拥有的特定资源的数量，并在请求的数量大于可用数量时返回 False。
返回整个部署中的所有计算节点记录非常浪费，并且这种效率低下随着部署规模的扩大而加剧。过滤器循环实际上是在实现一个 SQL WHERE 子句，但是在 Python 而不是更高效的数据库查询中实现。
用例¶
作为 CERN 的用户，我不想等待 nova-scheduler 处理 10K+ 个计算节点才能找到构建服务器的主机。
提议的变更¶
我们建议通过仅返回满足请求资源约束的计算节点资源提供者来减少 FilterScheduler 评估的计算节点集合。这将大大减少每次调用 select_destinations() 时需要从数据库中提取的计算节点记录数量。与其进行数据库调用，我们更愿意对 placement API 的特定 REST 资源进行 HTTP 调用，请求返回与原始 RequestSpec 对象中请求资源和 traits 标准匹配的资源提供者 UUID 列表。
此蓝图不旨在更改 CachingScheduler 驱动程序，该驱动程序会覆盖获取主机列表的方法。这意味着 CachingScheduler 将不会调用 placement API。
备选方案¶
我们可以创建一个全新的调度器驱动程序，而不是修改 FilterScheduler。Jay 并不赞成这种方法，因为它为系统引入了比直接使用 placement API 更多的复杂性。
数据模型影响¶
无。
REST API 影响¶
无。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
Jay 构建了一个基准测试 工具，它表明部署中的计算节点越多，在数据库端进行过滤而不是在 Python 端进行过滤并返回每个计算节点的记录所获得的收益就越大。 这直接读取数据库，但我们认为额外的 HTTP 惩罚影响不大。
其他部署者影响¶
在 Pike 中，CoreFilter、RAMFilter 和 DiskFilter 调度器过滤器将被从默认调度器过滤器列表中删除。当然，对于现有的部署，它们将在其启用的过滤器列表中继续拥有这些过滤器。我们将记录一个警告，说明这些过滤器现在是多余的，可以安全地从 nova.conf 文件中删除。
对于禁用 RAMFilter、DiskFilter 或 CoreFilter 的部署者，他们可能希望手动将适当的库存记录的分配比例设置为非常大的值，以模拟在调度决策中不考虑特定资源类。例如，如果部署者在部署中禁用了 DiskFilter，因为他们不关心磁盘使用情况，他们将为所有计算节点中 DISK_GB 资源类的每个库存记录设置 allocation_ratio 为 10000.0，通过新的 placement REST API。
这些更改旨在以一种“自我修复”的方式引入 Nova。在 Newton 中，引入了 placement REST API，nova-computes 将开始将 VCPU、MEMORY_MB 和 DISK_GB 资源的库存和分配记录写入 placement API。如果未设置 placement 服务，nova-compute 会记录一个警告，说明需要启动 placement 服务并在 Keystone 中创建一个新的服务端点，以便 nova-computes 可以找到 placement API。
在 Ocata 中，placement 服务是必需的，但是我们将构建一种自我修复过程，将其引入调度器调用 placement API 以减少要处理的计算主机集合的新行为。如果 placement 服务已设置，但尚未将所有 nova-computes 升级到 Ocata，则调度器将继续使用其查询 Nova cell 数据库 compute_nodes 表的现有行为。一旦所有 nova-compute 工作者都升级到 Ocata，新的 Ocata 调度器将尝试联系 placement 服务以获取满足一组请求资源数量的资源提供者（计算主机）列表。
在刚刚升级的 Ocata 部署的场景中，该部署先前没有建立 placement 服务（因此没有 nova-computes 成功写入 placement 数据库中的记录），调度器可能会暂时返回 NoValidHosts，直到 placement 数据库填充完毕。
随着 nova-computes 的重启（或升级+重启）推出，placement 数据库将开始填充分配和库存信息。请注意，在所有 nova-compute 工作者都升级到 Ocata 之前，调度器将不会使用 placement API 进行决策。调度器中有一个服务版本检查，要求在部署中所有 nova-computes 都升级到 Ocata 后，调度器才会开始使用 placement API 进行调度决策。
开发人员影响¶
无。
实现¶
负责人¶
- 主要负责人
bauzas
- 其他贡献者
cdent jaypipes
工作项¶
添加一个新方法，该方法接受一个 nova.objects.RequestSpec 对象，并将该对象转换为资源和 traits 标准列表
提供一种调用 placement API 以获取匹配这些标准的资源提供者列表的方法。
将资源提供者列表转换为主机列表，并仅为 FilterScheduler 驱动程序替换现有的数据库调用为 HTTP 调用。
现在将 NUMA 和 PCI 设备过滤器保留在调度器的 Python 端，直到 nested-resource-providers 蓝图完成。我们可以为通过数据库端处理 NUMA 和 PCI 资源使用单独的蓝图。
依赖项¶
这项工作有以下依赖蓝图
resource-providers-get-by-request
测试¶
现有的功能测试应该能够充分验证，将数据库端过滤切换为 RAM、vCPU 和本地磁盘的 Python 端过滤不会产生与 select_destinations() 调用不同的调度结果。
文档影响¶
确保我们记录冗余过滤器日志警告以及如何补救，并记录如何使用 allocation_ratio 来模拟禁用的过滤器。
参考资料¶
无。
历史¶
发布名称 |
描述 |
|---|---|
Newton |
引入 |
Ocata |
重新提出 |
