基于 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 rabbit@HRB-PCRP1-M-BCCLM-CTL7  # rabbitmqctl start_app  

查看集群状态

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

这里仅列出了主要内容。

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

本站所发布的一切资源仅限用于学习和研究目的;不得将上述内容用于商业或者非法用途,否则,一切后果请用户自负。本站信息来自网络,版权争议与本站无关。您必须在下载后的24个小时之内,从您的电脑中彻底删除上述内容。如果您喜欢该程序,请支持正版软件,购买注册,得到更好的正版服务。如果侵犯你的利益,请发送邮箱到 [email protected],我们会很快的为您处理。
超哥软件库 » 基于 Keepalived + HAproxy 的 RabbitMQ 高可用配置实践