《OpenStack高可用集群(下册):部署与运维》—11.1.2 制作OpenStack离线安装yum源
900
2022-05-30
11.4.2 HAProxy负载均衡器高可用部署
负载均衡是OpenStack高可用集群中非常关键的部分,可以认为负载均衡器是整个OpenStack功能集群的入口,任何外部客户端或内部组件对集群服务的请求访问都需要通过负载均衡器,从而实现单点故障时集群功能访问仍可继续进行。关于集群负载均衡系统更为详细的工作原理和使用方法请参考第4章的相关内容,本节将重点介绍如何在Pacemaker集群中配置HAProxy负载均衡器,以及如何规划OpenStack各个相关功能组件的服务IP和其在HAProxy配置文件中的设置。
通常,在HAProxy高可用配置中,虚拟IP可以有两种配置方式:其一为使用单一虚拟IP作为集群对外服务IP,即负载均衡器所有后端服务共享同一个对外服务IP;其二为每个功能服务模块使用自己的虚拟IP,即虚拟服务IP与负载均衡器后端功能模块一一对应。采用第一种方式的优点是节省服务IP,HAProxy配置也相对简单,缺点在于集群所有服务通过单一虚拟IP对外暴露,而单一IP仅能配置在单一控制节点上(负载均衡器部署在控制节点上),对于大规模集群高并发访问而言,容易造成单一控制节点负载过高和网络瓶颈问题,此类配置多见于OpenStack官方高可用配置网站和Mirantis部分高可用方案。如果采用第二种配置方式,则可以将不同的服务虚拟IP分布到不同的控制节点上,而访问负载也随之分布到不同节点上,因此对于大规模生产环境而言,第二种负载均衡IP配置方式更为合理,RedHat提出的OpenStack高可用方案采用的便是此类负载均衡配置方式。为了更为合理地负载客户端请求,本节介绍的HAProxy配置方案采用的是第二类虚拟服务IP配置方案。在本章介绍的OpenStack高可用配置中,对外服务IP网段为管理网段,即192.168.142.0/24。OpenStack高可用集群各个服务组件对外服务虚拟IP规划如表11-1所示。
表11-1 OpenStack高可用集群虚拟IP规划
在配置HAProxy之前,需要安装HAProxy负载均衡软件包。由于本节介绍的方案将负载均衡器部署在控制节点上,因此还需对控制节点操作系统做相应的设置:
yum install -y haproxy
echo "net.ipv4.ip_nonlocal_bind=1" > /etc/sysctl.d/haproxy.conf
sysctl -p
echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind
cat >/etc/sysctl.d/tcp_keepalive.conf << EOF
net.ipv4.tcp_keepalive_intvl = 1
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_time = 5
EOF
sysctl net.ipv4.tcp_keepalive_intvl=1
sysctl net.ipv4.tcp_keepalive_probes=5
sysctl net.ipv4.tcp_keepalive_time=5
不要手动启动HAProxy,因为HAProxy后续将配置为Pacemaker资源,其启动停止等操作完全由Pacemaker自行决定。根据表11-1中规划设置的服务虚拟IP,HAProxy配置文件/etc/haproxy/haproxy.cfg的配置内容如下所示:
[root@controller1-vm ~]# more /etc/haproxy/haproxy.cfg
……
frontend vip-keystone-admin
bind 192.168.142.203:35357
default_backend keystone-admin-vms
backend keystone-admin-vms
balance roundrobin
server controller1-vm 192.168.142.110:35357 check inter 1s
server controller2-vm 192.168.142.111:35357 check inter 1s
server controller3-vm 192.168.142.112:35357 check inter 1s
frontend vip-keystone-public
bind 192.168.142.203:5000
default_backend keystone-public-vms
backend keystone-public-vms
balance roundrobin
server controller1-vm 192.168.142.110:5000 check inter 1s
server controller2-vm 192.168.142.111:5000 check inter 1s
server controller3-vm 192.168.142.112:5000 check inter 1s
frontend vip-glance-api
bind 192.168.142.205:9191
default_backend glance-api-vms
backend glance-api-vms
balance roundrobin
server controller1-vm 192.168.142.110:9191 check inter 1s
server controller2-vm 192.168.142.111:9191 check inter 1s
server controller3-vm 192.168.142.112:9191 check inter 1s
……
在进一步配置之前,务必保证三个控制节点中/etc/haproxy/haproxy.cfg内容完全一致,关于haproxy.cfg文件的配置格式和参数解释请参考第4章中的相关内容。HAProxy大致工作原理就是客户端访问前端虚拟IP,之后HAProxy通过一定的负载均衡算法将访问请求负载均衡并转发到后端物理服务器中。上述haproxy.cfg配置文件中,一共有三个后端物理服务器,即controller1-vm、controller2-vm和controller3-vm,其对应的IP分别为192.168.142.110、192.168.142.111和192.168.142.112。在实际应用中,虚拟IP可以通过Keepalived或者Pacemaker资源管理的形式实现高可用,这里采用的虚拟IP高可用方案为Pacemaker资源形式,即将虚拟IP配置为受Pacemaker管理的Ipaddr2资源,通过Pacemaker IP资源管理的形式来实现虚拟IP的高可用。在Pacemaker集群中,HAProxy和虚拟IP高可用资源的创建过程如下。
创建Pacemaker集群HAProxy资源:
pcs resource create lb-haproxy systemd:haproxy --clone
创建Pacemaker集群虚拟IP资源:
components=lb db rabbitmq keystone memcache glance cinder swift-brick\
swift neutron nova horizon heat mongodb ceilometer qpid
offset=200
internal_network=192.168.142
for section in ${components}; do
case $section in
lb|memcache|swift-brick|mongodb)
echo "No VIP needed for $section"
;;
*)
pcs resource create vip-${section} IPaddr2\
ip=${internal_network}.${offset} nic=eth1
pcs constraint order start vip-${section} then lb-haproxy-clone\
kind=Optional
pcs constraint colocation add vip-${section} with lb-haproxy-clone
;;
esac
offset=$(( $offset + 1 ))
done
虚拟IP资源创建完成后,通过pcs status命令查看Pacemaker集群及其资源运行状态,集群输出信息应该如下:
[root@controller1-vm ~]# pcs status
……
fence3 (stonith:fence_xvm): Started controller3-vm
Clone Set: lb-haproxy-clone [lb-haproxy]
Started: [ controller1-vm controller2-vm controller3-vm ]
vip-db (ocf::heartbeat:IPaddr2): Started controller1-vm
vip-rabbitmq (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-keystone (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-glance (ocf::heartbeat:IPaddr2): Started controller1-vm
vip-cinder (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-swift (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-neutron (ocf::heartbeat:IPaddr2): Started controller1-vm
vip-nova (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-horizon (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-heat (ocf::heartbeat:IPaddr2): Started controller1-vm
vip-ceilometer (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-qpid (ocf::heartbeat:IPaddr2): Started controller3-vm
……
可以看到,HAProxy以Clone资源的形式同时运行在三个控制节点上,而全部集群虚拟IP均匀分布在三个控制节点上。此时,查看controller1-vm中eth1网口,正常情况下应该可以看到eth1上除了192.168.142.110外,还被配置了很多虚拟IP:
[root@controller1-vm ~]# ip a
......
3: eth1:
link/ether 00:0c:29:b9:a2:f2 brd ff:ff:ff:ff:ff:ff
inet 192.168.142.110/24 brd 192.168.142.255 scope global eth1
valid_lft forever preferred_lft forever
inet 192.168.142.205/24 brd 192.168.142.255 scope global secondary eth1
valid_lft forever preferred_lft forever
inet 192.168.142.201/24 brd 192.168.142.255 scope global secondary eth1
valid_lft forever preferred_lft forever
inet 192.168.142.209/24 brd 192.168.142.255 scope global secondary eth1
valid_lft forever preferred_lft forever
inet 192.168.142.212/24 brd 192.168.142.255 scope global secondary eth1
valid_lft forever preferred_lft forever
......
现关闭controller1-vm控制节点以模拟该节点故障,正常情况下之前运行在controller1-vm上的虚拟IP应该自动迁移到controller2或者controller3节点上。对controller1-vm进行隔离操作:
[root@controller3-vm ~]# pcs stonith fence controller1-vm --off
Node: controller1-vm fenced
再次检查Pacemaker集群上虚拟IP资源的节点分布情况。pcs status输出的集群资源信息如下:
[root@controller3-vm ~]# pcs resource
Clone Set: lb-haproxy-clone [lb-haproxy]
Started: [ controller2-vm controller3-vm ]
Stopped: [ controller1-vm ]
vip-db (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-rabbitmq (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-keystone (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-glance (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-cinder (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-swift (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-neutron (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-nova (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-horizon (ocf::heartbeat:IPaddr2): Started controller3-vm
vip-heat (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-ceilometer (ocf::heartbeat:IPaddr2): Started controller2-vm
vip-qpid (ocf::heartbeat:IPaddr2): Started controller3-vm
可以看到,controller1-vm节点故障后,Pacemaker集群IP资源一个没少,即之前位于controller1-vm节点的虚拟IP资源全部迁移到controller2-vm或controller3-vm控制节点上,真正实现了虚拟IP单点故障时的高可用。而HAProxy由于同时运行在三个控制节点上,因此任何一个节点故障均不会影响HAProxy的正常使用。本节HAProxy高可用部署源代码请参考笔者位于Github上的开源项目https://github.com/ynwssjx/Openstack-HA-Deployment,对应的部署脚本为2_create_vip_resource_on_pacemaker.sh。
OpenStack 云计算
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。