基于 Keepalived + HAproxy 的 RabbitMQ 高可用配置实践

本文使用的高可用架构是 Keepalived + HAproxy,用 HAproxy 来做 RabbitMQ 负载均衡和高可用,用 Keepalived 来保证 HAproxy 的高可用。

RabbitMQ 集群的安装过程这里不再赘述,可以参考 https://blog.csdn.net/WoogeYu/article/details/51119101

这里使用的三节点集群的安装方式,规划如下:

组件 IP 端口
RabbitMQ 主 192.168.151.7 5672
RabbitMQ 从 192.168.151.18 5672
RabbitMQ 从 192.168.151.19 5672
HAproxy 主 192.168.151.18
HAproxy 从 192.168.151.19
Keepalived 主 192.168.151.18
Keepalived 从 192.168.151.19
VIP 192.168.151.108

RabbitMQ 集群安装

在 192.168.151.7、192.168.151.18、192.168.151.19 三个节点上分别安装配置。

安装

1
2
yum -y install rabbitmq-server
service rabbitmq-server start

配置

1
2
3
4
5
6
rabbitmqctl add_user admin admin
rabbitmqctl set_user_tags admin administrator
set_permissions -p / admin '.*' '.*' '.*'
rabbitmqctl set_permissions -p / admin '.*' '.*' '.*'

rabbitmq-plugins enable rabbitmq_management
  • 局域网配置

分别在三个节点的 /etc/hosts 下设置相同的配置信息

1
2
3
192.168.151.7 HRB-PCRP1-M-BCCLM-CTL7
192.168.151.18 HRB-PCRP1-M-BCCLM-CTL18
192.168.151.19 HRB-PCRP1-M-BCCLM-CTL19
  • 设置不同节点间同一认证的 Erlang Cookie

采用从主节点 copy 的方式保持 Cookie 的一致性。

1
2
# scp /var/lib/rabbitmq/.erlang.cookie 192.168.151.18:/var/lib/rabbitmq
# scp /var/lib/rabbitmq/.erlang.cookie 192.168.151.19:/var/lib/rabbitmq12
  • 使用 -detached 运行各节点
1
2
rabbitmqctl stop
rabbitmq-server -detached
  • 查看各节点的状态
1
rabbitmqctl cluster_status
  • 创建并部署集群,以 192.168.151.7 节点为例:
1
2
3
4
# rabbitmqctl stop_app
# rabbitmqctl reset
# rabbitmqctl join_cluster rabbit@HRB-PCRP1-M-BCCLM-CTL7
# rabbitmqctl start_app
  • 查看集群状态
1
2
3
4
5
6
7
8
9
10
11
12
13
# rabbitmqctl cluster_status
Cluster status of node 'rabbit@HRB-PCRP1-M-BCCLM-CTL7' ...
[{nodes,[{disc,['rabbit@HRB-PCRP1-M-BCCLM-CTL18',
'rabbit@HRB-PCRP1-M-BCCLM-CTL19',
'rabbit@HRB-PCRP1-M-BCCLM-CTL7']}]},
{running_nodes,['rabbit@HRB-PCRP1-M-BCCLM-CTL18',
'rabbit@HRB-PCRP1-M-BCCLM-CTL19',
'rabbit@HRB-PCRP1-M-BCCLM-CTL7']},
{cluster_name,<<"rabbit@HRB-PCRP1-M-BCCLM-CTL7">>},
{partitions,[]},
{alarms,[{'rabbit@HRB-PCRP1-M-BCCLM-CTL18',[]},
{'rabbit@HRB-PCRP1-M-BCCLM-CTL19',[]},
{'rabbit@HRB-PCRP1-M-BCCLM-CTL7',[]}]}]

RabbitMQ 集群至此安装完成。可以通过访问各节点的 http://192.168.151.7:15672/ 管理页面查看 RabbitMQ 状态。用户名密码使用之前配置的 admin/admin。

Keepalived 监控 192.168.151.18、192.168.151.19 上的 HAproxy,利用 Keepalived 的 VIP 漂移技术,若两台服务器上的 HAprox 都工作正常,则 VIP 与优先级别高的服务器(主服务器)绑定,当主服务器当掉时,则与从服务器绑定,而 VIP 则是暴露给外部访问的 IP;HAproxy 利用 Keepalived 生产的 VIP 对多台 RabbitMQ 进行读负载均衡。

下面对上面的 RabbitMQ 集群进行高可用配置,HAproxy 和 Keepalived 的安装方法这里不再赘述。

高可用架构

Keepalived + HAproxy

其中 Keepalived 来控制 HAproxy 的高可用,HAproxy 的作用是控制下层应用的负载均衡,同时可以用来保证下层应用的高可用。

HAproxy

HAproxy 是一个七层的负载均衡高度器,和 nginx 是属于一个层次上的,而 lvs 是一个四层的负载均衡高度器,它最多只能工作在 TCP/IP 协议栈上,所以对于代理转发,HAproxy 做的可以比 lvs 更细腻。

HAProxy 提供高可用性、负载均衡以及基于 TCP 和 HTTP 应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。HAProxy 特别适用于那些负载特大的 web 站点,这些站点通常又需要会话保持或七层处理。HAProxy 运行在当前的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中,同时可以保护你的 web 服务器不被暴露到网络上。

HAproxy 配置

这里仅列出了主要内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
####################HAProxy配置中分成五部分内容,当然这些组件不是必选的,可以根据需要选择部分作为配置。
#global :参数是进程级的,通常和操作系统(OS)相关。这些参数一般只设置一次,如果配置无误,就不需要再次配置进行修改
#defaults:配置默认参数的,这些参数可以被利用配置到frontend,backend,listen组件
#frontend:接收请求的前端虚拟节点,Frontend可以根据规则直接指定具体使用后端的 backend(可动态选择)。
#backend :后端服务集群的配置,是真实的服务器,一个Backend对应一个或者多个实体服务器。
#listen :Frontend和Backend的组合体。

listen rabbitmq
bind 192.168.151.108:5673
balance roundrobin
mode tcp
option tcplog
option tcpka
bind-process 7
timeout client 15s
timeout connect 3s
timeout server 15s
server HRB-PCRP1-M-BCCLM-CTL7 192.168.151.7:5672 check inter 5000 rise 2 fall 3
server HRB-PCRP1-M-BCCLM-CTL18 192.168.151.18:5672 check inter 5000 rise 2 fall 3
server HRB-PCRP1-M-BCCLM-CTL19 192.168.151.19:5672 check inter 5000 rise 2 fall 3

# weight - 调节服务器的负重
# check - 允许对该服务器进行健康检查
# inter - 设置连续的两次健康检查之间的时间,单位为毫秒(ms),默认值 2000(ms)
# rise - 指定多少次连续成功的健康检查后,可认定该服务器处于可操作状态,默认值 2
# fall - 指定多少次不成功的健康检查后,认为服务器为当掉状态,默认值 3
# maxconn - 指定可被发送到该服务器的最大并发连接数

# 配置haproxy web监控,查看统计信息
listen private_monitoring :8100
mode http
option httplog
stats enable
#设置haproxy监控地址为http://localhost:8100/stats
stats uri /stats
stats refresh 5s

这里使用了一个 listen 块来同时实现前端和后端,也可以由前端(frontend)和后端(backend)配置。

最后我们打开 http://192.168.151.18:8100/stats,看一下监控页面,如果显示出正常就表明已经将 HAProxy 负载均衡配置好了!

HAProxy stats

注意点

启动 HAproxy 时可能会出现 cannot bind socket 的异常,这是因为 HAproxy 配置中使用了 VIP,但此时还没有启动 Keepalived,那么就还没有 VIP 绑定。

这时需要在 /etc/sysctl.conf 文件中配置如下内容:

1
2
net.ipv4.ip_nonlocal_bind = 1 # 意思是启动haproxy的时候,允许忽视VIP的存在
net.ipv4.ip_forward = 1 # 打开内核的转发功能

然后运行 sysctl –p 使其生效。

Keepalived

Keepalived 的作用是检测服务器的健康状态,在所有可能出现单点故障的地方为其提供高可用。如果有一台服务器死机,或工作出现故障,Keepalived 将检测到,并将有故障的服务器从系统中剔除,当服务器工作正常后 Keepalived 自动将服务器加入到服务器群中,这些工作全部自动完成,不需要人工干涉,需要人工做的只是修复故障的服务器。

这里使用的实现方式是单活方式,即主节点的 HAproxy 正常运行,备节点的会被停止。当主节点的出现故障时,备节点的 HAproxy 会自动启动。当主节点的恢复后,备节点的会自动停止。

当然 Keepalived 的高可用控制不止这一种,也可以有其他配置方式。

Keepalived 主节点配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
vrrp_script chk_haproxy {
script "service haproxy status" # 服务探测,返回0说明服务是正常的
interval 1 # 每隔1秒探测一次
weight -2 # 不正常时,权重-1,即haproxy上线,权重加2;下线,权重减2
}

vrrp_instance haproxy {
state MASTER # 主机为MASTER,备机为BACKUP
interface bond0 # 监测网络端口,用ipconfig查看
virtual_router_id 108 # 主备机必须相同
priority 100 # 主备机取不同的优先级,主机要大。
advert_int 1 # VRRP Multicast广播周期秒数
authentication {
auth_type PASS # VRRP认证方式
auth_pass 1234 # VRRP口令 主备机密码必须相同
}

track_script { # 调用haproxy进程检测脚本,备节点不配置
chk_haproxy
}
track_interface {
bond0
}
virtual_ipaddress { # VIP 漂移地址 即集群IP地址
192.168.151.108/25 dev bond0
}
}

Keepalived 备节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
vrrp_instance haproxy {
state BACKUP
interface bond0
virtual_router_id 108
priority 99
advert_int 1
authentication {
auth_type PASS
auth_pass 1234
}
track_interface {
bond0
}
virtual_ipaddress {
192.168.151.108
}
notify_master "/etc/keepalived/notify.sh master" # 当前节点成为master时,通知脚本执行任务,一般用于启动某服务
notify_backup "/etc/keepalived/notify.sh backup" # 当前节点成为backup时,通知脚本执行任务,一般用于关闭某服务

}

notify.sh 脚本

放在 /etc/keepalived/ 目录下,并赋予可执行权限。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/bin/bash

case "$1" in
master)
notify master
service haproxy start
exit 0
;;
backup)
notify backup
service haproxy stop
exit 0
;;
fault)
notify fault
service haproxy stop
exit 0
;;
*)
echo 'Usage: `basename $0` {master|backup|fault}'
exit 1
;;
esac

Keepalived 执行过程

MASTER - 初始 priority 为 100,BACKUP - 初始 priority 为 99

  • 模拟 MASTER 产生故障:

    • 当检测到 chk_haproxy 执行结果为 down 时,priority 每次减少 2,变为 98;低于 BACKUP 的 priority;
    • 此时 MASTER 变成 BACKUP;
    • 同时 BACKUP 变成 MASTER,同时执行 notify_master 的脚本文件(启动haproxy);
  • 模拟 MASTER 故障恢复:

    • 当 MASTER 节点的 HAproxy 恢复后,原 MASTER 的优先级又变为 100,高于原 BACKUP 的 priority;
    • 此时原 MASTER 由 BACKUP 又抢占成了 MASTER;
    • 同时原 BACKUP 由 MASTER 又变了 BACKUP,同时执行 notify_backup 的脚本文件(关闭haproxy);

参考:

hoxis wechat
提供 CSDN 资料免费下载服务,欢迎来撩~
赞赏一杯咖啡
0%