VRRP协议与keepalived原理及功能实例演示

VRRP是什么？ VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议）是一种容错协议，保证当主机的下一条路由器出现故障时，由另一台路由器来代替出现故障的路由器进行工作，从而保持网络通信的连续性和可靠性。 VRRP相关术语： 1.虚拟路由器：由一个Master路由器和一个或多个Backup路由器组成。所有的Master和Backup组成一个组，这个主就是虚拟路由器。 2.VRID：虚拟路由器的标识。同一虚拟路由器内的路由器有着相同的VRID。 3.Master：虚拟路由器中正在工作的路由器 4.Backup：备用路由器。 5.虚拟IP地址：路由器组(虚拟路由器)的IP地址。 6.优先级：用来确定Master和Backup。 7.抢占模式与非抢占模式：Master会以组播方式不断的向虚拟路由器组内发送自己的心跳报文，一旦Backup在设定时间内没有收到心跳信息的次数超过了设定次数，则会将Master的所有权转移到优先级最高的Backup，则就是抢占模式。非抢占模式是指只有在主节点完全故障时才能将backup变为master。

keepalived就是利用VRRP协议实现的一种可保障集群高可用的工具。通过主机之间的优先等级以及心跳检测来及时切换准备主机的工作状态，以提高集群的高可用性。 keepalived的核心组件： 1.VRRP stack 2.ipvs wrapper 3.checkers 为什么使用keepalived一定要确认网卡支持并开启组播功能？ 如VRRP中所述，Master需要通过组播功能定时向Backup发送心跳信息，报告自己的运作是否正常，组播通信方式是一种很节省资源的通信方式。

一、keepalived地址漂移演示

1.安装keeplived

从centos6.4开始，keepalived就集成在yum的base仓中了(keepalived的应用重要可见一斑)，所以直接yum安装即可。 [root@localhost ~]# yum install -y keepalived

2.keepalived简单配置实现两台主机实现高可用模型

准备两台虚拟机

n1:192.168.11.11 n2:192.168.11.22

将n1下做配置/etc/keepalived/keepalived.conf

! Configuration File for keepalived

global_defs {
   notification_email { #通知邮件配置，将keepalived的状态信息发送到指定邮箱
      root@localhost #这里配置通知的邮箱地址，为方便演示这里就配置为本机
   }
   notification_email_from keepalived@localhost #配置发邮件的地址，这里也配置为本机
   smtp_server 127.0.0.1
   smtp_connect_timeout 30 #邮件服务超时时间
   router_id n1 #当前标识当前主机
	 vrrp_mcast_group4 224.1.101.18 #配置组播地址，集群中通常不会使用默认的组播地址
}

vrrp_instance VI_1 { #当前节点所属的虚拟路由的名称
    state MASTER #当前节点的状态，有Master和Backup两种状态
    interface ens33 #定义vrrp地址绑定在哪个接口
    virtual_router_id 51 #虚拟路由器的标识，同一虚拟路由器组中的ID要相同
    priority 100  #优先级设置
    advert_int 1 #每隔多久以组播形式向外通告一次，默认是1秒
    authentication { #认证方式，在组播信息中添加的信息，防止滥竽充数
        auth_type PASS #认证开启
        auth_pass 1111 #认证密码
    }
    virtual_ipaddress { #配置虚拟路由ip，即漂移地址
        192.168.11.99/24 dev ens33 label ens33:0 #漂移地址为192.168.11.99，配置在ens33网卡上并指定接口0
    }
}

配置完成后将此配置复制到n1并修改route_id和priority [root@localhost ~]# scp /etc/keepalived/keepalived.conf root@n1:/etc/keepalived/ 确定网卡开启了multicast功能 [root@localhost ~]# ifconfig 出现MULTICAST就说明已开启

开启keepalived

现在n2上开启(n2优先级比n1低),并查看状态

[root@localhost ~]# systemctl start keepalived [root@localhost ~]# systemctl status keepalived 查看n2网卡配置 [root@localhost ~]# ifconfig 可看出n2进入了MASTER状态

再开启n1，优先级高于n2，并查看状态

[root@localhost ~]# systemctl start keepalived [root@localhost ~]# systemctl status keepalived 现在再查看n2 n1启动后漂移地址(虚拟IP)就漂移至n1了 n2网卡中的漂移地址(配置在ens33:0上)也被删除了，并漂移至n1上(同样配置在ens33:0)了。

利用抓包工具tcpdump可以更直观的看到虚拟地址漂移的过程

安装tcpdump [root@localhost ~]# yum install -y tcpdump 现在的状态是n1,n2的keepalived都开启了，n1的优先级大于n2。 在n1和n2上使用命令 [root@localhost ~]# tcpdump -i ens33 -nn host 224.1.101.11

注意：因为n1为master状态，所以n1会不停的(配置是每隔1秒)发送组播通告，并且这个通告在同一局域网的所有主机都能接收到，但只有配置了keepalived的主机才会起作用。

停掉n1的keepalived服务 [root@localhost ~]# systemctl stop keepalived 查看n2的抓包信息 [root@localhost ~]# tcpdump -i ens33 -nn host 224.1.101.11

这就比较完整的展示了两个节点间在4层上使用keepalived做高可用的最基本的原理过程了。但这没有涉及到应用层的高可用，keepalived还能实现具体服务的高可用。

以上通过实例演示了keepalived实现地址漂移的过程，并实现高可用的原理。下面通过高可用lvs-dr类型来演示keepalived是如何高可用lvs的。

在演示之前总结一下keepalived的功能可概括为下面几类： 1.基于VRRP协议实现地址漂移； 2.为VIP地址所在节点生成ipvs规则； 3.为ipvs集群的各RS做健康状态检测； 4.基于脚本调用接口通过执行脚本完成脚本中定义的功能，进而高可用集群中具体服务。

二、keepalived高可用LVS-DR

1.准备4台主机，其中两台调度器两台Real Server

DR1:192.168.11.111 DR2:192.168.11.222 RS1:192.168.11.11 RS2:192.168.11.22 简易架构图：

2.安装所需服务程序

DR1:192.168.11.111 安装ipvsadm、keepalived DR2:192.168.11.222 安装ipvsadm、keepalived RS1:192.168.11.11 安装nginx RS2:192.168.11.22 安装nginx (安装过程略) lvs-dr模型回顾： 1.在dr模型中需要将VIP配置到调度器和RealServer中。 2.因为RS也配置了VIP，为避免局域网广播发送到RS，需修改RS内核的报文响应和通告等级

3.在RS上添加VIP并修改内核

shell脚本实现如下：

#!/bin/bash
#
vip='192.168.11.99'
netmask='255.255.255.255'
iface='lo:0'

case $1 in
start)
        echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
        echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
        echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
        echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
        ifconfig $iface $vip netmask $netmask broadcast $vip up
        route add -host $vip dev $iface
        ;;
stop)
        ifconfig $iface down
        echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
        echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore
        echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
        echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
        ;;
*)
        exit 1
esac

在两台RS上运行脚本，配置RS就完成了

4.在两台DR上生成keepalived规则

keepalived可以自己生成lvs调度规则，而不需要单独安装ipvsadm来生成，本示例安装ipvsadm是为了查看规则是否生成成功。

安装keepalived后编辑配置文件如下(两台DR配置略有不同，星号标记为不同) vim /etc/keepalived/keepalived.conf

-
    real_server 192.168.11.22 80 {
    weight 1
    HTTP_GET {
        url {
             path /index.html
             status_code 200
        }
           nb_get_retry 3
           delay_before_retry 2
           connect_timeout 3
        }
        }
}

5.将安装nginx的RS1和RS2分别设置默认主页index.html如下，并测试健康监测过程

RS1:RS1 RS2:RS2 启动nginx，并访问VIP。如图(没有配置‘persistence_timeout 50’时) 可见后端RS轮询机制已配置成功。

当加上persistence_timeout 50后会出现返回页面在一定时间内是固定的的RS，因为persistence_timeout这个参数是设置长连接的

当关掉RS1的nginx服务时，RS1会自动down掉，RS2会一直保持工作，如图 当删除RS2默认主页(使主页返回值不是200)，集群也会判断RS出错将其down掉，如图 keepalived可以代替ipvsadm配置调度规则，在配置成功并启动keepalived后可查看lvs规则 ipvsadm -Ln 也能查看后端RS的规则状态，当任一RS不满足健康监测规则时，都会在调度规则中自动删除，在RS重新恢复后也会自动添加。

以上示例是通过HTTP协议对RS进行的健康监测，keepalived也可以基于TCP协议进行健康监测

只需将HTTP_GET{}替换为TCP_CHECK{}即可，很简单~这里不做演示了 keepalived还有一种MISC_CHECK功能，通俗讲就是自定义监测功能，也就是基于脚本命令做监测。

三、keepalived高可用nginx示例

1.准备工作

准备4台主机： 两台nginx主机做高可用负载均衡，两台后端RS 两台nginx分别有两个网卡， IP1：192.168.11.111 IP2：172.16.142.128 IP1：192.168.11.222 IP2：172.16.142.134 三台RealServer的IP： RS1：172.16.142.11 RS2：172.16.142.22 RS2：172.16.142.33 架构图

当keepalived高可用应用时，是通过调用脚本(或命令行)来实现资源监控的，并根据监控的结果状态能实现动态调整。

实现此功能的参数为： vrrp_script 在此参数中定义脚本或命令，根据脚本或命令的执行结果来对优先级做调整进而触发主备切换条件。

2.配置nginx负载均衡以及keepalived

a>在nginx默认配置中添加upstream组并在location中调用(两台nginx负载均衡主机配置相同)

b>在keepalived中配置监控脚本并调用

global_defs {
   notification_email {
      root@localhost
   }
   notification_email_from keepalived@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id n1
         vrrp_mcast_group4 224.1.101.18
}
vrrp_script chk_ngx { #定义名为chk_ngx的监控脚本
    script "killall -0 nginx && exit 0 || exit 1" #命令，若返回为1，执行下面的操作。killall -0是指检查nginx进程是否存在，若存在返回0
    weight -5 # 优先权减5
    interval 1 # 健康检查周期
    fall 1 # 做一次检查若失败即判定为失败
    rise 1 # 做一次检查若成功即判定为成功
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 22
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.11.88/24 dev ens33 label ens33:0
    }
    track_script { # 前面定义的脚本监测，需在这里调用，类似于nginx的upstream、cache等
        chk_ngx
        }
}

keepalived通过监控脚本实现了对nginx进程的监控，并通过调整优先级来实现主备切换，原理和配置都是很简单的。

3.keepalived高可用nginx负载均衡双主模式

keepalived配置双主模式的思路就是在keepalived中添加一个vrrp_instance实例，增加一个VIP，将原来的MASTER作为BACKUP，将原来的BACKUP作为MASTER，并修改相应的识别号与认证规则。配置示例如下：

vrrp_instance VI_2 { #改为VI_2
    state BACKUP #主备交叉
    interface ens33
    virtual_router_id 33 #重新定义一个新的id
    priority 96
    advert_int 1
    authentication { #修改认证密码
        auth_type PASS
        auth_pass 2222
    }
    virtual_ipaddress {
        192.168.11.99/24 dev ens33 label ens33:1 #添加新的VIP到新的别名端口
    }
    track_script {
        chk_ngx
        }
}

由图可见两台nginx负载均衡都在运作中了，若其中一台nginx故障，则两个VIP都会漂移到另一台nginx上。

思考1：在上述keepalived高可用ipvs的示例中若使用sh算法时，当其中一台RS故障后，同以客户端是否会依然绑定在此前的RS上？

下面来测试一下： 将keepalived配置中virtual_server配置做修改，将之前的rr算法换成sh算法，可见客户端请求会绑定在某一台RS上，如图 不断刷新都显示RS2，现在将RS2的nginx服务关掉 systemctl stop nginx

刷新后显示为RS1，由此可以判断在keepalived高可用ipvs时，当其中一台RS故障后，客户端请求会转移到另一台RS，并不会依然绑定在原来的RS上

思考2：在keepalived高可用nginx的示例中，如果划分了upstream组并启用了ip_hash算发，若组内其中一个

在两台nginx负载均衡的upstream组中添加ip_hash选项后，出现的效果类似于ipvs选择sh算法，使客户端绑定后端RS，当upstream组内一台故障时，客户请求会自动转移至组内另一台服务器，这和思考1中的结果是一样的，说明keepalived会自动的将故障的服务器下线，避免客户端始终绑定在故障服务器上。