2023-10-06 - Sahid Orentino Ferdjaoui (Société Générale)¶
本文档讨论了我们在 Société Générale 的生产平台中遇到的各种延迟问题，该平台大量使用 OpenStack。该平台正在快速增长，给 OpenStack 依赖的分布式服务带来了相当大的负载。
经过进一步调查，在虚拟机创建过程中发现了一个超时问题。此超时的出现表明 Nova 和 Neutron 服务之间存在通信困难。
底层¶
在虚拟机创建过程中，一旦选择了计算主机，Nova 就会在该主机上开始构建过程。这涉及几个步骤，包括启动 QEMU 进程并在主机上创建一个 TAP 接口。此时，Nova 将虚拟机置于暂停状态，等待 Neutron 发出的事件（或信号），以指示该特定虚拟机的网络已准备就绪。接收来自 Neutron 的此事件的过程可能很耗时，原因如下
负责构建网络并通知 Nova 的计算主机上的 Neutron 代理通过 RPC 向 Neutron 服务器发送消息。
Neutron 服务器反过来通过 REST API 与 Nova api 进行通信。
最后，Nova api 通过另一个 RPC 消息通知相关的计算主机有关该事件。
整个过程使用 事件回调 API，该 API 是为 icehouse 引入的，相关的事件包括 network-vif-plugged、network-vif-failed。
考虑到 Neutron 难以及时通知 Nova，我们决定专注于减少对其的活动。
减少 Nova 对 Neutron 的请求¶
对于每个虚拟机，Nova 会持续请求 Neutron 刷新其网络缓存。最初，这种机制旨在减少 Nova 对 Neutron 的 API 请求数量。但是，此周期性任务刷新的默认间隔设置为 60 秒，在拥有数千个虚拟机的繁忙环境中，这会导致针对任何给定虚拟机的缓存刷新请求数量大量增加。
[DEFAULT]
heal_instance_info_cache = 600
所使用的网络驱动程序非常稳定。根据社区内的讨论，将刷新间隔调整为 600 秒是安全的。甚至有可能完全禁用此功能。
注意
当您重新启动 Nova Compute 服务时，修复过程将重置并重新开始。这在经常重新启动 Nova Compute 服务的环境中可能尤其成问题。
增加 Neutron 的 RPC worker¶
我们还决定大幅增加 rpc_workers 的值。鉴于 RPC 操作旨在受 I/O 限制，我们认为超过主机上可用核心数量的两倍既保守又安全。
[DEFAULT]
rpc_workers = 20
增加 Neutron max_pool_size¶
我们有意更改了 Neutron 数据库设置中的 max_pool_size 值，从 1 增加到 60。鉴于我们增加了 worker 数量，并且可以预期这些 worker 将使用数据库，因此此调整是合理的。
[database]
max_pool_size = 60
推迟 flows 删除¶
我们观察到，在 OpenStack 环境中的 Neutron 代理在虚拟机终止过程的最后删除网络 flows 时会遇到延迟。此操作是阻塞性质的，导致代理在 flows 删除完成之前对任何其他任务无响应。
我们决定部署更改 OpenDev Review #843253，旨在缓解此问题。此更改将 flows 删除任务卸载到单独的线程，从而释放主线程继续执行其他操作。
# will not match with the ip flow's cookie so OVS won't actually
# delete the flow
flow['cookie'] = ovs_lib.COOKIE_ANY
+ self._delete_flows(deferred=False, **flow)
- self._delete_flows(**flow)
部署后的改进¶
最后，在部署这些更改后，我们注意到虚拟机创建的稳定性和成功率有了相当大的提高。创建虚拟机所涉及的延迟现在稳定，只需要合理的时间才能将其转换为活动状态。
