keepalived高可用——後期健康檢查和維護

前言

keepalived配置篇就不在這裏談了，自行參考：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服務器。
針對第四點：
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，都可以實現這種功能。