一、LVS简介
(1)、lvs流程
LVS(Linux Virtual Server)即Linux虚拟服务器,是一个虚拟的服务器集群系统,可以在unix/linux平台下实现负载均衡集群功能。LVS是一种集群(Cluster)技术,采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改客户端和服务器端的程序。
根据LVS工作模式的不同,真实服务器会选择不同的方式将用户需要的数据发送到终端用户,LVS工作模式分为NAT模式(地址转换)、TUN模式(隧道)、以及DR模式
(2)、DR工作模式
客户端向目标vip发出请求,lvs接收 ,LVS根据负载均衡算法选择一台活跃的的节点,将此节点的ip所在网卡的mac地址作为目标mac地址,发送到局域网里。
DR
DR模式小结:
1、通过在调度器DB上修改数据包的目的MAC地址实现转发。注意源地址仍然是CIP(客户端),目的地址仍然是VIP地址。
2、请求的报文经过调度器,而RS响应处理后的报文无需经过调度器DB,因此并发访问量大时使用效率很高(和NAT模式比)
3、因为DR模式是通过MAC地址改写机制实现转发,因此所有RS节点和调度器DB只能在一个局域网里面
4、RS主机需要绑定VIP地址在LO接口上,并且需要配置ARP抑制。
5、RS节点的默认网关不需要配置成DB,而是直接配置为上级路由的网关,能让RS直接出网就可以。
6、由于DR模式的调度器仅做MAC地址的改写,所以调度器DB就不能改写目标端口,那么RS服务器就得使用和VIP相同的端口提供服务。
(3)、keepalived
LVS的DR能够实现负载均衡,但是没有健康检测功能,即检测策略对应的后端服务是否正常,因此我们需要安装keepalived。其采用了vrrp虚拟路由冗余协议,keepalived利用这一协议实现了高可用。这样就可以实现多个调度器,多个后台服务器。
二、实验环境
本机打算用server1,server2做调度器,server3,server4做后台服务器
server1:172.25.42.1
server2:172.25.42.2
server3:172.25.42.3
server3:172.25.42.4
二、安装DR实现负载均衡
(1)、介绍
1、优缺点
通过直接路由实现虚拟服务器。DR模式是通过改写请求报文的目标MAC地址,将请求发给真实服务器的,而真实服务器响应后的处理结果直接返回给客户端用户。DR模式可以极大的提高集群系统的伸缩性,而且DR模式没有IP隧道的开销,对集群中的真实服务器也没有必要必须支持IP隧道协议的要求。但是要求调度器与真实服务器都有一块网卡连接到同一物理网段上,必须在同一个局域网环境。
2、原理
LVS通过控制IP来实现负载均衡。ipvsadm
是其具体的实现模块。
安装在调度器上面,在调度器上虚拟一个对外访问的IP(VIP)。用户访问VIP,到达调度器,调度器根据一定的规则选择一个真实服务器,处理完成后然后返回给客户端数据。
(2)、均衡调度操作
打算先将server1作为调度器,server2,server3作为服务器,基于4层即传输层进行调度
server1调度器上进行如下从操作
1、下载核心组件
yum install ipvsadm -y
2、添加虚拟vip地址
在server1上添加虚拟一个对外访问的IP:172.25.33.100(vip),即提供虚拟服务的ip地址,也可以直接用原有IP,但最好独立出来。
ip addr add 172.25.42.100/24 dev eth0 注意这只是临时的,重启后就没有了
3、书写规则
ipvsadm
-A
添加规则;
-a
添加
-t tcp
指定tcp协议
-s
调度;rr
轮叫
-r
real server即真实主机
-g
直连即DR模式
[root@server1 ~] touch /etc/sysconfig/ipvsadm
[root@server1 ~] systemctl start ipvsadm.service
[root@server1 ~] ipvsadm -A -t 172.25.42.100:80 -s rr 设定虚拟vip,设定均衡负载轮调方式为rr
[root@server1 ~] ipvsadm -a -t 172.25.42.100:80 -r 172.25.42.2:80 -g 将server2加入后端服务
[root@server1 ~] ipvsadm -a -t 172.25.42.100:80 -r 172.25.42.3:80 -g 将server3加入后端服务
ipvsadm -ln
:查看当前连接情况(-ln不用解析),
Forward
:转发方式,当前是路由转发;
Weight
:权重;
ActiveConn
:当前活跃的连接数;
lnActConn
:当前不活跃的连接数
目前已经将server2,server3加入了后端服务
4、server2和server3安装httpd服务,并开启
server2
[root@server2 ~] yum install httpd -y
[root@server2 ~] echo server2 > /var/www/html/index.html
[root@server2 ~] systemctl start httpd
server3
[root@server3 ~] yum install httpd -y
[root@server3 ~] echo server3 > /var/www/html/index.html
[root@server3 ~] systemctl start httpd
5、此时效果
利用客户端直接curl访问server2,server3可以访问到,但是访问虚拟vip不能访问到。
在DB调度器,可以看到均衡调度
6、server2,server3服务器添加虚拟vip
访问不到的原因是因为LVS-DR集群类型要求,当用户向vip发起请求时,调度器和真实服务器上必须都要有vip,因此需要给server2和server3添加虚拟IP。
给server2,server3添加虚拟vip
ip addr add 172.25.42.100/32 dev eth0 这里的子网掩码虽然是32位的,因为他只和这个虚拟ip沟通,所以无所谓
6、再次访问
查看到轮调的效果。
(3)、解决arp问题
虽然目前实现了轮调,但是会出现一个棘手的问题。如下
真机里面将vip(虚拟ip)和mac地址进行了缓存,即一旦访问172.25.42.100,访问到的必定是server1(DB调度器)
arp -an 可以查看到真机对应ip和mac地址的缓存
server1的mac地址
如果一旦真机清除了mac缓存,再次访问虚拟ip时,则到时候访问到的不一定是server1(DB调度器)
删除缓存后对应的虚拟ip不再是server1的mac,访问到的是server3的ip。因为访问虚拟ip时,server3反应更快,就连接到了server3。
对于这种问题,我们采用如下方法进行解决
1、为了解决这一问题,需要给server2和server3安装ARP防火墙arptables(用于管理内核中的ARP包过滤规则表)
yum install arptables -y
2、设定APR配置规则,DR模式要求服务器节点应该禁掉设备的APR响应
arptable_filter 只有一个表 filter ,不指定 -t 表名时默认就是 filter 表。
filter表有三个链,一个是INPUT
,表示外面发进来的ARP包;另外一个是OUTPUT
,表示本机发出的ARP包;第三个是FORWARD
,转发ARP包。
-A
:向规则链中追加规则;
-d
:指定要匹配ARP包的目的IP地址;
-j
:指定满足添加的规则时执行的动作;
-s
:指定要匹配ARP包的源ip地址;
-g
:直连
-r
:真实服务器地址
设置INPUT链条:当数据包的目的地址时100时就丢弃该数据包,
设置OUTPUT链条:当从本机发送出的数据包IP是虚拟ip地址的时候,mangle转换数据包源地址,伪装源地址IP为172.25.0.2/3。
server3
[root@server3 ~] arptables -A INPUT -d 172.25.42.100 -j DROP
[root@server3 ~] arptables -A OUTPUT -s 172.25.42.100 -j mangle --mangle-ip-s 172.25.42.3
[root@server3 ~] arptables-save > /etc/sysconfig/arptables
[root@server3 ~] systemctl restart arptables.service
[root@server3 ~] arptables -nL
可以看到保存策略后,哪怕重启也会生效
server2
[root@server2 ~] arptables -A INPUT -d 172.25.42.100 -j DROP
[root@server2 ~] arptables -A OUTPUT -s 172.25.42.100 -j mangle --mangle-ip-s 172.25.42.2
[root@server2 ~] arptables-save > /etc/sysconfig/arptables
[root@server2 ~] systemctl restart arptables.service
[root@server2 ~] arptables -nL
可以看到保存策略后,哪怕重启也会生效
3、真机清除arp缓存再次访问
此时没有了arp地址缓存,但是也能成功的轮调系统
三、安装keepalive实现集群管理
(1)、介绍
keepalive可以实现对每台服务器或者是调度器的健康检测,加入集群管理。当某一台服务器或者是调度器挂了后,另外一台能够马上接管工作。
(2)、服务器挂掉问题模拟
server2停止http服务
虽然还是均衡调度,但是在真实主机访问时发现访问server3能够成功,server2失败
(3)、安装keepalive
在调度器安装keepalive实现对后台服务器的健康检测
1、安装软件
安装keepalived,postfix, mailx。postfix, mailx时邮件的发送和接受软件,可以接受健康检测的通知
[root@server1 ~] yum install keepalived
[root@server1 ~] yum install postfix mailx
2、修改配置文件
修改keepalived的主配置文件
(vrrp虚拟路由冗余协议,keepalived利用这一协议实现了高可用)
[root@server1 ~] vim /etc/keepalived/keepalived.conf
设置邮件收发
主虚拟路由MASTER:向所有备用虚拟路由BACKUP发送“心跳包”,备用虚拟路由只负责接收,当备用虚拟路由接收不到时,priority优先级最高的备用虚拟路由代替MASTER提供虚拟服务,数字越高,优先级越高,所以MASTER优先级数字一定要最大。
虚拟路由id:确认哪些虚拟路由是同一个LVS集群的
后面会加入另一台调度器,优先级比这台调度器低,给的优先级为50。虚拟id同样为51,为同一个集群
虚拟服务语句块:
delay_loop
:每s/次健康检测;
lb_algo
:调度算法;
persistence_timeout
:持久连接,即在多长时间内DR会将所有连接请求持续调度给一个后端;
3、删除原先的手动设置,启用keepalive
清除原来的虚拟ip,发现启动keepalive后会自动启用虚拟vip
ipvsadm -ln发现,根据配置文件,自动建立了规则
4、模拟服务器停机实验
挂掉server2
发现真机已经全部访问server3
发现调度器这也检测到了server2挂掉,现在只调度server3
在日志里面可以看到再常识重新连接一次无效后,将sever3断开连接
邮件也会通知server2挂掉了
启动server2后
主机恢复正常访问
轮调系统也恢复正常
(4)、调度器挂了怎么办
添加另一台调度器,进行主双调度器和副调度器服务
1、启用另一台服务器server4作为调度器
[root@server4 ~] yum install keepalived -y
2、将server1(调度器)的keepalive的配置文件发送给server4
[root@server1 ~] scp /etc/keepalived/keepalived.conf root@172.25.42.4:/etc/keepalived/
3、更改server4的backup和优先级
4、server4启动下载ipvsadm,启动keepalive
[root@server4 ~] yum install ipvsadm.x86_64 -y
[root@server4 ~] systemctl start keepalived.service
[root@server4 ~] ipvsadm -ln
可以看到server4已经成功就变成了DB(调度器)
且为备用的DB调度器
5、模拟挂掉DB主服务器
关闭server1的keepalive服务
server4立马变成了主DB调度器
真机访问仍然正常,且对应的mac地址改为了server4的mac地址
当server1再次启动后,server1的优先级高,再次变为了主DB调度器
四、LVS的10个调度算法简介
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.源地址散列调度(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运算。