Openstack Linuxbridge网络高可用分析
source link: https://www.sdnlab.com/23119.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
作者简介:Mr Huang,SDN/NFV研发工程师,技术擅长:SDN、NFV、Openstack
本文是基于Openstack Queens版本,且采用Linuxbridge充当虚拟交换机,描述如何部署Neutron中的DHCP Agent、L3 Agent高可用特性。
本文涉及的实验都以Ubuntu16.04环境为准。
1 L3 Agent HA
1.1 VRRP
vrrp的相关知识这里不详细展开描述,具体参考如下的资料:
https://www.cnblogs.com/sammyliu/p/4692081.html
https://docs.openstack.org/neutron/rocky/admin/config-dvr-ha-snat.html
https://docs.openstack.org/neutron/rocky/admin/deploy-lb-ha-vrrp.html#deploy-lb-ha-vrrp
1.1.1 配置
1.1.1.1 控制节点
对于一个路由器关联多个L3 Agent时,当创建一个路由器时,需要由调度器分配合适的L3 Agent和这个路由器关联。调度的算法有两个,如下:
默认调度算法为LeastRoutersScheduler。配置(也在neutron.conf)如下图所示:
总之:一个路由器可以关联多个L3 Agent。而一个L3 Agent可以包含多个路由器。
重启下面的服务:
1.1.1.2 网络节点1
该网络节点为之前就已经安装部署好的。
首先在配置文件:/etc/neutron/plugins/ml2/linuxbridge_agent.ini将l2_population禁用掉。因为它与L3 Agent HA机制不兼容 (可参考链接: https://docs.openstack.org/neutron/queens/admin/deploy-lb-ha-vrrp.html#deploy-lb-ha-vrrp)。
其他的配置与原有的一样,无需改动。
重启服务:
1.1.1.3 网络节点2
新增的网络节点。存在管理网网卡、数据网网卡、外部网网卡。
需要安装如下的服务:
layer-2 agent, layer-3 agent。
需要修改如下的配置项,具体配置值参考网络节点1
1.1.1.4 计算节点
无需变化,保持原有的配置。
1.1.1.5 额外配置
修改配置文件(两个网络节点都需要改):/etc/neutron/l3_agent.ini
在该配置文件中提供了这个配置项:ha_vrrp_health_check_interval = xxx (单位s)
这个配置项的作用是:开启keepalived对外部网络的默认网关执行健康检查。如发现无法ping通外部网络的默认网关时,则将master router切换到另外一个l3 agent上。例如:master router绑定了外部网络:192.168.x.0/22,默认网关为: 192.168.x.254.当ping 192.168.x.254失败时则会发生路由主备切换,master router将不再是主路由器,其他的standby router将切换为master router。
配置完后,需要重启如下的服务:
1.1.2 实验
如上图所示,有两个节点,都部署了L3 Agent。其中主路由器在node1节点上,从路由器在node2节点上。
我们可以看到两个节点上都有route namespace,如下:
首先我们先来看下主路由器的namespace接口信息:
对应的路由表信息:
Keepalived进程信息:
进到keepalived配置文件所在的目录下,可以看到有如下几个文件:
其中state文件记录了当前的路由器是主还是从。
下图是keepalived的配置信息:
ha_check_script_1.sh的内容如下:
我们再来看下从路由器上的接口信息:
只有一个ha-xxx接口有IP地址,其他接口都没有关联任何的IP地址。只有当这个从路由器升为主路由器时才会关联IP地址。
只有一条路由表:
进到配置文件所在的目录,如下:
查看state文件得知该路由器是从路由器。
下图是keepalived的配置文件内容,如下:
由此可见,配置内容和主路由器上的配置内容是相同的。
ha_check_script_1.sh脚本内容如下:
现在在主路由器上将ha-xxx端口down掉来模拟主路由器故障,如下图所示:
从上图可知,主路由器已经不是主了。接口关联的IP地址全部都删除了。重新再把接口up起来后,也不会发生抢占:
我们再看下之前的从,如下图所示,可以看见接口都关联上了IP地址:
这两个接口不能手工删除,只有将整个路由器删除后,这些接口会自动删除。同时HA网络和子网也会自动删除。
同一个租户下,无论创建多少个路由器,HA网络都只会创建一个,如下:
路由器创建了两个:
在节点2上看路由命名空间,有两个路由器的接口信息如下:
在节点1上查看两个路由器的命名空间接口信息如下:
只有删除了route1和route2后才会自动删除HA网络和子网及其端口。
2 DHCP Agent HA
2.1 配置
2.1.1 新节点
在新的节点上安装dhcp agent,例如这次在计算节点上安装dhcp agent,执行如下:
然后重启如下的服务:
2.1.2 控制节点
然后重启如下的服务:
2.1.3 网络节点
保持不变。
2.1.4 计算节点
保持不变。
2.1.5 配置后结果
从上图可以看到,在计算节点也增加了一个dhcp agent。
2.2 实验
对于上图中所提及的”vm最终只选择其中一个dhcp server”,是由于DHCP协议的天然支持。在同一个局域网内,可以同时存在多个DHCP服务器供局域网内的主机动态获取IP地址等信息,最先返回响应给vm的DHCP服务器将会被选中。
先来创建一个租户网络:
查看该网络net1关联了哪些DHCP Agent,如下图所示:
可以看到创建的网络关联到了2个DHCP Agent(和我们配置的数量是一致的)。
查看某个DHCP Agent包含了哪些网络,如下图所示:
Show详细的dhcp agent信息:
查看dhcp namespace信息如下:
可以看到,两个节点上的dhcp namespace中分配的接口IP地址,MAC地址都是不同的。
我们再来看下两个节点接收到的dhcp报文信息,如下:
上图是在控制节点上接收的dhcp报文信息,有完整的交互过程。
上图为在计算节点接收到的dhcp报文信息,可以看出vm都向这两个dhcp server发送了dhcp广播请求报文,并且两个dhcp server都给VM回应了Offer报文。但是vm最终选择了在控制节点上的dhcp server分配的IP地址。
手动添加dhcp agent到某个网络的方法如下:
手动将dhcp agent移出某个网络的方法如下:
禁用dhcp agent的方法如下:
禁用dhcp agent之后,之前分配的资源依然保留着,因此需要删除dhcp agent才能释放资源,如下所示:
重启dhcp agent进程后,又会重新出现。
首先在控制节点上禁用dhcp agent,如下所示:
这个时候在vm再重新发起dhcp请求,看看在哪个dhcp agent会处理。如下图所示,计算节点上的dhcp server完成了整个dhcp的流程:
进入到dnsmasq进程的配置文件,两个节点的配置信息都是一样的:
3 结论
从上述的内容描述来看,开源自带的l3 agent ha和dhcp agent ha方案功能上是正常的。但该方案用于生产环境中是否存在稳定性、性能等问题仍需后续进一步考证。其次文中所述的HA方案与L2 Population机制存在冲突,具体冲突的原因还未知,实验过程中也未出现冲突的问题,因此该问题有待后续分析验证。
对于上述这两个问题,如果有朋友已经分析验证过,还望您能够分享下心得体会,非常感谢!
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK