1. 程式人生 > >keepalived健康檢查方式【轉】

keepalived健康檢查方式【轉】

進行 主機 aik 存在 ssl func main scrip software

keepalived具有很強大、靈活的後端檢測方式,其具有HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK 幾種健康檢測方式 ,在分別介紹各種檢測方式之前,先糾正一個常見的理論問題 。在百度百科 及 keepalived官方老文檔(田逸提交的)中,對keepalived的描述是其具有3、4、7層交換及健康檢測功能。不過根據官網對當前版本的介紹和這有些出入 。

網上一些文檔的介紹如下:

layer 3層檢測:進行ICMP ping包檢測,確認主機是否存活,如果異常,則會該主機從服務器集群中剔除;

layer 4層檢測:進行端口檢測,例如80、3306等,端口不通時,將服務器從集群中剔除;

layer 7層檢測:這個就是基於應用的了,如http返回碼是否為200,確認主機是否正常。

當然,上面這些對keepalived的描述不能說不對,只能說不準確 。對於當前的最近版本來說,管網上關於checkers 的描述如下:

This is one of the main Keepalived functionnality. Checkers are in charge of realserver healthchecking.A checker test if realserver is alive, this test end on a binary decision :remove or add realserver from
/into the LVS topology. The internal checker design is realtime networking software,it use a fully multi-threaded FSM design (Finite State Machine).This checker stack provide LVS topology manipulation accoring to layer4 to layer5/7 test results.Its run in an independent process monitored by parent process

上面的描述很清楚,是layer4 to layer5/7 ,並不包含上面所謂的三層交換檢測 。不過也並不能說網上這些說法是不準確的,因為三層相較於layer5/7這些,屬於低層級的基本功能,基於MISC_CHECK 進行ICMP ping 三層網絡檢測完全是不存在問題的 。不過僅僅通過ping確認一個服務是否正常,顯然也太低端了。---(本人有“潔癖” ,以上為對比官網描述和當下網上資料後的一點心得)

一、HTTP及SSL GET檢測

這裏有幾個要點:

1、兩者都有兩種檢測方式,一種是簡單的基於返回碼確認;另一種是基於確認後端頁面內容hash值,確認前後是否發生變化(是不是感覺有點高端,還有簡單的防止頁面被篡改的作用,當然,動態頁面顯然不行);

2、兩者都是處理簡單的GET請求,基於post返回值確認是否正常,這種方法顯然不適用 ,不過POST方式是可以通過MISC_CHECK方式進行支持檢測的;

3、兩者配置語法上相同,只不過類型名不同而已 。同屬於大的web請求範疇,只不過一個走的HTTP協議,一個走的HTTPS協議;

基於狀態碼的檢測

配置如下:

real_server 192.168.2.188 80 {
    weight 1
    HTTP_GET {
        url {
        path /index.html
        status_code 200 #http://192.168.2.188/index.html的返回狀態碼
          }
          connect_timeout 3
          nb_get_retry 3
          delay_before_retry 3
    }

基於genhash的檢測

配置如下:

real_server 192.168.2.188 80 {
    weight 1
    HTTP_GET {
        url {
        path /index.html
        digest bfaa334fdd71444e45eca3b7a1679a4a #http://192.168.2.188/index.html的digest值
          }
          connect_timeout 3
          nb_get_retry 3
          delay_before_retry 3
    }

安裝完keepalived包,系統中會多出一個命令genhash,通過該命令可以獲取頁面的hash串,如下是我更改某個頁面前後的digest值:

[root@lvs-dr ~]# genhash -s 192.168.122.10 -p 80 -u /index.html
MD5SUM = 6df8d89daedcbb90e3f0c1d1f82cbcf6
[root@lvs-dr ~]# genhash -s 192.168.122.10 -p 80 -u /index.html
MD5SUM = e6368a07d59e3922d2f428b2acd27090

也可以參考官方給出的文檔(包安裝後,會有該文件生成)。

二、TCP_CHECK 檢測

配置如下:

real_server 192.168.2.100 80 {
    weight 100
    TCP_CHECK {
           connect_timeout 3 #連接超時時間
           nb_get_retry 3 #重連次數
           delay_before_retry 3 #重連間隔
           connect_port 80
    }
}

這個在安裝包附帶的文檔中也有示例 。而且其還可以配合HTTP_GET和SSL_GET一起用,如下:

real_server 192.168.201.100 443 {
    weight 1
    SSL_GET {
    url {
    path /
    digest ff20ad2481f97b1754ef3e12ecd3a9cc
    }
    connect_port 444
    connect_timeout 3
    nb_get_retry 3
    delay_before_retry 3
    }
    }

以上配置也是安裝包中的示例 。

三、SMTP檢測

SMTP這個顧名思義,主要用於郵件系統SMTP協議的檢測,具體如下示例:

SMTP_CHECK {
    connect_timeout 10
    retry 2
    delay_before_retry 5
    helo_name foo.bar.com
    host {
    connect_ip 172.16.1.11
    }
    host {
    connect_ip 192.168.155.10
    }
    }

這裏也可以指定連接的端口(默認肯定是25啊),監聽的地址 ,更多也可以參看幫助文檔 。

四、MISC_CHECK檢測

這個是通過調用外部配置名腳本進行檢測確認後端主機是否正常的方法 。

    MISC_CHECK {
    misc_path <STRING>|<QUOTED-STRING># 外部程序或者腳本路徑
    misc_timeout <INT># 執行腳本的超時時間
    misc_dynamic #如果設置了misc_dynamic,healthchecker程序的退出狀態碼會用來動態調整服務器的權重(weight).
    #返回0:健康檢查OK,權重不被修改
    #返回1:健康檢查失敗,權重設為0
    #返回2-255:健康檢查OK,權重設置為:退出狀態碼-2,比如返回255,那麽weight=255-2=253
    }

對應的腳本後面是支持傳參的,兩個示例如下:

    #不傳參配置
    real_server 192.168.200.6 1358 {
    weight 1
    MISC_CHECK {
    misc_path /usr/local/bin/script.sh
    }
    }
    #傳參配置
    real_server 192.168.200.6 1358 {
    weight 1
    MISC_CHECK {
    misc_path "/usr/local/bin/script.sh arg1 arg2"
    }
    }

轉自

keepalived健康檢查方式 - 運維之路 http://www.361way.com/keepalived-health-check/5218.html

keepalived健康檢查方式【轉】