Neutron L3 auto Reschedule VRouter feature

最新推荐文章于 2020-12-15 14:16:13 发布

Matt_Mao

最新推荐文章于 2020-12-15 14:16:13 发布

阅读量1.9k

点赞数

分类专栏： Openstack 文章标签： openstack neutron L3 HA

本文链接：https://blog.csdn.net/matt_mao/article/details/38870339

版权

Openstack 专栏收录该内容

51 篇文章 1 订阅

订阅专栏

在Havana、icehouse版本的生产环境部署中，常常会启用一个外部cron job去监控是否存在down掉的L3，如果存在则将此L3上所有绑定的VRouter重新绑定到其他L3上。

这个feature现在被Kevin Benton写成了buildin版本，代码如下:
https://review.openstack.org/#/c/110893/16

最开始的代码存在以下bug，现在已经修复了:

https://bugs.launchpad.net/neutron/+bug/1359460

简单测试了一下这个feature, 发现触发L3 Reschedule 的时间大概是两倍的agent_down_time, 默认的agent_down_time为75秒，所以从L3 agent down掉到开始reschedule至少需要150秒。
reschedule过程所需要的时间是和虚拟路由器的个数有关。所以总共的traffic downtime为150 + reschedule VRouter的时间。

我的测试环境是devstack搭建的两个节点，L3 agent分别部署在两个节点上:

kill掉第二个节点的L3:
root@dev2:/opt/stack/neutron# ps axu | grep l3
stack 3750 0.1 0.3 32620 26332 pts/5 S+ 05:58 0:01 python /usr/local/bin/neutron-l3-agent --config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent.ini --config-file /etc/neutron/fwaas_driver.ini
root 7237 0.0 0.0 4208 828 pts/12 R+ 06:08 0:00 grep --color=auto l3
root@dev2:/opt/stack/neutron# kill -9 3750 | date
Wed Aug 27 06:08:41 UTC 2014

大约150s后，发生了Reschedule:
stack@dev1:/opt/stack/neutron$ tail -f /opt/stack/logs/screen/screen-q-svc.log | grep "Rescheduling router"
2014-08-27 06:11:14.713 WARNING neutron.db.l3_agentschedulers_db [-] Rescheduling router 42265639-d335-488c-af40-64a698c2cae5 from agent d6fc8003-59bd-4a68-a36b-8e36872df8cd because the agent did not report to the server in the last 150 seconds.
2014-08-27 06:11:14.782 WARNING neutron.db.l3_agentschedulers_db [-] Rescheduling router 893e7ce6-d838-444b-a03c-831cabdb046a from agent d6fc8003-59bd-4a68-a36b-8e36872df8cd because the agent did not report to the server in the last 150 seconds.

之后可以看到VRouter的namespace出现在了第一个节点上，接口也被正确配置了，虚机恢复了正常通信。

使用这个feature需要注意的地方:
1. 注意会有至少150s的downtime。VRouter如果很多的话，downtime会更长。
2. 触发Reschedule的条件其实应该是Node2的namespace不能正常工作了，而不是node2的neutron-l3-agent，但目前neutron不能判断Node2的namespace不能工作。如果出现了namespace可以正常工作，但neutron-l3-agent死掉的情况，就会影响虚机通信。所以我们需要对neutron-l3-agent进行监控，neutron-l3-agent一旦down掉就把它restart。这样只有再neutron-l3-agent不能restart的情况下才会触发Reschedule，一般这种情况是OS也出问题了。

总的来说这个feature只是一个过渡的feature, L3用VRRP做HA才能将downtime降到可接受范围。不过L3 VRRP的feature和DVR一样存在和高级service兼容的问题，所以目前这个feature还是有价值的。