OpenStack vxlan隧道问题定位及解决

 作者:闫兴安

1     vxlan隧道问题定位

本文描述某OpenStack测试环境vxlan隧道数目错误问题的原因定位及解决办法。

 

1.1   环境信息

节点类型

 

控制节点(起dhcp-agent)

3

网络节点(起vRouter)

2

计算节点(ovs-agent)

70

 

该环境曾经有73个计算节点,删除了3个计算节点。

 

1.2   问题现象

确认各分组数目:

 

Salt 配置文件中指定vxlannode分组为:

vxlannode: N@controller or N@network or N@compute

 

需要建立隧道的节点数目

salt -N vxlannode cmd.run "ovs-vsctl show |grep vxlan |grep Port|wc -l"  |grep scq |wc -l

应该是75个。

 

节点的隧道数目:

salt -N controller cmd.run "ovs-vsctl show |grep vxlan |grep Port|wc -l" |grep scq |wc -l

应该是3个。

 

salt -N network cmd.run "ovs-vsctl show |grep vxlan |grep Port|wc -l" |grep scq |wc -l

应该是2个。

 

salt -N compute cmd.run "ovs-vsctl show |grep vxlan |grep Port|wc -l" |grep scq |wc -l

应该是70个。

 

查看各节点的vxlan隧道数目。

salt -N controller cmd.run "ovs-vsctl show |grep remote|wc -l"

salt -N network cmd.run "ovs-vsctl show |grep remote |wc -l"

salt -N compute cmd.run "ovs-vsctl show |grep remote |wc -l"

salt -N vxlannode cmd.run "ovs-vsctl show |grep remote |wc -l"

 

看到有些节点是70个隧道,有些是78个隧道(未贴图)。

 

期望行为:每个节点都建立74个vxlan隧道。

 

查看agent状态,全为UP:

# neutronagent-list |grep Open |wc -l

75

 

1.3   问题定位

1.3.1 查看neutron vxlan endpoint db

mysql> use neutron;

Database changed

mysql>

mysql> select * from ml2_vxlan_endpoints;

+--------------+----------+-------------------+

| ip_address   | udp_port | host              |

+--------------+----------+-------------------+

|  A.B.C.D   |     4789 | NAME  |

+--------------+----------+-------------------+

70 rows in set (0.00 sec)

 

这里应该是75个才对,说明有agent没有成功上报vxlan endpint信息。

 

对比db和节点信息,找出db中丢失的6个节点信息。

 

主机名

管理网IP

业务网IP

Controller2


   

Controller3


   

计算节点13


   

计算节点41


   

计算节点68


   

Network2


   

以及多余的一个节点信息:

计算节点65

             

              

                

其他endpoint,host和ip都是正确的。

 

下面主要分析,为什么这5个节点没有注册endpoint到neutron db中。

 

找一个节点Controller2,进行分析原因

1.3.2 查看配置文件

查看配置文件中local_ip和hostname:

# cat /etc/neutron/plugin.ini |grep local_ip

local_ip = A.B.C.D

# hostname

没有异常。

 

1.3.3 查看neutron-server日志

 

这个日志后面分析一下原因。

 

1.4   代码流程分析

1.4.1 ovs-agent 如何注册vxlanendpoint

Agent中tunnel_sync触发条件:

agent刚启动,或者检测到ovs重启。

一旦同步完成,只要ovs不重启,tunnel就始终不会同步了。

 

tunnel信息注册:

Agent在tunnel_sync时,将本机的tunnel信息(tunnel_ip,tunnel_type, host name)上报plugin,并请求所有的tunnel列表,然后在本地建立vxlan隧道和流表。

 

Plugin 处理tunnel注册过程:(host,tunnel_ip)

1)      如果db中tunnel_ip被其他agent使用,删除其他agent注册的tunnel信息。并且打log:Tunnel IP %(ip)s was used by host %(host)s and will be assigned to%(new_host)s。

2)      如果db中有这个host,但是tunnel_ip与DB不同,删除db中这个tunnel_ip的隧道信息,并且通知其他agent。

3)      更新DB,然后通知其他Agent。

 

 

举个例子:

当前db中有两个隧道信息:

host_A, 1.1.1.2

host_B,  1.1.1.3

此时,

如果agent上报的是host_C, 1.1.1.2, 就删除(host_A, 1.1.1.2),并打印Log。

如果agent上报的是host_B, 1.1.1.2, 同上,删除(host_A, 1.1.1.2) ,并打印Log。

如果agent上报的是host_B, 1.1.1.4, 就删除(host_B, 1.1.13),然后通知所有agent,将1.1.1.3删除。

 

在Plugin中,收到某Agent(比如A)上报的tunnel信息之后,会主动通知其他Agent(其他agent可能已经完成了tunnel sync,如果不通知,会缺失 Agent A的隧道),让其他Agent与Agent A建立隧道。

 

 

1.5   问题分析测试

1.5.1 neutron-server中报Vxlanendpoint已存在的日志

从代码看,只要ovs-agent上报两次tunnel sync,就会出现这个Log。

 

我们找个正常的ovs-agent,然后重启Ovs-agent。

果然出现了:

2016-09-12 17:57:16.199 23537 WARNING neutron.plugins.ml2.drivers.type_vxlan [req-c05da8d6-d8ef-48d3-9eb3-d7191a1764a6 ] Vxlan endpoint with ip A.B.C.D already exists

 

所以这个日志不是问题。

 

1.5.2 节点vxlan隧道错误的原因分析

节点上vxlan隧道错误包括如下几种情况:

1)      缺失隧道。没有到达某个Agent的隧道。

2)      多余隧道。某个Agent被删除了,但是还有到达这个Agent的隧道。

3)      错误隧道。某个Agent的local_ip更改了,旧ip没有被使用,但是还有到达旧local_ip的隧道。

 

 

根据代码分析,有如下可能会导致上述问题。

1. 部署/运维直接从neutrondb中将某个agent的ml2_vxlan_endpoint删除。

   因为ovs agent不会周期上报tunnel信息,所以db无法恢复。

   其他agent无法建立到这个agent的隧道。

解决办法:

   重启ovs agent

 

2. 某个Agent被剔除了(主机挪作他用),此时db中 endpoint还是存在的。

   这样,其他agent到这个agent的隧道不会被删除。

解决办法:

   手动在Neutron db中删除这条entry,然后重启所有ovs-agent。

 

3. 某Agent tunnel_ip错误地配置为其他agent的ip,然后再改回来。

  该操作会导致neutrondb中tunnel信息丢失(会有error  log),原因同1,也无法恢复。

解决办法:

   重启neutron db中隧道被误删的ovs-agent,使其重新上报tunnel信息。

 

4. 某Agent tunnel_ip配置为错误ip,其他agent建立了到这个ip的隧道,然后Agent恢复IP配置。plugin在通知其他Agent删除配置时失败(比如agent与plugin失联了)。

   通知失败时,错误IP的隧道就会残留在Agent里。

解决办法:

   重启隧道错误的ovsagent。

 

5. 部署阶段清除整个neutron db,但是没有重启全部ovs-agent。

  这个同1,ovs-agent 中的tunnel不会进行同步。

解决办法:

  重启所有的ovs-agent。

 

经确认,环境中出现问题的原因是上面的第5种情况。

 

综上,本质原因:ovs-agent 不会定期同步tunnel(上报tunnel和同步本机的隧道)。

导致出现隧道信息错误的原因有:

1. 新增或删除节点。

2. 修改neutronml2_vxlan_endpoints db。

3. 修改主机hostname或者tunnel_ip。

4. 上述操作时plugin与agent失联。

可以看出,上述操作基本都是在部署阶段。

 

1.5.3 问题恢复方法

手动恢复方法:

1)      确认neutron ml2_vxlan_endpoints是否正确,有问题修复DB。

2)      重启全部ovs-agent。

 

如果要修改代码,支持周期同步,如何修改?

步骤如下:

1)      向Plugin上报本机的tunnel信息

2)      Plugin返回全部的tunnel信息

3)      与本地ovs br-tun中的tunnel对比:

4)      添加缺失的tunnel port和流表

5)      删除多余的tunnel port和流表

 

目前代码中没有主动删除endpoint的地方。

如何修改代码支持自动删除neutron db中残留的ml2_vxlan_endpoint?

1)      在删除agent时,去删除endpoint。

该改动可能会导致agent上vxlan隧道频繁变动。

 

是否修改代码,定期进行tunnel同步?

1)      问题是在部署阶段、环境发生改动时出现的,对于稳定环境不会出现。

2)      neutron db中可能存在残留endpoint,必须人工干预删除,仅仅在ovs-agent中定期同步tunnel,不能解决此问题。

综上,不修改代码进行解决,在部署/运维阶段监控隧道数目,出现问题时人工恢复。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章