可扩展资源跟踪

总结

Nova 中定义了许多资源，包括磁盘、内存和 vCPU 数量。本规范的目的是支持一组可扩展的资源，以便可以为计算节点和实例定义新的资源。这些资源将可供调度器使用，并由计算管理器分配。

计算节点的资源具有有限的容量。大多数资源，包括磁盘、内存和 vCPU，都映射到物理对应物，通常通过虚拟化技术，但也可以创建完全抽象的资源类型，而无需映射。例如，提供商可以选择仅在一个计算节点上运行某种类型的一个实例。可以通过为计算节点定义新资源并将该资源的请求与实例类型关联来支持此简单的示例。

每个实例的资源需求都指定为它需要的每种类型资源的数量。调度器使用这些需求将其与具有足够可用资源的计算节点进行匹配。

主机上的计算管理器了解计算节点上可用的资源，并负责它们的分配和管理。由于它明确了解实际使用了哪些资源，因此计算管理器最终决定计算节点是否能够托管实例。

幸运的是，我们已经拥有许多所需的功能。风味具有 extra_specs 属性，允许我们定义实例的资源需求。过滤器调度器具有一个插件框架，允许添加使用扩展资源的新的过滤器和称重器。本规范的主题，并且缺乏扩展机制的领域是计算节点及其资源跟踪器。

我们需要

资源的模型
资源需求的模型
命名方案，以允许将资源需求与资源关联
计算节点的变化
- 资源配置 - 定义扩展资源
- resource_tracker - 跟踪扩展资源
- 声明 - 测试需求与可用的扩展资源
资源需求信息配置
- 风味中的资源需求
- 请求中的资源需求
- 实例中的资源需求
数据库的变化
- compute_nodes 处的扩展资源
- 实例中的扩展资源需求
调度器变化（过滤器调度器）
- 主机管理器 - 访问扩展资源
- 过滤器 - 使用扩展资源的示例
- 称重器 - 使用扩展资源的示例

资源模型和命名

资源模型

一个资源具有以下属性

名称 - 用于标识此资源
类型 - 资源类型名称，供人工查看
描述 - 简短的描述，供人工查看

计算节点处的每个资源都由某种形式的容量表示 - 这由资源跟踪器记录，并在调度和分配决策中使用。此信息保存在资源跟踪器中，并通过数据库传递给调度器中的 host_manager。现有资源的通用形式使用可用总量和已用量 - 但可以为扩展资源使用任何任意表示形式。

资源容量（示例）

resource total = 值（配置或发现 - 资源总量）
resource used = 值（跟踪 - 当前使用的资源量）

每个实例所需的资源由一组需求表示；通常，这在现有资源中是一个单独的值，例如内存量。此信息定义于风味中，传递到创建请求中以供调度器使用，以及计算管理器的 resource_tracker/claims，并由实例继承。

资源需求（示例）

resource required = 值（配置 - 所需量）

与资源相关的最终数量是限制，即可以提交的总量。同样，这可以是任意或复杂的信息，但通常是一个单独的值。限制是在调度器处根据其他属性和策略在过滤器中实现的函数计算的每个计算节点。限制与创建请求一起传递，并由 resource_tracker 声明使用。

资源限制（示例）

resource limit = 值（计算 - 可以分配的资源总量）

命名

资源的名称在给定的 OpenStack 部署中应该是唯一的。在所有情况下，资源都通过其名称来识别，这用于在调度器和资源跟踪器处从不同来源进行信息比较。

在某些情况下（例如风味，将在 extra_specs 中使用以保存信息），需要一个前缀：prefix:name。前缀也应与任何现有功能使用的前缀不同。

计算节点的变化

资源配置

计算管理器的资源跟踪器需要知道资源及其数量。获取数量的方式可能因资源类型而异，有些是配置的，有些是程序化发现的。资源的表示方式和计算容量的方式也可能不同。因此，我们将使用资源插件框架。

将为新的资源类型实现一个基本类以进行扩展。这些类将在运行时加载，因为它们在配置中被发现。这遵循过滤器调度器处过滤器/称重器类的模型。

现有资源跟踪器和声明类中的一些方法将被移动到资源基本类，以便可以以特定于资源的方式实现它们。该类还将提供一种将任意信息添加到字典的方法：这基于风味的 extra_specs 属性，并将用于将资源容量传递给调度器。不适用 extra_specs 前缀约定，但可以使用。

标准的内存、磁盘和 vCPU 资源可以以这种形式实现。

资源跟踪器

资源跟踪器将加载资源类。这些类将用于获取本地容量。此外，资源跟踪器会将 extra_specs 数据传递给资源类。

声明

声明类将被修改为使用资源类提供的测试方法。这些测试将把 extra_specs 数据作为参数传递。

资源需求配置

风味中的资源需求

风味已经定义了标准资源类型的属性。这些将继续用于向后兼容性。将使用 extra_specs 扩展来合并扩展资源需求。

风味具有一个名为 extra_specs 的属性，可以包含任意属性。如果 extra_specs 中的属性没有prefix:形式的前缀，则它们被解释为在调度器中指定功能，因此所有扩展都需要名称中的前缀。但是，对于我们的目的，没有必要进一步指定前缀，因为这些属性将由特定于资源类型的插件代码解释。 extra_specs 中的资源需求示例可能是

"extra_specs" : { "provider_name:my_resource" : 5, "std_name:another_resource" : 10}

请求中的资源需求

风味详细信息被添加到创建请求中的 filter_properties 中，因此 extra_specs 属性会传递给调度器，并可供过滤器和称重器使用，以及计算管理器，可以在那里将其提供给 resource_tracker。

实例中的资源需求

实例对象直接作为属性保存标准资源需求，这些需求是从风味继承的。它还具有对其风味 ID (instance_type_id) 的引用，该 ID 包含 extra_specs 信息。每当需要调度实例时，无论是创建还是迁移，风味详细信息都会复制到请求的 filter 属性中，因此在需要时始终可用，可以直接从请求的 filter_properties 中获取，或者通过使用 instance_type_id 获取风味间接获取。

尚未确定将需求复制到实例对象中是否有性能优势。

因此，扩展资源需求不会在用户访问实例详细信息时呈现。只能通过访问风味详细信息来访问它。

数据库的变化

数据库当前用于记录计算节点的状态。这也为信息从计算节点传递到调度器提供了一条途径。未来这可能会改变，以避免数据库成为调度瓶颈。

将进行数据库模式更改以支持 compute_nodes 表的扩展资源容量。在 Nova 中，越来越普遍的做法是将可扩展的数据结构表示为 JSON 字符串，而不是出于性能原因的附加属性值表。这里也将这样做。

compute_nodes 处的扩展资源

compute_nodes 表已经包含标准资源类型的列。将添加一个名为extra_resources的附加列，以保存 JSON 字符串，该字符串序列化节点处的扩展属性的容量信息。信息是任意的，并且仅由调度器处的资源特定插件解释。

调度器变化

调度器已经为过滤器和称重器提供了一个扩展框架，并且将风味属性放入过滤器属性中。主机管理器从数据库中提取主机状态。

主机状态

HostState 类将提供对扩展资源容量信息的访问。这需要对 update_from_compute_node() 方法进行小的更改。 HostState 还具有 consume_from_instance() 方法，该方法根据调度器中的分配决策更新类记录的资源。这将更改为允许新的扩展资源，并再次需要插件来实现该方法。插件的模式将与过滤器类相同。

过滤器

将提供使用扩展资源类型的过滤器的示例

称重器

将提供使用扩展资源类型的称重器的示例。

消费者

将提供使用扩展资源类型的消费者的示例（实现 HostState 的 consume_from_instance() 方法的插件类）。

与感知利用率调度的关系

https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling

此说明的目的是阐明 bp utilization-aware-scheduling 和 bp extensible-resource-tracking 之间的异同。发布的评论提到了 UBS（基于利用率的调度）。 bp utilisation-based-scheduling 自 2013 年 5 月以来未进行任何工作，并被放弃，转而支持 bp utilization-aware-scheduling，因此我认为“UBS”实际上指的是后者。

从表面上看，可扩展资源跟踪和感知利用率调度似乎相似：它们在计算节点处收集数据并将其传递给调度器。但是，这并不是全部，我认为它们所做的事情足够不同，应该保持分离。因此，让我们看看它们做了什么以及如何做。

utilization-aware-scheduling 使用“资源监控器”插件从主机环境、操作系统或设备获取实际使用信息。

extensible-resource-tracking 使用“资源分配器”插件从实例计算分配信息，并确定资源分配。

需要考虑的重要实现点在于计算节点处的各自插件以及它们如何与更新过程和资源声明过程交互。

ResourceTracker.update_available_resources() - 这是更新资源信息的主要方法。在此方法期间，它们执行以下操作

utilization-aware-scheduling

在此方法期间，每个资源监控器都会被调用以获取其数据。监控器可以在此时收集数据，或者可能一直在后台以持续的方式执行此操作（尽管我不知道是否已以这种方式实现过）。

extensible-resource-tracking

资源分配器分三个步骤更新（遵循现有过程）
- 调用方法进行初始化
- 对于节点上的每个实例（正在运行或未运行），调用方法以计算分配信息
- 调用方法以获取最终数据

ResourceTracker.instance_claim() - 这是确定节点是否有足够的未分配资源来支持新实例的主要方法。在此方法期间，它们执行以下操作