(转) 一次批量重启引发的Neutron网络故障

现场回顾

故事发生于某个下午，采用 salt 更新某集群的 neutron.conf (log 相关配置项) 并批量重启 neutron-openvswitch-agent(以下简称 neutron-ovs-agent)，不久便有人反馈云主机宕机。

立即排查发现云主机并没有宕机，只是网络不通，大部分计算节点的 ovs 流表空空如也。Nova 和 Neutron 打出 ERROR 级别的日志。

$ ovs-ofctl dump-flows br-bond
NXST_FLOW repy (xid=0x4) cookies=0x0, duration=433.691s, table=0, n_packages=568733, n_bytes=113547542, idle_age=0, priority=1 actions=NORMAL cookies=0x0, duration=432.358s, table=0, n_packages=8418, n_bytes=356703, idle_age=0, priority=2, in_port=3 actions=drop

neutron-ovs-agent Log:

DeviceListRetrievalError: Unable to retrieve port details for devices because of error: Remote error: TimeoutError QueuePool limit of size 10 overflow 20 reached, connection timed out, timeout 10

neutron-server Log：

File "/usr/lib64/python2.6/site-packages/sqlalchemy/pool.py", ... 'TimeoutError: QueuePool limit of size 10 overflow 20 reached, connection timed out, timeout 10\n'

nova Log：

NeutronClientException: Request Failed: internal server error while processing your request.

上述信息可得出以下结论：

Neutron 日志表明 neutron-ovs-agent 通过 rpc 向 neutron-server 请求虚拟机 port 相关信息失败，失败的原因是 neutron-server 和数据库的连接数超出连接池的上限。
Nova 日志表明 neutron-server 无法响应 HTTP 请求。
被清空的 ovs 流表导致虚拟机的网络瘫痪。

导火索

深入剖析之前，先了解该 Icehouse 集群的基本信息：该集群有 102 个计算节点，运行着 nova, neutron, glance，ceilometer 等服务，为了避免单点故障，我们去除了 neutron l3 等相关服务，采用大二层的网络，虚拟机通过物理路由与外界通信。理论上说，无论哪个服务异常，甚至任意节点宕机，最差的结果是 openstack 服务不可用或者少量虚拟机故障，但绝大部分虚拟机依旧能正常运行。

经验告知，采用以上网络模型的多个集群一年多以来从未发生如此规模的故障。由于 log 模块配置项不会影响流表，直觉上推测批量重启可能是触发 ovs 流表被清空的导火索。

Neutron 的一个坑

由于流表被清空前仅仅重启了 neutron-openvs-agent，而计算节点，仅仅只有 neutron-ovs-agent 与 ovs 有交互，故按图索骥的浏览 neutron-ovs-agent 重启流程，梳理其逻辑如下：

清除所有流表
通过 rpc 向 neutron-server 获取流表相关信息
创建新流变

不难发现，如果步骤 2 异常，比如 neutron-server 繁忙，消息中间件异常和数据库异常等种种因素，都会影响流表的重建，重则导致虚拟机网络瘫痪。事实上，社区也意识到了类似的问题：重启 neutron-ovs-agent 会导致网络暂时中断。

Restarting neutron ovs agent causes network hiccup by throwing away all flows

社区的处理方式是增加配置项 drop_flows_on_start，默认其值为 False，从而避免上述问题。该 Patch 已合入 Liberty，梳理其重启的逻辑流程如下：

用一个 cookie 标志当前流表
获取新流变并更新至 ovs
根据 cookie 清除旧流表

neutron-ovs-agent 在重启的过程中就流表的处理留下了一个隐患，直接的后果就是导致计算节点的流表被清理的干干净净，虚拟机成一个个孤立的点，而多种因素可触发该隐患。

最大连接数

现在解释为什么批量重启 neutron-ovs-agent 会触发上述隐患，重启过程中，neutron 日志报出如下错误：

'TimeoutError: QueuePool limit of size 10 overflow 20 reached, connection timed out, timeout。

这条日志意味着 neutron-server 和数据库的连接数超出客户端连接池的上限，当 neutron-ovs-agent 批量重启时，上百并发的通过 rpc 向 neutron-server 请求构建流表的相关信息，neutron-server 和数据库的连接数也就远远超过 30，造成大量的请求失败，计算节点获取不到流表相关信息无法重建流表，故计算节点的流表为空。

要解决因 QueuePool 的限制而引起的 TimeoutError 问题也很简单，sqlalchemy 提供了两个配置项[1]，把下面两个参数适当调大即可。

[database]
max_overflow =
max_pool_size =

Note: MySQL server 默认最大连接数为 100，当集群的规模上升时，需适当调整 MySQL server 最大连接数。

进程的性能问题

然而问题并没有完全解决，请注意 nova 的错误日志：

nova.compute.manager NeutronClientException: Request Failed: internal server error while processing your request.

这是nova 发给 neutron-server 的一条 HTTP 请求，neutron 返回了 internal server error。Internal server error 对应的 HTTP status code 为 500，意味着 neutron-server 无法响应 nova 请求。为什么会无法响应呢，批量重启的过程中，发现 neutron-server 进程的 CPU 使用率为 100 %，意味着 neutron-server 正忙于处理 neutron-ovs-agent 大量的请求，因而无暇处理 nova 的 HTTP 请求。

解决该问题的方法同样很简答，增加更多的 neutron-server 进程数即可。事实上，因 nova-conductor 要处理 nova-compute 大量的 rpc 请求(nova-compute 通过 nova-conductor 访问数据库)，自 Icehouse 起，nova-conductor 就默认启动了多个进程，进程的数目等同服务器 CPU 的逻辑核数。

$ workers=`cat /proc/cpuinfo |grep processor |wc | awk '{print $1}'`

[DEFAULT]
api_workers = $workers
rpc_workers = $workers

Python 的并发 & IO

值得思考的是，对双路 12 核共 24 线程的服务器来说，数百并发请求真的算高么？neutron-server 进程的 CPU 最大使用率只能到达 100 %，意味着 neutron-server 仅仅利用了服务器的一个线程。这里不得不提协程(crontine)[2]，这种伪并发的“用户态线程” 意味着任意时刻只有一个协程在执行，即任意时刻只能利用服务器 CPU 的一个线程，而 openstack 所有组件的进程里满满都是协程(只有一个主线程)，因而单个进程下，neutron-server 不能充分利用多核的优势以提高处理并发的能力。

传统的 web 服务器 apache 和 nginx 利用多进程多线程提高并发数(上下文切换的开销：进程 > 线程 > 协程)。那么问题来了，单进程条件下，是不是可以用线程替换协程从而提高 neutron 的并发能力呢？真实的答案是 No, 根本原因在于 python GIL[3]，俗称 python 全局锁。对于 python 的程序来说，单进程只能在任何时刻只能占用一个物理线程，所有只有多进程才能充分利用服务器的多核多线程。

让我们深入一点，假设的 CPU 足够强大，是不是可以解决 neutron-server 单进程的并发问题呢？我觉得未必，这又回到了 IO 问题。Monkey patch[4] 虽然把系统的 socket 库替换成自己提供的非阻塞 socket 库，从而避免某些阻塞 IO 阻塞了整个进程(主线程)。但是 OpenStack 访问 MySQL 使用的是 libmysqlclient 库，eventlet 并不能对这个使用了系统 socket 的 C 库使用 monky_patch，所以对 MySQL CRUD 的时候会阻塞主线程，意味着 neutron-server 在访问数据库也容易出现性能瓶颈。

解决上诉并发问题的方法之一就是启动更多的 api worker 和 rpc worker。在较新的版本，OpenStack 默认的 wokers 就是服务器的逻辑核数。另外一种办法是用 apache 替换 python http server，最近各个组件逐步提供了对 apache 的支持。

Reference

http://wsfdl.com/openstack/2015/10/10/%E4%B8%80%E6%AC%A1%E6%89%B9%E9%87%8F%E9%87%8D%E5%90%AF%E5%BC%95%E5%8F%91%E7%9A%84Neutron%E7%BD%91%E7%BB%9C%E6%95%85%E9%9A%9C.html