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

文章目录

[隐藏]

• 组件 IP 端口
• RabbitMQ 集群安装
• 高可用架构 Keepalived + HAproxy
  • HAproxy
  • HAproxy 配置
  • Keepalived
  • Keepalived 主节点配置
  • Keepalived 备节点

本文使用的高可用架构是 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 三个节点上分别安装配置。

安装

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

配置

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 下设置相同的配置信息

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 的一致性。

# 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 运行各节点

rabbitmqctl stop  rabbitmq-server -detached  

查看各节点的状态

rabbitmqctl cluster_status  

创建并部署集群，以 192.168.151.7 节点为例：

# rabbitmqctl stop_app  # rabbitmqctl reset  # rabbitmqctl join_cluster [email protected]  # rabbitmqctl start_app  

查看集群状态

# rabbitmqctl cluster_status  Cluster status of node ‘[email protected]’ …  [{nodes,[{disc,[‘[email protected]’,  ‘[email protected]’,  ‘[email protected]’]}]},  {running_nodes,[‘[email protected]’,  ‘[email protected]’,  ‘[email protected]’]},  {cluster_name,<<“[email protected]”>>},  {partitions,[]},  {alarms,[{‘[email protected]’,[]},  {‘[email protected]’,[]},  {‘[email protected]’,[]}]}]  

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 配置

这里仅列出了主要内容。

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 时可能会出现 cannot bind socket 的异常，这是因为 HAproxy 配置中使用了 VIP，但此时还没有启动 Keepalived，那么就还没有 VIP 绑定。

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

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

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

Keepalived

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

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

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

Keepalived 主节点配置

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 备节点

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/ 目录下，并赋予可执行权限。

#!/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）；

原文出处：huur -> https://huur.cn/dc/web/1429.html