36

Openstack Linuxbridge网络高可用分析

 5 years ago
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环境为准。

04open668.jpg

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 控制节点

Java
修改配置文件:/etc/neutron/neutron.conf [DEFAULT] l3_ha = True l3_ha_net_cidr = 169.254.192.0/18 (HA网络) max_l3_agents_per_router = 2 (一个路由器关联的L3 Agent数量)
1
2
3
4
5
修改配置文件:/etc/neutron/neutron.conf
[DEFAULT]
l3_ha=True
l3_ha_net_cidr=169.254.192.0/18  (HA网络)
max_l3_agents_per_router=2(一个路由器关联的L3 Agent数量)

对于一个路由器关联多个L3 Agent时,当创建一个路由器时,需要由调度器分配合适的L3 Agent和这个路由器关联。调度的算法有两个,如下:

04open%20stack01.png

默认调度算法为LeastRoutersScheduler。配置(也在neutron.conf)如下图所示:

04open%20stack02.png

总之:一个路由器可以关联多个L3 Agent。而一个L3 Agent可以包含多个路由器。
重启下面的服务:

Java
service neutron-server restart
1
service neutron-server restart

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)。
其他的配置与原有的一样,无需改动。
重启服务:

Java
service neutron-l3-agent restart
1
service neutron-l3-agent restart

1.1.1.3 网络节点2
新增的网络节点。存在管理网网卡、数据网网卡、外部网网卡。
需要安装如下的服务:
layer-2 agent, layer-3 agent。

Java
修改配置文件:/etc/neutron/neutron.conf
1
修改配置文件:/etc/neutron/neutron.conf

需要修改如下的配置项,具体配置值参考网络节点1

Java
修改配置:/etc/neutron/plugins/ml2/linuxbridge_agent.ini 具体配置项参考:网络节点1 修改配置:/etc/neutron/l3_agent.ini 具体配置参考:网络节点1 重启如下的服务: service neutron-linuxbridge-agent restart service neutron-l3-agent restart
1
2
3
4
5
6
7
修改配置:/etc/neutron/plugins/ml2/linuxbridge_agent.ini
具体配置项参考:网络节点1
修改配置:/etc/neutron/l3_agent.ini
具体配置参考:网络节点1
重启如下的服务:
service neutron-linuxbridge-agent restart
service neutron-l3-agent restart

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。
配置完后,需要重启如下的服务:

Java
service neutron-l3-agent restart
1
service neutron-l3-agent restart

1.1.2 实验

04open%20stack03.jpg

如上图所示,有两个节点,都部署了L3 Agent。其中主路由器在node1节点上,从路由器在node2节点上。
我们可以看到两个节点上都有route namespace,如下:

04open%20stack04.png

04open%20stack61.png

首先我们先来看下主路由器的namespace接口信息:

04open%20stack06.png

对应的路由表信息:

04open%20stack07.png

Keepalived进程信息:

04open%20stack08.png

进到keepalived配置文件所在的目录下,可以看到有如下几个文件:

04open%20stack09.png

其中state文件记录了当前的路由器是主还是从。
下图是keepalived的配置信息:

04open%20stack10.png

ha_check_script_1.sh的内容如下:

04open%20stack11.png

04open%20stack12.png

我们再来看下从路由器上的接口信息:

04open%20stack13.png

只有一个ha-xxx接口有IP地址,其他接口都没有关联任何的IP地址。只有当这个从路由器升为主路由器时才会关联IP地址。
只有一条路由表:

04open%20stack14.png

04open%20stack15.png

进到配置文件所在的目录,如下:

04open%20stack16.png

查看state文件得知该路由器是从路由器。
下图是keepalived的配置文件内容,如下:

04open%20stack17.png

由此可见,配置内容和主路由器上的配置内容是相同的。
ha_check_script_1.sh脚本内容如下:

04open%20stack19.png

现在在主路由器上将ha-xxx端口down掉来模拟主路由器故障,如下图所示:

04open%20stack20.png

从上图可知,主路由器已经不是主了。接口关联的IP地址全部都删除了。重新再把接口up起来后,也不会发生抢占:

04open%20stack21.png

我们再看下之前的从,如下图所示,可以看见接口都关联上了IP地址:

04open%20stack22.png

04open%20stack23.png

04open%20stack24.png

04open%20stack25.png

04open%20stack26.png

04open%20stack27.png

04open%20stack28.png

这两个接口不能手工删除,只有将整个路由器删除后,这些接口会自动删除。同时HA网络和子网也会自动删除。
同一个租户下,无论创建多少个路由器,HA网络都只会创建一个,如下:

04open%20stack29.png

路由器创建了两个:

04open%20stack30.png

在节点2上看路由命名空间,有两个路由器的接口信息如下:

04open%20stack31.png

在节点1上查看两个路由器的命名空间接口信息如下:

04open%20stack32.png

只有删除了route1和route2后才会自动删除HA网络和子网及其端口。

2 DHCP Agent HA

2.1 配置

2.1.1 新节点

在新的节点上安装dhcp agent,例如这次在计算节点上安装dhcp agent,执行如下:

Java
apt-get install neutron-dhcp-agent 修改配置文件: /etc/neutron/dhcp_agent.ini [DEFAULT] interface_driver = linuxbridge dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq enable_isolated_metadata = true
1
2
3
4
5
6
apt-get install neutron-dhcp-agent
修改配置文件:/etc/neutron/dhcp_agent.ini
[DEFAULT]
interface_driver=linuxbridge
dhcp_driver=neutron.agent.linux.dhcp.Dnsmasq
enable_isolated_metadata=true

然后重启如下的服务:

Java
service neutron-dhcp-agent restart
1
service neutron-dhcp-agent restart

2.1.2 控制节点

Java
修改配置文件:/etc/neutron/neutron.conf [DEFAULT] dhcp_agents_per_network = 2 (每个网络会关联两个DHCP Agent)
1
2
3
修改配置文件:/etc/neutron/neutron.conf
[DEFAULT]
dhcp_agents_per_network=2  (每个网络会关联两个DHCP Agent)

然后重启如下的服务:

Java
service neutron-server restart
1
service neutron-server restart

2.1.3 网络节点

保持不变。

2.1.4 计算节点

保持不变。

2.1.5 配置后结果

04open%20stack33.png

从上图可以看到,在计算节点也增加了一个dhcp agent。

2.2 实验

04open%20stack34.jpg

对于上图中所提及的”vm最终只选择其中一个dhcp server”,是由于DHCP协议的天然支持。在同一个局域网内,可以同时存在多个DHCP服务器供局域网内的主机动态获取IP地址等信息,最先返回响应给vm的DHCP服务器将会被选中。
先来创建一个租户网络:

04open%20stack35.png

04open%20stack36.png

查看该网络net1关联了哪些DHCP Agent,如下图所示:

04open%20stack37.png

可以看到创建的网络关联到了2个DHCP Agent(和我们配置的数量是一致的)。
查看某个DHCP Agent包含了哪些网络,如下图所示:

04open%20stack38.png

Show详细的dhcp agent信息:

04open%20stack39.png

查看dhcp namespace信息如下:

04open%20stack40.png

04open%20stack41.png

可以看到,两个节点上的dhcp namespace中分配的接口IP地址,MAC地址都是不同的。
我们再来看下两个节点接收到的dhcp报文信息,如下:

04open%20stack42.png

上图是在控制节点上接收的dhcp报文信息,有完整的交互过程。

04open%20stack43.png

上图为在计算节点接收到的dhcp报文信息,可以看出vm都向这两个dhcp server发送了dhcp广播请求报文,并且两个dhcp server都给VM回应了Offer报文。但是vm最终选择了在控制节点上的dhcp server分配的IP地址。
手动添加dhcp agent到某个网络的方法如下:

04open%20stack44.png

手动将dhcp agent移出某个网络的方法如下:

04open%20stack45.png

禁用dhcp agent的方法如下:

04open%20stack46.png

禁用dhcp agent之后,之前分配的资源依然保留着,因此需要删除dhcp agent才能释放资源,如下所示:

04open%20stack47.png

重启dhcp agent进程后,又会重新出现。
首先在控制节点上禁用dhcp agent,如下所示:

04open%20stack48.png

这个时候在vm再重新发起dhcp请求,看看在哪个dhcp agent会处理。如下图所示,计算节点上的dhcp server完成了整个dhcp的流程:

04open%20stack49.png

进入到dnsmasq进程的配置文件,两个节点的配置信息都是一样的:

04open%20stack50.png

04open%20stack51.png

3 结论

从上述的内容描述来看,开源自带的l3 agent ha和dhcp agent ha方案功能上是正常的。但该方案用于生产环境中是否存在稳定性、性能等问题仍需后续进一步考证。其次文中所述的HA方案与L2 Population机制存在冲突,具体冲突的原因还未知,实验过程中也未出现冲突的问题,因此该问题有待后续分析验证。
对于上述这两个问题,如果有朋友已经分析验证过,还望您能够分享下心得体会,非常感谢!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK