将分配比例迁移到资源跟踪器¶
https://blueprints.launchpad.net/nova/+spec/allocation-ratio-to-resource-tracker
将分配比例的定义和计算从调度器移至资源跟踪器。
问题描述¶
目前，分配比例在调度器中定义不当。这会导致效率问题，因为调度器在不需要时会与数据库交互，并且在不需要时会重新计算调整后的资源使用量。
内存和 CPU 分配比例当前以全局或每聚合为基础进行控制，全局配置设置由调度器中的 core_filter 和 ram_filter 过滤器模块确定，每聚合的分配比例覆盖存储在数据库的 aggregates 表中，core_filter 调度器过滤器执行重复查找 aggregates 表，以确定在部署中使用主机聚合时要使用的分配比例。
分配比例不是调度器策略，根本不应该在调度器中定义或查询。分配比例仅仅是一种计算节点宣传其能够服务于比其物理可用资源更多的资源的方式：超额承诺比率。因此，计算节点上宣传的总资源量不需要在每次调度器运行以查找实例的计算节点时重新计算，而且资源跟踪器是设置可用资源量的最合适位置。
用例¶
操作员希望为每个计算节点指定分配比例
项目优先级¶
Liberty 尚未定义优先级，但此规范应与之前的 Kilo ‘scheduler’ 优先级工作相关联。
提议的变更¶
我们建议将 CPU 和内存分配比例的定义从当前定义的调度器过滤器（core_filter 和 ram_filter）移至资源跟踪器（nova.compute.resource_tracker）。
此外，我们建议从 core_filter.py 和 ram_filter.py 中删除 CPU 和 RAM 的计算节点超额承诺比率的所有计算。
此计算最初将移动到 host_manager.HostManager 类中，该类将在其 HostState 结构集合中存储每个计算节点的真实可用资源量和调整后的可用资源量。由于 Nova 中的当前资源跟踪器仅考虑单个计算节点，因此我们现在必须使用调度器的内部资源跟踪器（HostManager）来跟踪所有计算节点的分配比例。
由于现在每个计算节点的主机聚合信息都提供到 HostState 中，因此我们可以直接获取相关的超额承诺比率。如果计算节点属于任何主机聚合，则 CPU 和内存的超额承诺比率应为任何主机聚合设置的最低比率或默认全局配置比率值。
长远目标是使系统中的每个计算节点都具有其可设置的分配比例，并消除资源跟踪器或调度器本身中对此特定检查或计算的需求。我个人的最终目标是将调度器的内部资源跟踪器与 nova.compute.resource_tracker 中的代码对齐，但此蓝图的范围仅限于上述相对较小的更改。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
即使进行了相对较小的更改，由于每次调度器请求中进行的计算减少，单个调度器请求的性能也应该提高。对于使用主机聚合的部署，性能改进将更大，因为每次调度器请求的数据库查询次数将减少。
其他部署者影响¶
无
开发人员影响¶
无
实现¶
工作项¶
将分配比例的定义从过滤器移至 nova.compute.resource_tracker
为 ComputeNode 对象和 DB compute_nodes 模型提供 ram_allocation_ratio 和 cpu_allocation_ratio 作为新的字段
更改 HostManager.get_all_host_states() 中的行为，以正确地在 HostState 中计算从主机聚合的最小比率或全局定义比率获得的可用资源
负责人¶
- 主要负责人
sylvain-bauza
依赖项¶
无
测试¶
需要对现有的单元测试进行一些小的调整。
文档影响¶
无
参考资料¶
邮件列表讨论
http://lists.openstack.org/pipermail/openstack-dev/2014-June/036602.html
