重构 OVS L2 agent¶
https://blueprints.launchpad.net/neutron/+spec/restructure-l2-agent
- 作者:
Rossella Sblendido <rsblendido@suse.com>
- 作者:
Marios Andreou <marios@redhat.com>
该蓝图专注于解决 OVS L2 agent 的技术债务问题，正如 Kilo 设计峰会上讨论的那样 [1] 。这项工作的目标是提高 OVS l2 agent 的代码质量，特别是关于可扩展性和性能方面。我们将通过使用 Rally 进行压力测试，并比较更改前后结果来评估这些改进。作为该蓝图的一部分，还将改进 OVS L2 agent 的测试覆盖率。
问题描述¶
L2 agent 存在几个可以改进的点，以提高性能和可扩展性。该蓝图将解决以下领域：RPC、设备处理和 OVSDB 监控。每个点将在下一节中详细分析。与此蓝图正交的是，Kilo 中已经完成了一个规范，即使用 OVS Python 库而不是 CLI [2] 。
提议的变更¶
我们针对问题描述中识别的每个领域提出更改。
RPC¶
update_device_up 和 update_device_down 是用于通知插件设备已启动或关闭的调用。目前，这些调用仅接受一个设备，但可以改进为处理多个设备。将引入以下新的 RPC 调用：update_device_list_up 和 update_device_list_down。代理将为所有设备进行单个 RPC 调用，而不是为每个设备进行一次 RPC 调用。在可能的情况下，neutron 插件将发出单个数据库更新，而不是为每个设备进行单独更新
当代理收到 security_groups_provider_updated 时，它会刷新所有端口的过滤器，而不仅仅是受更改影响的端口。这不必要地代价高昂。将向 security_groups_provider_updated 添加一个新参数来指定 subnet_id，以便代理能够计算需要更新过滤器的设备列表，而不是刷新所有端口的过滤器。
修改 port_update 消息以指示影响端口的更改。L2 agent 实际上只关心端口状态的更改，其余更改不需要代理采取任何操作。
智能重同步¶
使用当前的实现，如果在代理循环期间与插件的通信中出现错误，则同步标志设置为 true，并且代理在下一次迭代时将执行完全重同步。这意味着代理将再次处理所有设备。为了避免这种情况，当发生错误时，正在处理的设备将被放入错误设备列表中。仅对这些设备执行重同步。代理对错误的反应也应该改进。代理应该分析错误并执行以下操作之一
重试失败的操作
重同步涉及的设备
在发生致命错误（例如，相同操作失败次数 > 阈值）的情况下，将设备置于错误状态
L2 agent 没有可靠的方法来确保服务器端报告的状态与后端应用的状态一致。提供此问题的解决方案不在该蓝图的范围内。
避免处理不需要处理的设备¶
代理跟踪收到 port update 通知的所有端口。在代理循环期间，更新的端口与添加的端口一起处理。它们以相同的方式处理，但实际上在大多数情况下，更新的端口不需要代理执行任何操作。建议的更改是添加一个检查，仅当更新是状态更改时才处理更新的端口。应该定义一个状态更改。例如，ML2 会为很多事情发送端口更新消息。对 l2 agent 重要的消息是
名称或 IP 更改
MAC 地址更改（当代码合并时）
管理状态更改
安全组更改
安全组成员资格更改
端口安全更改（如果相应的蓝图被接受并且代码被合并）
当端口更新时，端口过滤器会再次应用。如果 IP 地址没有更改，则不需要这样做。添加一个检查。
当收到 security_groups_provider_updated 时，将执行防火墙的全局刷新。如果跟踪更新提供程序规则的子网，则可以避免这种情况。代理可以刷新属于该子网的设备的过滤器。
OVS DB 监控¶
OVS DB 监控知道哪些设备已添加，哪些设备已删除。因此，它可以用于生成代理需要处理的事件，至少是主机启动的事件，例如 vif 插入和 vif 断开。但是，我们只是使用 OVS DB 监控来“发出信号”事件发生，然后扫描桥接器以收集已经由 OVS DB 监控检索到的信息。
以这种方式利用 OVS DB 监控还可以简化将代理事件处理机制从轮询循环转换为基于队列的机制的过程。事件可以由主机本身（例如：vif 插入）或 neutron 服务器（例如：安全组成员资格更改）启动。在许多情况下，这些事件可以独立处理。将新事件添加到队列将简化启用多个工作程序以使用这些事件的过程，并确保具有先决事件的事件按适当的顺序执行。
还可以根据其关键性使用不同的队列来处理不同优先级的事件。但是，这可以在后续迭代中完成（不再是偿还债务而是“增强”）。
目前正在努力修改 OVS Python 库，以使其客户端可以使用有关端口添加或删除事件的通知。即使现在 OVS Python 库基本上运行监控以更新接口的本地缓存，它也不会向库的用户提供这些事件（设备添加或删除）。Terry Wilson otherwiseguy 正在研究它。
当更改合并到上游时，L2 agent 可以使用此通知系统。但这不在该蓝图的范围内。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
修改端口更新以指定对端口进行的更改
其他最终用户影响¶
无
性能影响¶
应该提高性能。现在无法量化它，但预计如下
减少事件处理的等待时间
减少事件饥饿的风险
更快的 OVSDB 通信
减少 AMQP 总线上的负载
减少设备处理的抖动
IPv6 影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
社区影响¶
此更改在 Kilo 设计峰会上讨论过，并支持 Kilo 专注于偿还技术债务。
备选方案¶
最终，该蓝图是一个小更改列表。可以讨论每个小更改，并可以提出几种略有不同的变体。但是，该蓝图的唯一替代方案是：保持代理不变或编写一个全新的代理。
实现¶
负责人¶
- 主要负责人
- 其他贡献者
工作项¶
- (以下项目已经有上游补丁，但
之前的版本没有合并代码)
代理的功能测试
RPC 改进
代理循环 - 设备处理
避免处理不需要处理的设备
添加检查以处理更新的端口
避免全局刷新防火墙
使用来自 OVS Python 库的事件通知
依赖项¶
无
测试¶
Tempest 测试¶
没有新的测试
功能测试¶
ip_lib 和 ovs_lib 的功能测试
目前代理没有功能测试。将测试以下情况
设备启动
设备关闭
端口更新
设置隧道端口
清理隧道端口
ovs 重启
同一子网上的两个端口之间可以 ping 通
默认端口过滤器（检查不允许的流量被阻止，反之允许的流量通过）
添加安全组规则
删除安全组规则
API 测试¶
无
文档影响¶
用户文档¶
无
开发人员文档¶
将添加新的 RPC 调用 update_device_list_up 和 update_device_list_down
将向 security_groups_provider_updated 添加一个新参数。
将修改端口更新通知以指定影响端口的更改
参考资料¶
https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
