LVS实现负载均衡「建议收藏」

2022-09-15 10:42:47 浏览数 (1)

大家好,又见面了,我是你们的朋友全栈君。

一、LVS

1、LVS是什么?

LVS(Linux Virtual Server)即Linux虚拟服务器,是由章文嵩博士主导的开源负载均衡项目,目前LVS已经被集成到Linux内核模块中。终端互联网用户从外部访问公司的外部负载均衡服务器,终端用户的Web请求会发送给LVS调度器,调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器,比如,轮询算法可以将外部的请求平均分发给后端的所有服务器,终端用户访问LVS调度器虽然会被转发到后端真实的服务器,但如果真实服务器连接的是相同的存储,提供的服务也是相同的服务,最终用户不管是访问哪台真实服务器,得到的服务内容都是一样的,整个集群对用户而言都是透明的。

LVS基于内核网络层工作,有着超强的并发处理能力,单台LVS可以承受上万的并发连接。LVS是基于4层的负载均衡软件,因此LVS在所有负载均衡软件中性能最强,稳定性最高,消耗CPU和内存少。LVS是工作在4层,所以它可以对应用层的所有协议作负载均衡,包括http、DNS、ftp等。

2、LVS分层及组成

LVS负载均衡分为3层:

第一层:负载调度器(load balancer/Director),它是整个集群的总代理,它在有两个网卡,一个网卡面对访问网站的客户端,

一个网卡面对整个集群的内部。负责将客户端的请求发送到一组服务器上执行,而客户也认为服务是来自这台主的。举个生动

的例子,集群是个公司,负载调度器就是在外接揽生意,将接揽到的生意分发给后台的真正干活的真正的主机们。当然需要将活

按照一定的算法分发下去,让大家都公平的干活。

第二层:服务器池(server pool/ Realserver),是一组真正执行客户请求的服务器,可以当做WEB服务器。

第三层:共享存储(sharedstorage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。一个公司得有一个后台账目吧,这才能协调。不然客户把钱付给了A,而换B接待客户,因为没有相同的账目。B说客户没付钱,那这样就不是客户体验度的问题了。

3、LVS的工作流程

1、用户请求的数据包到达负载均衡器的内核空间,首先经过的是内核的PREROUTING链, 2、因为请求的数据包的目的地址一定是本机,然后将数据包送到INPUT链, 3、ipvs就工作在INPUT链上,ipvs利用ipvsadm定义的规则工作,ipvs对数据包进行检查,如果目的地址和端口不在规则里边,则将数据包送往用户空间, 4、如果目的地址和端口在规则里边,则将数据包的目的地址和端口修改为后端真实服务器,然后将修改后的数据包送往POSTROUTING链, 5、最后经过POSTROUTING链将数据包转发给后端服务器。

二、LVS工作模式

1、基于NAT的LVS模式负载均衡

NAT(Network Address Translation)即网络地址转换,其作用是通过数据报头的修改,使得位于企业内部的私有IP地址可以访问外网,以及外部用用户可以访问位于公司内部的私有IP主机。VS/NAT工作模式拓扑结构如图2所示,LVS负载调度器可以使用两块网卡配置不同的IP地址,eth0设置为私钥IP与内部网络通过交换设备相互连接,eth1设备为外网IP与外部网络联通。

第一步,用户通过互联网DNS服务器解析到公司负载均衡设备上面的外网地址,相对于真实服务器而言,LVS外网IP又称VIP(Virtual IP Address),用户通过访问VIP,即可连接后端的真实服务器(Real Server),而这一切对用户而言都是透明的,用户以为自己访问的就是真实服务器,但他并不知道自己访问的VIP仅仅是一个调度器,也不清楚后端的真实服务器到底在哪里、有多少真实服务器。

第二步,用户将请求发送至124.126.147.168,此时LVS将根据预设的算法选择后端的一台真实服务器(192.168.0.1~192.168.0.3),将数据请求包转发给真实服务器,并且在转发之前LVS会修改数据包中的目标地址以及目标端口,目标地址与目标端口将被修改为选出的真实服务器IP地址以及相应的端口。

第三步,真实的服务器将响应数据包返回给LVS调度器,调度器在得到响应的数据包后会将源地址和源端口修改为VIP及调度器相应的端口,修改完成后,由调度器将响应数据包发送回终端用户,另外,由于LVS调度器有一个连接Hash表,该表中会记录连接请求及转发信息,当同一个连接的下一个数据包发送给调度器时,从该Hash表中可以直接找到之前的连接记录,并根据记录信息选出相同的真实服务器及端口信息。

LVS-NAT模型的特性

RS应该使用私有地址,RS的网关必须指向DIP DIP和RIP必须在同一个网段内 请求和响应报文都需要经过Director Server,高负载场景中,Director Server易成为性能瓶颈 支持端口映射 DIP必须有公网IP

缺陷:对Director Server压力会比较大,请求和响应都需经过director server

2、基于TUN的LVS负载均衡

在LVS(NAT)模式的集群环境中,由于所有的数据请求及响应的数据包都需要经过LVS调度器转发,如果后端服务器的数量大于10台,则调度器就会成为整个集群环境的瓶颈。我们知道,数据请求包往往远小于响应数据包的大小。因为响应数据包中包含有客户需要的具体数据,所以LVS(TUN)的思路就是将请求与响应数据分离,让调度器仅处理数据请求,而让真实服务器响应数据包直接返回给客户端。VS/TUN工作模式拓扑结构如图所示。其中,IP隧道(IP tunning)是一种数据包封装技术,它可以将原始数据包封装并添加新的包头(内容包括新的源地址及端口、目标地址及端口),从而实现将一个目标为调度器的VIP地址的数据包封装,通过隧道转发给后端的真实服务器(Real Server),通过将客户端发往调度器的原始数据包封装,并在其基础上添加新的数据包头(修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口),LVS(TUN)模式要求真实服务器可以直接与外部网络连接,真实服务器在收到请求数据包后直接给客户端主机响应数据。

(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。 (b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链 (c) IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP (d) POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP (e) RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP (f) 响应报文最终送达至客户端

和DR模式差不多,但是比DR多了一个隧道技术以支持realserver不在同一个物理环境中。就是realserver一个在北京,一个工作在上海。

LVS-TUN的特点 1. RIP、VIP、DIP全是公网地址 2.RS的网关不会也不可能指向DIP 3.不支持端口映射

4.RS的系统必须支持隧道

3、基于DR的LVS负载均衡

在LVS(TUN)模式下,由于需要在LVS调度器与真实服务器之间创建隧道连接,这同样会增加服务器的负担。与LVS(TUN)类似,DR模式也叫直接路由模式,该模式中LVS依然仅承担数据的入站请求以及根据算法选出合理的真实服务器,最终由后端真实服务器负责将响应数据包发送返回给客户端。

与隧道模式不同的是,直接路由模式(DR模式)要求调度器与后端服务器必须在同一个局域网内,VIP地址需要在调度器与后端所有的服务器间共享,因为最终的真实服务器给客户端回应数据包时需要设置源IP为VIP地址,目标IP为客户端IP,这样客户端访问的是调度器的VIP地址,回应的源地址也依然是该VIP地址(真实服务器上的VIP),客户端是感觉不到后端服务器存在的。由于多台计算机都设置了同样一个VIP地址,所以在直接路由模式中要求调度器的VIP地址是对外可见的,客户端需要将请求数据包发送到调度器主机,而所有的真实服务器的VIP地址必须配置在Non-ARP的网络设备上,也就是该网络设备并不会向外广播自己的MAC及对应的IP地址,真实服务器的VIP对外界是不可见的,但真实服务器却可以接受目标地址VIP的网络请求,并在回应数据包时将源地址设置为该VIP地址。调度器根据算法在选出真实服务器后,在不修改数据报文的情况下,将数据帧的MAC地址修改为选出的真实服务器的MAC地址,通过交换机将该数据帧发给真实服务器。整个过程中,真实服务器的VIP不需要对外界可见。

LVS/DR原理和特点

重将请求报文的目标MAC地址设定为挑选出的RS的MAC地址 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP REROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链 IPVS比对数据包请求的服务是否为集群服务,若是,将请求报文中的源MAC地址修改为DIP的MAC地址,将目标MAC地址修改RIP的MAC地址,然后将数据包 发至POSTROUTING链。 此时的源IP和目的IP均未修改,仅修改了源MAC地址为DIP的MAC地址,目标MAC地址为RIP的MAC地址 由于DS和RS在同一个网络中,所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址,那么此时数据包将会发至Real Server。 RS发现请求报文的MAC地址是自己的MAC地址,就接收此报文。处理完成之后,将响应报文通过lo接口传送给eth0网卡然后向外发出。 此时的源IP地址为VIP,目标IP为CIP 响应报文最终送达至客户端

LVS-DR模型的特性

特点1:保证前端路由将目标地址为VIP报文统统发给Director Server,而不是RS RS可以使用私有地址;也可以是公网地址,如果使用公网地址,此时可以通过互联网对RIP进行直接访问 RS跟Director Server必须在同一个物理网络中 所有的请求报文经由Director Server,但响应报文必须不能进过Director Server 不支持地址转换,也不支持端口映射 RS的网关绝不允许指向DIP(因为我们不允许他经过director) RS上的lo接口配置VIP的IP地址

缺陷:RS和DS必须在同一机房中

4、fullNAT 模式

看完上图后发现 FULLNAT有一个问题是:RealServer无法获得用户IP;淘宝通过叫TOA的方式解决的, 主要原理是:将client address放到了TCP Option里面带给后端RealServer,RealServer收到后保存在socket 的结构体里并通过toa内核模块hook了getname函数,这样当用户调用getname获取远端地址时,返回的是保 存在socket的TCPOption的IP. 百度的BVS是通过叫ttm模块实现的,其实现方式跟toa基本一样,只是没有开源.

三、LVS负载均衡调度算法

根据前面的介绍,我们了解了LVS的三种工作模式,但不管实际环境中采用的是哪种模式,调度算法进行调度的策略与算法都是LVS的核心技术,LVS在内核中主要实现了一下十种调度算法。

1.轮询调度

轮询调度(Round Robin 简称’RR’)算法就是按依次循环的方式将请求调度到不同的服务器上,该算法最大的特点就是实现简单。轮询算法假设所有的服务器处理请求的能力都一样的,调度器会将所有的请求平均分配给每个真实服务器。

2.加权轮询调度

加权轮询(Weight Round Robin 简称’WRR’)算法主要是对轮询算法的一种优化与补充,LVS会考虑每台服务器的性能,并给每台服务器添加一个权值,如果服务器A的权值为1,服务器B的权值为2,则调度器调度到服务器B的请求会是服务器A的两倍。权值越高的服务器,处理的请求越多。

3.最小连接调度

最小连接调度(Least Connections 简称’LC’)算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态的调度算法,它通过服务器当前活跃的连接数来估计服务器的情况。调度器需要记录各个服务器已建立连接的数目,当一个请求被调度到某台服务器,其连接数加1;当连接中断或者超时,其连接数减1。

(集群系统的真实服务器具有相近的系统性能,采用最小连接调度算法可以比较好地均衡负载。)

4.加权最小连接调度

加权最少连接(Weight Least Connections 简称’WLC’)算法是最小连接调度的超集,各个服务器相应的权值表示其处理性能。服务器的缺省权值为1,系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

5.基于局部的最少连接

基于局部的最少连接调度(Locality-Based Least Connections 简称’LBLC’)算法是针对请求报文的目标IP地址的 负载均衡调度,目前主要用于Cache集群系统,因为在Cache集群客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求,算法的设计目标是在服务器的负载基本平衡情况下,将相同目标IP地址的请求调度到同一台服务器,来提高各台服务器的访问局部性和Cache命中率,从而提升整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则使用’最少连接’的原则选出一个可用的服务器,将请求发送到服务器。

6.带复制的基于局部性的最少连接

带复制的基于局部性的最少连接(Locality-Based Least Connections with Replication 简称’LBLCR’)算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统,它与LBLC算法不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射。按’最小连接’原则从该服务器组中选出一一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按’最小连接’原则从整个集群中选出一台服务器,将该服务器加入到这个服务器组中,将请求发送到该服务器。同时,当该服务器组有一段时间没有被修改,将最忙的服务器从服务器组中删除,以降低复制的程度。

7.目标地址散列调度

目标地址散列调度(Destination Hashing 简称’DH’)算法先根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且并未超载,将请求发送到该服务器,否则返回空。

8.源地址散列调度U

源地址散列调度(Source Hashing 简称’SH’)算法先根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且并未超载,将请求发送到该服务器,否则返回空。它采用的散列函数与目标地址散列调度算法的相同,它的算法流程与目标地址散列调度算法的基本相似。

9.最短的期望的延迟

最短的期望的延迟调度(Shortest Expected Delay 简称’SED’)算法基于WLC算法。举个例子吧,ABC三台服务器的权重分别为1、2、3 。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用SED算法后会进行一个运算

A:(1 1)/1=2 B:(1 2)/2=3/2 C:(1 3)/3=4/3 就把请求交给得出运算结果最小的服务器。

10.最少队列调度

最少队列调度(Never Queue 简称’NQ’)算法,无需队列。如果有realserver的连接数等于0就直接分配过去,不需要在进行SED运算。

四、LVS安装

LVS 由2部分程序组成,包括 ipvs 和 ipvsadm。 ipvs(ip virtual server):一段代码工作在内核空间,叫ipvs,是真正生效实现调度的代码。 ipvsadm:另外一段是工作在用户空间,叫ipvsadm,负责为ipvs内核框架编写规则,定义谁是集群服务,而谁是后端真实的服务器(Real Server)

LVS的编译安装参考本站文章:http://www.linuxe.cn/post-192.html,对于LVS这种功能性软件,在生产中用yum安装也是没有问题的。

代码语言:javascript复制
yum install ipvsadmin -y

LVS工具ipvsadm常用选项:

-l:列出所有负载均衡规则

-n:不进行dns解析

-C:清空所有规则

-A:增加一个虚拟服务器

-a:增加一个真实服务器

-S:保存规则

-A –add-server 新加一条虚拟服务器记录 -E –edit-server 编辑虚拟服务器记录 -D –delete-server 删除一条虚拟服务器记录 -C –clear   清空所有的虚拟服务器记录 -R –restore  恢复虚拟服务器规则,从-S保存的规则中恢复 -t –tcp-service 表示tcp服务,指虚拟服务器 -u –udp-service 表示udp服务,指虚拟服务器 -s –schedule 使用的调度算法   rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq  the default scheduler is wlc -p  代表持久连接 -f  代表防火墙的标记 -a 添加一条新的真实主机记录 -r 添加真实主机的地址 -m 指定LVS的工作模式为NAT -w 指定真实服务器的权值 -g 指定LVS的工作模式为DR(默认) -i 指定LVS的工作模式为TUN   -e 编辑一条虚拟服务器记录中的某条真实服务器 -d 删除一条虚拟服务器记录中的某条真实服务器 -L|-l 列出所有的虚拟服务器记录 -Z 清空当前的连接数(-l会显示虚拟服务器中连接数量)

代码语言:javascript复制
ipvsadm -Sn > /root/lvsrules.txt  #保存规则

cat /root/lvsrules.txt | ipvsadm -R  #恢复规则

ipvsadm -e -t 192.168.239.129:80 -r 192.168.239.130 -g -w 3

ipvsadm -d -t 192.168.239.129:80 -r 192.168.239.230

ipvsadm -a -t 192.168.239.129:80 -r 192.168.239.130 -m -w 1

ipvsadm -A -t 192.168.239.129:80 -s wlc

ipvsadm -E -t 192.168.239.129:80 -s rr

ipvsadm -S > /etc/sysconfig/ipvsadm

ipvsadm -R < /etc/sysconfig/ipvsadm

五、LVS DR模式搭建流程

模拟环境如下:

DIP:192.168.36.10

VIP:192.168.36.100

RIP:192.168.36.15、192.168.36.16

1、首先Director服务器外网卡上配置VIP,并且添加一个路由条目,指明接收到该VIP的请求后交给谁处理

代码语言:javascript复制
[dev@dasheng-dev ~]$ ifconfig eth0:1 192.168.36.100 broadcast 192.168.36.100 netmask 255.255.255.255 up  #添加VIP,广播地址和VIP一样,注意子网掩码不要写错
[dev@dasheng-dev ~]$ ping 192.168.36.100    #验证是否畅通
[dev@dasheng-dev ~]$ route add -host 192.168.36.100 dev eth0:1    #增加路由条目

2、使用ipvsadm工具配置Director和Real Server信息

代码语言:javascript复制
[root@Server01 ipvsadm-1.26]# ipvsadm -A -t 192.168.36.100:80 -s rr    #指定LVS调度器的地址以及算法,-t代表tcp协议             
[root@Server01 ipvsadm-1.26]# ipvsadm -a -t 192.168.36.100:80 -r 192.168.36.15:80 -g    #指定Real Server的地址以及工作模式,-g代表DR模式
[root@Server01 ipvsadm-1.26]# ipvsadm -a -t 192.168.36.100:80 -r 192.168.36.16:80 -g

3、使用ipvsadm -L 可以检查一下配置结果

4、在每台Real Server上绑定VIP到回环网卡上,并增加路由条目

代码语言:javascript复制
[dev@dasheng-dev ~]$ ifconfig lo:0 192.168.36.100 broadcast 192.168.36.100 netmask 255.255.255.255 up
[dev@dasheng-dev ~]$ route add -host 192.168.36.100 dev lo:0

5、在每台Real Server上做ARP抑制,其中2个参数为arp_ignore、arp_announce。

arp_ignore(接收到ARP请求后的响应级别):

0:本地有相应地址就相应,无论在哪个接口

1:仅对请求的目标地址是在本地接口上才作响应,这样后端服务器回环地址上的IP不会去响应广播

arp_announce(向外回应自己网络地址):

0:在任意网络接口上的本地地址都向外响应

1:尽量使用与本地接口匹配的地址向外响应

2:仅使用与本地接口匹配的网络向外响应,效果和arp_ignore类似也是避免响应

ARP抑制的配置方法(也可以配置在/etc/sysctl.conf中):

代码语言:javascript复制
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

6、访问VIP地址测试,可以看到分别访问到了两台不同的服务器,实际生产环境中两个服务器上文件应该是一致的,这里为了测试效果,所以放了不同的文件区分,如果无法正常打开页面,查看下iptables的规则是否有清空。

六、LVS NAT模式部署

使用LVS NAT模式需要保证集群中的服务器处于NAT网络中,下面是Centos部署NAT的方法

1、在后端每台服务器上将网关设置为LVS服务器地址

代码语言:javascript复制
route add default gw 192.168.36.10

2、在LVS服务器上开启网络转发

代码语言:javascript复制
echo net.ipv4.ip_forward =1 > /etc/sysctl.conf
sysctl -p

3、使用iptables转发

代码语言:javascript复制
iptables -t nat -A POSTROUTING -s 192.168.36.0/24 -o ens33 -j MASQUERADE

4、NAT模式下无需配置ARP抑制

代码语言:javascript复制
ifconfig ens33:1 192.168.36.100 netmask 255.255.255.0 up
ipvsadm -A -t 192.168.36.100 -s rr
ipvsadm -a -t 192.168.36.100 -r 192.168.36.110  -m
ipvsadm -a -t 192.168.36.100 -r 192.168.36.120  -m

七、LVS持久连接

HTTP协议是一种无状态的协议,即每次发送请求之后就会马上断开连接。假如这种无状态的协议运用在LVS负载均衡中,就会出现这样的情况,以购物网站为例子,用户浏览一商品并加入购物车,这时候请求被送往RS1,然后就断开连接,之后用户又浏览一商品并加入购物车,这时候请求又被送往RS2,这样用户再次访问购物车的时候,反馈给用户的信息是购物车里只有一件商品(假如请求被调度到RS1或RS2的其中一台),这样肯定是不行的。 解决这种问题的办法是可以利用源地址hash调度算法,当然还可以利用LVS的持久连接。

代码语言:javascript复制
# 基于上面例子中的NAT模型试验,为其增加持久连接
[root@LVS ~]# ipvsadm -E -t 192.168.0.105:80  -s wrr -p

现在规划这样一个场景,客户通过访问VIP发来http请求,需要将80端口的请求和8080端口的请求在一定时间范围内调度到后端同一台服务器上,就是端口联姻。完成这样的需求需要借助防火墙的标记持久连接。为了看到测试的效果,规划这样的环境拓扑

前端调度器的配置:

代码语言:javascript复制
# 在防火墙上将VIP的80端口请求和8080端口请求都标记为100
[root@LVS ~]# iptables -F
[root@LVS ~]# iptables -t mangle -A PREROUTING -d 192.168.0.105 -p tcp --dport 80 -j MARK --set-mark 100
[root@LVS ~]# iptables -t mangle -A PREROUTING -d 192.168.0.105 -p tcp --dport 8080 -j MARK --set-mark 100
# 利用标记添加ipvs规则(借助ipvsadm命令的-f选项)
[root@LVS ~]# ipvsadm -C
[root@LVS ~]# ipvsadm -A -f 100 -s wrr -p
[root@LVS ~]# ipvsadm -a -f 100 -r 192.168.239.129 -m -w 1
[root@LVS ~]# ipvsadm -a -f 100 -r 192.168.239.133 -m -w 2

后端RS的配置

代码语言:javascript复制
# 开通后端服务器的80端口和8080端口的服务,然后他们各自的访问内容分别如下
[root@Web1 ~]# curl http://localhost:80
This is web1 with 80
[root@Web1 ~]# curl http://localhost:8080
This is web1 with 8080
[root@Web2 ~]# curl http://localhost:80
This is web2 with 80
[root@Web2 ~]# curl http://localhost:8080
This is web2 with 8080
# 因为是NAT的工作模式,因此需要将后端RS的网关指向DIP
[root@Web1 ~]# route add default gw 192.168.239.130 
[root@Web2 ~]# route add default gw 192.168.239.130

八、LVS健康监测

LVS本身是无法监测后端服务器的状态的,即使后端某台服务器宕机,LVS还是会把请求调度到这台宕机的服务器上边,这样用户就会无法得到响应,这对用户的体验是极差的。因此为LVS加入了后端服务器健康状态检测机制,只有后端正常的服务器才会接受请求。 这里引入一个新的软件包ldirectord,这个软件包会为系统开启一个名叫ldirectord的守护进程,该进程专门用来管理ipvs的规则。该软件的rpm包下载地址如下: ldirectord-3.9.6(centos6)下载 下载完成之后完成安装即可。安装命令如下:

代码语言:javascript复制
[root@LVS ~]# yum -y localinstall ldirectord-3.9.6-0rc1.1.1.x86_64.rpm

ldirectord软件包的主配置文件为   /etc/ha.d/ldirectord.cf 其中软件包中会默认提供一个主配置文件的模板文件供参考,它是   /usr/share/doc/ldirectord-3.9.6/ldirectord.cf 以实验的LVS-DR模型的环境拓扑为例,这里使用ldirectord定义ipvs的规则,而不再使用ipvsadm命令。ldirectord的主配置文件的主要参数与其意义如下

代码语言:javascript复制
checktimeout=5      # 超时时间
checkinterval=1      # 两次检查的时间间隔
autoreload=yes      # 如果ldirectord的配置文件更新,是否主动重读配置文件
logfile="/var/log/ldirectord.log"    # 定义日志文件
quiescent=no         # 当后端某台服务器故障的时候,yes表示将节点的权值降为0,no表示将节点剔除ipvs的规则,当恢复正常后自动恢复值ipvs规则中
virtual=192.168.239.250:80   # 虚拟IP:port
    real=192.168.239.129:80 gate 1  # RS的IP:port <工作模式> [权值]
    real=192.168.239.133:80 gate 2
    service=http
    scheduler=wrr     # 调度算法
    #persistent=600
    protocol=tcp
# ldirectord实际上是根据下面参数来具体地监控RS是否正常
    checktype=negotiate  # ldirectord进程监控RS的方法
    checkport=80             # 监控的Port
    request="check.html" # 监控的文件
    receive="This web is OK" # 监控的文件内容

VIP的设置和后端服务器的ARP抑制的相关操作请参考实验的LVS-DR模型,这里不再重写。 在后端的服务器的web根目录下放入监控的文件

代码语言:javascript复制
[root@Web1 web]# pwd
/data/web
[root@Web1 web]# cat check.html 
This web is OK
[root@Web2 web]# pwd
/data/web
[root@Web2 web]# cat check.html
This web is OK

开启ldirectord进程,ipvsadm查看ipvs规则如下

现在将后端Web1的监控的页面内容改成其他内容,再次查看ipvs规则,结果如下图。

代码语言:javascript复制
[root@Web1 web]# pwd
/data/web
[root@Web1 web]# cat check.html 
This web is Down

———————————————— 版权声明:本文为CSDN博主「chenhuyang」的原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/weixin_40470303/article/details/80541639

https://blog.csdn.net/hehehechen/article/details/79893386

https://blog.51cto.com/13570193/2154294

发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/163776.html原文链接:https://javaforall.cn

0 人点赞