可扩展资源跟踪

https://blueprints.launchpad.net/nova/+spec/extensible-resource-tracking

此蓝图引入插件来跟踪资源分配，允许操作员选择他们希望跟踪的资源，并允许开发人员在不更改现有代码的情况下添加资源类型。

问题描述

已分配的计算资源集在资源跟踪器中硬编码。这些资源的分配始终被跟踪，无论它们对云操作员是否相关。在许多情况下，操作员希望跟踪不同资源的用途或以不同的方式计算其用途。

为了支持此需求，我们需要一种易于开发其他资源跟踪组件的方式，以满足操作员的偏好，并使其成为可选的，以便只有对它们感兴趣或愿意承担任何相关性能影响的操作员才需要使用它们。

以下是一个基于依赖项部分中引用的 CPU Entitlement 蓝图的使用案例示例。

作为操作员，我希望为风味定义一个参数，称为 cu（计算单元）。对于用户来说，cu 代表使用该风味实例提供的 CPU 性能。在内部，cu 代表应分配给实例的物理 CPU 容量的比例。我希望根据以 cu 为单位测量的可用 CPU 容量将实例调度到服务器。

此用例描述了与 vcpu 不同的 CPU 度量，并且不能根据 vcpu 实现。资源跟踪器需要跟踪主机上使用的 cu 数量，并将 cu 容量报告给调度器。请注意，映射到 cu 的物理 CPU 比例取决于处理器的性能。因此，在这种情况下，操作员将不使用 vcpu，而是使用 cu。可以就其他资源做出其他选择。

提议的变更

建议的解决方案是为资源跟踪提供一个插件机制，并使插件的选择可配置。这包括资源跟踪器中的插件，用于表示计算资源，跟踪其使用情况，在声明中测试可用性，以及将资源信息传达给调度器。它还将包括调度器主机管理器的插件，用于解释和处理收到的资源信息。

当前，将计算资源信息提供给调度器的方式是通过数据库中的 compute_nodes 表。该表中的一个字段将用于传达表示资源信息的字典。

风味现有的 extra_specs 参数已经支持添加资源需求作为键值/对，因此 API 中不需要任何更改。但是，extra_specs 参数当前未保留在 instances 或 instance_system_metadata 表中，因此它将被添加。

将为资源跟踪器的计算资源插件定义一个基类，其中包含以下方法：

• 初始化插件

• 添加和删除实例

• 测试是否有足够的资源来支持新实例

• 报告资源信息

资源跟踪器将在启动时使用 stevedore 加载插件，并在资源跟踪器代码路径的现有点调用它们。方法执行期间发生的异常将被处理和记录。

插件将

• 定义为名称空间中的入口点：nova.compute.resources

• 在资源跟踪器配置选项中按名称选择：compute_resources

插件的资源信息将记录在数据库的 compute_nodes 表中的 stats 字段中。

将为主机管理器的资源使用者插件定义一个基类，其中包含以下方法：

• 读取资源信息

• 更新资源信息以反映调度器决策

主机管理器将在启动时使用 stevedore 加载插件，并在主机管理器代码路径的现有点调用它们，以使资源信息在主机状态中可用。方法执行期间发生的异常将被处理和记录。

插件将

• 定义为名称空间中的入口点：nova.scheduler.consumers

• 在主机管理器配置选项中按名称选择：scheduler_consumers

过滤器和权重可以在过滤器调度器中利用新的资源信息。过滤器还可以访问风味的 extra_specs，从而能够定义可以与主机状态中的新资源信息进行比较的新资源需求。

由于分布式系统的配置性质，可能会加载不一致的资源、使用者、过滤器和权重插件集。插件开发人员负责在缺少或意外信息的情况下插件的行为。围绕插件方法调用的异常处理将提供通用的错误处理和报告。

备选方案

我们建议的解决方案定义了两种类型的插件：资源跟踪器的计算资源和主机管理器的资源使用者。将实例添加到计算资源插件以及在资源使用者插件中消耗资源的逻辑本质上是相同的。这些可以实现为单个插件，该插件同时加载到这两个位置。采用双插件方法是为了避免在调度器从 nova 的其余部分分离之前，在调度器和 nova 的其余部分之间共享代码。

当此蓝图在 Icehouse 周期中首次实现时，决定资源数据将通过名为 extra_resources 的字段进行通信。该字段为此目的而创建并在 Icehouse-2 中合并。随后，进行了单独的更改以删除 compute_node_stats 表，并将统计信息放入 compute_nodes 表中。创建了 stats 字段用于此目的。

创建 stats 字段后，一直存在关于 extra_resources 字段的未来以及哪个字段应该用于此蓝图的争论。实施此蓝图后，计划将 stats 重构为资源插件。一个关键的决定因素是如何进行这种重构。

可以在不更改数据库中 stats 数据表示的情况下，将 stats 处理迁移到资源和使用者插件。因此，为了方便迁移，我们建议使用 stats 字段并删除 extra_resources 字段。

数据模型影响

蓝图使用了 compute node 表中的 extra_resources 字段来通信资源跟踪信息。该字段已添加到 Icehouse-2 中的数据库中，但尚未被使用。如上所述，这将删除并使用现有的 stats 字段代替。

将在 instances 表中添加 extra_specs 字段。

REST API 影响

此蓝图不影响现有的 REST API。可以使用现有的 extra_specs API 扩展为风味设置新的资源需求。

安全影响

此蓝图不会引入任何新的安全问题。插件的选择将由操作员确定，并且它们将在现有的路径上运行通信的数据。开发人员可以通过检查他们运行的数据的完整性来使他们的插件更健壮。

通知影响

此蓝图不会引入新的通知。

其他最终用户影响

此蓝图为操作员提供了扩展的资源管理功能。它不会超出实例放置影响最终用户。

性能影响

插件机制本身没有固有的性能影响，但性能可能会受到插件交换的数据量以及它们在插件方法中执行的任何操作的性能影响。

在实例创建、调整大小或迁移时，以及计算节点执行其定期资源更新时，将调用计算资源插件。

调度器中的使用者插件将在解释接收到的数据并更新主机状态时被调用。这些可能是轻量级操作。

其他部署者影响

插件将以以下方式配置

• nova setup.cfg 文件将包含插件的入口点

• compute_resources 配置选项选择计算资源插件

• scheduler_consumers 配置选项选择资源使用者插件

默认配置选项将是空列表，因此不会加载任何插件。这将确保只有在显式配置时，此新功能才会生效。

开发人员影响

开发人员将能够添加此功能的新插件。

实现

负责人

主要负责人

pmurray

其他贡献者

andrea-rosa-m

工作项

参见：https://review.openstack.org/#q,topic:bp/extensible-resource-tracking,n,z

前两个工作项目已经准备好进行审查

• 将资源插件机制添加到资源跟踪器

• 将资源使用者插件机制添加到主机管理器

• 将 extra_specs 添加到 instances 表并将其写入 instance_system_metadata

以下工作项目用于 housekeeping

• compute_nodes 表的 extra_resources 字段已合并到 Icehouse-2 中。现在它将被删除，因为采用了新的 stats 字段

依赖项

以下蓝图依赖于此蓝图

• https://blueprints.launchpad.net/nova/+spec/cpu-entitlement

• https://blueprints.launchpad.net/nova/+spec/network-bandwidth-entitlement

• https://blueprints.launchpad.net/nova/+spec/cache-qos-monitoring

测试

单元测试足以覆盖功能更改。

文档影响

配置选项是自动派生的。应在实施时列出新的插件。

参考资料

重构计算节点统计信息的原始蓝图：https://blueprints.launchpad.net/nova/+spec/stats-as-rt-extension

与此蓝图一起在 Icehouse 周期中提供的原始规范：https://wiki.openstack.org/wiki/ExtensibleResourceTracking