目录:
- LVS 介绍
- 一.进行lvs集群的搭建
- 二.后端(real server)提供服务
- real server禁用arp
- 禁用arp协议:
- 三、LVS集群工作模式
- DR直接路由模式
- NAT模式
- TUN 工作模式(隧道工作模式)
- 四.iptable(防火墙)与LVS调度是否有冲突
- 某台RealServer down了,怎么办?
- 五.Keepalive+LVS高可用
- 修改keepalive配置文件
LVS 介绍
LVS是Linux Virtual Server的简称,也就是Linux虚拟服务器,该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案,终端互联网用户从外部访问公司的外部负载均衡服务器,终端用户的Web请求会发送给LVS调度器,调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器
将外部的请求平均分发给后端的所有服务器,终端用户访问LVS调度器虽然会被转发到后端真实的服务器,但如果真实服务器连接的是相同的存储,提供的服务也是相同的服务,最终用户不管是访问哪台真实服务器,得到的服务内容都是一样的!!
LVS工作模式分为NAT模式、TUN模式、以及DR模式。
一.进行lvs集群的搭建
环境搭建:client --> DR -->RS --client
安装的是管理工具,第一种叫ipvsadm,第二种叫keepalive
ipvsadm是通过命令行管理,而keepalive读取配置文件管理
server1:
yum install -y ipvsadm
新建一个虚拟服务,它需要有一个vip(虚拟ip),这个ip在部署完高可用后可以在不同节点之间浮动
ip addr add 172.25.1.100/24 dev eth0
然后查看ip
ip addr
添加虚拟服务以及将其关联到真实服务器上去
ipvsadm -A -t 172.25.1.100:80 -s rr # 添加虚拟服务
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.2:80 -g #将虚拟服务关联到真实服务上
ipvsadm -a -t 172.25.1.100:80 -r 172.25.1.3:80 -g
#LVS默认无80端口,需另外添加新的虚拟IP记录
添加之后,查看配置结果
可以看到server2,server3都同步了
ipvsadm -ln
二.后端(real server)提供服务
在server2上:
yum install -y httpd
systemctl enable --now httpd
echo server2>/var/www/html/index.html
server3上:
yum install -y httpd
systemctl enable --now httpd
echo server3>/var/www/html/index.html
real server禁用arp
##在DR(直连)模式中,客户端想要通过vip访问到真实后端的资源,要求调度节点和后端都要有相同的vip,但是同时会有这样一个问题产生:
DR模式下,调度节点和real server真实服务器在一个vlan(同一个网段)里面,并且拥有相同的vip,那么其它主机访问vip的时候如何能够根据实现定义好的调度算法正确的在两个real server之间完成调度呢?
我们可以禁用后端的arp(地址广播协议),让主机不要对外广播自己的vip地址,就相当于不要告诉别人我有这个ip,链路层的传输只需要mac地址而不需要通过ip
我们在真机curl一下添加的vip地址
curl 172.25.1.100
访问不到资源但是在server1上可以看到调度次数:
ipvsadm -ln查看调度次数:
因为没有在server2,3上添加vip
给两台服务器上的网卡绑定VIP地址
[root@server2 ~]# ip addr add 172.25.1.100/32 dev eth0
[root@server3 ~]# ip addr add 172.25.1.100/32 dev eth0
再次在真机上curl 172.25.1.100
发现可以访问到资源,可以轮询调度
但是,现在的负载均衡还是有问题,因为此时能够负载均衡只是因为客户端随机访问到了server1上的vip所以才能够正常调度,正常情况下,server1、2、3上都有vip,因此客户端访问vip的时候可能会随机访问到这三个节点的任何一个节点上,那么我们该如何保证客户端在访问vip的时候只能访问到调度节点server1呢?这就需要禁用server12和server13节点的arp协议,让它们不对外广播vip地址
举个例子:
我们在真机上先抓出ip地址
arp -an | grep 100
然后删掉vip
再次抓出ip为空
arp -d 172.25.1.100
arp -an | grep 100
这时候重新ping 172.25.1.100就可以使得vip重新过来
ping 172.25.1.100
arp -an | grep 100
但是仔细观察两次抓出的ip后面at后的数据不一样!!!
因为第二次连接的是server3的vip!!!
我们重新curl 172.25.1.100观察
全部都是server3!!!
我们再删掉vip,重新ping,抓出ip地址:
我们发现at后的参数和最之前的一样了!
再一次curl 172.25.1.100,发现又可以2,3之前负载均衡
但是这也是不对的,我们需要实现的是一直在server2,server3上负载均衡!
禁用arp协议:
使用arptables_jf工具(相当于arp防火墙)禁用
arptable只针对arp协议生效,只控制arp,不影响其它协议
在server2,server3上都要执行:
yum install arptables.x86_64 -y
[root@server2 html]# arptables -A INPUT -d 172.25.1.100 -j DROP
[root@server2 html]# arptables -A OUTPUT -s 172.25.1.100 -j mangle --mangle-ip-s 172.25.1.2
systemctl restart arptables.service
[root@server3 html]# arptables -A INPUT -d 172.25.1.100 -j DROP
[root@server3 html]# arptables -A OUTPUT -s 172.25.1.100 -j mangle --mangle-ip-s 172.25.1.3
systemctl restart arptables.service
查看策略
和前面一样,删掉ip节点重新ping一下,发现查到的ip地址的数据没有变化了,都是server1!!
arp -an| grep 100
arp -d 172.25.1.100
ping 172.25.1.100
arp -an| grep 100
可以看到at后面的信息都是79:15:a1
这时候再进行负载均衡测试发现ok了!!
而且我们可以看到在server1上查看ip addr显示的 eth0的网络信息也是79:15:a1!!!
三、LVS集群工作模式
DR直接路由模式
client -> DR -> RS ->client
客户端访问DR,DR访问RS,RS直接把数据包定向到了客户端
在LVS的三种工作模式中,DR模式的工作效率最高,它工作在第二层数据链路层,直接通过mac地址转发数据,它仅仅承担转发工作,直接把数据往后甩,最后返回给客户端,性能非常高。
三种工作模式中NAT性能最差,因为需要进行地址转换,数据流一进一出原路径返回需要经过调度器,隧道模式和DR模式性能最接近,隧道模式需要支持广域网、多个网段,而DR直连模式要求必须要在一个vlan里面。
NAT模式
client --> vs --> rs --> vs --> client
通过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器,真实服务器的响应报文处理之后,返回时必须通过调度器,经过调度器时报文的源地址被重写,再返回给客户,完成整个副在调度过程。
TUN 工作模式(隧道工作模式)
客户请求包封装在一个IP tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后解开IP tunnel后,进行响应处理。并且直接把包通过自己的外网地址发送给客户不用经过LB服务器
缺点在于:
1、RS配置复杂(IPIP模块)
2、RS上绑定VIP,风险比较大
四.iptable(防火墙)与LVS调度是否有冲突
我们需要考虑一个问题:iptable防火墙与LVS调度是否有冲突?哪个优先级更高一点呢?
那么我们在server1也也装上apache服务编写发布页,再次访问vip,lvs是否能将我们的请求调度到server2和server3上面而不调度server1呢?
在server1上:
yum install -y httpd
systemctl start httpd
echo server1 > /var/www/html/index.html
curl localhost
然后再次到真机进行负载均衡测试:
发现还是OK的,并没有调度server1
我们发现调度正常,那么这个过程是怎么实现的呢?server1调度节点上的apache为什么不会被访问到呢?查看iptables -L
发现请求进来时,先到input链中,但是由于server1上有lvs策略,所以把需求转发到了rs的 80端口上
接下来我们在防火墙INPUT链中添加相关策略再进行访问测试,
在server1调度节点上添加防火墙策略:所有访问172.25.1.100的请求都丢弃,这时候我们来在客户端访问172.25.1.100,观察是否能够正常完成调度,如果无法调度,则说明防火墙策略优先级高,否则反之在server1上
iptables -A INPUT -d 172.25.1.100 -j DROP
然后iptables -nL查看策略已经删掉
再次负载均衡查看发现无响应
由以上实验可知:防火墙优先级最高,防火墙数据包过滤防火墙,只要数据包进来就会受到它的控制,这时候都轮不到ipvs生效!!
某台RealServer down了,怎么办?
server2或者server3上的httpd停掉!
systemctl stop httpd,然后进行负载均衡测试:
此时调度器依然正常工作,但是客户端将会有错误连接提示,这就说明调度器并不关心后端real server的死活,即使已经down掉了也依然会对其进行调度!!
我们这时候,只需要删掉server2,或者server3上的 调度策略,这时候客户端在访问的时候就不会有错误信息提示了
ipvsadm -d -t 172.25.1.100:80 -r 172.25.1.2
ipvsadm -ln
发现server2已经不再策略里面了!!
再一次在客户端负载均衡测试:
不会报错!
五.Keepalive+LVS高可用
Keepalived 一方面具有配置管理LVS的功能,同时还具有对LVS下面节点进行健康检查的功能,另一方面也可实现系统网络服务的高可用功能。
开启一台虚拟机server4准备测试lvs的高可用!!
[root@server1 ~]# yum install keepalived -y
[root@server4 ~]# yum install ipvsadm keepalived -y
清除之前server1上的ipvsadm策略:
ipvsadm -C
删除server1上的vip
ip addr del 172.25.1.100/24 dev eth0
ipvsadm -ln查看策是空的
修改keepalive配置文件
cd /etc/keepalived
vim keepalived.conf
global_defs {
notification_email {
root@localhost %邮件通知,如果主机联网的话可以写外部邮箱,用于通知集群状态,写localhost本机的话需要安装mailx
}
notification_email_from keepalived@localhost %邮件来源
smtp_server 127.0.0.1 %必须是本机
smtp_connect_timeout 30
router_id LVS_DEVEL
vrrp_skip_check_adv_addr
#vrrp_strict #禁掉这个选项
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_instance VI_1 { %高可用部分,vrrp协议巧妙利用了路由器硬件的冗余
state MASTER %主调度节点
interface eth0
virtual_router_id 1 #这个写自己的数字
priority 100 %优先级,只要设置backup优先级比master优先级低就可以
advert_int 1 %与backup之间每秒发一次心跳
authentication { %认证
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
172.25.1.100 # 写vip
}
}
virtual_server 172.25.1.100 80 { %这部分相当于将lvs的策略以文本的方式写出来了,集群将会根据这部分内容来制定lvs策略
delay_loop 6 %每隔6秒钟对后端做一次健康检查
lb_algo rr %定义调度算法
lb_kind DR %lvs模式(注意大小写)
#persistence_timeout 50 %50秒内同一个客户端发过来的请求将会交给同一个后端处理,为了看到效果,建议注释掉
protocol TCP
real_server 172.25.1.2 80 {
weight 1 %权重
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
real_server 172.25.1.3 80 {
weight 1
TCP_CHECK {
connect_timeout 3
nb_get_retry 3
delay_before_retry 3
}
}
}
修改之后重启服务:
systemctl start keepalived
把2,3上的httpd服务都启动一下:
在真机负载均衡恢复:
这个时候如果停掉server3的httpd服务:
在server1上查看ipvsadm -ln
会提示有邮件
yum install -y mailx
下在完成之后
mail查看邮件
可以看到server3的服务停掉的消息
这个时候把server2也停掉httpd
此时打开前面下载好的server4
把server1上的 /etc/keepalived/keepalived.conf 复制到server4上
scp /etc/keepalived/keepalived.conf server4:/etc/keepalived/修改一下:修改优先级为50和state为backup
还有
然后启动服务“:
启动server2,server3的httpd服务
systemctl start keepalived.service
ipvsadm -ln
ip addr
发现vip也出现了!
查看server1的日志: cat /var/log/messages
查看server4的日志:
客户端访问可以实现负载均衡
此时将server1的keepalive down掉之后,server4将接管成为master,并且获得vip和ipvs策略,仍然不影响客户端的正常访问,调度依然可以进行
此时如果server1再次启开keepalive,则server4又会称为backup,vip和ipvs策略都会迁移到server11上,因为server11优先级更高
我们停掉server1的keepalive
systemctl stop keepalived
查看server4的日志:发现它变为了master
vip也飘过来了
重新启动server1的keepalived服务:
我们可以看到server1上的日志,显示server1又接管了master
而且在server1down之后,客户端的负载均衡是好的,重新启动server1之后
客户端的负载均衡也是好的!不影响客户的使用!