keepalived高可用——后期健康检查和维护

前言

keepalived配置篇就不在这里谈了，自行参考：https://blog.csdn.net/weixin_43815140/article/details/105417158
keepalived与zookeeper都可以用来实现高可用，主写了keepalived，ZK稍微提了一点。

keepalived

优点：简单，基本不需要业务层面做任何事情，就可以实现高可用，主备容灾。而且容灾的宕机时间也比较短。
缺点：也是简单，因为VRRP、主备切换都没有什么复杂的逻辑，所以无法应对某些特殊场景，比如主备通信链路出问题，会导致脑裂。同时，keepalived也不易做负载均衡。

调度器群集里面做了keepalived高可用后，其他的backup处于闲置状态，只有master在工作，相对削弱了调度器群集的作用

脑裂：指在一个高可用（HA）系统中，当联系着的两个节点断开联系，没有主备之分，相互抢夺共享资源，导致系统混乱，数据崩溃的现象。

脑裂出现的原因：

心跳线松动或网卡故障
服务器硬件故障，崩溃
节点服务器开启防火墙，却没有做vrrp例外
nginx服务宕机掉,不会出现裂脑现象，但整个集群都无法正常运作

如何预防脑裂现象

前两个非人为可控制的，做好定期检查就好，该检查检查，该换就换。
针对第三点：
编写好检测裂脑脚本（在备用服务器运行）

vim split_brain.sh
#!/bin/sh
while true
do
ping -c 2 -W 3 192.168.10.100 &> /dev/null
if [ $? -eq 0 -a `ip add|grep 192.168.10.100|wc -l` -eq 1 ]
  then
    echo "split brain....."
else
    echo "HA is ok"
fi
sleep 5           #每5秒重复一次
done

简单测试一下，在这期间我在另一个终端打开了防火墙，又关闭了防火墙，效果如下

[root@localhost ~]# sh split_brain.sh 
HA is ok
HA is ok
HA is ok
HA is ok
split brain.....
split brain.....
split brain.....
HA is ok
HA is ok
HA is ok
^CHA is ok
^C
[root@localhost ~]#

扩展：

给防火墙添加VRRP例外,在测试一遍

[root@localhost ~]# firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0  --destination 224.0.0.18 --protocol vrrp -j ACCEPT
success
[root@localhost ~]# firewall-cmd --reload
success

[root@localhost ~]# sh split_brain.sh 
HA is ok
HA is ok
HA is ok
HA is ok
HA is ok
HA is ok
HA is ok
HA is ok
HA is ok
HA is ok
HA is ok
^C
[root@localhost ~]#

224.0.0.18，是VRRP组播使用的目的地址，协议默认每一秒发一次，该时间间隔可以自己设置。
抓包如下图所示，192.168.10.2是我的负载调度器，也是keepalived的master服务器。在这里插入图片描述
针对第四点：
nginx故障造成群集无法工作时，虽然不会出现脑裂，但keepalived也不会工作，所以监控好nginx健康状态就可以判断keepalived是否健康。编辑nginx检查脚本，追踪到keepalived配置文件就好。

编辑监控nginx的脚本

vim /sh/check_nginx_proxy.sh
#！/bin/bash
killall  -0  nginx  #检测 nginx状态，正常则回传值为0
if  [ $? -ne 0 ];then
  systemctl stop keepalived
fi

添加脚本追踪模块到keepalived配置文件

global_defs {
   router_id lb1
}
vrrp_script check_nginx_proxy {
        script “/sh/check_nginx_proxy.sh”
        interval 2
        weight 5
        }
vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.10.100
    }
    track_script {
        check_nginx_proxy
    }
}

保存退出
重启服务：systemctl restart keepalived

扩展：
也可以计划任务定期执行nginx检测脚本，方法不唯一，适用就好。
例：每周一早9:00执行检查脚本
00 9 * * 1 /sh/check_nginx_proxy.sh

zookeeper

优点：可以支持高可用，负载均衡。本身是个分布式的服务。
缺点：跟业务结合的比较紧密。需要在业务代码中写好ZK使用的逻辑，比如注册名字。拉取名字对应的服务地址等。

对比来看，从简单性来说：Keepalived最简单；从负载均衡能力来看，keepalived能力最弱；从与业务的紧密程度来看：keepalived基本与业务没关系，所以，对于框架级别的业务可能会选择ZK，仅仅需要做容灾的用Keepalived。

要注意：keepalived只能用在真实服务器上配置，不能再云服务器配置，例如:阿里云不支持再单独购买ip，即使无法做漂移地址，故不支持在服务器使用，如果需要做负载均衡和高可用，阿里云提供了自己的SLB，都可以实现这种功能。

@李子矜

发布了39 篇原创文章 · 获赞 3 · 访问量 6443

私信关注