OVS 辅助网桥以减少 OVN 中的实时迁移网络中断¶
Launchpad bug: https://bugs.launchpad.net/neutron/+bug/1933517
本规范的目标是提出 VM - 后端 (OVN) 连接性中的一项更改，以改进实时迁移过程。
问题描述¶
实时迁移是一个非常敏感的过程，这意味着配置目标主机以执行已经正在运行的虚拟机。当目标 hypervisor 准备好后，源虚拟机将被暂停并在目标主机上立即取消暂停。
自从 [1] 和 [2]，Nova 能够插拔端口并在实时迁移前的目标主机上创建接口。但是，TAP 设备是在 VM 取消暂停时由 libvirt 创建的。此时，OpenFlow 端口 ID 会分配给端口接口。
当端口创建时，网络后端检测到连接的新端口，并通知 OVN Northbound，Neutron 接收到此事件。网络后端被命令配置此新端口所需的规则。
此操作序列的问题在于，当虚拟机取消暂停时，网络后端尚未准备好继续任何网络通信，直到 OVN 控制器（在计算节点上）使用分配给 TAP 接口创建的 OpenFlow 端口 ID (interface.ofport) 设置所有必要的 OpenFlow 规则和 chassis 配置为止。
提议的变更¶
本规范的范围仅限于 OVN 后端。本规范不考虑硬件卸载端口的情况，这些端口具有其他插拔过程。本规范仅考虑与相关网络后端中的 os_vif.objects.vif.VIFOpenVSwitch VIF 类型。
本规范建议在集成网桥和虚拟机 tap 接口之间创建一个中间 OVS 网桥。此 OVS 网桥将通过一个 patch 端口连接到集成网桥。TAP 接口将在虚拟机创建或取消暂停时（在实时迁移期间发生）插入到中间网桥中。此架构与 OVS 混合插拔非常相似，但中间有一个 OVS 网桥。
这种方法的优点是，在此过程期间创建的集成网桥端口（在本例中为 patch 端口）具有有效的 OpenFlow 端口 ID (interface.ofport)，这对于在集成网桥中提供正确的 OpenFlow 规则是必需的。
端口插拔后，Nova 命令 libvirt 将 guest 内存复制到目标主机。如果使用“live_migration_permit_post_copy” [3]，目标主机上的虚拟机将在所有内存复制完成之前被激活。但是，有一段时间端口绑定到目标主机，而虚拟机仍在源主机上运行。在此期间，虚拟机将无法通信，与未使用此功能的情况相同。
当虚拟机在目标主机上取消暂停时，OVN 后端已准备好立即继续从 guest 传输数据包。
实现¶
VIF 的插拔过程由 Nova 执行，使用 os-vif 库提供的不同后端实现。桥接创建和删除将在插拔过程中完成 [4]，就像 OVS 混合插拔策略一样。
提议的架构和命名如下，在 [5] 中实现
┌────────┐
│tap-xxx │ TAP interface port
┌─────┴────────┴─────┐
│ pbr-xxx │ Port bridge
└─────┬────────┬─────┘
│pbp-xxx │ Port bridge patch port (port bridge side)
└────┬───┘
┌────┴───┐
│ipb-xxx │ Port bridge patch port (integration bridge side)
┌─────┴────────┴─────┐
│ integration │
│ bridge │
└────────────────────┘
对于每个新的 VM TAP 接口，将创建一个 OVS 网桥以及一个 patch 端口，以将此网桥与集成网桥连接。此端口网桥将具有默认 OpenFlow 规则，允许来自 TAP 接口端口到 patch 端口的所有流量
cookie=0x0, duration=84162.020s, table=0, n_packets=444223, n_bytes=832399534, priority=0 actions=NORMAL
OVN 将 OVS 端口（Open vSwitch DB）与逻辑交换机端口（OVN NB 数据库）链接，使用 Neutron DB 端口 ID。Neutron 创建的 OVN NB 逻辑交换机端口将在 lsp.name 字段中具有此端口 ID。OVS 端口 ipb-xxx（集成网桥侧 patch 端口）使用 interface.external_ids={iface-id: port_id} 创建。ovn-controller 将检测到这个新端口并将相应的 chassis 分配给 OVN SB Port Binding。interface.external_ids 信息由 os-vif 在端口插拔过程中添加 [5]，由 Nova 调用。
注意：OVS 和 OVN 端口在 os-vif 中使用相同的 VIF 类型表示，objects.vif.VIFOpenVSwitch。os-vif 实现可以同时用于 OVS 和 OVN 后端。但是，本规范的范围仅限于 OVN 后端。
Nova - Neutron 事件¶
Nova 和 Neutron 有一种机制来通信 VIF 的状态 [6]。这是一个单向 API，允许 Neutron 在 VIF 被插拔时通知 Nova。Nova 期望 Neutron 发送 network-vif-plugged 事件，当端口被绑定或插拔时。根据后端，Nova 将期望在端口被绑定或端口被插拔时收到 network-vif-plugged [7]。例如，在具有混合插拔的 OVS 中，Nova 期望端口插拔到 OVS 时收到该事件。在 OVN 中，Nova 期望在实时迁移过程中端口绑定时收到此事件 [8]。
一旦 Nova 创建了中间网桥 [1] [2]，Neutron 可以在端口插拔并且网络后端配置时发送 network-vif-plugged 事件。
本规范建议使用现有的 OVN 事件基础设施来捕获 patch 端口创建事件，使用 LogicalSwitchPortCreateUpEvent，并在处理程序方法中将事件推送到 Nova。与此同时，Neutron 将通过在 port.vif_details 中添加一个名为 backend 的字段，来通知 Nova 端口中使用的后端。该值将为“ovn”。此端口更新将在 [9] 中完成，在 mech 驱动程序的端口绑定方法中。
Neutron 配置¶
如前一节所述，本规范建议更改 Neutron 发出的事件。这将取决于 os-vif 是否配置为在集成网桥和 TAP 设备之间创建此中间网桥。
由于 Neutron 无法读取 os-vif 配置，本规范建议在 ML2 OVN 插件部分添加相同的配置标志：“per_port_bridge”。
如果启用，Neutron 将在端口插拔时发送 network-vif-plugged 事件，而不是在端口绑定更新时发送。
QoS¶
使用此功能，逻辑交换机端口现在是 patch 端口与端口网桥和 TAP 设备之间的端口，而不是 TAP 设备端口。在 OVS 中，QoS 规则只能应用于外部端口。但是，在 OVN 中，QoS 规则是使用 QoS 寄存器中的“match”字段应用的 [10]。这是一种与 Logical_Flow 表中使用的相同表达式语言中的字符串。应用于 TAP 设备的流量整形与使用 patch 端口引用时相同，因为两种端口中的流量流相同。
性能¶
中间网桥将具有一个规则，操作为 NORMAL。这意味着来自 TAP 端口的所有流量将被发送到 patch 端口，反之亦然。
数据平面将折叠此网桥，从而产生与没有网桥相同的流。换句话说，新的中间网桥不会对数据包处理性能产生任何影响。
OVN DPDK¶
与其它网桥（物理网桥、隧道网桥、外部网桥）一样，每个端口网桥将通过 patch 端口连接到集成网桥。正如上一节中评论的那样，这保持了一个单一的数据平面（在 DPDK 的情况下为“netdev”）。
升级影响¶
可以使用配置变量“per_port_bridge” [11] 在 os-vif 中启用此功能。如果启用此选项，任何 OVN 端口都将使用本规范中描述的实现进行插拔。目前，此实现不处理在同一主机上混合使用两种插拔方法（将 TAP 端口直接连接到集成网桥或创建如本规范所述的端口网桥）。如果启用此选项，计算节点不应托管任何虚拟机。此时，如所提议的更改中所述，创建或迁移到此主机的任何虚拟机都将使用中间端口网桥进行插拔。在迁移的情况下，这将解决或减轻虚拟机在目标主机上取消暂停时连接问题。
本规范不涵盖在同一主机上（与 OVS 混合插拔策略相同）混合使用两种插拔策略的 TAP 端口的任何场景。
测试¶
Tempest 测试¶
实时迁移 tempest 测试涵盖在 Nova CI 中。为了测试此功能，应在 neutron-ovn-tempest-slow CI 作业上执行来自 tempest.api.compute.admin.test_live_migration 的一组测试。
文档影响¶
用户文档¶
记录新的架构和更改 Neutron 事件发出的配置标志。
实现¶
负责人¶
Sean K Mooney (smooney@redhat.com, IRC: sean-k-mooney) Rodolfo Alonso Hernandez (ralonsoh@redhat.com, IRC: ralonsoh)
