Neutron L3 auto Reschedule VRouter feature

在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还是有价值的。