RabbitMQ扩展内容

• 消息追踪
• • 1.1 Firehose
  • 1.2 rabbitmq_tracing插件
• 负载均衡
• • 2.1 在客户端内部实现负载均衡
  • 2.2 使用HAProxy实现负载均衡
  • 2.3 使用Keepalived+HAProxy实现高可靠负载均衡
  • 2.4 使用Keepalived+LVS实现负载均衡

消息追踪

目的：跟踪记录消息的投递过程，协议开发人员或运维人员快速定位问题。

1.1 Firehose

在RabbitMQ中可以使用Firehose功能来实现消息追踪，其可以记录每一次发送或消费消息的过程，方面进行调试、排错等。

Firehose的原理是将生产者或者消费者的消息按指定的格式发送到默认交换器上。默认交换器为amp.rabbitmq.trace，它是一个topic类型的交换器，发送到其上的消息路由键为publish.{exchangename}和deliver.{queuename}，其中exchangename和queuename为交换器和队列的名称，分别对应生产者投递到交换器的消息和消费者从队列中获取的消息。

#开启Firehose
rabbitmqctl trace_on [-p vhost]

#关闭Firehose
rabbitmqctl trace_off [-p vhost]

Firehose默认处于关闭状态，并且Firehose的状态也是非持久化的，会在RabbitMQ服务重启的时候还原成默认状态。开启会多少影响整体服务性能，因为它会引起额外的消息生成、路由和存储。

下面我们举例说明下Firehose的用法。需要做一下准备工作，确保Firehose处于开启状态，创建7个队列：queue、queue.another、queue1、queue2、queue3、queue4和queue5。之后再创建2个交换器exchange和exchange.another，分别通过绑定键rk和rk.another与queue和queue.another进行绑定。最后将amq.rabbitmq.trace这个关键的交换器与queue1、queue2、queue3、queue4和queue5绑定，详细可以参考下图。

分别用客户端向exchange和exchange.another中发送一条消息“trace test payload.”，然后再用客户端消费队列queue和queue.another中的消息。

此时queue1中有2条消息，queue2中有2条消息，queue3中有4条消息，而queue4和queue5中只有一条消息。在向exchange发送一条消息后，amq.rabbitmq.trace分别向queue1、queue3和queue4发送1条内部封装的消息。同样，在向exchange.another中发送1条消息之后，对应的队列queue1和queue3中会多一条消息。消费队列queue的时候，queue2、queue3和queue5中会多一条消息，消费队列queue.another的时候，queue2和queue3会多一条消息。“publish.#”匹配发送到所有交换器的消息，“deliver.#”匹配消费所有队列的消息，而“#”则包含了“publish.#”和“deliver.#”。

在Firehose开启状态下，当有客户端发送或者消费消息时，Firehose会自动封装相应的消息体，并添加详细的headers属性。对于前面的将“trace test payload.”这条消息发送到交换器exchange来说，Firehore会将其封装成如下的内容：

在消费queue时，会将这条消息封装成如下的内容：

headers中的exchange_name表示发送此条消息的交换器；routing_keys表示与exchange_name对应的路由键列表；properties表示消息本身的属性，比如delivery_mode=2表示消息需要持久化处理。

1.2 rabbitmq_tracing插件

rabbitmq_tracing插件相当于Firehose的GUI版本，它同样能跟踪RabbitMQ中消息的流入流出情况。rabbitmq_tracing插件同样会对流入流出的消息做封装，然后将封装后的消息日志存入相应的trace文件之中。

可以使用rabbitmq-plugins enable rabbitmq_tracing命令来启动rabbitmq_tracing插件。

# rabbitmq-plugins enable rabbitmq_tracing

对应的关闭插件的命令是：rabbitmq-plugins disable rabbitmq_tracing。
在Web管理界面 “Admin”右侧原本只有"Users"、"Virtual Hosts"以及”Policies“这个三Tab项，在添加rabbitmq_tracing插件之后，会多出”Tracing"这一项内容:

可以在此Tab项中添加响应的trace，如图所示：

图中相关参数解释如下：

• Name：就是为即将创建的trace任务取个名称。
• Format：表示输出的消息日志格式，有Text和JSON两种，Text格式的日志方便人类阅读，JSON格式方便程序解析，JSON格式的payload（消息体）默认会采用Base64进行编码。
• Max payload bytes：表示每条消息的最大限制，单位为B。比如设置了了此值为10，那么当有超过10B的消息经过RabbitMQ流转时，在记录到trace文件的时候会被截断。
• Pattern：表示用来匹配的模式。和Firehose的类似。如“#”匹配所有消息流入流出的情况，即当有客户端生产消息或者消费消息的时候，会把相应的消息日志都记录下来；“publish.#”匹配所有消息流入的情况；“deliver.#”匹配所有消息流出的情况。

在添加完trace之后，会根据匹配的规则将相应的消息日志输出到对应的trace文件之中，文件的默认路径为/var/tmp/rabbitmq-tracing。可以在页面中直接点击“Trace log files”下面的列表直接查看对应的日志文件。

负载均衡

负载均衡（Load balance）是一种计算机网络技术，用于在多个计算机（计算机集群）、网络连接、CPU、磁盘驱动器或其他资源中分配负载，以达到最佳资源使用、最大化吞吐率、最小响应时间以及避免过载的目的。使用带有负载均衡的多个服务器组件，取代单一的组件，可以通过冗余提高可靠性。

负载均衡通常分为软件负载均衡和硬件负载均衡两种，具体描述如下：

• 软件负载均衡：指在一个或者多个交互的网络系统中的多台放服务器上安装一个或多个相应的负载均衡软件来实现一种均衡负载技术。软件可以很方便的安装在服务器上，并且实现一定的均衡负载功能。软件负载均衡技术配置简单、操作也仿版，最重要的是成本很低。
• 硬件负载均衡：指在多台服务器间安装相应的负载均衡设备，也就是负载均衡器（如F5）来完成均衡负载技术，与软件负载均衡技术相比，能达到更好的负载均衡效果。由于硬件负载均衡技术需要额外的增加负载均衡器，成本比较高，所以适用于流量高的大型网站系统。

如何有效的对RabbitMQ集群使用软件负载均衡技术？目前主流的方式有：在客户端内部实现负载均衡，或者使用HAProxy、LVS等负载均衡软件来实现。

2.1 在客户端内部实现负载均衡

在客户端连接时简单的使用负载均衡算法来实现负载均衡。负载均衡算法有很多种，其中主流的有以下几种：

1. 轮询法
   将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

2. 随机法
   通过随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。

3. 源地址哈希法
   源地址哈希的思想是根据获取的客户端IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客户端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

4. 加权轮询法
   不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请求；而配置低、负载高的集群，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

5. 加权随机法
   与加权轮询法一样，加权随机法也根据后端机器的配置、系统的负载分配不同权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。

6. 最小连接数法
   最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有块有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负载合理地分流到每一台服务器。

2.2 使用HAProxy实现负载均衡

HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。根据官方数据，其最高极限支持10G的并发。HA Proxy实现了一种事件驱动、单一进程模型、此模型支持非常大的并发连接数。HAProxy支持从4层至7层的网络交换，即覆盖所有的TCP协议。就是说，Haproxy 甚至还支持 Mysql 的均衡负载。

HA Proxy的特点：

• HAProxy是支持虚拟主机的，，并能支持上万级别的连接;
• 能够补充Nginx的一些缺点比如Session的保持，cookie的引导等工作;
• 支持url检测后端的服务器出问题的检测会有很好的帮助;
• 它跟LVS一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度，在并发处理上也是优于Nginx的;
• HAProxy可以对mysql读进行负载均衡，对后端的MySQL节点进行检测和负载均衡，不过在后端的MySQL slaves数量超过10台时性能不如LVS，所以我向大家推荐LVS+Keepalived;
• 能够提供4层，7层代理。HAProxy支持两种主要的代理模式："tcp"也即4层（大多用于邮件服务器、内部协议通信服务器等），和7层（HTTP）。在4层模式 下，HAProxy仅在客户端和服务器之间转发双向流量，7层模式下，HAProxy会分析协议，并且能通过允许、拒绝、交换、增加、修改或者删除请求 (request)或者回应(response)里指定内容来控制协议，这种操作要基于特定规则；
• HAProxy的算法现在也越来越多了，具体有如下8种：
  • roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
  • static-rr，表示根据权重，建议关注；
  • leastconn，表示最少连接者先处理，建议关注；
  • source，表示根据请求源IP，这个跟Nginx的IP_hash机制类似，我们用其作为解决session问题的一种方法，建议关注；
  • ri，表示根据请求的URI；
  • rl_param，表示根据请求的URl参数’balance url_param’ requires an URL parameter name；
  • hdr(name)，表示根据HTTP请求头来锁定每一次HTTP请求；
  • rdp-cookie(name)，表示根据据cookie(name)来锁定并哈希每一次TCP请求。

安装HAProxy：

yum install haproxy

配置HAProxy：
HAProxy使用单一配置文件来定义所有属性，包括从前端IP到后端服务器。下面展示了用于3个RabbitMQ节点组成集群的负载均衡配置。这3个节点的IP地址分别为192.168.0.2、192.168.0.3、192.168.0.4，HAProxy运行在192.168.0.9这台机器上。

vim /etc/haproxy/haproxy.cfg
#全局配置
global#日志输出配置，所有日志都记录在本机，通过local0输出log 127.0.0.1 local0 info#最大连接数maxconn 4096#改变当前的工作目录chroot /opt/haproxy-1.7.8#以指定的UID运行haproxy进程uid 99#以指定的GID运行haproxy进程gid 99#以守护进程方式运行haproxy #debug #quietdaemon#debug#当前进程pid文件pidfile /opt/haproxy-1.7.8/haproxy.pid#默认配置
defaults#应用全局的日志配置log global#默认的模式mode{tcp|http|health}#tcp是4层，http是7层，health只返回OKmode tcp#日志类别tcplogoption tcplog#不记录健康检查日志信息option dontlognull#3次失败则认为服务不可用retries 3#每个进程可用的最大连接数maxconn 2000#连接超时timeout connect 5s#客户端超时timeout client 120s#服务端超时timeout server 120s#绑定配置,在HAProxy监听RabbitMQ 5671端口
listen rabbitmq_cluster 5671#配置TCP模式mode tcp#简单的轮询balance roundrobin#RabbitMQ集群节点配置#check inter 5000 是检测心跳频率，rise 2是2次正确认为服务器可用，fall 3是3次失败认为服务器不可用, weight 当前RabbitMQ服务的权重server rmq_node1 192.168.0.2:5672 check inter 5000 rise 2 fall 3 weight 1server rmq_node2 192.168.0.3:5672 check inter 5000 rise 2 fall 3 weight 1server rmq_node3 192.168.0.4:5672 check inter 5000 rise 2 fall 3 weight 1#haproxy监控页面地址
listen monitor :8100mode httpoption httplogstats enable#设置haproxy监控地址为http://localhost:8100/statsstats uri /statsstats refresh 5s
# 将RabbitMQ的管理界面也放在HAProxy
listen rabbitmq_admin  0.0.0.0:15672
server rmq_node1 192.168.0.2:15672
server rmq_node2 192.168.0.3:15672
server rmq_node3 192.168.0.4:15672

运行HAProxy：

[root@node1 haproxy]# haproxy -f haproxy.cfg

运行HAProxy之后可以在浏览器上输入http://192.168.0.9:8100/stats来加载相关的页面。

2.3 使用Keepalived+HAProxy实现高可靠负载均衡

如果前面配置的HAProxy主机192.168.0.9突然宕机或者网卡失效，那么虽然RabbitMQ集群没有任何故障，但是对于外界的客户端来说所有的连接都会被断开，结果将是灾难性的。确保负载均衡服务的可靠性同样显得十分的重要。这里就引入Keepalived工具，它能够通过自身健康检查、资源接管功能做高可用（双机热备），实现故障转移。

Keepalived采用VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议），以软件的形式实现服务器热备功能。通常情况下是将两台Linux服务器组成一个热备组（Master和Backup），同一时间热备组内只有一台主服务器Master提供服务，同时Master会虚拟出一个公用的虚拟IP地址，简称VIP。这个VIP只存在在Master上并对外提供服务。如果Keepalived检测到Master宕机或者服务故障，备份服务器Backup会自动接管VIP称为Master，Keepalived并将原Master从热备组中移除。当原Master恢复后，会自动加入到热备组，默认再抢占称为Master，起到故障转移的功能。

Keepalived工作在OSI模型中的第3层、第4层和第7层，具体为：

• 工作在第3层是指Keepalived会定期向热备组中的服务器发送一个ICMP数据包来判断某台服务器是否故障，如果故障则将这台服务器从热备组移除。
• 工作在第4层是指Keepalived以TCP端口的状态判断服务器是否故障，比如检测RabbitMQ的5672端口，如果故障则将这台服务器从热备组中移除。
• 工作在第7层是指Keepalived根据用户设定的策略（通常是一个自定义的检测脚本）判断服务器上的程序是否正常运行，如果故障将这台服务器从热备组移除。

安装过程比较简单，在此省略。Keepalived的相关启动关闭命令为：

service keepalived restart
service keepalived start
service keepalived stop
service keepalived status

配置Keepalived
在安装的时候已经创建了/etc/keepalived目录，并将keepalived.conf配置文件拷贝到此目录下，如此Keepalived便可以读取这个默认的配置文件了。如果要将Keepalived与前面的HAProxy服务结合起来需要更改/etc/keepalived/keepalived.conf这个配置文件，在此之前先来看看本次配置需要完成的详情及目标。

如下图所示，两台Keepalived服务器之间通过VRRP进行交互，对外部虚拟出一个VIP为192.168.0.10。

**Keepalived与HAProxy部署在同一台机器上，两个Keepalived服务实例匹配两个HAProxy服务实例，这样通过Keeaplived实现HAProxy的双机热备。**所以在上一小节的192.168.0.9的基础之上，还要再部署一台HAProxy服务，IP地址为192.168.0.8。整条调用链路为：客户端通过VIP建立通信链路；通信链路通过Keeaplived的Master节点路由到对应的HAProxy之上；HAProxy通过负载均衡算法将负载分发到集群中的各个节点之上。正常情况下客户端的连接通过图中左侧部分进行负载分发。当Keepalived的Master节点挂掉或者HAProxy挂掉无法恢复，那么Backup提升为Master，客户端的连接通过图中右侧部分进行负载分发。如果追求要更高的可靠性，可以加入多个Backup角色的Keepalived节点来实现一主多从的多机热备。当然这样会提升硬件资源的成本，该如何抉择需要更细致的考虑，一般情况下双机热备的配备已足够满足应用需求。

接下来要修改/etc/keepalived/keepalived.conf文件，在Keepalived的Master上配置详情如下：

#Keepalived配置文件
global_defs {router_id NodeA                 #路由ID, 主/备的ID不能相同
}#自定义监控脚本
vrrp_script chk_haproxy {script "/etc/keepalived/check_haproxy.sh"interval 5weight 2
}vrrp_instance VI_1 {state MASTER 			#Keepalived的角色。Master表示主服务器，从服务器设置为BACKUPinterface eth0          #指定监测网卡virtual_router_id 1priority 100            #优先级，BACKUP机器上的优先级要小于这个值advert_int 1            #设置主备之间的检查时间，单位为sauthentication {        #定义验证类型和密码auth_type PASSauth_pass root123}track_script {chk_haproxy}virtual_ipaddress {     #VIP地址，可以设置多个：192.168.0.10}
}

Backup中的配置大致和Master中的相同，不过需要修改global_defs{}的router_id，比如置为NodeB；其次要修改vrrp_instance VI_1{}中的state为BACKUP；最后要将priority设置为小于100的值。注意：Master和Backup中的virtual_router_id要保持一致。下面简要的展示下Backup的配置：

global_defs {router_id NodeB
}
vrrp_script chk_haproxy {...
}
vrrp_instance VI_1 {state BACKUP...priority 50...
}

为了防止HAProxy服务挂了，但是Keepalived却还在正常工作而没有切换到Backup上，所以这里需要编写一个脚本来检测HAProxy服务的状态。当HAProxy服务挂掉之后该脚本会自动重启HAProxy的服务，如果不成功则关闭Keepalived服务，如此便可以切换到Backup继续工作。这个脚本就对应了上面配置中vrrp_script chk_haproxy{}的script对应的值，/etc/keepalived/check_haproxy.sh的内容如代码清单所示：

#!/bin/bash
if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ];thenhaproxy -f /opt/haproxy-1.7.8/haproxy.cfg
fi
sleep 2
if [ $(ps -C haproxy --no-header | wc -l) -eq 0 ];thenservice keepalived stop
fi

如此配置好之后，使用service keepalived start命令启动192.168.0.8和192.168.0.9中的Keepalived服务即可。之后客户端的应用可以通过192.168.0.10这个IP地址来接通RabbitMQ服务。

查看Keepalived的运行情况
可以通过tail -f /var/log/messages -n 200命令查看相应的Keepalived日志输出。

查看VIP：
Master启动之后可以通过ip add show命令查看添加的VIP，即inet 192.168.0.10/32 scope global eth0，Backup节点是没有VIP的，示例如下：

[root@node1 ~]# ip add show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host loinet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP qlen 1000link/ether fa:16:3e:5e:7a:f7 brd ff:ff:ff:ff:ff:ffinet 192.168.0.8/18 brd xx.xx.255.255 scope global eth0inet 192.168.0.10/32 scope global eth0inet6 fe80::f816:3eff:fe5e:7af7/64 scope link valid_lft forever preferred_lft forever

在Master节点执行 service keepalived stop模拟异常关闭的情况，观察Master的日志发现，对应的Master上的VIP也会消失。Backup会提升为新的Master，新的Master节点上虚拟出了VIP，VIP不变。

2.4 使用Keepalived+LVS实现负载均衡

适合RabbitMQ使用的除了HAProxy之外还有LVS。LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分，在Linux2.6.32内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.6.32内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。

LVS是4层负载均衡，也就是说建立在OSI模型的传输层之上。LVS支持TCP/UDP的负载均衡，相对于其它高层负载均衡的解决方案，比如DNS域名轮流解析、应用层负载的调度、客户端的调度等，它是非常高效的。LVS自从1998年开始，发展到现在已经是一个比较成熟的技术项目了。可以利用LVS技术实现高可伸缩的、高可用的网络服务，例如WWW服务、Cache服务、DNS服务、FTP服务、MAIL服务、视频/音频点播服务等等，有许多比较著名网站和组织都在使用LVS架设的集群系统，例如：Linux的门户网站（www.linux.com）、向RealPlayer提供音频视频服务而闻名的Real公司（www.real.com）、全球最大的开源网站（sourceforge.net）等。

LVS主要由3个部分组成：

• 负载调度器（Load Balancer/ Director）：它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（VIP）上的。
• 服务器池（Server Pool/ RealServer）：是一组真正执行客户端请求的服务器，如RabbitMQ服务器。
• 共享存储（Shared Storage）：它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

目前，LVS的负载均衡方式也分为三种：

• VS/NAT：即Virtual Server via Network Address Translation的简称。VS/NAT是一种最简单的方式，所有的RealServer只需要将自己的网关指向Director即可。客户端可以是任意的操作系统，但此方式下，一个Director能够带动的RealServer比较有限。
• VS/TUN：即Virtual Server via IP Tunneling的简称。IP隧道（IP Tunneling）是将一个IP报文封装再另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能够被封装和转发到另一个IP地址。IP隧道技术亦可以称之为IP封装技术（IP encapsulation）。
• VS/DR：即Virtual Server via Direct Routing的简称。VS/DR方式是通过改写报文中的MAC地址部分来实现的。Director和RealServer必须在物理上有一个网卡通过不间断的局域网相连。RealServer上绑定的VIP配置在各自Non-ARP的网络设备上（如lo或tunl），Director的VIP地址对外可见，而RealServer的VIP对外是不可见的。RealServer的地址即可以是内部地址，也可以是真实地址。

对于LVS而言，配合Keepalived一起使用同样可以实现高可靠的负载均衡，对于2.3节来说，LVS可以完全的替代HAProxy而其他内容可以保持不变。LVS不需要额外的配置文件，直接集成在Keepalived的配置文件之中。修改/etc/keepalived/keepalived.conf文件内容如下：

#Keepalived配置文件（Master）
global_defs {router_id NodeA         #路由ID, 主备的ID不能相同
}
vrrp_instance VI_1 {state MASTER 			#Keepalived的角色。Master表示主服务器，从服务器设置为BACKUPinterface eth0          #指定监测网卡virtual_router_id 1priority 100            #优先级，BACKUP机器上的优先级要小于这个值advert_int 1            #设置主备之间的检查时间，单位为sauthentication {        #定义验证类型和密码auth_type PASSauth_pass root123}track_script {chk_haproxy}virtual_ipaddress {     #VIP地址，可以设置多个：192.168.0.10}
}virtual_server 192.168.0.10 5672 { 		#设置虚拟服务器delay_loop 6					#设置运行情况检查时间，单位是秒#设置负载调度算法，共有rr,wrr,lc,wlc,lblc,lblcr,dh,sh这8种。lb_algo wrr						#这里是加权轮询lb_kind DR						#设置LVS实现的负载均衡机制方式VS/DR#指定在一定的时间内来自同一IP的连接将会被转发到同一RealServer中。persistence_timeout 50			protocal TCP					#指定转发协议类型，有TCP和UDP两种#这个real_server即指LVS的三大部分之一的RealServer，这里特指RabbitMQ的服务real_server 192.168.0.2 5672 {	#配置服务节点weight 1				#配置权重TCP_CHECK {connect_timeout 3nb_get_retry 3delay_before_retry 3connect_port 5672}}real_server 192.168.0.3 5672 {weight 1TCP_CHECK {connect_timeout 3nb_get_retry 3delay_before_retry 3connect_port 5672}}real_server 192.168.0.4 5672 {weight 1TCP_CHECK {connect_timeout 3nb_get_retry 3delay_before_retry 3connect_port 5672}}
}
#为RabbitMQ的rabbitmq_management插件设置负载均衡
virtual_server 192.168.0.10 15672 {delay_loop 6lb_algo wrrlb_kind DRpersistence_timeout 50protocal TCPreal_server 192.168.0.2 15672 {weight 1TCP_CHECK {connect_timeout 3nb_get_retry 3delay_before_retry 3connect_port 15672}}real_server 192.168.0.3 15672 {weight 1TCP_CHECK {connect_timeout 3nb_get_retry 3delay_before_retry 3connect_port 15672}}real_server 192.168.0.4 15672 {weight 1TCP_CHECK {connect_timeout 3nb_get_retry 3delay_before_retry 3connect_port 15672}}
}

对于Backup的配置可以参考前一小节中的相应配置。在LVS和Keepalived环境里面，LVS主要的工作是提供调度算法，把客户端请求按照需求调度在RealServer中，Keepalived主要的工作是提供LVS控制器的一个冗余，并且对RealServer做健康检查，发现不健康的RealServer就把它从LVS集群中剔除，RealServer只负责提供服务。

通常，在LVS的VS/DR模式下需要在RealServer上配置VIP。原因在于当LVS把客户端的包转发给RealServer时，因为包的目的IP地址是VIP，那么如果RealServer收到这个包后发现包的目的地址不是自己系统的IP，那么就会认为这个包不是发给自己的，就会丢弃这个包，所以需要将这个IP地址绑定到网卡下。当发送应答包给客户端时，RealServer就会把包的源和目的地址调换，直接回复给客户端。下面为所有的RealServer的的lo:0网卡创建启动脚本（vim /opt/realserver.sh）绑定VIP地址，详细内容如下：

#!/bin/bash
VIP=192.168.0.10
/etc/rc.d/init.d/functionscase "$1" in
start)/sbin/ifconfig lo:0 $VIP netmask 255.255.255.255 broadcast $VIP/sbin/route add -host $VIP dev lo:0echo "1" >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho "2" >/proc/sys/net/ipv4/conf/lo/arp_announceecho "1" >/proc/sys/net/ipv4/conf/all/arp_ignoreecho "2" >/proc/sys/net/ipv4/conf/all/arp_announcesysctl -p >/dev/null 2>&1echo "RealServer Start Ok"
;;
stop)/sbin/ifconfig lo:0 down/sbin/route del -host $VIP dev lo:0echo "0" >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho "0" >/proc/sys/net/ipv4/conf/lo/arp_announceecho "0" >/proc/sys/net/ipv4/conf/all/arp_ignoreecho "0" >/proc/sys/net/ipv4/conf/all/arp_announce
;;
status)islothere=`/sbin/ifconfig lo:0 | grep $VIP | wc -l`isrothere=`netstat -rn | grep "lo:0"|grep $VIP | wc -l`if [ $islothere -eq 0 ]thenif [ $isrothere -eq 0 ]thenecho "LVS of RealServer Stopped."elseecho "LVS of RealServer Running."fielseecho "LVS of RealServer Running."fi
;;
*)echo "Usage:$0{start|stop}"exit 1
;;
esac

**注意：上面绑定VIP的掩码是255.255.255.255，说明广播地址使其自身，那么它就不会将ARP发送到实际的自己该属于的广播域了，这样防止与LVS上的VIP冲突进而导致IP地址冲突。**为/opt/realserver.sh文件添加可执行权限后，运行/opt/realserver.sh start命令之后可以通过ip add show命令查看lo:0网卡的状态，注意与Keepalived节点的网卡状态进行区分。

[root@node1 keepalived]# ip add show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00inet 127.0.0.1/8 scope host loinet 192.168.0.10/32 brd xx.xx.197.74 scope global lo:0inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP qlen 1000link/ether fa:16:3e:5e:7a:f7 brd ff:ff:ff:ff:ff:ffinet 192.168.0.2/18 brd xx.xx.255.255 scope global eth0inet6 fe80::f816:3eff:fe5e:7af7/64 scope link valid_lft forever preferred_lft forever

参考资料：

1. 《RabbitMQ实战指南》 朱忠华 著

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！