- 微信
- 微博
  
  分享文章到微博
- 复制链接
  
  复制链接到剪贴板

《OpenStack高可用集群（下册）：部署与运维》—11.4.2　HAProxy负载均衡器高可用部署

华章计算机发表于 2019/05/29 20:58:23 2019/05/29

【摘要】本书摘自《OpenStack高可用集群（下册）：部署与运维》一书中的第11章，第11.4.2节，作者是山金孝。

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: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

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