限制分配候选¶
https://blueprints.launchpad.net/nova/+spec/allocation-candidates-limit
本文档提供了一种限制在发出 GET /allocation_candidates 请求时返回的分配候选数量的模型，同时保持合理的性能，并且不影响打包（pack）与分散（spread）行为。
问题描述¶
在大型且稀疏的云环境中（例如，10,000 个空闲计算节点），GET /allocation_candidates?resource=VCPU:1 请求可能会返回 10,000 个资源提供者信息。 这对放置服务和客户端（目前是 nova-scheduler）的内存和性能都有影响。
有许多潜在的解决方案来解决这个问题，其中许多会引入其他问题，例如影响调度决策中的打包与分散处理，破坏数据库中的索引使用，或增加服务器进程的复杂性。
用例¶
作为放置服务的客户端，我希望能够选择性地请求有限数量的分配候选。
提议的变更¶
提出的解决方案是讨论了许多不同的选项后，最终确定采取一种简单的方法来解决放置服务客户端存在的问题，同时为将来根据需要进行调整留下空间。
在一个新的微版本中，接受
GET /allocation_candidates上的可选limit查询参数，其值表示响应中将返回的最大分配候选数量。 目前不考虑表达分页或排序的支持。 该值表示前 N 个候选。 如果未设置，则没有限制。修改 AllocationCandidates.get_by_filters 以接收大小由
limit定义的 allocation_requests 的切片，并仅提供那些在请求中提到的提供者的 provider_summaries。该切片要么是前 N 个项目，要么是根据一个布尔配置设置 (
randomize_allocation_candidates) 的值进行随机抽样。 这允许部署在结果中选择打包或分散行为。 默认值为False，保持现有行为。
此解决方案意味着将较小的数据集转换为 JSON 并通过网络传输给候选，并且服务器端创建的对象的数量较少，但仍会从数据库查询返回大量行。
备选方案¶
有许多替代方案，其中大多数涉及对数据库进行侵入性更改并在放置服务中建立定期作业。
对于第一次尝试，上述相对简单的模型将有效，并且如果出现问题，可以逐步改进或调整。
数据模型影响¶
无。
REST API 影响¶
扩展 GET /allocation_candidates 请求的查询参数模式，在一个新的微版本中，接受一个 limit 参数，该参数采用一个整数值，表示将返回的最大候选数量。
安全影响¶
N/A
通知影响¶
N/A
其他最终用户影响¶
N/A
性能影响¶
此更改的目的是通过限制通过网络发送的结果集的大小来保护全局性能。 但是，在资源提供者数量非常多的环境中，数据库查询仍然会有一个大的结果集。 根据我们在 Python 中处理该结果集的方式，可能会对服务器资源使用产生影响。 如果事实证明是这样，我们有额外的技术来解决这个问题，而这些技术已经在此处提出。
其他部署者影响¶
N/A
开发人员影响¶
需要更改新的配置项，以便那些不想使用默认设置的部署。
实现¶
此更改的主要内容发生在 get_by_filters 中的一个循环内，其中遍历资源提供者列表。
负责人¶
- 主要负责人
cdent
- 其他贡献者
rgerganov
工作项¶
添加一个如上所述的配置设置，以控制如何切片结果集。
将
limit添加到GET /allocation_candidates查询参数 JSON 模式调整 AllocationCandidates.get_by_filters 以接受可选的
limit参数，用于处理结果。更新功能测试，以确认
get_by_filters的限制和随机化功能。更新 gabbi 测试，以测试
GET /allocation_candidates的limit功能。
依赖项¶
N/A
测试¶
我们可能希望在进行此更改之前和之后，以及在此更改之后和在进行任何进一步调整之前，提供一些用于检查性能的设施。
文档影响¶
新的配置设置将被记录。
参考资料¶
N/A
历史¶
发布名称 |
描述 |
|---|---|
Queens |
引入 |
