QoS 最小保证包速率¶

https://blueprints.launchpad.net/nova/+spec/qos-minimum-guaranteed-packet-rate

与带宽可能成为网络接口的限制因素类似，包处理能力往往是像 OVS 这样的软交换解决方案的限制因素。同时，某些应用程序不仅依赖于保证的带宽，还依赖于保证的包速率才能正常工作。OpenStack 已经通过最小带宽 QoS 策略规则支持带宽保证。本规范旨在添加对类似最小包速率 QoS 策略规则的支持。

为了支持新的 QoS 规则类型，Neutron 和 Nova 都需要扩展。本规范涵盖这些影响的高层描述、Neutron、Placement 和 Nova 之间的交互。并包含 Nova 特定更改的详细信息。有关 Neutron 影响的详细描述，请参阅 Neutron 规范。

问题描述¶

OpenStack 需要通过新的 QoS 策略规则类型，为 Neutron 端口提供最小包速率保证的支持。

用例¶

我作为管理员希望定义我的 OVS 软交换机每计算节点能够处理的最大包速率，以千包每秒 (kpps) 为单位，以便避免 OVS 过载。

作为最终用户，我希望定义 Neutron 端口需要为我的 Nova 服务器提供的最小包速率，单位为千包每秒 (kpps)，以便使用该端口的应用程序能够按预期工作。

作为管理员，我希望将具有此类端口的 Nova 服务器放置在能够仍然提供 Neutron 端口请求的最小包速率的计算节点上，以便应用程序获得其请求的内容。

作为管理员，我希望在服务器的 Neutron 端口请求的最小包速率保证无法在任何其他符合条件的计算节点上满足的情况下，拒绝 Nova 服务器生命周期操作，以便避免 OVS 过载并保持应用程序保证。

提议的变更¶

整个解决方案非常相似，并且提议的实现严重依赖于已经实现的 qos 保证最小带宽功能。

新的资源¶

该解决方案需要区分两种部署场景。

数据包处理功能是在共享硬件上实现的（例如，在相同的计算主机 CPU 上），因此入站和出站队列都由相同的硬件资源处理。这在非硬件卸载的 OVS 部署中是这种情况。在这种情况下，OVS 代表单个数据包处理资源池。这可以用一个新的资源类来表示，即 NET_PACKET_RATE_KILOPACKET_PER_SEC。
数据包处理功能是在专用硬件上实现的，其中入站和出站队列由独立的硬件资源处理。这是硬件卸载的 OVS 的情况。在这种情况下，单个 OVS 具有两个独立的资源池，一个用于传入数据包，一个用于传出数据包。因此，需要用两个新的资源类来表示这些资源：NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC 和 NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC。

注意

在数据包速率资源上下文中，1 千包表示 1000 个数据包。

需要将这些新的资源类添加到 Placement 的 os-resource-classes 库中。

数据包处理资源清单¶

带宽资源建模在 OVS physnet 网桥上，因为每个网桥连接到特定的物理 NIC，该 NIC 提供带宽资源。由于数据包处理资源由 OVS 服务本身提供，因此需要在对整个 OVS 服务全局的实体上建模数据包处理资源。今天我们有这样一个实体，即 Neutron OVS 代理本身。这假设一个 Neutron OVS 代理只处理一个 OVS，这是今天的情况。我们认为这是一个很强的假设。如果以后需要在同一计算主机上需要两个交换机，我们认为复制处理它们的代理比增强当前代理以处理两个交换机更容易。

资源清单报告¶

有关这些 Neutron 更改的详细信息，请参阅 Neutron 规范。

Neutron OVS 代理需要提供配置选项，供管理员定义 OVS 每计算节点的最大数据包处理能力。根据部署场景，这可能意味着单个无方向性清单值，或者两个有方向性的值。
Neutron 代理需要通过代理心跳将配置的容量传达给 Neutron 服务器。
Neutron 服务器需要向 Placement 的 Open vSwitch agent 资源提供程序报告 NET_PACKET_RATE_KILOPACKET_PER_SEC 或 NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC 资源清单。

请求最小包速率保证¶

有关这些 Neutron 更改的详细信息，请参阅 Neutron 规范。

需要通过新的最小包速率 QoS 规则类型扩展 Neutron QoS API。这种类型的规则需要像其他 QoS 规则一样持久存储在 neutron DB 中。

为了支持两种不同的 OVS 部署场景，我们需要两组新的最小保证 QoS 规则类型。一组是无方向性的，以支持资源也是无方向性的情况。另外两组是有方向性的，以支持资源也是有方向性的部署情况。

具有新的 QoS 策略的 Nova 服务器¶

今天，Neutron 通过 resource_request 字段表达端口的资源需求。该字段的值旨在以通用、机器可读的方式传达资源需求。Nova（以及间接的 Placement）在服务器调度期间使用它来确定哪个计算主机可以满足服务器的整体资源需求，包括服务器的端口。到目前为止，端口只能拥有带宽资源请求。

为了支持新的包速率资源，Neutron API 需要更改，以便端口的 resource_request 只读字段可以包含多个请求的资源组和所需的 traits。今天，resource_request 的内容在调度期间被转换为单个命名的 Placement 请求组。由于单个端口可以应用带宽和包速率 QoS，并且因为带宽是从网桥/物理设备分配的，而包速率资源是从整个 OVS 实例分配的，因此需要分别请求这两组资源。这样做的技术原因是 Placement 中的单个命名资源请求组始终从单个资源提供程序分配。因此，如果带宽和包速率不需要来自相同的资源提供程序，则应在不同的资源请求组中请求它们。

resource_request 的新格式是

{
    "request_groups":
    [
        {
            "id": <some unique identifier string of the group>
            "required": [<CUSTOM_VNIC_TYPE traits>],
            "resources":
            {
                NET_PACKET_RATE_[E|I]GR_KILOPACKET_PER_SEC:
                <amount requested via the QoS policy>
            }
        },
        {
            "id": <some unique identifier string of the group>
            "required": [<CUSTOM_PHYSNET_ traits>,
                         <CUSTOM_VNIC_TYPE traits>],
            "resources":
            {
                <NET_BW_[E|I]GR_KILOBIT_PER_SEC resource class name>:
                <requested bandwidth amount from the QoS policy>
            }
        },
    ],
   "same_subtree":
    [
        <id of the first group from above>,
        <id of the second group from above>
    ]
}

有关原因，请参见 Neutron 规范

需要扩展 Neutron 端口绑定 API。今天，binding:profile 中端口的 allocation 键由 Nova 用于传达 resource_request 从哪个资源提供程序满足的 UUID。然后，Neutron 的端口绑定逻辑使用它将端口绑定到 Placement 资源分配的相同物理设备。现在，端口可以从多个 Placement 资源提供程序请求资源，单个 UUID 无法传达这些资源分配在哪些地方。Nova 需要提供一个映射，描述哪些资源（也称为哪个请求组）从 Placement 中的哪个资源提供程序满足。

有关新结构的详细信息，请参阅 Neutron 规范

使 Nova 适应 Neutron 的更改¶

Nova 需要适应 Neutron 端口的 resource_request 字段的结构和语义变化。今天，Nova 将该字段转换为单个命名的资源请求组。在 Neutron 更改之后，该字段将传达一个这样的请求组列表。
Nova 还假设今天端口只从单个资源提供程序分配资源。需要删除此假设，并且实现需要支持这样的资源提供程序列表。Nova 仍然可以假设单个 Placement 请求组由单个资源提供程序满足，因为这是 Placement 的不变行为。

这些 Nova 更改需要应用于 Nova 中导致新的调度尝试的每个代码路径，包括

服务器创建
迁移、调整大小、撤离、实时迁移、卸架后恢复
接口附加和分离

超出范围¶

支持 OVS 后端以外的最小包速率策略超出范围，但以后可以使用类似的提案来处理。

本规范仅旨在为包速率提供调度时间保证。新策略的数据平面实施超出范围。当包速率限制策略规则功能实施时，可以通过将最小和最大包速率 QoS 规则添加到相同的 QoS 策略中来应用基本的数据平面实施，其中最大限制设置为等于最小保证。

备选方案¶

数据包处理资源清单¶

或者有人建议在 OVS 网桥级别定义数据包处理清单。将 pps 资源表示在与带宽资源相同的 OVS 网桥上，其主要优点是简化了整体设计。这意味着我们可以继续保持资源请求端口始终从单个资源提供程序满足的假设。因此，resource_request 和 binding:profile.allocation 的格式不需要更改。但是，有一系列反对这个方向的论点

如果我们在网桥上定义数据包处理能力，那么如果有多个网桥，整个 OVS 的数据包处理能力需要静态地在网桥之间分割，而 OVS 的实际资源使用情况并没有以这种方式分割。今天，使用多个网桥是可能的，即使在经常使用一个 phynet 网桥用于 VLAN 流量和一个隧道网桥用于 VXLAN 流量的情况下。
对于带宽，实际资源位于 physnet 网桥之后，即网桥连接到的物理接口，因此资源专用于该网桥。但对于数据包处理，实际资源根本不是专用于给定的网桥，而是专用于整个 OVS 实例。因此，虽然我们可以将一部分整体资源分配给网桥，但这种分配永远无法很好地代表现实。
主机上 VM 之间的流量不会流经 physnet 或隧道网桥，但它会影响主机上 OVS 的容量。
虽然目前提议的设计更改意义重大，但它使解决方案更具未来可扩展性。例如，对于 IP 池资源处理将被重构以使用端口的 resource_request 时，我们无论如何都需要能够处理另一个资源提供程序，该资源提供程序与任何现有资源提供程序不同，因为 IP 地址是多个主机之间的共享资源。

另一种替代方案是将数据包处理能力表示在映射到 br-int 的新提供程序上，即 OVS 集成网桥，VM 连接到该网桥。这样做的优点是资源清单将是 OVS 实例级别的全局资源，并且它还可以消除一些由单独的 OVS Agent RP 引起的混淆。进一步发展，我们甚至可以考虑放弃 Agent RP 并仅在 Placement 中使用资源提供程序层次结构来表示网桥层次结构。从逻辑上讲，这与我们今天将 OVS Agent RP 重命名为 br-int RP 没有区别。但是，我们同意将此作为未来的练习，如果每个 OVS 代理需要更多 OVS 实例时再进行处理。

请求最小包速率保证¶

或者有人建议，只需一组有方向性的 QoS 规则类型就足够了。然后，在正常的 OVS 部署场景中，资源是无方向性的，可以先将来自有方向性 QoS 规则的资源请求加在一起，然后再与单个无方向性资源清单进行匹配。Neutron 可以根据端口的 vnic_type 在端口级别区分这两种部署情况。normal vnic_type 表示请求端口由具有无方向性资源核算的正常 OVS 支持。而 direct vnic_type 表示请求端口由硬件卸载的 OVS（或非 OVS 后端，如 SRIOV）与有方向性的资源清单支持。

数据模型影响¶

预计不会对 Placement DB 模式进行更改。

有关 Neutron DB 更改，请参阅 Neutron 规范。

预计不会对 Nova DB 模式进行更改。

预计会进行一些 Nova o.v.o 更改。

RequestSpec 对象已经存储了一个 RequestGroups 列表，因为它需要支持每个实例的多个端口和 cyborg 设备。

RequestGroup 对象不假定 requester_id 字段的格式。但是，驱动 PCI 声明基于已经分配的带宽的 Nova 的部分假定 InstancePCIRequest.requester_id 与 RequestGroup.requester_id 相同。为了便于区分同一端口请求的不同组，需要删除此假设。我们需要在 RequestGroup 对象中添加一个新字段 group_id，该字段存储来自 requested_resources 的组 ID，同时将 requester_id 保留为今天的 port_id。PCI 请求更新逻辑需要更改为使用具有带宽资源的组来驱动 PCI 声明。这会产生 Nova 代码与 resource_request 内容之间的不幸依赖关系。一旦我们开始在 Placement 中建模 PCI 设备，就可以删除此依赖关系。

RequestLevelParams 对象也需要扩展，以存储来自 resource_request 字段的 same_subtree 字段的 same_subtree 请求列表。

请参阅端口的 binding:profile 中 allocation 键的处理方式的更改，以及这可能会如何影响 Neutron 规范。

Placement 中与 Neutron 相关的资源提供者模型需要扩展，添加一个新的库存，包括 OVS 代理资源提供者上的 NET_PACKET_RATE_KILOPACKET_PER_SEC、NET_PACKET_RATE_EGR_KILOPACKET_PER_SEC 和 NET_PACKET_RATE_IGR_KILOPACKET_PER_SEC 资源，如果管理员在相关的代理配置中配置了这些资源库存。此外，目前仅应用于桥接和设备 RP 的 CUSTOM_VNIC_TYPE_ 需要在 OVS Agent RP 上报告，以便进行适当的调度。请注意，由于该资源不会在可用的 physnet 之间拆分，因此不需要 CUSTOM_PHYSNET_ 特性用于数据包速率调度。

REST API 影响¶

有关 Neutron REST API 更改，请参阅 Neutron 规范。

此功能不会更改 Nova API，只是调整 Nova 以能够使用新的 Neutron API 扩展。即使使用最新的 Nova 微版本，在 Wallaby Neutron 和 Xena Nova 中，也无法通过单独的 Nova 微版本向最终用户发出该功能可用性的信号。因此，现在将添加微版本更新。我们建议的是，最终用户根据管理员为他们创建的 QoS 策略来决定功能的可用性。如果 QoS 策略中包含新的最小保证 QoS 策略规则，则最终用户可以确信该功能可用。请参阅 IRC 日志以获取更多讨论。

如果由于范围限制，当前发布周期未实现某些生命周期操作的支持，则这些操作将使用 HTTP 400 状态码被拒绝。

安全影响¶

无

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

在服务器生命周期操作期间，将对 Neutron GET /extensions API 进行额外的调用，以检测 Neutron 使用的 resource_request 格式以及 Neutron 期望的 binding:profile.allocation 格式。这只是为了支持升级场景，在这种场景中，Nova 已经升级到 Xena，但 Neutron 没有。在 Y 版本中，我们可以删除额外的调用，并假设 Neutron 始终返回新的格式。

其他部署者影响¶

Nova 建议不提出新的配置选项，但要使用此功能，Neutron 需要正确配置。有关详细信息，请参阅 Neutron 规范。

开发人员影响¶

无

升级影响¶

OpenStack 需要支持 Neutron 和 Nova 的主要版本不同的部署。这意味着该功能的变化需要编写以支持两种情况。

Wallaby Neutron - Xena Nova
Xena Neutron - Wallaby Nova

Neutron 将引入一个新的 API 扩展，该扩展将更改端口的 resource_request 字段的结构和语义。Nova 需要检查新 API 扩展的存在，并相应地解析该字段。

Neutron 需要通过配置标志使此扩展成为可选的。这样，即使 Neutron 升级到 Xena，也不会显示该扩展和新的 API 行为，以便 Wallaby Nova 仍然可以与 Neutron 成功交互。

另一方面，Xena Nova 需要理解 Neutron 仍然处于 Wallaby 级别时的旧 Neutron API，以及 Neutron 也升级到 Xena 时的新的 API。

在 Nova 完全支持新的 Neutron API 扩展之后，可能在 Xena 之后，Neutron API 扩展可以在 Neutron 中强制使用。然后，可以从 Nova 中删除对 resource_request 字段的旧格式的支持。

由于影响 nova-compute 服务的更改，将引入一个新的服务版本。如果启用了新的 Neutron API 扩展，但部署中存在不支持新扩展的旧服务版本的计算服务，Nova 将使用 HTTP 400 状态码拒绝任何生命周期操作（服务器创建、删除、迁移、调整大小、撤离、实时迁移、卸架后恢复、接口附加和分离）。

实现¶

负责人¶

主要负责人: balazs-gibizer

工作项¶

如果启用了更改 resource_request 字段结构的 Neutron API 扩展，则使用 HTTP 400 状态码拒绝所有生命周期操作。随着我们对每个操作的支持，该操作的拒绝将被删除。这样，每当我们达到功能冻结时，我们将拥有一个拒绝不支持内容的一致系统。
将新的资源类建议给 Placement 的 os-resource-classes 库
增强 resource_request 解析逻辑以支持新格式
如果启用了新的 Neutron API 扩展，则使用新的解析逻辑
对于每个生命周期操作
- 删除代码中单个端口只请求单个请求组的假设。如果这需要 nova-compute 更改，则更新服务版本，并在 API 端添加检查，以拒绝集群中存在旧计算时的操作。
- 通过删除自动拒绝并仅保留服务版本检查来启用该操作。
调整 nova-manage placement heal_allocation CLI 的实现，以适应新的 resource_request 格式。

依赖项¶

Neutron 规范中定义的端口的新的 Neutron API 扩展，请参阅 Neutron 规范。

测试¶

可以通过上游 CI 系统使用标准 OVS 后端进行集成测试。硬件卸载的 OVS 情况无法在上游 CI 中进行测试。

在自动假设的单元测试覆盖率之上，将添加大量的函数测试，以覆盖具有仅最小数据包速率 QoS 策略规则或同时具有最小带宽和最小数据包速率 QoS 规则的端口的相关生命周期操作。

文档影响¶

API 指南
管理员指南
在开发者文档中记录 Nova 对 Neutron 端口的 resource_request 字段格式的期望。

参考资料¶

Neutron 规范补充本规范中的 neutron 细节
Neutron RFE 用于数据包速率限制策略规则。

历史¶

修订¶
发布名称	描述
Xena	引入

隧道网络的 QoS 最小保证包速率

QoS 最小保证包速率¶

问题描述¶

用例¶

提议的变更¶

新的资源¶

数据包处理资源清单¶

资源清单报告¶

请求最小包速率保证¶

具有新的 QoS 策略的 Nova 服务器¶

使 Nova 适应 Neutron 的更改¶

超出范围¶

备选方案¶

数据包处理资源清单¶

请求最小包速率保证¶

数据模型影响¶

REST API 影响¶

安全影响¶

通知影响¶

其他最终用户影响¶

性能影响¶

其他部署者影响¶

开发人员影响¶

升级影响¶

实现¶

负责人¶

工作项¶

依赖项¶

测试¶

文档影响¶

参考资料¶

历史¶

Nova Specs

页面内容