Centos7.9搭建rabbitmq+haproxy+keepalived高可用集群

Posted 2022-01-28 我是一只小小茑

Centos7.9搭建rabbitmq+haproxy+keepalived高可用集群 

一 rabbitmq简介

为什么搭建rabbitmq集群？rabbitmq集群有那些模式？如何搭建Rabbitmq集群？rabbitmq镜像高可用策略有那些？

1、首先这款产品本身的优点众多，大家最看好的便是他的异步化提高系统抗峰值能力，然后便是系统及功能结构解耦，那么照此两点来说，他的在整个系统中的作用还是至关重要的，那么如此重要，当然要考虑他的高可用性，那么便有啦第一个问题的解答。

2、rabbitmq有3种模式，但集群模式是2种。详细如下：

• 单一模式：即单机情况不做集群，就单独运行一个rabbitmq而已。

• 普通模式：默认模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。

• 镜像模式:把需要的队列做成镜像队列，存在与多个节点属于RabbitMQ的HA方案。该模式解决了普通模式中的问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用。

二 安装RabbitMQ单机环境（2台机器操作一样）

我的环境如下：

1、两台Centos7.9的机器，hostname分别为：centos1，centos2,centos3 .

2、IP地址分别为：

192.168.2.230 centos1

192.168.2.231 centos2

192.168.2.232 centos3

3、修改hosts文件如下，2台机器的hosts文件内容，如下配置：

4.安装rpm

[root@centos2 ~]# rpm -ivh socat-1.7.3.2-2.el7.x86_64.rpm

[root@centos2 ~]# rpm -ivh erlang-22.2.7-1.el7.x86_64.rpm

[root@centos2 ~]# rpm -ivh rabbitmq-server-3.8.1-1.el7.noarch.rpm

注：rabbitmq3.8版本默认用户guest访问报错User can only log in via localhost解决方案

cat > /etc/rabbitmq/rabbitmq.config <<EOF

[rabbit, [loopback_users, []]].

EOF

5.设置开机启动服务

[root@centos1 ~]# systemctl start rabbitmq-server

[root@centos1 ~]# systemctl enable rabbitmq-server

6.开启图形化管理界面

[root@centos1 ~]# rabbitmq-plugins enable rabbitmq_management

7.添加用户

[root@centos1 ~]# rabbitmqctl add_user test test

--添加test用户，password为test

[root@centos1 ~]# rabbitmqctl set_user_tags test administrator

--设置 test 为administrator权限

三 搭建rabbitmq的一般模式集群

在上述的两台机器上安装rabbitmq完成之后，你可以看到你的机器中有如下1个文件。路径在$HOME中或者在/var/lib/rabbitmq中，文件名称为.erlang.cookie,他是一个隐藏文件。

那么这文件存储的内容是什么，是做什么用的呢？

这样说吧：RabbitMQ的集群是依赖erlang集群，而erlang集群是通过这个cookie进行通信认证的，因此我们做集群的第一步就是干cookie。怎么干？

1.必须使集群中也就是centos1，centos2这两台机器的.erlang.cookie文件中cookie值一致，且权限为owner只读。(将centos1的cookie的值拷贝到centos2)

[root@centos1 ~]# grep -v ^$ /var/lib/rabbitmq/.erlang.cookie

[root@centos1 rabbitmq]# chmod 600 .erlang.cookie

2.我们这里以 centos1 为 master 节点，centos2，centos3为slave节点(从节点操作一样)

[root@centos2 ~]# rabbitmqctl stop_app

把centos2中的rabbitmq加入到集群中来

[root@centos2 ~]# rabbitmqctl join_cluster --ram rabbit@centos1

[root@centos2 ~]# rabbitmqctl start_app

3.查看集群状态（任意一个节点操作）

[root@centos2 ~]# rabbitmqctl cluster_status

打开网页管理页面查看nodes

上面已经完成RabbitMQ默认集群模式，但并不保证队列的高可用性，尽管交换机、绑定这些可以复制到集群里的任何一个节点，但是队列内容不会复制。虽然该模式解决一项目组节点压力，但队列节点宕机直接导致该队列无法应用，只能等待重启，所以要想在队列节点宕机或故障也能正常应用，就要复制队列内容到集群里的每个节点，必须要创建镜像队列。

四.搭建rabbitmq的镜像高可用模式集群

镜像队列概念

镜像队列可以同步queue和message，当主queue挂掉，从queue中会有一个变为主queue来接替工作。

镜像队列是基于普通的集群模式的,所以你还是得先配置普通集群,然后才能设置镜像队列。

镜像队列设置后，会分一个主节点和多个从节点，如果主节点宕机，从节点会有一个选为主节点，原先的主节点起来后会变为从节点。

queue和message虽然会存在所有镜像队列中，但客户端读取时不论物理面连接的主节点还是从节点，都是从主节点读取数据，然后主节点再将queue和message的状态同步给从节点，

因此多个客户端连接不同的镜像队列不会产生同一message被多次接受的情况。

$ rabbitmqctl set_policy [-p Vhost]NamePatternDefinition [Priority]-p Vhost:可选参数，针对指定vhost下的queue进行设置

Name:policy的名称

Pattern:queue的匹配模式(正则表达式)Definition:镜像定义，包括三个部分ha-mode,ha-params,ha-sync-mode

ha-mode:指明镜像队列的模式，有效值为 all/exactly/nodes

all:表示在集群中所有的节点上进行镜像

exactly:表示在指定个数的节点上进行镜像，节点的个数由ha-params指定

nodes:表示在指定的节点上进行镜像，节点名称通过ha-params指定

ha-params:ha-mode模式需要用到的参数

ha-sync-mode:进行队列中消息的同步方式，有效值为automatic和manual

priority:可选参数，policy的优先级

1.设置镜像队列策略(命令设置)

将所有队列设置为镜像队列，进行队列中消息的同步方式,即队列会被复制到各个节点，各个节点状态一致。

[root@centos1 ~]# rabbitmqctl set_policy ha-all "^" "ha-mode":"all","ha-sync-mode":"automatic"

以下示例声明名为ha-all的策略，它与名称以”ha”开头的队列相匹配，并将镜像配置到集群中的所有节点：

rabbitmqctl set_policy ha-all "^""ha-mode":"all"

策略的名称以”two”开始的队列镜像到群集中的任意两个节点，并进行自动同步：

rabbitmqctl set_policy ha-two "^two.""ha-mode":"exactly","ha-params":2,"ha-sync-mode":"automatic"

以”node”开头的队列镜像到集群中的特定节点的策略：

rabbitmqctl set_policy ha-nodes "^nodes.""ha-mode":"nodes","ha-params":["rabbit@nodeA","rabbit@nodeB"]

2.设置镜像队列策略(图形界面设置)

2.1）.创建rabbitmq策略

在centos1节点的控制台上创建策略

（1）点击admin菜单–>右侧的Policies选项–>左侧最下下边的Add/update a policy。

（2）按照图中的内容根据自己的需求填写。

2.2）添加队列

在centos1节点的控制台上添加队列

（1）点击Queues菜单–>左侧下边的Add a new queue

（2）输入Name和Arguments参数的值，别的值默认即可

2.3）创建消息

（1）点击abc队列按钮

（2）拖动滚动条，点击publish message

（3）填写相关内容

点击queue按钮，发现ab队列的Ready和Total中多了一条消息记录。

2.4）做破坏性测试

（1）将centos1节点的服务关闭，再通过centos2查看消息记录是否还存在。

从中可以看到abc队列已经从之前的+2显示变成了+1，而且消息记录是存在的。

（2）将centos1的服务再启动起来

·测试了rabbitmq集群的破坏性测试，说明集群配置成功。

五 keepalived高可用

安装（2台机器都需要安装）

[root@node2 ~]# rpm -ivh haproxy-1.5.18-9.el7_9.1.x86_64.rpm

HAprox.cfg配置

[root@node2 ~]# cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg-back

cat > /etc/haproxy/haproxy.cfg << EOF

global

maxconn 20000 #最大连接数

ulimit-n 40014 #设置每个进程的可用的最大文件描述符

log 127.0.0.1 local0 info #使用本地的日志设备为haproxylog的日志设置记录，在rsyslog中配

pidfile /var/run/haproxy.pid

uid 200 #所属运行的用户uid

gid 200 #所属运行的用户组

nbproc 1 #启动ha-proxy实例数

daemon #以守护线程方式启动

defaults #默认设置

mode tcp #所处理的类别，默认是http,但是本次是tcp转发

retries 3 #3次连接失败就认为服务器不可用，主要通过后面的check检查

option redispatch #机器死掉后重定向到健康的机器

option abortonclose #当负载过高时，自动结束当前处理比较久的连接

timeout connect 5000ms #成功连接到一台服务器的最长等待时间

timeout client 30000ms #设置服务器回应客户端数据发送的最长等待时间

log 127.0.0.1 local1 err

listen admin_stats #配置ha的自带admin监控界面

bind 0.0.0.0:1080

mode http

log global #继承global中log定义

maxconn 10

stats refresh 30s #设置统计页面刷新频率

stats uri /stats #配置admin界面请求的uri地址

stats auth admin:admin #配置admin登录账户和password

stats realm codis haproxy for private user ,enter username/password #配置登录时提醒信息

stats hide-version

frontend codis-tcp-in #指定前置处理器，处理用户请求，绑定端口

bind *:5672 #监听端口19000的请求

mode tcp

log global

option tcplog

option dontlognull

option nolinger

timeout client 30s

default_backend codis-tcp-out #指定后置处理器转发

backend codis-tcp-out

mode tcp

timeout connect 5s

timeout server 5s

retries 3

balance roundrobin #负载均衡算法，轮询

server node1 192.168.2.230:5672 check inter 2000 rise 3 fall 3 weight 1

server node2 192.168.2.231:5672 check inter 2000 rise 3 fall 3 weight 1

server node3 192.168.2.232:5672 check inter 2000 rise 3 fall 3 weight 1

EOF

重启haproxy服务

[root@node2 ~ ]# systemctl restart haproxy

[root@node2 ~]# systemctl enable haproxy

安装keepalived(2台都需要安装)

[root@node2 ~]# yum localinstall keepalived-1.3.5-19.el7.x86_64.rpm

[root@node2 ~]# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf-back

[root@node2 ~]# cat /etc/keepalived/keepalived.conf （master配置）

global_defs

notification_email

[e-mail]

notification_email_from [e-mail]

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id node2

vrrp_script chk_haproxy

script "/home/check_HA.sh"

interval 2

weight -20

vrrp_instance VI_1

state MASTER

interface ens33

virtual_router_id 51

priority 100

advert_int 1

authentication

auth_type PASS

auth_pass 1111

virtual_ipaddress

192.168.2.182/24 brd 192.168.2.182 dev ens33 label ens33:0

track_script

chk_haproxy

[root@node3 ~]# cat /etc/keepalived/keepalived.conf （backup配置）

global_defs

notification_email

[e-mail]

notification_email_from [e-mail]

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id node3

vrrp_script chk_haproxy

script "/home/check_HA.sh"

interval 2

weight -20

vrrp_instance VI_1

state BACKUP

interface ens33

virtual_router_id 51

priority 99

advert_int 1

authentication

auth_type PASS

auth_pass 1111

virtual_ipaddress

192.168.2.182/24 brd 192.168.2.182 dev ens33 label ens33:0

track_script

chk_haproxy

脚本文件

[docker@node2 ~]$ cat /home/check_HA.sh

#!/bin/bash

A=​​​ps -C haproxy --no-header | wc -l​​​

if [ $A -eq 0 ];then

exit 1

else

exit 0

fi

[root@node2 ~] # systemctl start keepalived

[root@node2 ~]# systemctl enable keepalived

Keepalived+haproxy测试