默认分配比例配置

https://blueprints.launchpad.net/nova/+spec/initial-allocation-ratios

为计算节点提供单独的 CONF 选项来指定初始分配比例。将 CONF.xxx_allocation_ratio 选项的默认值更改为 None，并更改资源跟踪器的行为，仅当 CONF.xxx_allocation_ratio 值不为 None 时，才覆盖现有计算节点的分配比例。

此功能的主要目标是支持通过 API 和配置文件两种方式传递分配比例。

问题描述

手动设置的 Placement 分配比例会被覆盖

目前，管理员无法在 Placement API 的资源提供程序的库存记录中设置分配比例，而资源跟踪器会在下次运行 update_available_resources 定期任务时，最终覆盖该值，这是 nova-compute 服务上的问题。

计算主机上的分配比例值的故事

Nova 确定超visor 上 CPU、RAM 和磁盘资源的分配比例的过程令人困惑且容易出错。Nova cell DB 中的 compute_nodes 表包含三个字段，分别表示超visor 上 CPU、RAM 和磁盘资源的分配比例。这些字段使用不同的默认值填充，具体取决于运行在 nova-compute 服务上的 Nova 版本。

启动时，nova-compute 服务工作器中的资源跟踪器检查 Nova cell DB 的 compute_nodes 表中是否存在自身的记录。如果未找到，资源跟踪器创建 表中的记录，设置 compute_nodes 表中关联的分配比例值，为 nova.conf 配置文件中的 cpu_allocation_ratio、ram_allocation_ratio 和 disk_allocation_ratio 选项找到的值，但前提是配置选项的值不等于 0.0。

目前，cpu_allocation_ratio、ram_allocation_ratio 和 disk_allocation_ratio CONF 选项的默认值设置为0.0。

资源跟踪器将这些默认的 0.0 值保存到 compute_nodes 表中，当资源跟踪器调用 compute node 对象的 save() 时。但是，nova.objects.ComputeNode._from_db_obj 中存在代码，在第一次保存时从数据库读取记录时，会将这些值从 0.0 更改为 16.0、1.5 或 1.0。

资源跟踪器通过 save() 的 ComputeNode 对象在一段时间内具有这些新值，而 compute_nodes 表中的记录仍然具有错误的 0.0 值。当资源跟踪器运行其下一个周期性任务 update_available_resource() 时，这些新的 16.0/1.5/1.0 值将被保存到计算节点表中。

有一个修复bug/1789654，即不在 ResourceTracker 中持久化零分配比例，以避免将 placement allocation_ratio 初始化为 0.0（因为分配比例 0.0 会乘以库存中的总金额，导致系统中显示 0 资源）。

用例

管理员希望通过 Placement API 设置计算节点上单个资源的分配比例，而该值不会被计算节点的资源跟踪器覆盖。

管理员选择仅使用配置文件来设置计算节点上的分配比例覆盖，并且不想使用 Placement API 来设置这些比例。

提议的变更

首先，我们建议将现有 CONF.cpu_allocation_ratio、CONF.ram_allocation_ratio 和 CONF.disk_allocation_ratio 选项的默认选项值从现有的默认值 0.0 更改为 None。我们更改的原因是该值将从 0.0 更改为 16.0、1.5 或 1.0，这很奇怪且令人困惑。

我们还将更改资源跟踪器，以仅当 cpu_allocation_ratio、ram_allocation_ratio 和 disk_allocation_ratio CONF 选项的值不为 ``None`` 时，才覆盖计算节点的分配比例到这些 CONF 选项的值。

换句话说，如果这些 CONF 选项中的任何一个设置为不是None 的值，则应将该 CONF 选项视为该资源类分配比例的完整覆盖值。即使管理员手动调整 Placement API 中资源类的分配比例，在下次运行 update_available_resource() 定期任务时，它也会被覆盖为 CONF 选项的值。

其次，我们建议添加 3 个新的 nova.conf 配置文件选项

• initial_cpu_allocation_ratio

• initial_ram_allocation_ratio

• initial_disk_allocation_ratio

这些将被用于确定在计算工作器首次启动并在 nova cell DB 中创建其计算节点记录以及在 placement 服务中创建相应的库存记录时，如何设置 VCPU、MEMORY_MB 和 DISK_GB 资源类的初始分配比例。如果计算服务的资源跟踪器无法在 placement 服务中找到它正在管理的计算节点的记录，则仅使用这些新的配置选项的值。

这些 CONF 选项的默认值应分别为 16.0、1.5 和 1.0。这是为了匹配在原始分配比例 CONF 选项设置为 0.0 之前，这些选项的默认值。

这些新的 initial_xxx_allocation_ratio CONF 选项仅在资源跟踪器检测到超visor 的 compute_nodes nova cell DB 中没有现有记录时才使用。

最后，我们还需要添加一个在线数据迁移，并继续从 DB 读取 xxx_allocation_ratio 或 initial_xxx_allocation_ratio 配置，如果值是 0.0 或 None。如果它是具有 0.0 值的现有记录，我们希望执行以下操作，即使用配置的 xxx_allocation_ratio 配置（如果它不为 None），否则使用 initial_xxx_allocation_ratio。

并添加一个在线数据迁移，更新所有具有 0.0 或 None 分配比例的 compute_nodes 表记录。然后，我们可以在某个时间点删除它，并使用阻止迁移来删除 nova.objects.ComputeNode._from_db_obj 中的代码，该代码会调整分配比例。

我们建议添加一个 nova-status 升级检查，以迭代单元格，查找具有 0.0 或 None 分配比例的 compute_nodes 记录，并将其标记为警告，表明您尚未执行在线数据迁移。我们还可以检查配置选项，看看它们是否显式设置为 0.0，如果是，我们应该使状态检查失败。

备选方案

无

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

无

其他部署者影响

无

开发人员影响

无

升级影响

我们需要对任何具有现有 0.0 和 None 分配比例的 compute_nodes 进行在线数据迁移。如果它是具有 0.0 值的现有记录，我们将用配置的 xxx_allocation_ratio 配置替换它（如果它不为 None），否则使用 initial_xxx_allocation_ratio。

注意

迁移来自现有 compute_nodes 表记录的 0.0 分配比例是必要的，因为基于这些表记录的 ComputeNode 对象是调度程序[1] 中使用的对象，特别是 NUMATopologyFilter 和 CPUWeigher（CoreFilter、DiskFilter 和 RamFilter 也使用它们，但这些过滤器已被弃用以供删除，因此这里不需要担心）。

并且显然，为了能够利用手动设置计算节点上分配比例的能力，该超visor 需要进行升级。对旧的计算主机没有影响。

实现

负责人

主要负责人

yikun

工作项

• 将 CONF.xxx_allocation_ratio 选项的默认值更改为 None。

• 修改资源跟踪器，仅当 CONF 选项不为 None 时，才在 compute node 对象上设置分配比例

• 添加新的 initial_xxx_allocation_ratio CONF 选项，并修改资源跟踪器的初始计算节点创建，以使用这些值

• 删除 ComputeNode._from_db_obj() 中更改分配比例值的部分代码

• 添加一个 db 在线迁移来处理所有具有现有 0.0 和 None 分配比例的 compute_nodes。

• 添加一个 nova-status 升级检查，用于检查 0.0 或 None 分配比例。

依赖项

无

测试

除了正常的单元和功能测试之外，没有特殊的测试

文档影响

应创建一个发行说明，解释新的 initial_xxx_allocation_ratio CONF 选项的使用，并创建更详细的管理员指南文档，解释以下主要场景

• 当部署者希望始终为计算节点上的资源设置覆盖值时。在这种情况下，部署者将确保 cpu_allocation_ratio、ram_allocation_ratio 和 disk_allocation_ratio CONF 选项设置为非 None 值。

• 当部署者想要为计算节点的分配比例设置一个初始值，但希望允许管理员稍后在不修改任何 CONF 文件的情况下调整此值时。此场景使用新的 initial_xxx_allocation_ratios 来设置初始比例值，然后展示部署者使用 osc placement 命令手动为资源提供程序上的资源类设置分配比例。

• 当部署者始终希望使用 Placement API 设置分配比例时，部署者应确保 CONF.xxx_allocation_ratio 选项全部设置为 None，并且部署者应发出 Placement REST API 调用到 PUT /resource_providers/{uuid}/inventories/{resource_class} [2] 或 PUT /resource_providers/{uuid}/inventories [3] 来根据需要设置资源的分配比例（或使用相关的 osc-placement 插件命令 [4]）。

参考资料

[1]

https://github.com/openstack/nova/blob/a534ccc5a7/nova/scheduler/host_manager.py#L255

[2]

https://developer.openstack.org/api-ref/placement/#update-resource-provider-inventory

[3]

https://developer.openstack.org/api-ref/placement/#update-resource-provider-inventories

[4]

https://docs.openstack.org/osc-placement/latest/

Nova Stein PTG 讨论

• https://etherpad.openstack.org/p/nova-ptg-stein

缺陷

• https://bugs.launchpad.net/nova/+bug/1742747

• https://bugs.launchpad.net/nova/+bug/1729621

• https://bugs.launchpad.net/nova/+bug/1739349

• https://bugs.launchpad.net/nova/+bug/1789654

历史

修订

发布名称	描述
Stein	提议