K版OVS-Agent重启分析



本文基于openstack K版代码，在大规模环境中分析openvswitch-agent重启过程中的时间消耗，并根据分析提出优化的方案。

 

资源	数目
Openvswitch-agent	565
Network	1010
Port	1010(dhcp), 18(nova)

 

         测试环境如上表所示，vxlan端口总数565，我们找一台计算节点，上面有18个属于不同网络的虚机。流表总数约为600个，即: 565条vxlan port对应的流表， 18*2共36条本地vlan和远端tunnel双向映射的流表。

         重启计算节点ovs-agent，我们发现vxlanport和所有的ovs flow都被删除，然后缓慢添加。待全部port和flow全部添加完成，总共用了约50分钟。为了计算添加port和flow的时间消耗，我们在添加port和flow前后添加log打印，得到部分打印日志。

         我们统计了下“setup_tunnel_port”的个数为374条，“add_flowstart”的个数为372条，“mod_flow start”的个数却高达7068条，远超600条实际的流表数目! 仔细查看日志，发现每次“setup_tunnel_port”都会有18次“mod_flow”。查看代码发现，每添加一个tunnel，都会遍历所有的本地vlan(此处总共18个），然后更新vlan到tunnel的映射的流表，新增一个tunnel port。

         这显然是不合理的，vlan到tunnel的映射的流表的太低。为此我们修改了代码[1]，在全部tunnel都完成以后，再添加vlan到tunnel映射的流表。

         此时重启ovs-agent，发现端口、流表恢复时间缩短到7分钟左右。

         计算节点的上承载的虚机有限，所以我们重启dhcp节点的ovs-agent，得到日志分析如下：

阶段	资源类型	用时（秒）	资源数量	平均用时ms
读取ovsdb	网络数目	192	1010	190.09901
分配vlan, 添加tunnel到vlan映射的流	网络数目	270	1010	267.326733
tunnel_sync，添加Port，添加flow	隧道数目	390	565	210
	网络数目		1010	267
配置/删除端口vlan tag	网络数目	600	1010	594.059406
发送rpc更新neutron db中的端口状态	网络数目	240	1010	237.623762
总用时(分钟):		28.2

 

         从这个表格可以看出，如果节点上承载的网络数目较大，重启恢复时间仍然很大。前面提到ovs-agent重启时会删除端口和流表，如果不删除，恢复时间会大大减小。实际上，在neutron L版中已经支持了ovs-agent重启时不删除端口和流表[2]，而且支持通过ryu配置ovs flow，速度也会提高不少。

 

[1] https://review.openstack.org/#/c/326818/

[2] https://review.openstack.org/#/q/drop_flows_on_start+status:merged