嵌套资源提供者¶
https://blueprints.launchpad.net/nova/+spec/nested-resource-providers
我们提议修改资源提供者的数据库模式、对象模型和 REST API，以允许表示不同资源提供者之间的层次关系。
问题描述¶
随着新的 placement API 的加入，我们现在有了新的方法来考虑系统中的定量资源。资源提供者包含各种资源类别的库存。这些库存是简单的整数数量，并且与分配记录一起，旨在回答以下问题
“此提供者有多少种类型的资源可用？”
“系统中正在消耗多少种类型的资源？”
“每个提供者针对每种类型的资源暴露了多少过量提交？”
在 placement API 中资源提供者模式的初始版本中，我们坚持一种简单的世界观，即资源提供者只能通过聚合关系相互关联。换句话说，资源提供者“X”只有当“X”与所有“S”的成员也关联的聚合“A”关联时，才能为其他资源提供者“S”的集合提供共享资源。
这种关系对于共享存储或 IP 池之类的东西来说非常有效。但是，某些类别的资源需要比聚合关联提供的多对多关系更强的父级->子级关系。处理计算主机上 NUMA 节点上的 VCPU/MEMORY_MB 资源以及处理计算主机上 NIC 上的 SRIOV_NET_VF 资源是父级->子级关系更合适的两个例子。
在 NUMA 节点的情况下，系统必须能够跟踪已分配给主机上每个单独 NUMA 节点的 VCPU 和 MEMORY_MB 的数量。将内存分配给客户机并让该内存跨越连接到不同 NUMA 节点的 DIMM 银行上的地址空间会导致性能次优，对于某些高性能客户机工作负载，这种惩罚是不可接受的。
另一个例子是 SRIOV 启用的网络接口卡提供的 SRIOV_NET_VF 资源类。在计算主机上存在多个 SRIOV 启用的 NIC 的情况下，可以为每个 NIC 标记不同的定性特征。例如，名为 enp2s0 的 NIC 可能具有特征“network:public”，指示该 NIC 连接到名为“public”的物理网络。NIC enp2s1 可能具有特征“network:intranet”，指示该 NIC 连接到名为“Intranet”的物理网络。我们需要一种方法来表示这些 NIC 都提供 SRIOV_NET_VF 资源，但这些虚拟功能与不同的物理网络相关联。在资源提供者数据建模中，与定性特征关联的实体是资源提供者对象。因此，我们需要一种方法来表示 SRIOV 启用的 NIC 本身是具有 SRIOV_NET_VF 资源库存的资源提供者。这些资源提供者包含在计算主机上，该计算主机是具有其他类型资源（例如 VCPU、MEMORY_MB 或 DISK_GB）库存记录的资源提供者。
用例¶
作为 NFV 云运营商，我希望请求我的 VNF 工作负载需要在标记为物理网络“public”的 NIC 上使用 SRIOV 虚拟功能，并且我希望能够以每物理网络为基础查看 SRIOV 虚拟功能的资源消耗情况。
作为 NFV 云运营商，我希望确保分配给我的工作负载的内存和 vCPU 位于特定的 NUMA 拓扑中，并且这些资源表示为每个 NUMA 节点的唯一库存并报告为单独的分配。
提议的变更¶
我们将向资源提供者数据模型添加两个新属性
parent_provider_uuid: 指示直接父级提供者的 UUID。对于绝大多数提供者来说，这将为 None，对于嵌套资源提供者来说，这很可能是计算主机的 UUID。
root_provider_uuid: 指示位于提供者树“根”处的资源提供者的 UUID。该字段允许我们实现高效的树访问查询并避免使用递归查询来跟踪子级->父级关系。
将向 placement REST API 添加一个新的微版本，该版本将上述属性添加到适当的请求和响应有效负载中。
调度程序报告客户端将被修改为跟踪 NUMA 节点和 SRIOV 启用的 NIC 作为父级计算主机资源提供者的子级资源提供者。
VCPU 和 MEMORY_MB 资源类将继续在父级资源提供者（即计算节点资源提供者）上进行库存，而不是 NUMA 节点子级提供者。NUMA 节点子级提供者将填充 NUMA_CORE、NUMA_THREAD 和 NUMA_MEMORY_MB 资源类的库存记录。当收到启动请求时，Nova API 服务需要确定请求（flavor 和 image）是否指定了特定的 NUMA 拓扑，如果是，则为适当的 NUMA_XXX 资源构建对 placement 服务的请求。这目前不在此规范的范围内。此规范仅涉及使用适当的资源类对各种子级提供者进行库存。
在 CPU 引脚方面，我们不计划允许计算节点充当通用计算节点或充当 NUMA 特定（固定）工作负载的目标。计算节点将是固定工作负载的目标，或者将是通用（浮动 CPU）工作负载的目标。尚不清楚我们将使用什么来指示计算节点针对浮动工作负载还是不针对浮动工作负载。最初的想法是使用 pci_passthrough_whitelist CONF 选项来确定这一点，但这仍然需要讨论。
此规范将仅确保如果 virt 驱动程序在其 get_available_resource() 调用结果中返回 NUMATopology 对象，则我们将创建代表这些 NUMA 节点的子级资源提供者。 同样，如果 PCI 设备管理器返回计算主机上的 SR-IOV 物理功能集，我们将为这些 SR-IOV PF 创建子级资源提供者记录。
备选方案¶
我们可以尝试从 GET /resource-provider[s] REST API 响应有效负载中隐藏 root_provider_uuid 属性，以降低 API 的复杂性。但是，我们仍然需要一个 REST API 调用，该调用“获取树中的所有资源提供者”，其中用户将传递一个 UUID，我们将查找所有将该 UUID 作为其根提供者 UUID 的资源提供者。
与其采用嵌套资源提供者的概念，我们可以强制部署者为每个物理网络特征的排列创建自定义资源类。例如，假设上面的示例，运营商需要创建 SRIOV_NET_VF_PUBLIC_NET 和 SRIOV_NET_VF_INTRANET_NET 自定义资源类，然后手动将计算节点资源提供者的库存设置为每个 PF 暴露的 VF 数量。这种方法的弊端有两个。首先，我们不再对 SRIOV_NET_VF 资源类进行任何标准化。其次，我们再次将定性和定量方面结合在一起，这是现有 Nova 代码库中的问题之一，也是为什么难以标准化资源跟踪和调度。
数据模型影响¶
将向 resource_providers DB 表添加两个新字段
root_provider_uuid: 这将使用在线数据迁移填充，该迁移会将所有现有资源提供者的 root_provider_uuid 设置为 resource_providers.uuid 字段的值。
parent_provider_uuid: 这将是一个可为空的字段，默认值为 NULL
REST API 影响¶
root_provider_uuid 和 parent_provider_uuid 字段将添加到适当的 placement REST API 的相应请求和响应有效负载中。
在 GET /resource-providers 调用中，将添加一个新过滤器 root={uuid}，当存在时，将返回所有资源提供者记录，包括根记录，其 root_provider_uuid 等于 {uuid}。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
无。
其他部署者影响¶
无。提供者树信息的设置和获取将完全在 nova-compute 工作器中处理，部署者无需进行任何更改。
开发人员影响¶
无。
实现¶
负责人¶
- 主要负责人
jaypipes
- 其他贡献者
cdent
工作项¶
添加 DB 模式和对象模型更改
添加用于添加资源提供者新属性的 REST API 微版本
添加用于添加 root={uuid} 过滤器到 GET /resource-providers 的 REST API 微版本
添加代码到调度程序报告客户端，以跟踪 NUMA 节点作为父级计算主机资源提供者的子级资源提供者
添加代码到调度程序报告客户端，以跟踪 SRIOV PF 作为父级计算主机资源提供者的子级资源提供者
依赖项¶
无。
测试¶
大部分的重点将放在 DB/服务器的功能测试以及本规范中描述的特定 NUMA 和 SRIOV PF 子级提供者场景的新功能测试上。
文档影响¶
应该编写一些 devref 内容。
参考资料¶
历史¶
无。
