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

忘是亡心i 2023-07-24 13:08 11阅读 0赞

## 前言 ##

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

### keepalived ###

1.  优点：简单，基本不需要业务层面做任何事情，就可以实现高可用，`主备容灾`。而且容灾的宕机时间也比`较短`。
2.  缺点：也是简单，因为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服务器。![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxNTE0MA_size_16_color_FFFFFF_t_70]  
针对第四点：  
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 ###

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

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

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

[https_blog.csdn.net_weixin_43815140_article_details_105417158]: https://blog.csdn.net/weixin_43815140/article/details/105417158
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzgxNTE0MA_size_16_color_FFFFFF_t_70]: /images/20230528/e8d44ff9f52f4596ad9034a298b755b3.png