LVS的NAT和DR模型的工作原理 lvs drc

目录

• 一、LVS DR模式工作原理
• 二、iptable（防火墙）与LVS调度是否有冲突

• 举例
• linux访问控制

• 三、LVS本身存在的问题

• 某台RealServer down了，怎么办？

• 脚本方式自动检测、启动恢复

• LVS本身down了，怎么办？

• 四、通过keepalive解决rs健康检测与调度节点高可用问题

• 配置新节点与基本环境
• 修改keepalive配置文件
• 启动keepalived,客户端访问测试

一、LVS DR模式工作原理

图示：

• 客户端访问：cip -> vip
• 数据包到达DR的时候将目标地址的mac转换成了rs(real server）的mac地址：dmac -> rmac；因为DR的工作机制是在第二层，数据链路层，数据包的转发不经过ip地址，而是通过mac地址进行转发，因此要求DR调度器和real server必须要在同一个vlan(网段)中，因为如果不在一个vlan里的话，数据链路层是不通的（在数据链路层的时候是不能过路由的，无法进行ip转换，因此如果不在一个vlan的话，链路层无法走的通）
• 数据包到达rs后，此时通过解包能看到要访问的vip，因此rs上也必须要有要访问的vip，只有这样才能告诉客户端，哎，你找的就是我，否则这个数据包将会被丢弃
• 同时，DR和rs还在一个vlan中，同时二者都具有vip，为了能让客户端能够从调度器访问rs，因此要禁用掉rs的arp协议，不让rs对外广播自己的vip地址
• 总结来说，rs上的vip是为了告诉客户端，你访问的就是我；而保证DR和rs在一个vlan的目的是为了保证链路层的通畅



• 
  

二、iptable（防火墙）与LVS调度是否有冲突

• 我们思考这样一个问题：
  iptable防火墙与LVS调度是否有冲突？哪个优先级更高一点呢？

举例

我们在server11（DR调度节点上）也安装apache并且编写访问测试页，此时再次访问vip，lvs是否能将我们的请求调度到server12和server13上面而不调度server11呢?

• 我们发现调度正常，那么这个过程是怎么实现的呢？server11调度节点上的apache为什么不会被访问到呢？
• 我们可以通过查看iptable防火墙来理解这个过程
  
  
• 通过上面的实验演示我们能否下定结论：lvs调度优先级高于防火墙呢？显然还不能。因为目前防火墙中没有在INPUT链中设定相关策略，接下来我们在防火墙INPUT链中添加相关策略再进行访问测试，来验证我们的猜想
• 在server11调度节点上添加防火墙策略：所有访问172.25.0.100的请求都丢弃，这时候我们来在客户端访问172.25.0.100,观察是否能够正常完成调度，如果无法调度，则说明防火墙策略优先级高，否则反之

iptables -A INPUT  -d 172.25.0.100 -j DROP

• 由以上实验可知：防火墙优先级最高，防火墙数据包过滤防火墙，只要数据包进来就会受到它的控制，这时候都轮不到ipvs生效

Linux防火墙三表五链详解：.

linux访问控制

• iptables -->tcpwarp -->xinted(超级守护进程) -->service -->filesystem(rwx,SELINUX)

三、LVS本身存在的问题

某台RealServer down了，怎么办？

例如：server12down掉：
systemctl stop httpd

• 此时调度器依然正常工作，但是客户端将会受到错误连接提示，这就说明调度器并不关心后端real server的死活，即使已经down掉了也依然会对其进行调度



• 
  
• 解决办法：在ipvs中删除对server12的调度策略（对应的虚拟服务），这时候客户端在访问的时候就不会有错误信息提示了
  
• 再次将server12的http启动，并在调度节点添加虚拟服务，这时候客户端访问将会恢复

脚本方式自动检测、启动恢复

[root@server11 ~]# cat lvs.sh 
#!/bin/bash
VIP=172.25.0.100
PORT=80
RS=(172.25.0.12 172.25.0.13)
LOG=checklvs.log

addrs() {
	ipvsadm -a -t $VIP:$PORT -r $1:$PORT -g
	echo "add $1 to ipvs" >> $LOG
}

delrs() {
	ipvsadm -d -t $VIP:$PORT -r $1
        echo "del $1 to ipvs" >> $LOG
}

checkrs() {
	for i in ${RS[*]}
	do
		num=`curl  -I -s -o /dev/null -w %{http_code} http://$i`
		if [ $num -eq 200 -a $(ipvsadm -ln|grep $i|wc -l) -eq 0 ];then
			addrs $i
		elif [ $num -ne 200 -a $(ipvsadm -ln|grep $i|wc -l) -ne 0 ];then
			delrs $i
		fi
	done
}
while true
do
        checkrs
		sleep 5          %每隔5秒检测一次
done

• 也可以结合crontab创建定时任务，每隔一段时间调用一次checkrs函数

LVS本身down了，怎么办？

四、通过keepalive解决rs健康检测与调度节点高可用问题

配置新节点与基本环境

• 开启server14配合server11做lvs高可用（lvs冗余），server12和server13仍做rs
• 可以做server11和server14的免密连接，便于后续操作（非必须）
  ssh-keygen
  ssh-copy-id server14
• server11和server14上都安装keepalive集群套件，直接安装即可，系统自带
  yum install keepalived -y
• 清除server11上之前的ipvsadm策略：ipvsadm -C
• 删除原先server11上的vip
  这些都由集群套件来发配，是自动维护的，包括ipvs策略，不需要人为添加

修改keepalive配置文件

[root@server11 keepalived]# cat keepalived.conf 
! Configuration File for keepalived

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 51
   priority 100                %优先级，只要设置backup优先级比master优先级低就可以
   advert_int 1                %与backup之间每秒发一次心跳
   authentication {            %认证
       auth_type PASS
       auth_pass 1111
   }
   virtual_ipaddress {
       172.25.0.100
   }
}

virtual_server 172.25.0.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.0.12 80 {
       weight 1             %权重
       TCP_CHECK { 
              connect_timeout 3
              nb_get_retry 3
              delay_before_retry 3
       }
   }
   real_server 172.25.0.13 80 {
       weight 1
       TCP_CHECK {
             connect_timeout 3
           	 nb_get_retry 3
          	 delay_before_retry 3
       }
   }
}

• server14上keepalive的配置文件只需要更改节点类型为backup和优先级低于100即可
  

启动keepalived,客户端访问测试

server11上：
systemctl star keepalived.service

• 此时将server11的keepalive down掉之后，server14将接管成为master，并且获得vip和ipvs策略，仍然不影响客户端的正常访问，调度依然可以进行
• 此时如果server11再次启开keepalive,则server14又会称为backup，vip和ipvs策略都会迁移到server11上，因为server11优先级更高
• 随着调度节点的变化，arp也会随之变换，客户端在访问时，arp过滤出来的mac地址也会变化