高可用服務之Keepalived利用腳本實現服務的可用性檢測

　　上一篇博客主要聊到了keepalived高可用LVS集羣的相關配置，回顧請參考http://www.javashuo.com/article/p-kllhxleh-nk.html；keepalived高可用LVS集羣是Keepalived的設計之初的功能，因此它高可用LVS集羣內置了對LVS的RS的健康狀態檢測，自動生成IPVS規則；咱們知道LVS是Linux內核功能，本質上在用戶空間不會監放任何端口，它的主要做用是對用戶請求的流量作4層調度，因此對於這種沒有進程，沒有端口信息的服務咱們怎麼去判斷它是否正常就先得尤其重要；一樣的道理對於高可用nginx或haproxy這類在用戶空間有監聽端口和進程的服務來講，若是用keepalived作高可用，咱們須要考慮到咱們高可用的服務是否正常可用，從而實如今服務不正常的狀況下，把對應的VIP可以遷移到其餘節點；爲了實現可以檢測到高可用的服務是否正常，keepalived提供了調用外部腳本的接口，讓咱們配置對高可用的服務作可用性檢測；根據咱們定義的腳本，keepalived會週期性的去執行咱們的定義的腳本，根據腳本執行退出碼判斷服務是否可用，一旦發生服務不可用，或者可用性檢測不經過，它就會觸發當前keepalived節點的優先級下降，從而實現當前節點在通告優先級時，觸發備份節點接管VIP，從而實現VIP轉移，服務的高可用；

　　在keepalived的配置文件中，咱們能夠用vrrp_script {...} 來定義咱們能夠執行的腳本相關信息；用track_script {..}在對應vrrp實例中調用vrrp_script定義的腳本；

　　示例：利用腳本對LVS作可用性檢測

　　一、編寫腳本

[root@node01 keepalived]# ls
check_lvs.sh  keepalived.conf  keepalived.conf.bak  notify.sh
[root@node01 keepalived]# chmod a+x check_lvs.sh 
[root@node01 keepalived]# ll
total 16
-rwxr-xr-x 1 root root   98 Sep 13 22:26 check_lvs.sh
-rw-r--r-- 1 root root 1611 Sep 13 22:24 keepalived.conf
-rw-r--r-- 1 root root 3598 Sep  8 23:29 keepalived.conf.bak
-rwxr-xr-x 1 root root  472 Sep 10 13:58 notify.sh
[root@node01 keepalived]# cat check_lvs.sh 
#!/bin/bash
ping -c 2 192.168.0.1 &> /dev/null
if [ $? -eq 0 ];then
    exit 0
else
    exit 1
fi
[root@node01 keepalived]# 

　　提示：以上腳本主要是利用ping 192.168.0.1這個地址來判斷推出碼是0仍是1，正常退出時0，非正常退出爲1；

　　二、配置keepalived調用上面的腳本，並在VIP所在實例中引用；

　　提示：以上配置表示定義了一個腳本，名爲check_LVS(這個名稱能夠任意起，主要起標識做用，後面在實例中引用的一個標識)；這個腳本執行時間間隔爲每2秒執行一次，超時時長爲2秒，若是腳本執行失敗（退出碼非0）就把對應節點的優先級下降20（一般這個下降的值要大於兩節點優先級之差就行，意思就是下降後的優先級要小於備份節點優先級，這樣纔有意義）；腳本執行連續3次檢測都爲成功狀態（腳本推出碼都爲0），則keepalived就標記該實例爲OK狀態，並會一直檢測下去，若是連續3次檢查都爲失敗狀態（退出碼非0），則標記對應實例爲KO狀態；一旦標記對應實例爲失敗狀態就會觸發當前節點的優先級下降；從而在通告心跳時，會通告下降後的優先級，從而實現備份節點接管VIP來完成vip轉移；

　　完整的keepalived配置

[root@node01 keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
        root@localhost
   }
   notification_email_from node01_keepalived@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id node01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_iptables
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_mcast_group4 224.0.12.132
}

vrrp_script check_LVS {
    script "/etc/keepalived/check_lvs.sh"
    interval 2
    timeout 2
    weight -20
    rise 3
    fall 3
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 12345678
    }
    virtual_ipaddress {
        192.168.0.111/24 brd 192.168.0.255 dev ens33 label ens33:1
    }
    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault  "/etc/keepalived/notify.sh fault"
    track_script {
        check_LVS
    }
}

virtual_server 192.168.0.111 80 {
        delay_loop 3
        lb_algo wrr
        lb_kind DR
        protocol TCP
        sorry_server 127.0.0.1 80

        real_server 192.168.0.43 80 {
                weight 1
                nb_get_retry 2
                delay_before_retry 2
                connect_timeout 30
                HTTP_GET {
                    url {
                    path /index.html
                    status_code 200
                    }
                }
        }
        real_server 192.168.0.44 80 {
                weight 1
                nb_get_retry 2
                delay_before_retry 2
                connect_timeout 30
                HTTP_GET {
                    url {
                    path /index.html
                    status_code 200
                    }
                }
        }
}

[root@node01 keepalived]# 

View Code

　　提示：vrrp_script中的script能夠是腳本路徑，也能夠是一段命令；

　　驗證：重啓keepalived，修改腳本中的IP地址，模擬故障，故意讓其對指定地址ping不通，看看對應vip是否會從master節點飄逸到備份節點？對應節點的優先級是否有變化？

　　未修改腳本時，vip在node01上

　　修改腳本之後

　　提示：修改腳本之後對應的VIP就沒有在node01上了；

　　查看node01上keepalived的日誌信息，看看它是如何故障轉移的

　　提示：從日誌文件能夠看到，當keepalived週期性去執行check_lvs.sh腳本時，連續3次都執行失敗，就觸發了動態調整當前節點所在keepalived的優先級，把原來優先級爲100調整至80，而後通告本身的心跳信息時，又觸發了備份節點通告本身的優先級信息，對應主節點收到高於它的優先級通告，因此它就自動轉換成backup狀態，並刪除了VIP；而後後續也在每隔2秒檢測一次腳本執行否正常；

　　在node02上查看vip是否存在？

　　訪問VIP看看服務是否可訪問？

　　提示：能夠看到對應用戶訪問仍是能夠正常訪問；

　　驗證：修改腳本爲正常可通訊地址，看看對應節點是否會從新轉換爲master角色呢？對應vip是否會漂移回來呢？

　　提示：可看到修改腳本之後，對應vip就回來了；

　　查看keepalived的日誌

　　提示：能夠看到當腳本執行成功之後，首先會觸發當前節點的優先級還原爲原有優先級，並通告出去，而後把當前節點從backup角色轉換爲master角色，接管VIP;

　　以上示例主要用於對那種高可用服務在用戶空間沒有監聽端口，沒有進程，咱們須要藉助某種機制去判讀該服務是否正常，好比上面咱們利用ping某個ip地址去判斷LVS是否正常，從而來決定對應節點的優先級是否調整，進而來決定vip是否轉移；固然對於在用戶空間有監聽端口，有進程的服務也是一樣的套路，咱們能夠利用腳本去檢測端口是否存在，或者對應進程是否正常來決定VIP是否轉移；

　　示例：keepalived利用腳原本檢測nginx進程是否正常，從而來實現對nginx的高可用

 　　一、編寫腳本

　　提示：以上腳本利用killall命令對nginx進程發送0號信號，去判斷對應的nginx進程是否存在，若是存在該命令會返回0，不然返回非0；利用命令的返回值來肯定腳本退出碼；

　　二、在keepalived的配置文件中定義腳本相關參數，並在vrrp實例中引用定義的腳本信息

　　完整的keepalived配置

[root@node01 ~]# cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived

global_defs {
   notification_email {
        root@localhost
   }
   notification_email_from node01_keepalived@localhost
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id node01
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_iptables
   vrrp_garp_interval 0
   vrrp_gna_interval 0
   vrrp_mcast_group4 224.0.12.132
}

vrrp_script check_LVS {
    script "/etc/keepalived/check_lvs.sh"
    interval 2
    timeout 2
    weight -20
    rise 3
    fall 3
}
vrrp_script check_nginx {
    script "/etc/keepalived/check_nginx.sh"
    interval 2
    timeout 2
    weight -20
    rise 3
    fall 3
}

vrrp_instance VI_1 {
    state MASTER
    interface ens33
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 12345678
    }
    virtual_ipaddress {
        192.168.0.111/24 brd 192.168.0.255 dev ens33 label ens33:1
    }
    notify_master "/etc/keepalived/notify.sh master"
    notify_backup "/etc/keepalived/notify.sh backup"
    notify_fault  "/etc/keepalived/notify.sh fault"
    track_script {
        check_LVS
        check_nginx
    }
}
[root@node01 ~]# 

View Code

　　提示：vrrp_script須要定義在實例以外，表示引用一段上下文來定義腳本相關信息；定義了腳本信息，若是不在實例中引用，它是不會週期性的去執行腳本，只有在實例中引用的腳本名稱之後（這裏的名稱是vrrp_script後面的名稱）纔會使對應的腳本週期性的去執行；

　　在node01和node02上安裝nginx

yum install nginx -y

　　提供測試頁面

　　重啓keepalived 和nginx

systemctl restart nginx keepalived.service 

　　提示：能夠看到重啓nginx和keepalived之後，在node01上有VIP和80端口，在node02上沒有vip，但80端口處於監聽狀態；若是此時有用戶訪問vip，就會由node01上的nginx提供響應；

　　驗證：用瀏覽器訪問vip，看看響應的內容是不是咱們在node01上提供的測試頁面？

　　驗證：把node01上的nginx停掉，看看對應的服務是否還可訪問？

　　提示：能夠看到把node01上的nginx停掉之後，對應的vip也就隨之被刪除；

　　再次訪問vip看看是否會有響應？

　　提示：能夠看到如今訪問vip響應的頁面內容變成了node02上nginx提供的測試頁面；說明如今是由node02上的nginx在提供服務；

　　到此keepalived高可用nginx的配置就完成了，至於nginx怎麼工做，是否爲調度器，這裏的keepalived並不關心，它只關心nginx進程是否正常；對於keepalived高可用其餘服務，思路都是相似的，不一樣的是對於不一樣的服務，檢測腳本可能有所不一樣；