网络带宽资源提供者

https://blueprints.launchpad.net/nova/+spec/bandwidth-resource-provider

本规范建议添加表示网络带宽的新资源类，并在 Placement 中将网络后端建模为资源提供者。同时，为 Nova 添加对新资源的支持。

问题描述

目前 Nova 调度器中没有根据主机可用的网络带宽来放置服务器的方法。Placement 服务不会跟踪主机中存在的不同网络后端及其可用带宽。

用例

用户希望启动一个与特定物理网络关联的端口的服务器。用户还希望为该端口定义一个保证的最小带宽。Nova 调度器必须选择一个满足此请求的主机。

提议的变更

本规范建议 Neutron 对计算主机上物理 NIC 的带宽资源进行建模，并在 Placement 服务中将其资源提供者表达在 Neutron 端口中的带宽请求中，并修改 Nova 以在基于每个计算主机上可用带宽资源的情况下，在服务器调度期间考虑请求的带宽资源。

这也意味着本规范建议使用 Placement 和 nova-scheduler 来选择提供带宽的 RP，从而选择为给定 Neutron 端口提供带宽的物理设备。目前，物理设备的选择发生在 Neutron 端口绑定期间，但在本规范实施后，该选择将发生在 nova-scheduler 中为服务器选择分配候选时。因此，Neutron 需要在 Placement 中的 Networking RP 模型和端口的 resource_request 字段中提供足够的信息，以便 Nova 可以查询 Placement 并接收与 Neutron 端口绑定逻辑不冲突的分配候选。Networking RP 模型和新 resource_request 端口属性的模式在 Placement API 中的 QoS 最小带宽分配 Neutron 规范中描述。

请注意，目前如果 nova-scheduler 选择 Neutron 无法绑定端口的计算主机，Neutron 端口绑定可能会失败。本规范不旨在消除此限制，但我们也不希望增加此类端口绑定失败的频率，因为这会破坏系统的可用性。

职责分离

  • Nova 创建计算节点 RP 树的根 RP，就像今天一样

  • Neutron 在计算节点根 RP 下创建计算节点的网络 RP 树，并报告带宽库存

  • Neutron 在 Neutron API 中提供端口的 resource_request

  • Nova 接收端口的 resource_request 并将其包含在 GET /allocation_candidate 请求中。Nova 不需要理解或操作实际的资源请求。但 Nova 需要为每个端口的资源请求分配唯一的粒度资源请求组后缀。

  • Nova 选择一个分配候选并声明 Placement 中的资源。

  • Nova 将用于满足端口资源请求的 RP UUID 传递给 Neutron 进行端口绑定

范围

由于此功能的规模和复杂性，当前规范的范围有限。为了在功能完全实施之前保持向后兼容性，两个新的 Neutron API 扩展将是可选的，并且默认情况下处于关闭状态。Nova 将检查引入端口 resource_request 字段的扩展，如果未加载该扩展，则回退到当前的资源处理行为。

Nova 视角的范围之外

  • 支持为从 Neutron 端口的 resource_request 创建的粒度资源请求组单独的邻近策略。Nova 将使用 flavor extra_spec 中定义的策略，就像今天一样，这种策略是 allocation_candidate 请求的全局策略。

  • 在 nova-scheduler 中的 weigher 中处理 Neutron 机制驱动程序偏好顺序

  • 如果端口（传递或在传递的网络中创建）resource request 非空，则使用具有 QoS 最小带宽策略规则的端口或网络进行接口附加。由于 interface_attach 今天不调用 scheduler，Nova 将拒绝 interface_attach 请求。

  • 具有 QoS 最小带宽策略规则的网络服务器创建，因为该网络中的端口是在服务器调度决策之后由 nova-compute 创建的。本规范建议在 compute-manager 中使此类启动失败。

  • 绑定端口上的 QoS 策略规则创建或更新

  • 绑定父端口下的 QoS 感知 trunk 子端口创建

  • 由于 Neutron 不拥有裸机计算节点上的网络设备，因此具有 QoS 带宽策略规则的裸机端口超出范围。

场景

本规范需要考虑以下部分中详细描述的多个流程和场景。

Neutron agent 首次启动

在给定计算主机上运行的 Neutron agent 使用现有的 host neutron.conf 变量在 Placement 中找到与该主机相关的计算 RP。有关详细信息和原因，请参阅 查找计算 RP。

Neutron agent 在计算 RP 下创建网络 RP，并根据计算主机的发现和/或配置的资源库存报告资源库存。有关详细信息，请参阅 Placement API 中的 QoS 最小带宽分配。

Neutron agent 重启

在重启期间，Neutron agent 确保 Placement 中的 RP 树存在正确的库存和特征，如果需要则通过创建/更新 RP 树来确保。Neutron agent 仅修改由该 agent 创建的 RP 的库存和特征。此外，Neutron 仅修改实际添加或删除的部分。未修改的部分应保持原样（不删除并重新创建）。

使用预先创建的具有 QoS 策略规则的 Neutron 端口创建服务器

最终用户使用 Neutron API 创建 Neutron 端口，并直接或间接地通过将规则附加到创建端口的网络来附加 QoS 策略最小带宽规则。然后，最终用户在 Nova 中创建服务器，并在服务器创建请求中传递端口 UUID。

Nova 从 Neutron 获取端口数据。这已经在当前代码库的 create_pci_requests_for_sriov_ports 中发生。端口包含请求的资源和所需的特征。参见 端口中的资源请求。

create_pci_requests_for_sriov_ports() 调用需要重构为更通用的调用，该调用不仅生成 PCI 请求，还收集来自 Neutron 端口的请求资源。

nova-api 将请求的资源和所需的特征存储在 RequestSpec 对象的新字段 requested_resources 中。新的 requested_resources 字段不应持久化到 api 数据库中，因为它基于来自不同来源（在本例中为 Neutron 端口）的资源请求的计算数据，并且端口数据可能会在 Nova 之外发生变化。

nova-scheduler 使用 RequestSpec 中的此信息向 Placement 发送包含端口相关资源请求以及计算相关资源请求的分配候选请求。来自每个端口的请求资源和所需的特征将被限制为单个 RP，并如 granular-resource-request 规范中定义的单独编号请求组。这是必要的，因为将来自不同端口（例如，一个 OVS 和一个 SRIOV）的请求资源和所需的特征混合到 Placement 会导致空的分配候选响应，因为没有 RP 会同时具有 OVS 和 SRIOV 特征。

或者，我们可以扩展并使用 build_instance 代码路径的 requested_networks（NetworkRequestList ovo）参数来存储和通信来自 Neutron 端口的资源需求。然后，scheduler rpc 调用 select_destinations() 需要扩展一个包含 NetworkRequestList 的新参数。

需要修改 nova.scheduler.utils.resources_from_request_spec() 调用，以使用 RequestSpec 对象中新引入的 requested_resources 字段来生成适当的分配候选请求。

稍后，Neutron 端口 API 中的资源请求可以发展到支持 Nova flavor 资源覆盖功能所支持的相同粒度级别。

Placement 返回分配候选。在 nova-scheduler 中进行额外的过滤和加权后，调度器在 Placement 中以单个事务声明所选候选中的资源。创建的分配的 consumer_id 是 instance_uuid。参见 端口相关资源的消费者。

如果多个端口具有针对相同物理网络的 QoS 策略规则，则附加到服务器（例如，同一 PF 上的两个 VF），则结果分配是每个单独端口请求的资源数量之和。

删除具有 QoS 策略规则的端口的服务器

在正常删除期间，local delete 和 shelve_offload Nova 今天删除 Placement 中的资源分配，其中 consumer_id 是 instance_uuid。由于此分配将包括端口相关资源，因此这些资源也会被清理掉。

分离具有 QoS 策略规则的端口的接口

在 Neutron 和 hypervisor 中分离成功后，nova-compute 需要删除 Placement 中与分离端口相关的分配。服务器的其余分配不会更改。

服务器移动操作（冷迁移、撤离、调整大小、实时迁移）

在移动操作期间，Nova 在目标主机上进行分配，consumer_id == instance_uuid，同时源主机上的分配更改为 consumer_id == migration_uuid。这些分配集将包含端口相关的分配。如果移动操作成功，Nova 将删除目标主机上的分配。如果移动操作回滚，Nova 将清理目标主机上的分配。

由于端口相关的资源请求未持久化在 RequestSpec 对象中，Nova 需要在调用调度器之前从端口数据重新计算该请求。

使用 force host 标志（撤离、实时迁移）的移动操作不调用调度器。因此，为了确保处理每种情况，我们必须遍历 reportclient.claim_resources() 函数的每个直接或间接调用，并确保正确处理端口相关的资源。今天我们 盲目地将分配从源主机复制到目标主机，使用目标主机作为 RP。这将变得更加复杂，因为将有多个 RP 需要替换，并且 Nova 将很难弄清楚源主机的哪个 Network RP 映射到目标主机的哪个 Network RP。一种可能的解决方案是 通过调度器发送移动请求，无论 force 标志如何，但跳过调度器过滤器。

注意

在 Stein 中不支持具有资源请求的端口的服务器移动操作。

Shelve_offload 和 unshelve

在 shelve_offload 期间，Nova 删除资源分配，包括端口相关资源，因为它们也具有相同的 consumer_id，即实例 uuid。在 unshelve 期间，以与服务器创建案例中描述相同的方式进行新的调度。

注意

在 Stein 中不支持在 Shelve offload 之后进行 unshelve 操作，并且具有资源请求的端口。

详情

查找计算 RP

Neutron 已经依赖于 host conf 变量设置为 Nova 在 Neutron 端口绑定中使用的相同 ID。Nova 在端口绑定中使用主机名。如果 Neutron 配置中未定义 host，则它也默认为主机名。这样，Neutron 和 Nova 今天保持同步。可以使用相同机制（即主机名）在 Neutron agent 中找到 Nova 为相同计算主机创建的计算 RP。

在部署中使用非完全限定的主机名可能会导致歧义。例如，不同的 cell 可能会包含具有相同主机名的主机。这种主机名歧义在没有当前提出的功能的情况下也是一个问题，因为 Nova 使用主机名作为 Placement 中的计算 RP 名称，并且名称字段在 Placement db 模型中具有唯一约束。因此，在歧义情况下，具有非唯一主机名的 Nova 计算服务已经无法在 Placement 中创建 RP。

可以通过强制主机名是 FQDN 来解决歧义。但是，由于此问题不特定于当前提出的功能，因此此修复超出本规范的范围。override-compute-node-uuid 蓝图描述了一种可能的解决方案。

分离无 QoS 感知端口和 QoS 感知端口

如果同一物理端口上混合了支持QoS和不支持QoS的端口，则无法满足最小带宽规则。至少可以在两个层面上实现分离

  • 通过主机聚合分离计算主机。部署者可以在Nova中创建两个主机聚合，一个用于支持QoS的服务器，另一个用于不支持QoS的服务器。无需更改Nova或Neutron即可完成此分离。这是此功能第一个版本的提议解决方案。

  • 通过traits分离物理端口。Neutron agent可以将traits，例如 CUSTOM_GUARANTEED_BW_ONLY 和 CUSTOM_BEST_EFFORT_BW_ONLY 放入网络 RPs 中，以指示哪个物理端口属于哪个组。Neutron可以通过 neutron.conf 提供此可配置性。然后，Neutron可以为 QoS 感知的端口添加 CUSTOM_GUARANTEED_BW_ONLY trait，否则添加 CUSTOM_BEST_EFFORT_BW_ONLY trait。此解决方案将允许更好的粒度，因为服务器可以为其数据端口请求保证带宽，并可以接受控制端口上的最佳努力连接。此解决方案需要在 Neutron 中进行额外的工作，但在 Nova 中不需要额外的工作。此外，这将意味着没有 QoS 策略规则的端口也将至少有一个 trait 请求 (CUSTOM_BEST_EFFORT_BW_ONLY)，并且会导致 nova-compute 创建的端口出现调度问题。因此，只有在 nova端口创建移动到conductor 之后才能支持此选项。

  • 如果我们使用 *_ONLY traits，那么我们永远无法将它们组合起来，尽管这是期望的。例如，为某人保证10千兆卡的5千兆带宽，并让剩余带宽以最佳努力的方式使用，这是完全有意义的。为了允许这样做，我们只需要反转逻辑并使用 traits CUSTOM_GUARANTEED_BW 和 CUSTOM_BEST_EFFORT_BW。如果管理员仍然希望将保证和最佳努力流量完全分离，那么他/她永远不会将这两个 traits 放在同一个 RP 上。但如果需要，可以混合使用它们。即使是最佳努力流量的潜在饥饿（在保证流量旁边）也可以通过保留一些带宽库存来轻松解决。

备选方案

替代方案在本规范的各自子章节中讨论。

数据模型影响

将定义两个新的标准资源类来表示每个方向的带宽，分别命名为 NET_BW_IGR_KILOBIT_PER_SEC 和 NET_BW_EGR_KILOBIT_PER_SEC。选择 kbps 单位是因为 Neutron API 已经在 QoS 最小带宽规则 API 中使用此单位，并且我们希望保持单位同步。

RequestSpec 版本对象中添加了一个新的 requested_resources 字段，类型为 ListOfObjectField(‘RequestGroup’) 以存储来自 Neutron 端口的资源和 trait 请求。此字段不会持久化到数据库中。

InstancePCIRequest 版本对象中添加了一个新的字段 requester_id，以将从 Neutron 端口创建的 PCI 请求与从同一 Neutron 端口创建的资源请求连接起来。Nova 将使用 Neutron 端口的 port_id 填充此字段，并且 RequestGroup 版本对象的 requester_id 字段将用于将 PCI 请求与资源请求匹配。

Neutron spec 中的 Placement API 中的 QoS 最小带宽分配 将提出在 Placement 中对 Networking RP 子树进行建模。Nova 不依赖于这种模型的具体结构，因为 Neutron 将以不透明的方式提供端口的资源请求，并且 Nova 只需要盲目地将该资源请求包含到 GET allocation_candidates 请求中。

端口中的资源请求

Neutron 需要以类似于资源请求可以通过 flavor extra_spec 完成的方式，在端口 API 中表达端口的资源需求。目前，我们假设单个端口从单个 RP 请求资源。因此，Nova 将每个端口的资源请求映射到单个编号的资源请求组，如 granular-resource-request spec 中定义的。该规范要求编号资源组的名称具有 resources<integer> 的形式。Nova 将端口的 resource_request 映射到 allocation_candidate 请求中的第一个未使用的编号组。Neutron 不知道服务器创建请求中哪些端口一起使用，以及 flavor extra_spec 已经使用了哪些编号组，因此 Neutron 无法为这些端口分配唯一的整数 ID。

从实现的角度来看，这意味着 Nova 将为每个 Neutron 端口创建一个 RequestGroup 实例，基于端口的 resource_request，并将其插入到 RequestSpec.requested_resources 的末尾。

当使用 Neutron multi-provider 扩展时，并且逻辑网络映射到多个 physnet 时，端口的资源请求将要求所选网络 RP 具有网络映射到的其中一个 physnet traits。Placement 今天不支持这种 any-traits 类型的请求，但可以像 Placement 中用于 aggregate 选择的 member_of 查询参数一样实现。这将在单独的 spec any-traits-in-allocation_candidates-query 中提出。

物理资源消耗与声明的资源之间的映射

Neutron 必须确保 Placement 为端口分配的资源与端口从物理基础设施消耗的资源相同。为了能够做到这一点，Neutron 需要知道端口的资源请求与服务器的分配记录中的特定 RP（或 RPs）之间的映射，这些 RP 正在满足该请求。

Nova 将计算哪个端口由哪个 RP 满足，并且 RP UUID 将在端口绑定期间提供给 Neutron。

REST API 影响

Neutron REST API 的影响在单独的 Placement API 中的 QoS 最小带宽分配 Neutron spec 中讨论。

Placement REST API 需要扩展以支持查询具有至少来自请求 traits 列表的 RP 的分配候选者。此功能将在单独的 any-traits-in-allocation_candidates-query spec 中描述。

此功能还依赖于 granular-resource-request 和 nested-resource-providers 功能，这些功能会影响 Placement REST API。

将向 Nova REST API 添加一个新的 microversion，以指示服务器创建支持具有资源请求的端口。使用旧的 microversion 的服务器操作（例如，创建、interface_attach、move）涉及具有资源请求的端口将被拒绝。但是，对于这些服务器，使用旧的 microversion 仍将支持服务器删除和端口分离。

注意

即使使用新的 microversion，Stein 中的服务器移动操作也不受支持。

安全影响

无

通知影响

无

其他最终用户影响

无

性能影响

  • Placement API 将由 Neutron 用于创建 RPs，并且计算 RP 树的大小将会增长。

  • Nova 将向 Placement 发送更复杂的分配候选者请求，因为它将包含与端口相关的资源请求。

  • Nova 将计算每个端口的资源请求与在整体分配中满足该请求的 RP 之间的映射。

由于 Placement 今天似乎不是瓶颈，因此我们预计由于上述更改不会出现性能下降。

其他部署者影响

此功能会影响多个模块，并在 Nova、Neutron 和 Placement 之间创建新的依赖关系。

此外，部署者应注意，在此功能之后，由于 Neutron 管理的带宽限制，服务器创建和移动操作可能会失败。

开发人员影响

无

升级影响

今天，具有 QoS 最小带宽策略规则的 SRIOV 端口的服务器可能存在，对于它们，资源分配在调度期间不会在 Placement 中强制执行。升级到实现此功能的 OpenStack 版本将允许更改 Neutron 中的规则以感知 Placement（即请求资源），然后（实时）迁移服务器，并且在选择迁移的目标时，调度程序将强制执行最小带宽规则。还可以提供工具来搜索现有实例并尝试就地进行最小带宽分配。这样可以限制必要的迁移次数。

升级后，最终用户将看到 Nova API 的行为变化

  • 启动具有 QoS 最小带宽策略规则请求带宽资源的网络的服务器将失败。当前的 Neutron 功能提案引入了 QoS 策略规则以请求资源的可能性，但在第一次迭代中，Nova 仅支持预创建端口上的此类规则。

  • 将具有 QoS 最小带宽策略规则请求带宽资源的端口附加到正在运行的服务器将失败。当前的 Neutron 功能提案引入了 QoS 策略规则以请求资源的可能性，但在第一次迭代中，Nova 不支持 interface_attach 的此类规则。

Neutron 中的新的 QoS 规则 API 扩展和新的端口 API 扩展将被标记为实验性的，直到解决上述两个限制为止。

实现

负责人

主要负责人

  • balazs-gibizer (Balazs Gibizer)

其他贡献者

  • xuhj (Alex Xu)

  • minsel (Miguel Lavalle)

  • bence-romsics (Bence Romsics)

  • lajos-katona (Lajos Katona)

工作项

此规范未列出 Neutron 影响的工作项。

  • 将 RequestGroup 设为 ovo 并将新的 requested_resources 字段添加到 RequestSpec。然后将 resources_from_request_spec() 重构为使用新字段。

  • 实现 any-traits-in-allocation-candidates-query 和 mixing-required-traits-with-any-traits 在 Placement 中的支持。可以与以下工作项并行完成这项工作，因为 any-traits 类型的查询仅适用于一小部分用例。

  • 在 nova-api 中读取 Neutron 端口的 resource_request，并将请求存储在 RequestSpec 对象中。

  • 在 nova-scheduler 和 nova-conductor 中包含与端口相关的资源，并在 allocation candidate 请求中，并根据选择的候选者声明与端口相关的资源。

  • 在端口绑定期间将服务器的整个分配发送到 Neutron

  • 确保使用 force 标志处理端口资源的服务器移动操作通过调度程序进行处理。

  • 在成功的 interface detach 操作后从 Placement 中删除与端口相关的分配

  • 拒绝包含具有 QoS 策略规则的端口或网络的 interface_attach 请求，该规则请求资源。

  • 在 nova-compute 中检查，由 nova-compute 在服务器启动期间创建的端口在 Neutron API 中具有非空 resource_request，如果端口具有，则启动失败

依赖项

测试

将添加 Tempest 测试以及功能测试，以确保服务器创建操作、服务器移动操作、shelve_offload 和 unshelve 以及 interface detach 与 QoS 感知端口一起工作，并且资源分配正确。

文档影响

  • 关于如何使用 QoS 感知端口的用户文档。

参考资料

历史

修订版

发布名称

描述

Queens

引入

Rocky

经过多次讨论后重新编写

Stein

  • 重新提出，因为 Rocky 中尚未完成实现

  • 根据 Stein 中实现的内容进行更新