(转) 一次批量重启引发的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 重启流程，梳理其逻辑如下：

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

不难发现，如果步骤 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，梳理其重启的逻辑流程如下：

  1. 用一个 cookie 标志当前流表
  2. 获取新流变并更新至 ovs
  3. 根据 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

    1. http://docs.sqlalchemy.org/en/rel_0_9/core/pooling.html
    2. http://www.dabeaz.com/coroutines/Coroutines.pdf
    3. http://stackoverflow.com/questions/1294382/what-is-a-global-interpreter-lock-gil
    4. http://stackoverflow.com/questions/11977270/monkey-patching-in-python-when-we-need-it

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

时间： 2024-08-07 00:17:05

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

openstack M 版 neutron网络组件基础入门

在我们openstack学习当中,网络组件neutron无疑是令很多人很难理解的,可以说要深入理解 了neutron组件,你基本完成了openstack 60%的学习,存储方面只要不涉及到分布式,剩下的基本都比较简单了 相信很多人第一次看到这种图的时候都会被吓一跳,没错,这就是openstack  neutron组件里面涉及到的数据流程,里面涉及到的知识点很多很多 Openstack网络模型中的几个概念网络: Management Network: 管理网络,连接所有节点. External N

Neutron网络入门

Neutron是OpenStack核心项目之中的一个,提供云计算环境下的虚拟网络功能.Neutron的功能日益强大,并在Horizon面板中已经集成该模块.作为Neutron的核心开发人员之中的一个.个人认为Neutron全然取代Nova Network模块作为云计算网络管理中心是必定趋势.要使用好OpenStack,了解Neutron概念及其对应操作就显得格外重要.为此目的,这篇博客主要讲述Neutron网络的一些基本概念,网络规划和Horizon中怎样使用Neutron中的网络功能. Neu

潮湿引发的电路板常见故障(转载)

潮湿引发的电路板常见故障问题 时间:2016-02-03 19:52:53编辑:电工栏目:电路 导读:潮湿引发的电路板常见故障,导致电路板中电路参数发生改变引发电路板故障,电路板中电路处于短路状态,致使电路板故障,信号处理或传输线路出现断路,致使电路板故障. 潮湿引发的电路板常见故障问题 潮湿的定义即含有比正常状态下较多的水份,所以在潮湿环境中使用的电路板,由于空气中含有比较大的湿气,当湿气过大时就会化成水珠跌落到电路板上,跌落到电路板上水珠在电路板上散开后,会依附在电子元件的各个引脚或者印制线

Openstack实践（1）安装部署第一个实例及neutron网络

版权声明:本文为博主原创文章,欢迎转载,转载请注明作者.原文超链接 ,博主地址:http://www.cnblogs.com/SuperXJ/ 如何快速部署使用openstack,使用kolla吧,openstack技术结合容器分分钟部署(单点或者多节点,任选),分分钟升级,kolla项目是为了容器化openstack,目标是做到开箱即用,所有的组件的HA都具备.kolla是一个革命性的项目,我们以前积累的安装部署经验,全部都报废.使用kolla可以快速部署可扩展,可靠的生产就绪的opensta

openstack O版 Neutron网络服务

1.创建neutron数据库[[email protected] ~]# mysql -uroot -pdevopsWelcome to the MariaDB monitor. Commands end with ; or \g.Your MariaDB connection id is 94Server version: 10.1.20-MariaDB MariaDB ServerCopyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab

MyBatis批量插入引发的血案

需要注意的 Mybatis 批量插入 https://my.oschina.net/zjllovecode/blog/1818716 Mybatis 批量插入 数量限制 https://blog.csdn.net/sunyanchun/article/details/89187552 原文地址:https://www.cnblogs.com/yixiu868/p/12695158.html

云计算之openstack（N版）neutron网络服务最佳实践

2.6网络服务 2.6.1neutron的概况 网络服务提供网络,子网以及路由这些对象的抽象概念.每个抽象概念都有自己的功能,可以模拟对应的物理设备:网络包括子网,路由在不同的子网和网络之间进行路由转发. 对于任意一个给定的网络都必须包含至少一个外部网络.不想其他的网络那样,外部网络不仅仅是一个定义的虚拟网络.相反,它代表了一种openstack安装之外的能从物理的,外部访问的试图.外部网络上的IP地址可供外部网络上的任意的物理设备访问,外部网络之外,任何networking设置拥有一个或多个内

openstack之Neutron网络模式vlan，gre，vxlan详解

第一:neutron openvswitch + vlan虚拟网络 一:基础知识 vlan基础知识 1.vlan介绍 1.1:首先说下lan,LAN 表示 Local Area Network,本地局域网,通常使用 Hub 和 Switch 来连接LAN 中的计算机.(一个 LAN 表示一个广播域) vlan:(Virutal LAN) 将同一个LAN上的用户在逻辑上分成多个虚拟局域网,换句话说,一个带有 VLAN 功能的switch 能够同时处于多个 LAN 中,每个vlan中的主机连接交换机

openstack之Neutron网络虚拟化

第一:为什么需要网络虚拟化? 一.数据中心的现有网络不能满足云计算的物理需求: 互联网行业数据中心的基本特征就是服务器的规模偏大.进入云计算时代后,其业务特征变得更加复杂,包括:虚拟化支持.多业务承载.资源灵活调度等(如下图所示).与此同时,互联网云计算的规模不但没有缩减,反而更加庞大.这就给云计算的网络带来了巨大的压力. 互联网云计算业务特点 1. 大容量的MAC表项和ARP表项 虚拟化会导致更大的MAC表项.假设一个互联网云计算中心的服务器有5000台,按照1:20的比例进行虚拟化,则有10