嵌套资源提供者¶

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_NET_VF 资源类，它由支持 SRIOV 的网络接口卡提供。在计算主机上存在多个支持 SRIOV 的网卡的情况下，可以为每个网卡标记不同的定性特征。例如，名为 enp2s0 的网卡可能具有一个特征“CUSTOM_PHYSNET_PUBLIC”，表明该网卡连接到名为“public”的物理网络。网卡 enp2s1 可能具有一个特征“CUSTOM_PHYSNET_INTRANET”，表明该网卡连接到名为“Intranet”的物理网络。我们需要一种方式来表示这些网卡各自提供 SRIOV_NET_VF 资源，但这些虚拟功能与不同的物理网络相关联。在资源提供者的数据建模中，与定性特征相关联的实体是 资源提供者 对象。因此，我们需要一种方式来表示支持 SRIOV 的网卡本身是具有 SRIOV_NET_VF 资源库存的资源提供者。这些资源提供者包含在计算主机上，而计算主机是一个资源提供者，它具有其他类型的资源（例如 VCPU、MEMORY_MB 或 DISK_GB）的库存记录。

本规范建议创建嵌套的资源提供者，以便区分某些资源提供者的复杂组件的详细信息。在审查期间，有人提出了关于将这些嵌套提供者的数量“汇总”到根级别的问题。想象一下这个场景：我有一个带有两个 PF 的网卡，每个 PF 只有一个 VF 可用，并且我收到一个请求 2 个 VF，没有用于区分它们的特征。由于没有单个资源提供者可以满足此请求，它将不会选择此根提供者，即使根提供者“拥有” 2 个 VF。本规范不建议对库存进行任何形式的“汇总”，但这可能是在未来需要考虑的事情。如果这是一个得到支持的想法，那么可以创建另一个 BP/规范来添加此行为。

用例¶

作为 NFV 云运营商，我希望请求我的 VNF 工作负载需要在标记为物理网络“public”的 NIC 上使用 SRIOV 虚拟功能，并且我希望能够以每物理网络为基础查看 SRIOV 虚拟功能的资源消耗情况。

作为 NFV 云运营商，我希望确保分配给我的工作负载的内存和 vCPU 位于特定的 NUMA 拓扑中，并且这些资源表示为每个 NUMA 节点的唯一库存并报告为单独的分配。

提议的变更¶

我们将向资源提供者数据模型添加两个新属性

parent_provider_uuid：指示直接父提供者的 UUID。对于根提供者，这将为 None。需要明确的是，资源提供者可以有 0 或 1 个父级。我们不支持资源提供者具有多个父级。
root_provider_uuid：指示位于提供者树“根”处的资源提供者的 UUID。对于 Nova 的使用，这将是与计算主机对应的资源提供者的 UUID。该字段允许我们实现高效的树访问查询，并避免使用递归查询来跟踪子节点->父节点关系。

将向 placement REST API 添加一个新的微版本，该版本将上述属性添加到适当的请求和响应有效负载中。

未来，调度器报告客户端可能会被修改为将 NUMA 节点和支持 SRIOV 的网卡跟踪为父计算主机资源提供者的子资源提供者。

未来的 NUMA 支持可能包括 NUMA 节点子提供者具有填充 NUMA_CORE、NUMA_THREAD 和 NUMA_MEMORY_MB 资源类的库存记录。 VCPU 和 MEMORY_MB 资源类将继续在父资源提供者（即计算节点资源提供者）上进行库存，而不是在 NUMA 节点子提供者上。当收到启动请求时，Nova API 服务需要确定请求（flavor 和 image）是否指定了特定的 NUMA 拓扑，如果是，则为适当的 NUMA_XXX 资源构建对 placement 服务的请求。这目前不在本规范的范围内。本规范仅关于使用适当的资源类对各种子提供者进行库存。

在 CPU 引脚方面，我们不计划允许计算节点充当通用计算节点或充当 NUMA 特定（固定）工作负载的目标。计算节点将是固定工作负载的目标，或者将是通用（浮动 CPU）工作负载的目标。尚不清楚我们将使用什么来指示计算节点针对浮动工作负载还是不针对浮动工作负载。最初的想法是使用 pci_passthrough_whitelist CONF 选项来确定这一点，但这仍然需要讨论。

备选方案¶

我们可以尝试从 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 调用中，将添加一个新的过滤器 in_tree={uuid}，当存在时，将返回所有资源提供者记录，包括根节点，其 root_provider_uuid 等于指示的提供者的 root_provider_uuid {uuid}。需要明确的是，考虑像

    A
   / \
  B   D
 /
C

指定任何 A、B、C 或 D 的 UUID 到 in_tree={uuid} 将返回树中的所有提供者 ({A, B, C, D})。

过滤器参数 in_tree={uuid} 将不会添加到 GET /allocation_candidates，因为没有用例需要它。

注意

还需要更多的工作才能使树模型可用于实际部署。 GET /allocation_candidates API 需要更新以处理请求的资源，这些资源分布在树中。并且需要在资源跟踪器和报告客户端（最终由 virt 驱动程序发起）中完成工作，以使用这些功能构建嵌套模型。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

无。

性能影响¶

无。

其他部署者影响¶

无。提供者树信息的设置和获取将完全在 nova-compute 工作器中处理，部署者无需进行任何更改。

开发人员影响¶

无。

实现¶

负责人¶

主要负责人: jaypipes
其他贡献者: cdent

工作项¶

添加 DB 模式和对象模型更改
添加带有资源提供者和分配候选者新属性的 REST API 微版本
添加带有 GET /resource_providers 上新的 in_tree={uuid} 过滤器的 REST API 微版本

请注意，本规范并非全部预期在一个发布周期内实现。在 Queens PTG 上，我们同意完全支持 NUMA 可能需要推迟到下一个版本。

依赖项¶

无。

测试¶

大部分的重点将放在 DB/服务器的功能测试以及本规范中描述的特定 NUMA 和 SRIOV PF 子级提供者场景的新功能测试上。

文档影响¶

应该编写一些 devref 内容。

参考资料¶

http://etherpad.openstack.org/p/nested-resource-providers

历史¶

修订版¶
发布名称	描述
Ocata	引入
Pike	重新提出
Queens	重新提出

嵌套资源提供者