lvs的keepalived原理

keepalived原理:

keepalived可以提供vrrp以及health-check功能，vrrp可以实现多个lvs之间的热备高可用功能，让vip在多个lvs之间浮动，也就是当一个主lvs宕机后，vip会漂移到另外一个备用的lvs上，保证了lvs的高可用性，health-check是lvs对RS的健康检查，可以通过指定的URL周期性请求信息来实现健康检查，或者是周期性的建立TCP连接来实现健康性检查，当发现某个RS宕机后，就将其从ipvsadm中对应VIP注册的RS列表中移除，这样lvs就不会再把客户端的请求转发给这个RS，也保证了RS的高可用性，当RS重新启动以后，会重新把RS加入到RS列表中，lvs会继续根据负载均衡算法把客户端请求转发给这个RS，所以总体来看就是通过vrrp实现lvs的高可用性，通过health-check实现RS的高可用性

 

lvs的高可用性——VRRP：

    1.协议简介：

VRRP协议是为消除在静态缺省路由环境下的缺省路由器单点故障引起的网络失效而设计的主备模式的协议，使得在发生故障而进行设备功能切换时可以不影响内外数据通信，不需要再修改内部网络的网络参数。VRRP协议需要具有IP地址备份，优先路由选择，减少不必要的路由器间通信等功能。

VRRP协议将两台或多台路由器设备虚拟成一个设备，对外提供虚拟路由器IP(一个或多个)，而在路由器组内部，如果实际拥有这个对外IP的路由器如果工作正常的话就是MASTER，MASTER实现针对虚拟路由器IP的各种网络功能，如ARP请求，ICMP，以及数据的转发等；其他设备不拥有该IP，状态是BACKUP，除了接收MASTER的VRRP状态通告信息外，不执行对外的网络功能。当主机失效时，BACKUP将接管原先MASTER的网络功能。

配置VRRP协议时需要配置每个路由器的虚拟路由器ID(VRID)和优先权值，使用VRID将路由器进行分组，具有相同VRID值的路由器为同一个组，VRID是一个0～255的正整数；同一组中的路由器通过使用优先权值来选举MASTER，优先权大者为MASTER，优先权也是一个0～255的正整数，VRID和优先权值都是可以直接通过配置文件来进行设置的。

VRRP协议使用多播数据来传输VRRP数据，VRRP运行时只有MASTER路由器定时发送VRRP通告信息，表示MASTER工作正常以及虚拟路由器IP(组)，BACKUP只接收VRRP数据，不发送数据，如果一定时间内没有接收到MASTER的通告信息，各BACKUP将宣告自己成为MASTER，发送通告信息，重新进行MASTER选举状态。

master选举规则：

1)如果对外的虚拟路由器IP就是路由器本身配置的IP地址的话，该路由器始终都是MASTER；

2)如果实际IP不是虚拟IP的话，将进行MASTER选举，各路由器都宣告自己是MASTER，发送VRRP通告信息，如果收到其他机器的发来的通告信息的优先级比自己高，将转回BACKUP状态；

3)如果优先级相等的话，将比较路由器的实际IP，IP值较大的优先权高；

2.keepalived中的VRRP

在keepalived中VRRP协议状态有三种，初始化，MASTER，BACKUP。

初始化：

lvs启动时，所有lvs都会向对方发送VRRP通告消息，这个消息中会携带上自己的优先级，如果收到的VRRP通告消息的优先级高于自己的优先级，那么这个lvs会进入BACKUP状态，这样只有优先级最高的那个lvs会成为MASTER，并发送广播ARP信息通告VIP地址对应的MAC地址为本lvs的MAC，设置通告信息定时器准备定时发送VRRP通告信息，BACKUP状态的lvs会设置定时器，定时检查是否收到MASTER的通告信息。

MASTER的lvs功能主要如下：

1.设置定时通告定时器，定时发送VRRP通告消息；

2.对外发送ARP广播，宣称VIP对应本lvs的MAC地址，并响应对VIP的ARP请求，从而让客户端的请求能转发到本lvs上；

3.转发客户端发来的对VIP的请求，也就是实现负载均衡的功能；

4.对RS做health-check的检查，如果检查失败则将其从对应的VIP的RS列表中移除，并继续做health-check检查，如果检查成功后，会重新加入到RS的列表中；

BACKUP的lvs功能主要如下：

1.设置MASTER超时定时器，如果一定时间内收不到MASTER的VRRP通告消息，则开启新一轮选举，向其他lvs发送VRRP消息，根据收到VRRP通告消息的优先级，决定自己是否要成为新的MASTER；

2.对RS做health-check的检查，如果检查失败则将其从对应的VIP的RS列表中移除，并继续做health-check检查，如果检查成功后，会重新加入到RS的列表中；

 

模拟实验：

    在GNS3中构建lvs keepalived的DR模式来看一下这个过程，首先构建如下的实验拓扑图

实验拓扑：

实验步骤：

    1.在各个虚拟机上配置ip地址，并注意要在两个RS上安装httpd服务，在两个lvs上安装ipvsadm和keepalived(yum install –y ipvsadm keepalived)

 

2.在两个RS上配置ARP抑制，并开启http服务

为了方便直接写个脚本

#!/bin/bash
VIP=10.0.0.6
case "$1" in
start)
           echo "start LVS of RealServer DR"
           /sbin/ifconfig lo:0 $VIP broadcast $VIP netmask 255.255.255.255 up
           /sbin/route add -host $VIP dev lo:0
           echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore
           echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce
           echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore
           echo "2" > /proc/sys/net/ipv4/conf/all/arp_announce
       ;;
stop)
           /sbin/ifconfig lo:0 down
           echo "close LVS of RealServer DR"
           echo "0" > /proc/sys/net/ipv4/conf/lo/arp_ignore
           echo "0" > /proc/sys/net/ipv4/conf/lo/arp_announce
           echo "0" > /proc/sys/net/ipv4/conf/all/arp_ignore
           echo "0" > /proc/sys/net/ipv4/conf/all/arp_announce
           ;;

*)
          echo "Usage: $0 {start|stop}"
          exit 1
esac
exit 0

为脚本添加可执行权限后，执行./lvs-web start即可快速设置arp抑制以及vip，然后执行systemctl start httpd开启http服务，http服务开启在80端口上

 

3.在两个lvs上配置keepalived

将lvs-1作为MASTER的lvs，首先在MASTER上修改/etc/keepalived/keepalived.conf内容如下

! Configuration File for keepalived
global_defs {
   router_id LVS #不一定要与主机名相同，也不必与BACKUP的名字一致
}
vrrp_instance VI_1 {
    state MASTER #一台为MASTER 一台为BACKUP
    interface ens33 #对外提供的网卡的名字
    virtual_router_id 51 #虚拟路由ID(0-255)，在一个VRRP实例中主备服务器ID必须一样
    priority 100 #MASTER要比BACKUP值要大
    advert_int 1 #通告时间间隔：单位秒，主备要一致
    authentication { #认证机制 MASTER和BACKUP要一致
        auth_type PASS# 默认PASS; 有两种：PASS或AH　
        auth_pass 1111# 默认1111; 可多位字符串，但仅前8位有效
    }
    virtual_ipaddress {
        10.0.0.6 #VIP的设置，可以设置多个
    }
}

virtual_server 10.0.0.6 80 { #这里边设置VIP的相关信息
    delay_loop 6 # 设置健康状态检查时间
    lb_algo rr # 调度算法，这里用了rr轮询
    lb_kind DR # DR模式
#    persistence_timeout 50 ## 持久连接超时时间，先注释掉，不然在单台上测试时，全部会被lvs调度到其中一台Real Server
    protocol TCP
    real_server 10.0.0.4 80 {# 第一个RS的ip地址和端口号
        weight 1
        TCP_CHECK {
            connect_port 80 #RS提供服务的端口
            connect_timeout 3 #设置health-check的超时时间
            nb_get_retry 3 #设置health-check的超时重传次数
            delay_before_retry 3#设置health-check的超时重传间隔
        }
    }

    real_server 10.0.0.5 80 {
        weight 1
        TCP_CHECK {
            connect_port 80
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
        }
    }
}

对于另一台lvs，只需要将state从MASTER改成BACKUP，将priority改小即可，然后在两台lvs上执行systemctl start keepalived即可

   

抓包分析：

在两台lvs上执行systemctl start keepalived后，来看一下VRRP的初始化阶段

以MASTER的lvs为例，开启keepalived后首先会发送IGMP报文，加入到224.0.0.18这个组中

同样的，BACKUP的lvs也会发送IGMP报文，加入到224.0.0.18这个组

之后MASTER的lvs会周期发送VRRP通告消息

可以看到，这个VRRP通告消息的目的ip是224.0.0.18，就是刚才的组播地址，源ip就是MASTER的lvs的ip地址，在内容中，会包含刚才配置的虚拟路由id，以及priority值等，BACKUP的lvs收到这个VRRP通告消息后，发现priority值比自己的大，因此会处于BACKUP状态，而此时的MASTER的lvs会产生ARP广播报文，宣称VIP10.0.0.6对应在自己的mac地址上

这个时候在两台lvs上输入ip add命令可以看到此时的vip是在MASTER上的

在BACKUP上是没有这个vip的

然后查看client的arp缓存表

可以看到VIP的mac地址对应的是master的mac地址，这样当客户端请求的时候是会把请求发送到master的lvs上的

继续在两台lvs上抓包，可以看到对RS的health-check的过程

可以看到master的lvs会周期性地和两个RS建立tcp连接并断开连接，来进行health检查，同时backup的lvs也会进行健康检查

这说明master和backup的lvs是会独立的对RS进行health-check的

然后在客户端上执行curl 10.0.0.6命令，是可以正常实现lvs的DR模式的负载均衡的，只不过这个时候的流量只经过MASTER的lvs

现在来看一下，如果关闭MASTER的keepalived的过程，首先会看到BACKUP的lvs会发出VRRP通告消息

然后MASTER会发送IGMP消息来宣称自己离开了224.0.0.22组

接下来BACKUP会发送ARP广播宣称vip对应在本机的mac地址上

然后查看BACKUP的IP地址

可以看到vip已经转移到BACKUP的lvs上了，然后再来看客户端的arp缓存表

这个时候的vip的mac地址已经是BACKUP的mac地址了，所以这个时候客户端的请求会转发到BACKUP的lvs上，负载均衡同样是可以正常工作的，当然如果再次开启MASTER的lvs，由于MASTER的优先级大，所以MASTER会重新获取vip并广播ARP请求，继续进行负载均衡的工作

再来验证一下keepalived对RS的health-check的效果，来关闭掉web2的http服务，可以看到lvs还是会对web2进行健康检查，周期性建立连接

只不过这个时候是没法正常建立连接的，用ipvsadm命令查看一下RS列表

发现此时web2已经从RS列表中移除，当客户端再次curl 10.0.0.6的时候请求是不会被转发到web2上的

当然因为lvs是会持续检查RS的健康状态的，所以当web2再次启动http服务后，它会被重新加如到ipvsadm的RS列表中

此时客户端再次进行curl请求，lvs还是会把请求分发到web1和web2上的