ML2+OVS+DVR 和 OVN 的融合¶
Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1828607
在当前状态下，DVR 缺乏一些对操作人员有益的功能。在寻找解决这些问题的方法时，我们发现 DVR 在 ML2+OVS 上的期望状态和 OVN 之间存在大量功能重叠。本规范旨在概述这些重叠区域以及 OVN 或 ML2+OVS+DVR 缺乏功能的区域，然后描述一个融合这两个解决方案的计划。
问题描述¶
在当前状态下，ML2+OVS+DVR 存在以下差距
当处理大量端口以及大量节点参与 neutron 部署时，控制平面可扩展性。
在与 BGP 和/或 neutron-dynamic-routing 结合使用 IPv6 时，对分布式入口/出口的支持。
由于其使用 linux 命名空间，DVR 无法使用智能网卡技术或用户空间工具进行干净地卸载。
除了上述缺点之外，DVR 还可以从以下增强功能中受益
如果操作人员选择，支持在没有网络节点的情况下运行
支持分布式 DHCP（本地 DHCP 响应器） [1]
支持分布式 SNAT
在考虑增强控制平面可扩展性、分布式 DHCP 以及将所有转发策略推送到 OVS 以进行潜在的硬件卸载时，我们注意到 OVN 已经实现了其中许多功能。OVN 也缺乏 ML2+OVS+DVR 具有的一些功能，例如完全分布式的入口和出口，这使得可以将所有南北流量直接路由到适当的计算节点，绕过中央网络节点。
提议的变更¶
为了解决之前讨论的问题，ML2+OVS+DVR 解决方案将与 networking-ovn 解决方案合并。作为期望的最终状态，neutron 将 OVN 作为基于 OVS 的环境的参考 ML2 插件。这具有以下好处
Neutron 可以利用 OVN 提供的控制平面性能优化。
消除了核心 neutron 开发人员和 networking-ovn 开发人员的工作重复，并允许针对解决规模、数据平面性能和 neutron 中可用性问题的想法进行交叉传播。
使支持 neutron 和 OVN 的开发人员社区保持一致，扩大了 neutron 的潜在贡献者基础。
为了使这项工作成功并最大限度地减少对用户的干扰，应考虑以下事项
用户实际上会观察到更好的控制平面扩展性吗？
用户会失去对任何用例的支持吗？
迁移路径是什么？迁移会造成多大的破坏？如何简化它？
以下部分试图回答这些问题，并概述 ML2+OVS+DVR 和 networking-ovn 融合的程序和技术方面。
功能差距分析¶
这是 ML2/OVS 和 OVN 之间当前已知差距的列表。它不是一个完整的列表，但足以作为实现人员在弥合这些差距时使用的起点。OVN 的 TODO 列表位于 [2]。
分片和巨型帧支持
上游工作已在 OVS/OVN 代码中完成，networking-ovn 仓库中还需要额外的工作才能启用它。更改在 [3]。
端口转发
目前 ML2/OVS 支持南北方向的端口转发。浮动 IP 的特定 L4 端口可以定向到 VM 的特定固定 IP:端口号，以便在 VM 中运行的不同服务可以隔离，并且可以轻松地与外部网络通信。
这是一个相对较新的扩展，需要向 OVN 添加支持。
一种可能的方法是使用 OVN 原生负载均衡功能。OVN 负载均衡器表示在 OVN 北向负载均衡器表中。通常，VIP 及其成员表示为 [4]
VIP:PORT = MEMBER1:MPORT1, MEMBER2:MPORT2
可以将其扩展为端口转发，如下所示
FIP:PORT = PRIVATE_IP:PRIV_PORT
安全组日志 API
ML2/OVS 支持一个日志文件，其中记录了安全组事件，供安全实体使用。这允许用户检查实例是否正在尝试执行受限制的操作，或访问远程服务器上的受限制端口。
这是一个相对较新的扩展，需要向 OVN 添加支持。
QoS DSCP 支持
目前 ML2/OVS 支持 QoS DSCP 标记和出口带宽限制。这些是基本的 QoS 功能，虽然集成在 OVS/OVN C 核心中，但尚未集成（或完全测试）在 neutron OVN 机制驱动程序中。
QoS 用于 Layer 3 IP
QoS 最小带宽支持
目前 ML2/OVS 支持 QoS 最小带宽限制，但 OVN 不支持。
BGP 支持
目前 ML2/OVS 支持通过 BGP 使租户子网可路由，并可以为浮动和固定 IP 地址通告主机路由。
性能影响¶
在 2018 年底进行的性能测试表明，OVN 在大多数操作中都优于 ML2/OVS [8]。只有创建网络和列出端口的速度较慢，这主要是因为 OVN 在创建网络时会创建一个额外的端口（用于元数据），因此对于 OVN 案例，相同 rally 任务列出的端口数量是 2 倍。
此外，OVN 中的资源利用率较低 [9] 与 ML2/OVS [10]，主要是由于缺乏代理以及不使用 RPC。
一个提出的问题是 OVN 使用 Geneve 而不是 VXLAN，以及这是否会引入任何性能问题。研究表明这没有问题。通常，支持 VXLAN 的网卡也支持 Geneve 硬件卸载。有趣的是，即使在不支持的情况下，由于 Geneve 受益的其他优化，使用 Geneve 的性能也更好。更多信息可以在 Russell Bryant 的博客中找到 [11]，他在这方面做了大量工作。
其他部署者影响¶
从 ML2/OVS 迁移到 OVN 取决于使用的部署工具。目前，TripleO 上的迁移文档位于 [12]，其中一些可能适用于其他部署工具。将信息重写为不同的部分 - 一部分是通用的高级描述，说明需要哪些步骤，另一部分是特定于部署的说明，将有助于其他人添加更多工具。
开发人员影响¶
将 networking-ovn 代码移动到 neutron 仓库并将 OVN 作为树内驱动程序
将 networking-ovn 移动到 neutron 仓库是支持融合的第一步。
一个 etherpad 用于跟踪信息和工作项，位于 [13]。
IPv6 的分布式入口/出口
在当前状态下，DVR 支持使用 IPv4 时的分布式入口和出口。当使用浮动 IP 时，它可以路由到计算节点上的 fip-xxxxx 命名空间中的 /32 主机路由（在使用 neutron-dynamic-routing 时），或者可以从 fip-xxxxx 命名空间发送 gratuitous ARP。
当使用 IPv6 时，所有云入口和出口流量都通过集中式路由器发送。这意味着无法将流量直接引导到计算节点。
为了解决这个问题，将实现 IPv6 的分布式入口/出口（也称为“快速退出”）。这将允许到达 fip-xxxxx 命名空间中的 IPv6 数据包通过计算节点上的适当 qrouter-xxxxx 命名空间路由，绕过托管在网络节点上的集中式路由器。
存在一个现有的 RFE，请参阅 [14]。
支持智能网卡或用户空间卸载
允许完全去中心化操作
这涉及使操作人员能够在不引入网络节点概念的情况下运行其环境。
这意味着支持分布式 SNAT、分布式 DHCP 以及 IPv4 和 IPv6 的分布式入口/出口。
与 neutron-dynamic-routing 兼容，直接路由到租户网络 [17]。
在完全去中心化的部署中，路由器作为逻辑结构，不需要被认为是“HA”或“分布式”，因为它本质上都是由 virtue of 在每个计算节点上实例化。
分布式 SNAT
这涉及允许 SNAT 直接在计算节点上发生，而不是将其集中在网络节点上。
为了在使用基于命名空间的 DVR 实现时提供适当的租户隔离，SNAT 将执行两次（插入图表并详细说明此处）。
未解决的问题
SNAT 流量是否应使用 FIP 网关 IP 作为源地址，或者是否应使用与租户路由器相关的 IP 地址？使用 FIP 网关 IP 似乎更简单，并减少了地址使用（尽管子网服务类型使这个问题不太重要）。另一方面，与路由器关联的地址允许更好地审查网络流量，因为流量可以与特定的项目和路由器相关联。
允许操作人员选择是否使用分布式 SNAT 是前进的最佳方式。
有关一些历史背景和详细信息，请参阅 [18]。
CLI 影响¶
预计不会对 CLI 产生影响。将继续支持所有现有的 CLI 命令。
API 影响和所需的扩展¶
OVN 插件支持的扩展与 ML2+OVS 相比，应在数据平面功能方面提供等效的功能，例如 trunks、路由网络、地址范围等。在所有情况下，匹配对每个特定扩展的支持不是必需的。例如，OVN 在其实现中提供 DVR 功能，而无需实现 DVR 引入的 API 扩展。
实现¶
负责人¶
Brian Haley <haleyb.dev@gmail.com>
工作项¶
将 networking-ovn 移动到 neutron 树中。
确保为功能差距和开发人员影响部分中的所有项目创建了 RFE。
用于捕获使用 OVN 的控制平面性能的 Rally 作业。
