OVN Neutron Agent 和硬件卸载 QoS 扩展

Launchpad bug: https://bugs.launchpad.net/neutron/+bug/1998608

该 RFE 的目标是定义一个新的通用 OVN agent 的架构，该 agent 将执行任何所需的功能，并且像任何其他 ML2 agent 一样可扩展。要实现的首个功能将是硬件卸载 QoS 扩展。

问题描述

ML2/OVN 是一种机制驱动程序，没有后端 agent。此机制驱动程序暴露两种 agent 类型：OVN 控制器 agent 和元数据 agent。OVN 控制器 agent 是节点上 ovn-controller 服务状态的表示；元数据 agent 是向虚拟机提供元数据的服务。

但是，ML2/OVN 机制驱动程序没有 agent 来执行本地 Open vSwitch 服务配置，就像 ML2/OVS 一样，使用扩展驱动程序（如 QoS 或 Trunk）。ovn-controller 读取 OVN 南向数据库以配置本地 OVS 数据库。

缺乏运行在本地节点上、由 Neutron 拥有的 agent，阻止我们实现 OVN 或驱动程序当前不支持的一些功能。例如，这将是 OVN agent 将要实现的第一个功能，由于驱动程序的限制，硬件卸载端口无法应用 OVS QoS 规则，特别是针对 NVIDIA Mellanox ConnectX-5 网络卡 [0]。

提议的变更

此 RFE 建议创建一个在计算节点上运行的通用 agent。该 agent 将被称为“OVN Neutron Agent”。此 agent 的执行是可选的，仅当特定计算节点上请求其实现的功能时才需要。换句话说，最初此服务将是必需的，如果计算节点具有硬件卸载端口并且需要 QoS（未来可以实现新功能）。

与其他机制驱动程序 agent（如 ML2/OVS 或 ML2/SRIOV）不同，此 agent 不实现 RPC 客户端。所需的信息将从本地 OVS 数据库、OVN 北向数据库和 OVN 南向数据库中检索。在未来的 RFE 中讨论包含 RPC 功能以与 Neutron 服务器和 Neutron 数据库建立直接连接。

可扩展的功能

新的 agent 功能将通过扩展定义。它将使用 neutron.agent.agent_extensions_manager.AgentExtensionsManager 类来加载配置的 OVN Neutron Agent 扩展。它将使用其他 ML2 agent 使用的相同的配置变量“agent.extensions”。OVN Neutron Agent 扩展将继承自 neutron_lib.agent.extensions.AgentExtension，并在 agent 启动时由 agent 扩展管理器加载。

如前所述，OVN agent 将具有活动的 OVN 北向、OVN 南向和本地 OVS 数据库连接，使用相应的 IDL 类。这些类将监视一组表并注册一组事件。每个扩展都必须报告启动过程中需要哪些表和事件。扩展将继承自特定的 OVN Neutron Agent 扩展类（从上述 AgentExtension 派生），该类将提供 API 方法来检索此信息。

OVN agent 状态报告

需要在 Neutron 服务器中跟踪这个新的 OVN Neutron Agent。当前有两种类型的 agent：“OVN Controller agent”/“OVN Controller Gateway agent”和“OVN metadata agent”。此 RFE 将引入“OVN Neutron Agent”类型。这是一个通用名称，符合此规范的目标，即创建一个通用的 OVN agent 来实现 OVN 控制器无法提供的所有所需功能（元数据将是下一个要实现的特性，从当前的“OVN metadata agent”迁移）。

报告机制将与 OVN 元数据 agent 中实现的一样。当南向表“SB_Global”更新时，agent 将更新“external_ids”字典中的一个键。请查看 neutron.agent.ovn.metadata.agent.SbGlobalUpdateEvent 以获取实现示例。服务器将读取此变量，检查时间戳并确定 agent 状态。

硬件卸载端口的 QoS

此 agent 将要实现的第一个功能（扩展）是硬件卸载端口的 QoS 扩展。由于当前驱动程序的限制，这些端口无法使用当前的 QoS 规则正确配置。

此 RFE 建议使用相应的“ip-link” [1] 命令（或其“pyroute2”等效命令）来配置端口代表虚拟功能速率（最大值和最小值）。这类似于 ML2/SRIOV 为虚拟功能 (VF) 所做的事情。

端口代表（或 devlink 端口 [2]）是一种暴露设备信息的 API；它不是物理端口，而是硬件端口的代表。devlink 端口连接到本地 OVS 交换机；使用“devlink”工具（或“pyroute2”等效工具），可以检索端口信息，包括物理功能 (PF) PCI 地址。例如：

$ devlink port show enp4s0f1_5 -jp
 "port": {
     "pci/0000:04:00.1/65542": {
         "type": "eth",
         "netdev": "enp4s0f1_5",
         "flavour": "pcivf",
         "pfnum": 1,
         "vfnum": 5,
         "splittable": false,
         "function": {
             "hw_addr": "fa:16:3e:f8:7b:10"
         }
     }
 }

有了 PF PCI 地址，就可以检索 PF 名称，该名称将存储在

$ cat /sys/bus/pci/devices/$pf_pci_address/net

使用 ML2/SRIOV 类 PciDeviceIPWrapper，可以设置 VF 的最大和最小速率，了解 VF 索引和 PF 名称。

OVN QoS 信息位置

OVN QoS 信息存储在两个不同的位置（由于 ML2/OVN 和核心 OVN 中 QoS 的当前实现方式）

• 最大带宽（“rate”）和最大突发（“burst”）限制存储在“Qos:bandwidth”字典中

$ ovn-nbctl list Qos
 _uuid               : 376303c4-5290-4c4e-a489-d35894315199
 action              : {}
 bandwidth           : {rate=1000, burst=800}
 direction           : to-lport
 external_ids        : {"neutron:port_id"="89a81cc0-7b3e-473d-8c01-2539cf2a9a6a"}
 match               : "outport == \"89a81cc0-7b3e-473d-8c01-2539cf2a9a6a\""
 priority            : 2002

• 最小带宽速率存储在“Logical_Switch_Port:options”字典中

$ ovn-nbctl list Logical_Switch_Port
 _uuid               : 502b3852-4a46-4fcb-9b49-03063cfc0b34
 addresses           : ["fa:16:3e:c4:b8:29 10.0.0.8"]
 dhcpv4_options      : a7e4cfb1-ef22-490a-9ffe-fea04de3fe1c
 dhcpv6_options      : []
 dynamic_addresses   : []
 enabled             : true
 external_ids        : {...(skipped)}
 ha_chassis_group    : []
 name                : "e6808371-c9ac-4015-94a3-7f16ac3fbb2d"
 options             : {mcast_flood_reports="true", qos_min_rate="1000",
                        requested-chassis=u20ovn}
 parent_name         : []
 port_security       : ["fa:16:3e:c4:b8:29 10.0.0.8"]
 tag                 : []
 tag_request         : []
 type                : ""
 up                  : true

OVN QoS 事件

硬件卸载 QoS 扩展将通过响应以下事件来配置 QoS 设置（请查看工作 POC [3] 以获取更多信息）

• 本地 OVS 接口创建：使用此事件，OVN 监视器将存储哪些端口绑定到本地实例。它将存储 Neutron 端口 ID（存储在“Interface.external_ids:iface-id”字符串中）和 OVS 端口名称。

• 本地 OVS 接口删除：此事件将触发 QoS 重置和接口本地缓存删除。

• OVN 南向“Port_Binding”创建事件：在本地 OVS 中创建端口后接收此事件。如果接收到此事件，将触发本地端口的 QoS 更新。值得注意的是，此事件始终在本地 OVS 接口创建之后发生；这意味着 OVN 监视器已经注册了该端口已本地绑定。

• OVN 北向“Logical_Switch_Port”注册更改：如果本地绑定 LSP 的最小带宽发生变化，则此事件会触发 QoS 更新。

• OVN 北向“QoS”注册更改：类似于前一个，但影响最大带宽限制。

REST API 影响

此 RFE 不引入任何 API 更改。

数据模型影响

此 RFE 不引入任何模型更改。

安全影响

无。

性能影响

每个监视器将具有到本地 OVS 数据库以及远程 OVN 北向和南向数据库的连接。连接到远程 OVN 数据库可能会对 OVN 数据库节点（通常是 OpenStack 控制器）的负载产生严重影响。此初始实现将订阅以下表

• 北向：QoS、Logical_Switch_Port 和 Logical_Switch

• 南向：Chassis、Encap、Port_Binding、Datapath_Binding 和 SB_Global

应通过以下方式减少此性能影响

• 减少节点上的 agent 数量。下一步要实现（在本 RFE 范围之外）是将 OVN 元数据 agent 功能移动到这个新的 OVN Neutron agent。这将把南向数据库连接减少到一个 agent。

• 找到一种将最小带宽信息存储在 Logical Switch Port 之外的方法。通过不订阅此表，北向连接将显著减少负载。Logical Switch Port 是最繁忙和最活跃的表之一；不本地缓存或接收其更新将减少对 OVN 数据库的影响。

其他影响

无。

实现

负责人

主要负责人

Rodolfo Alonso Hernandez <ralonsoh@redhat.com> (IRC: ralonsoh)

工作项

• OVN 监视器实现和硬件卸载 QoS 扩展。

• 测试和 CI 相关更改。

测试

• 单元/功能测试。

注意

硬件卸载 QoS 扩展需要特定的硬件来测试此功能。目前无法在 CI 上实现任何 tempest 测试。

文档影响

用户文档

• 有关如何配置和启动 OVN 监视器的信息。

• 有关硬件卸载 QoS 扩展的信息。

参考资料

[0]

https://bugzilla.redhat.com/show_bug.cgi?id=2002406

[1]

https://man7.org/linux/man-pages/man8/ip-link.8.html

[2]

https://linuxkernel.org.cn/doc/html/latest/networking/devlink/devlink-port.html

[3]

https://review.opendev.org/c/openstack/neutron/+/866480