资源提供者 - 分配

https://blueprints.launchpad.net/nova/+spec/resource-providers-allocations

此蓝图规范解释了将存储已分配/指定资源数量的数据从旧模式迁移到在 resource-providers 规范中引入的新模式的过程。

问题描述

在 compute-node-inventory-newton 工作中，我们通过资源跟踪器同时将数据写入子单元数据库（通过现有的 ComputeNode.save() 调用）以及写入 API 数据库中的新的 resource-providers inventories 表（通过新的 ResourceProvider.set_inventory() 调用）来填充新的资源提供者 inventories 表。

我们需要以类似的方式填充 API 数据库中新的 resource-providers allocations 表中的资源分配信息。

用例

作为选择使用共享存储解决方案来存储实例临时磁盘的部署者，我希望 Nova 和 Horizon 报告正确的用法和容量信息。

提议的变更

我们建议资源跟踪器通过调用两个新的 placement REST API 方法来填充 API 数据库中的分配信息。当实例在本地计算节点上声明资源（无论是新实例还是迁移实例）时，将调用 PUT /allocations/{consumer_uuid}。当实例被终止或从计算节点迁移时，将调用 DELETE /allocations/{consumer_uuid}。请注意，generic-resource-pools 规范包括实现上述 placement REST API 调用的服务器端更改。

这些调用将除了现有的对 ComputeNode.save() 和 Instance.save() 的调用之外进行，这些调用当前将分配和使用信息分别保存在子单元的 compute_nodes 和 instance_extra 表中。

注意：在 Newton 中，我们计划让资源跟踪器将分配记录发送到 placement API，用于以下资源类：VCPU、MEMORY_MB、DISK_GB、PCI_DEVICE。对于 NUMA 拓扑类和 SRIOV_NET_*，这些资源类将在 Ocata 中处理，当嵌套资源提供者的工作稳定时。

备选方案

我们可以继续以我们当前所做的各种字段存储格式来存储分配的资源量。但是，添加新的资源类/类型几乎不可避免地会导致将另一个字段添加到数据库模式中，并针对 Nova 引入一种全新的计算方式。

数据模型影响

无。

REST API 影响

无。

安全影响

无。

通知影响

无。

其他最终用户影响

无。

性能影响

在一段时间内，资源跟踪器通过 placement HTTP API 进行额外调用的行为会对性能产生负面影响。这种影响应该很小，不会对租户造成破坏。

其他部署者影响

显然，要使此功能正常工作，需要部署新的 placement REST API（在 generic-resource-pools 蓝图中实现）。这使得 generic-resource-pools 成为此功能的明确依赖项。

开发人员影响

没有。新的 placement API 当然需要进行良好的文档记录，但此更改不会在阅读新的 placement API 之外引入任何特定的开发人员影响。

实现

从 generic-resource-pools 规范中回顾一下，存在两个 placement REST API 调用，用于创建和删除针对资源提供者的分配（使用量）记录集

  • PUT /allocations/{consumer_uuid}

  • DELETE /allocations/{consumer_uuid}

资源跟踪器将调用 PUT API 调用，提供实例（消费者）在计算节点（资源提供者）上获得分配的所有资源量。 PUT API 调用以事务方式写入所有分配记录（每个消耗的资源类一个），确保没有部分更新。

当实例被终止时，将从资源跟踪器发出相应的 DELETE API 调用，该调用将原子地删除该实例（消费者）在计算节点（资源提供者）上的所有分配记录。

在资源跟踪器的定期 update_available_resource() 方法期间，也将对现有实例进行 PUT API 调用的调用。

返回 404 Not Found 的 DELETE API 调用将简单地在 Nova 计算节点上被忽略。

注意

nova-api 服务的“本地删除”功能即使在与运行实例的 nova-compute 的连接中断时，也可以在单元数据库中射入实例记录。在这种情况下，我们将依赖于资源跟踪器 update_available_resource() 方法中的审核过程，以正确调用 placement API 中不再存在的实例的 DELETE 操作。

在构造 PUT placement API 调用的有效负载时，资源跟踪器应检查 Instance 对象（和/或 Migration 对象），以获取不同资源类别的各种使用信息。URI 的 consumer_uuid 部分应为实例的 uuid 字段值。 resource_provider_uuid 应为计算节点的 UUID，除非使用共享存储或从卷启动（请参阅下面的说明）。有效负载的“allocations”字段是一个字典，其键是适当的 nova.objects.fields.ResourceClass 枚举值的字符串表示形式（例如“VCPU”或“MEMORY_MB”）。

以下方式处理各种资源类

  • 对于 MEMORY_MB 和 VCPU 资源类，使用 Instance.flavor.memory_mb 和 vcpus 字段值

  • 对于 DISK_GB 资源类，遵循以下规则

  • 当计算节点使用本地存储来存储实例磁盘或从卷启动时，应使用的值应为 flavor 的 root_gb、ephemeral_gb 和 swap 字段值的总和。 resource_provider_uuid 应为计算节点的 UUID。请注意，对于从卷启动的实例，root_gb 的值将为 0。

  • 当计算节点使用共享存储来存储实例磁盘并且实例未从卷启动时，应使用的值应为 flavor 的 root_gb、ephemeral_gb 和 swap 字段值的总和。 resource_provider_uuid 最终应为该共享磁盘存储的资源提供者的 UUID。但是，在云管理员创建共享存储池的资源提供者并将该提供者通过主机聚合关联与计算节点关联之前，资源跟踪器无法知道该共享存储提供者的 UUID。

  • 如果 pci_devices 表包含任何将实例 UUID 链接到 ALLOCATED 状态下的任何 PCI 设备的记录，则为具有 dev_type 为 type-PCI 的记录创建一个分配记录。 type-PCI dev_type 表示通用的 PCI 设备。我们尚未为与 SR-IOV 设备对应的更复杂的 PCI 设备类型创建分配记录。记录的值应该是 type-PCI 设备的总数。例如，如果一个实例与计算节点上的两个通用 PCI 设备相关联，资源跟踪器应将一个元素添加到 PUT 有效负载的“allocations”字典中，如下所示

    "PCI_DEVICE": 2

注意

我们不会在 Newton 中为 SR-IOV PCI 设备或 NUMA 拓扑资源创建分配记录。这些分配记录及其相关的库存记录将在 Ocata 中完成。

负责人

主要负责人

jaypipes

其他贡献者

cdent

工作项

此规范的实施涉及以下不同的任务

  • 修改资源跟踪器以通过调用 placement HTTP API 为上述所有资源类创建分配记录。

  • 添加完整的集成功能测试，以验证 API 数据库中的分配表是否正在使用正确的数据填充。

依赖项

  • resource-classes 蓝图必须在此之前完成。

  • generic-resource-pools 蓝图必须在此之前完成。

  • compute-node-inventory-newton 蓝图必须在此之前完成，因为它确保每个计算节点都作为具有 UUID 的资源提供者添加。

测试

必须添加完整的单元和集成功能测试，以证明分配相关字段的迁移以适当且向后兼容的方式完成。

文档影响

无。

参考资料

[1] 与资源使用报告和计算相关的错误