LVS负载均衡-集群搭建,集群工作模式,keepalive结合lvs的高可用

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之后
客户端的负载均衡也是好的!不影响客户的使用!
在这里插入图片描述

  • 2
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

dudududu--

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值