高可用解决方案keepalived

高可用指标=MTBF/(MTBF+MTTR)
MTBF：Mean Time Between Failture [两次故障平均间隔时间]
MTTR：Mean Time To Restoration [平均恢复时间]

从上诉公式可以得出，要提高系统的高可用性，就需要提高系统的无故障时间（MTBF）和缩短系统修复的时间（MTTR）。
缩短MTTR的办法：引入冗余机制，当系统某一部分出现故障，备份可以快速替换。因此MTTR主要取决于检测出故障的时间和完成故障切换的时间。

keepalived的作用：
??①生成ipvs规则；
??②实现IP漂移。
keepalived是VRRP协议在Linux系统上的实现软件，是为了实现IP漂移。

目录

• VRRP协议的实现
• keepalived的工作原理
• keepalived的配置文件
• keepalived的主备模型实例
• keepalived的双主模型实例
• keepalived实现状态切换时的消息通知
• keepalived实现高可用ipvs
• vrrp script实现特定服务的高可用

1、VRRP协议的实现

VRRP的相关术语

?虚拟路由器：由一个Master路由器和多个Backup路由器组成。通俗讲就是一个路由器集群。
?VRID：虚拟路由器标识，如果多个路由器有相同的VRID，那么这些路由器就组成了一个虚拟路由器。
?Master路由器：虚拟路由器中真正承担报文转发的节点。
?Backup路由器：虚拟路由器中某一时刻除Master路由器的其他都有节点。
?虚拟IP（VIP）：虚拟路由器的IP，VIP是用于客户接入的IP地址。
?虚拟MAC地址：虚拟路由器拥有的MAC地址，其格式为00-00-5E-00-01-VRID。
?优先级：VRRP根据每个节点的优先级确定节点在虚拟路由器中的地位。如果优先级相同，则根据节点的IP地址大小进行比较。
?抢占方式和非抢占方式：抢占方式中只要优先级最高才会成为Master路由器，而非抢占方式中只要Master路由器没有出现故障，则Baskup路由器的优先级再高也不会成为Master路由器。

VRRP协议的工作原理

可以参考VRRP协议工作原理

2、keepalived的工作原理

keepalived的核心组件

Checkers：对后端服务器节点（RS）进行健康状态监测和故障隔离，我们知道，LVS本身是没有健康状态监测功能，keepalived起初就是为LVS生成ipvs规则和增加健康状态检测功能而设计的。
VRRP Stack：这是keepalived实现VRRP功能的模块，VRRP功能可以实现对前端调度器集群的故障切换(failover)。
SMTP：Checkers和VRRP Stack都是对节点进行状态监测，不同的是监测前端调度器和监测后端RS，但是这两个模块都可以通过SMTP通知管理员故障信息的邮件。
System Call：Checkers和VRRP Stack同样都可以调用系统内核功能完成故障隔离和故障切换。
IPVS wrapper：Checkers通过监测后端RS的工作状态得出信息，IPVS wrapper通过这些信息添加ipvs规则，内核中的IPVS则通过这些规则进行工作。
Netlink Reflector：在调度器发生故障切换的时候，该模块充当调用内核NETLINK的接口，完成虚拟IP的设置和切换。
Watch Dog：keepalived的核心模块就是Checkers和VRRP Stack，当这两个模块发生故障的时候怎么办呢，这时候Watch Dog就发生了作用，它是一个硬件检测工具，一旦Checkers和VRRP Stack发生故障，Watch Dog就能够检测到并采取恢复措施（重启）。

3、keepalived的配置文件

配置文件的结构层次

keepalived的配置文件分为三个部分，分别是：
?Global Configuration：全局配置部分
??Global definition
??static routes/address
?VRRPD Configuration：VRRPD配置部分
??VRRP instance:VRRP实例配置
??VRRP synchronization group:VRRP同步组
?LVS Configuration：LVS配置部分
??Virtual server:ipvs的RS和VS

全局配置的常用参数

VRRPD配置的常用参数

??VRRP实例参数

上诉notify相关的四个参数，一般用于状态监控通知的脚本。

4、keepalived主备模型实例

在主备模型中的所有节点中，某一时刻只允许有一个节点处于MASTER状态，其他节点均为BACKUP状态。工作中只有MASTER节点会接受请求，BACKUP状态的节点处于闲置状态。只有在MASTER出现故障的时候，BACKUP节点才会重新选举出新的节点进入MASTER状态。
主节点的配置文件内容如下：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state MASTER      # 初始化设置为MASTER节点
    interface eth1
    virtual_router_id 50   # 同一个VRRP实例中每个节点的虚拟路由ID必须相同
    priority 100             # MASTER节点的优先级必须高于BACKUP节点
    advert_int 1
    authentication {
        auth_type PASS    # 验证类型为密码认证
        auth_pass 1111qwer # 验证密码，需要注意密码最大长度为8位
    }
    virtual_ipaddress {
        192.168.239.250/24 dev eth1  # 主备节点的VIP一定要相同
    }
}

Backup节点的配置文件内容如下：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 50
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }
    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

关闭防火墙和SELinux。
开启两个节点的keepalived服务。

[root@Master ~]# /etc/init.d/keepalived restart
Starting keepalived:                                       [  OK  ]
[root@Backup ~]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]

查看主节点的日志信息

查看备节点的日志信息

利用命令ip a查看主节点的ip状态，可以看到VIP已经配置到了eth1网卡上

备节点因为处于BACKUP状态，则没有获得VIP。

arp 192.168.239.250命令也可以看出VIP的MAC地址为主节点eth1网卡的MAC地址。

现在将主节点中的keepalived.conf中的优先级参数设置为80（低于备节点），然后重启主节点的keepalived服务。再次查看IP状态和ARP缓存表信息。


并且VIP对应的MAC地址也发生了变化。说明IP漂移已经实现。

5、keepalived双主模型实例

在keepalived的主备模型中，当主节点正常的时候，备节点永远处于闲置状态，不会接受web请求，这样就会浪费一半的资源。因此可以使用keepalived的双主模型实例，使得其中的两个节点都能够接受web请求，这要求节点1在一个vrrp实例处于master状态，在另一个vrrp实例中处于backup状态；节点2在一个vrrp实例中处于backup状态，在另一个vrrp实例中处于master状态。
节点1的配置文件内容如下：

[root@Master ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
    notification_email {      
        root@localhost
} 
    notification_email_from keepalived@localhost  
    smtp_server 127.0.0.1  
    smtp_connect_timeout 10  
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state MASTER
    interface eth1 
    virtual_router_id 50   
    priority 100
    advert_int 1  
    authentication { 
        auth_type PASS  
        auth_pass 1111qwer    
    }
    virtual_ipaddress {        
        192.168.239.250/24 dev eth1
    }
}
vrrp_instance VI_2 {
    state BACKUP
    interface eth1
    virtual_router_id 52
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }
    virtual_ipaddress {
        192.168.239.150/24 dev eth1
    }
}

节点2的配置文件内容如下：

[root@Backup ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
    notification_email {      
        root@localhost
} 
    notification_email_from keepalived@localhost  
    smtp_server 127.0.0.1  
    smtp_connect_timeout 10  
    router_id node2
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth1 
    virtual_router_id 50   
    priority 90
    advert_int 1  
    authentication { 
        auth_type PASS  
        auth_pass 1111qwer    
    }
    virtual_ipaddress {        
                192.168.239.250/24 dev eth1 # VIP1的信息
    }
}
vrrp_instance VI_2 {
    state MASTER
    interface eth1
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }
    virtual_ipaddress {
        192.168.239.150/24 dev eth1 # VIP2的信息
    }
}

节点1的VIP1信息：

节点2的VIP2信息：

当节点1的keepalived停止，节点1的VIP移除，效果如下：

节点2获得两个VIP，如图：

6、keepalived状态切换时的消息通知

当keepalived的状态发生变化的时候，往往需要通知管理员，这个时候就需要借助notify_master、notify_backup、notify_fault三个参数，进而配合脚本来实现keepalived的消息通知机制。这三个参数的使用规范上面有说过。
实验中每个节点使用同一个脚本，脚本内容如下：
脚本的主要功能是当keepalived的状态发生转换之后，keepalived会给指定收件人发送通知邮件，告诉收件人哪个节点切换为什么状态。

#!/bin/bash
#
recipient="root@localhost"

notify () {
    local mailsubject="$(hostname) to be $1 and VIP floating"
    local mailbody="$(date ‘+%F %T‘):vrrp transation,$(hostname) changed to be $1"
    echo "$mailbody" | mail -s "$mailsubject" $recipient
}

case $1 in
master)
    notify master
    ;;
backup)
    notify backup
    ;;
fault)
    notify fault
    ;;
*)
    echo "Usage:$(basename $0) {master|backup|fault}"
    exit 1
    ;;
esac

该实验使用的是主备模型，其中主节点的配置文件内容如下：

[root@Master ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
            notification_email {      
        root@localhost
} 
            notification_email_from keepalived@localhost  
            smtp_server 127.0.0.1  
            smtp_connect_timeout 10  
            router_id node1
            vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
            state MASTER
            interface eth1 
            virtual_router_id 50   
            priority 100
            advert_int 1  
            authentication { 
                    auth_type PASS  
                    auth_pass 1111qwer    
            }

            track_interface {
                    eth1
            }

            notify_master "/etc/keepalived/notify.sh master"
            notify_backup "/etc/keepalived/notify.sh backup"
            notify_fault "/etc/keepalived/notify.sh fault"

            virtual_ipaddress {        
                    192.168.239.250/24 dev eth1
            }
}

备节点的配置文件内容如下：

[root@Backup ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
            notification_email {      
        root@localhost
} 
            notification_email_from keepalived@localhost  
            smtp_server 127.0.0.1  
            smtp_connect_timeout 10  
            router_id node2
            vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
            state BACKUP
            interface eth1 
            virtual_router_id 50   
            priority 90
            advert_int 1  
            authentication { 
                    auth_type PASS  
                    auth_pass 1111qwer    
            }

            track_interface {
                    eth1
            }

            notify_master "/etc/keepalived/notify.sh master"
            notify_backup "/etc/keepalived/notify.sh backup"
            notify_fault "/etc/keepalived/notify.sh fault"

            virtual_ipaddress {        
                        192.168.239.250/24 dev eth1
            }
}

现在启动主备节点的keepalived服务，其中主节点获得VIP，进入MASTER状态，备节点进入BACKUP状态。然后每个节点会收到相对应的通知邮件。可以使用mail命令查看，该命令是由mailx软件提供的。


对于keepalived的FAULT状态，该状态与keepalived监控的网络接口有关，如果节点的网卡出现故障，则keepalived会进入FAULT状态，暂停主节点的网卡，然后系统会受到通知邮件，如下图，通知keepalived进入FAULT状态。

[root@Master ~]# ifdown eth1

7、keepalived实现高可用ipvs

keepalived的另一个重要的配置段是关于LVS的配置，LVS配置段是实现LVS高可用功能。该配置段以virtual_server为开始标识。

应用层检测配置段的参数：
HTTP_GET|SSL_GET {
??url {
????path /index.html
????status_code 200
????digest xxxxxxxx

??}

??nb_get_retry 3
??delay_before_retry 2
??connect_ip
??connect_port
??bindto
??bind_port
??connect_timeout
}
url：指定HTTP/SSL监控的URL信息.
path：定义要监控的详细的URL
status_code：指定返回http检测正常的状态码类型，就是当返回指定的状态码时即可认定节点正常，一般为200。
digest：status_code定义的状态码并不准确，即使返回200的状态码，还是有网页内容被篡改的可能，这样就无法发现错误信息，因此加入了digest参数，对网页内容的摘要信息进行比对，如果一致则认为页面没有发生改变。该摘要信息可以使用命令genhash生成。

genhash -s 192.168.239.129 -p 80 -u /index.html

nb_get_retry：重试的次数
delay_before_retry：重试之前等待的时间延迟,即两次重试之间的间隔，单位是秒
上边的两个参数是在检测到错误信息之后才会生效。
connect_ip：向当前RS的哪个IP地址发送健康状态监测信息
connect_port：向当前RS的哪个端口发送健康状态监测信息
如果connect_ip和connect_port都没有指定，则默认使用real_server参数指定的IP和port。
bindto：指定负载均衡器对RS发送健康状态监测的源IP地址
bind_port：指定负载均衡器对RS发送健康状态监测的源端口
connect_timeout：定义健康状态监测的连接超时时间
基于四层监测配置段参数：
TCP_CHECK {
??connect_ip
??connect_port
??bindto
??bind_port
??connect_timeout
}
keepalived的LVS段配置实例
实验环境：

开始该实验之前先暂停上面实验的keepalived的服务。
第一步：
配置后端真实服务器集群的每个节点，其中的HTTP服务使用Nginx实现，具体Nginx的操作可以参考博客Nginx使用，并且设置Web1.linux.com节点的首页文件index.html的内容为This is web1 with 80 。Web2.linux.com节点的首页文件index.html的内容为This is web2 with 80。
当出现下图所示的页面内容的时候表示RS集群的http服务配置成功。


第二步：
该实验中基于LVS的DR模型，因此需要设置RS的VIP地址和ARP抑制参数等。我这里使用脚本。

[root@Web1 data]# cat arp_depress.sh 
#!/bin/bash
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
ifconfig lo:0 192.168.239.250 broadcast 192.168.239.250 netmask 255.255.255.255 up
route add -host 192.168.239.250 dev lo:0

然后在两个RS节点上分别运行该脚本，运行效果如下：


到目前为止，客户端ping VIP-192.168.239.250，结果显示无法访问目标主机。说明ARP抑制已经实现。

第三步：
配置keepalived的两个节点的配置文件 ，配置内容是在4、keepalived的主备模型和6、keepalived的状态切换时的消息通知机制的基础上增加virtual_server配置段来完成的。
主节点的配置文件内容：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}
# LVS配置段
virtual_server 192.168.239.250 80 {
    delay_loop 3
    lb_algo rr
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 192.168.239.129 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
            nb_get_retry 3
            delay_before_retry 2
            connect_ip 192.168.239.129
            connect_port 80
            bindto 192.168.239.137
            bind_port 80
            connnect_timeout 6
        }
    }
    real_server 192.168.239.133 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
        nb_get_retry 3
        delay_before_retry 2
        connect_ip 192.168.239.133
        connect_port 80
        bindto 192.168.239.137
        bond_port 80
        connect_timeout 6
        }
    }
}

备节点的配置文件内容：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node2
    vrrp_mcast_group4 224.0.199.32
}
vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 50
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault "/etc/keepalived/notify.sh fault"

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

virtual_server 192.168.239.250 80 {
    delay_loop 3
    lb_algo rr
    lb_kind DR
    protocol TCP
    sorry_server 127.0.0.1 80
    real_server 192.168.239.129 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
            nb_get_retry 3
            delay_before_retry 2
            connect_ip 192.168.239.129
            connect_port 80
    # 发送检测消息的源地址和端口是调度器的真实IP，不是VIP
            bindto 192.168.239.138
            bind_port 80
            connnect_timeout 6
        }
    }
    real_server 192.168.239.133 80 {
        weight 1
        HTTP_GET {
            url {
                path /index.html
                status 200
            }
        nb_get_retry 3
        delay_before_retry 2
        connect_ip 192.168.239.133
        connect_port 80
        bindto 192.168.239.138
        bond_port 80
        connect_timeout 6
        }
    }
}

第四步：
配置整个集群中的备用节点，也即sorry_server参数，假设这样的场景，后端RS集群的每个节点都出现故障，这时候就需要备用节点返回响应内容。这里将sorry_server配置为keepalived的两个节点。因此在第三步的两个keepalived节点中设置sorryserver 127.0.0.1 80，并且两个备用节点都返回相同的页面内容“This web is maintaining”。
主节点的操作流程：

[root@Master ~]# yum -y install httpd
[root@Master ~]# vim /var/www/html/index.html 
This web is maintaining
[root@Master ~]# /etc/init.d/httpd start

备节点的操作流程：

[root@Backup ~]# yum -y install httpd
[root@Backup ~]# vim /var/www/html/index.html 
This web is maintaining
[root@Backup ~]# /etc/init.d/httpd start

效果图如下：


第五步：
接下来开启主备节点的keepalived服务。

[root@Master ~]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]
[root@Backup ~]# /etc/init.d/keepalived start
Starting keepalived:                                       [  OK  ]

然后访问VIP地址，结果会返回后端RS的页面内容，并且每次刷新页面内容会发生变化。说明LVS的负载均衡已经实现。并且利用ipvsadm工具也可以查看到主备节点已经生成了ipvs规则。


第六步：
测试，暂停主节点的keepalived服务，浏览器能够继续返回页面内容，


现在暂停两个RS节点的http服务，然后继续访问VIP地址，结果返回是备用节点的信息。说明sorry_server已经实现。

8、vrrp script实现特定服务的高可用

keepalived本身是由三个配置段组成的，分别是全局配置段、VRRP配置段和LVS配置段。VRRP配置段是用来实现IP地址（VIP）漂移的，LVS配置段是用来实现生成ipvs规则的。keepalived的基本功能仅此而已，总之keepalived的基本功能就是实现LVS的高可用，如果要实现特定服务的高可用功能，就需要借助脚本来实现。例如通过keepalived实现Nginx、Apache、mysql等特定服务的高可用，则需要编写相应的监控脚本。

脚本中priority和weight参数的关系

vrrp script在keepalived的配置文件的格式为：
vrrp_script check_server-name {
??script " ... "
??interval ...
??weight <+|-int>
}
check_script {
??check_server-name
}
其中集群中MASTER和BACKUP角色进行切换，是由priority和weight共同决定的。weight的绝对值一定为整数。
一、weight为正数（+int）：
① 脚本执行成功，MASTER节点的priority和int之和小于BACKUP节点的priority和int之和，则发生角色切换；
② 脚本执行失败，MASTER节点的priority和int之和大于BACKUP节点的priority和int之和，则不发生角色切换。
二、weight为负数（-int）：
① 脚本执行失败，MASTER节点的priority和int之差小于BACKUP节点的priority，则发生角色切换；
② 脚本执行成功，MASTER节点的priority和int之差大于BACKUP节点的priority，则不发生角色切换。
因此为了保证weight的值能够保证脚本在成功与失败后触发主备切换，通常设置weight的绝对值大于主备节点priority之差

vrrp script实现Apache的http服务高可用

实验环境：

第一步：
配置两个节点的http服务，这里使用Apache，为了显示请求确实发生了跳转，将两个节点的http主页设置为不同的内容。
Master.linux.com节点的页面内容：

[root@Master ~]# cat /var/www/html/index.html 
This is web1

Backup.linux.com节点的页面内容：

[root@Backup ~]# cat /var/www/html/index.html 
This is web2

然后开启两个节点的http服务。
第二步：
配置两个节点的keepalived配置文件和脚本文件，脚本思路：原本主节点的权值为100，备节点的权值为90，各个节点每隔一秒监控各自的http服务是否正常，如果主节点的http服务发生异常，则权值减少20（即降低至80），这样80小于90，MASTER会变为权值90的节点。内容如下，
Master.linux.com：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node1
    vrrp_mcast_group4 224.0.199.32
}
# 监控http服务的脚本
vrrp_script check_httpd {
# script "<脚本内容或者脚本文件>"
    script "killall -0 httpd"   # 检测httpd进程是否运行，这里前边的script参数比不可少
    interval 1   # 脚本运行一次的时间间隔
    weight -20 # httpd进程出现异常后，该节点keepalived的权值减少20，原本权值为100
}
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 50
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    track_script {
        check_httpd
    }

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

Backup.linux.com：

! Configuration File for keepalived
global_defs {
    notification_email {
        root@localhost
}
    notification_email_from keepalived@localhost
    smtp_server 127.0.0.1
    smtp_connect_timeout 10
    router_id node2
    vrrp_mcast_group4 224.0.199.32
}

vrrp_script check_httpd {
    script "killall -0 httpd"
    internal 1
    weight -20
}

vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 50
    priority 90
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111qwer
    }

    track_interface {
        eth1
    }

    track_script {
        check_httpd
    }

    virtual_ipaddress {
        192.168.239.250/24 dev eth1
    }
}

然后依次开启Master.linux.com和Backup.linux.com的keepalived服务。利用抓包工具tcpdump可以看到是主节点（权值100）在发送心跳信息。

通过浏览器访问VIP，在会返回主节点的网页内容。

第三步：
关闭主节点的http服务（注意是http服务，不是上面实验做的关闭keepalived服务），抓包工具可以看到主节点的权值降低为80，然后权值90的节点获得VIP进入MASTER状态。

浏览器继续访问VIP，此时网页内容已经自动跳转到新的主节点（Backup.linux.com）。

这样keepalived就可以实现Apache的高可用。

高可用解决方案--keepalived