keepalived健康檢查方式

一、前言 這篇文章是前幾篇文章的總結，我們先簡單的總結一下我們前面講解的內容，前面我們講解了，LVS（負載均衡器）、Heartbeat、Corosync、Pacemaker、Web高可用集群、MySQL高可用集群、DRDB、iscsi、gfs2、cLVM等，唯一沒有講解的就是LVS可用，也就是前端高可用，我們這一篇博文主要講解內容。在說這個之前我們得和大家討論一個問題，也是好多博友問的問題。Heartbeat、Corosync、Keepalived這三個集群組件我們到底選哪個好，首先我想說明的是，Heartbeat、Corosync是屬於同一類型，Keepalived與Heartbeat、Corosync，根本不是同一類型的。Keepalived使用的vrrp協議方式，虛擬路由冗余協議 (Virtual Router Redundancy Protocol，簡稱VRRP)；Heartbeat或Corosync是基於主機或網絡服務的高可用方式；簡單的說就是，Keepalived的目的是模擬路由器的高可用，Heartbeat或Corosync的目的是實現Service的高可用。所以一般Keepalived是實現前端高可用，常用的前端高可用的組合有，就是我們常見的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是實現服務的高可用，常見的組合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 實現Web服務器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 實現MySQL服務器的高可用。總結一下，Keepalived中實現輕量級的高可用，一般用於前端高可用，且不需要共享存儲，一般常用於兩個節點的高可用。而Heartbeat(或Corosync)一般用於服務的高可用，且需要共享存儲，一般用於多節點的高可用。這個問題我們說明白了，又有博友會問了，那heartbaet與corosync我們又應該選擇哪個好啊，我想說我們一般用corosync，因為corosync的運行機制更優於heartbeat，就連從heartbeat分離出來的pacemaker都說在以后的開發當中更傾向於corosync，所以現在corosync+pacemaker是最佳組合。但說實話我對於軟件沒有任何傾向性，所以我把所有的集群軟件都和大家說了一下，我認為不管什么軟件，只要它能存活下來都有它的特點和應用領域，只有把特定的軟件放在特定的位置才能發揮最大的作用，那首先我們得對這個軟件有所有了解。學習一種軟件的最好方法，就是去查官方文檔。好了說了那么多希望大家有所收獲，下面我們來說一說keepalived。 二、Keepalived 詳解 1.Keepalived 定義 Keepalived 是一個基於VRRP協議來實現的LVS服務高可用方案，可以利用其來避免單點故障。一個LVS服務會有2台服務器運行Keepalived，一台為主服務器（MASTER），一台為備份服務器（BACKUP），但是對外表現為一個虛擬IP，主服務器會發送特定的消息給備份服務器，當備份服務器收不到這個消息的時候，即主服務器宕機的時候， 備份服務器就會接管虛擬IP，繼續提供服務，從而保證了高可用性。Keepalived是VRRP的完美實現，因此在介紹keepalived之前，先介紹一下VRRP的原理。 2.VRRP 協議簡介 在現實的網絡環境中，兩台需要通信的主機大多數情況下並沒有直接的物理連接。對於這樣的情況，它們之間路由怎樣選擇？主機如何選定到達目的主機的下一跳路由，這個問題通常的解決方法有二種： 在主機上使用動態路由協議(RIP、OSPF等) 在主機上配置靜態路由 很明顯，在主機上配置動態路由是非常不切實際的，因為管理、維護成本以及是否支持等諸多問題。配置靜態路由就變得十分流行，但路由器(或者說默認網關default gateway)卻經常成為單點故障。VRRP的目的就是為了解決靜態路由單點故障問題，VRRP通過一競選(election)協議來動態的將路由任務交給LAN中虛擬路由器中的某台VRRP路由器。 3.VRRP 工作機制 在一個VRRP虛擬路由器中，有多台物理的VRRP路由器，但是這多台的物理的機器並不能同時工作，而是由一台稱為MASTER的負責路由工作，其它的都是BACKUP，MASTER並非一成不變，VRRP讓每個VRRP路由器參與競選，最終獲勝的就是MASTER。MASTER擁有一些特權，比如，擁有虛擬路由器的IP地址，我們的主機就是用這個IP地址作為靜態路由的。擁有特權的MASTER要負責轉發發送給網關地址的包和響應ARP請求。 VRRP通過競選協議來實現虛擬路由器的功能，所有的協議報文都是通過IP多播(multicast)包(多播地址224.0.0.18)形式發送的。虛擬路由器由VRID(范圍0-255)和一組IP地址組成，對外表現為一個周知的MAC地址。所以，在一個虛擬路由 器中，不管誰是MASTER，對外都是相同的MAC和IP(稱之為VIP)。客戶端主機並不需要因為MASTER的改變而修改自己的路由配置，對客戶端來說，這種主從的切換是透明的。 在一個虛擬路由器中，只有作為MASTER的VRRP路由器會一直發送VRRP通告信息(VRRPAdvertisement message)，BACKUP不會搶占MASTER，除非它的優先級(priority)更高。當MASTER不可用時(BACKUP收不到通告信息)， 多台BACKUP中優先級最高的這台會被搶占為MASTER。這種搶占是非常快速的(<1s)，以保證服務的連續性。由於安全性考慮，VRRP包使用了加密協議進行加密。 4.VRRP 工作流程 (1).初始化： 路由器啟動時，如果路由器的優先級是255(最高優先級，路由器擁有路由器地址)，要發送VRRP通告信息，並發送廣播ARP信息通告路由器IP地址對應的MAC地址為路由虛擬MAC，設置通告信息定時器准備定時發送VRRP通告信息，轉為MASTER狀態；否則進入BACKUP狀態，設置定時器檢查定時檢查是否收到MASTER的通告信息。 (2).Master 設置定時通告定時器； 用VRRP虛擬MAC地址響應路由器IP地址的ARP請求； 轉發目的MAC是VRRP虛擬MAC的數據包； 如果是虛擬路由器IP的擁有者，將接受目的地址是虛擬路由器IP的數據包，否則丟棄； 當收到shutdown的事件時刪除定時通告定時器，發送優先權級為0的通告包，轉初始化狀態； 如果定時通告定時器超時時，發送VRRP通告信息； 收到VRRP通告信息時，如果優先權為0，發送VRRP通告信息；否則判斷數據的優先級是否高於本機，或相等而且實際IP地址大於本地實際IP，設置定時通告定時器，復位主機超時定時器，轉BACKUP狀態；否則的話，丟棄該通告包； (3).Backup 設置主機超時定時器； 不能響應針對虛擬路由器IP的ARP請求信息； 丟棄所有目的MAC地址是虛擬路由器MAC地址的數據包； 不接受目的是虛擬路由器IP的所有數據包； 當收到shutdown的事件時刪除主機超時定時器，轉初始化狀態； 主機超時定時器超時的時候，發送VRRP通告信息，廣播ARP地址信息，轉MASTER狀態； 收到VRRP通告信息時，如果優先權為0，表示進入MASTER選舉；否則判斷數據的優先級是否高於本機，如果高的話承認MASTER有效，復位主機超時定時器；否則的話，丟棄該通告包； 5.ARP查詢處理 當內部主機通過ARP查詢虛擬路由器IP地址對應的MAC地址時，MASTER路由器回復的MAC地址為虛擬的VRRP的MAC地址，而不是實際網卡的 MAC地址，這樣在路由器切換時讓內網機器覺察不到；而在路由器重新啟動時，不能主動發送本機網卡的實際MAC地址。如果虛擬路由器開啟的ARP代理 (proxy_arp)功能，代理的ARP回應也回應VRRP虛擬MAC地址；好了VRRP的簡單講解就到這里，我們下來講解一下Keepalived的案例。 一、健康檢查方式 keepalived對后端realserver的健康檢查方式主要有以下幾種 TCP_CHECK：工作在第4層，keepalived向后端服務器發起一個tcp連接請求，如果后端服務器沒有響應或超時，那么這個后端將從服務器池中移除。 HTTP_GET：工作在第5層，向指定的URL執行http請求，將得到的結果用md5加密並與指定的md5值比較看是否匹配，不匹配則從服務器池中移除；此外還可以指定http返回碼來判斷檢測是否成功。HTTP_GET可以指定多個URL用於檢測，這個一台服務器有多個虛擬主機的情況下比較好用。 SSL_GET：跟上面的HTTP_GET相似，不同的只是用SSL連接 MISC_CHECK：用腳本來檢測，腳本如果帶有參數，需將腳本和參數放入雙引號內。腳本的返回值需為： 0） 檢測成功 1） 檢測失敗，將從服務器池中移除 2－255）檢測成功；如果有設置misc_dynamic，權重自動調整為 退出碼-2，如退出碼為200，權重自動調整為198=200-2。 SMTP_CHECK：用來檢測郵件服務的smtp的 二、相關配置： delay_loop 隔多長時間做一次健康檢測，單位為秒 connect_timeout 連接超時時間，單位為秒 nb_get_retry 檢測失敗后的重試次數，如果達到重試次數仍然失敗，將后端從服務器池中移除。 delay_before_retry 失敗重試的間隔時間，單位為秒 Keepalived健康檢查方式配置 HTTP_GET|SSL_GET HTTP_GET | SSL_GET { url { path /# HTTP/SSL 檢查的url 可以是多個 digest # HTTP/SSL 檢查后的摘要信息 用工具genhash生成 status_code 200# HTTP/SSL 檢查返回的狀態碼 } connect_port 80 # 連接端口 bindto connect_timeout 3 # 連接超時時間 nb_get_retry 3 # 重連次數 delay_before_retry 2 #連接間隔時間 } # END OF HTTP_GET|SSL_GET TCP健康檢查方式 TCP_CHECK { connect_timeout 5 #連接超時時間 nb_get_retry 3#重連次數 delay_before_retry 3 #重連間隔時間 connect_port 80 #健康檢查的端口 } # TCP_CHECK SMTP健康檢查方式 SMTP_CHECK { host { connect_ip connect_port # 默認檢查端口25 } connect_timeout retry delay_before_retry helo_name | # "請求命令參數，可選 } #SMTP_CHECK MISC MISC_CHECK { misc_path | # 外部程序或者腳本路徑 misc_timeout # 執行腳本的超時時間 misc_dynamic#如果設置了misc_dynamic,healthchecker程序的退出狀態碼會用來動態調整服務器的權重（weight）. #返回0：健康檢查OK，權重不被修改 #返回1：健康檢查失敗，權重設為0 #返回2-255：健康檢查OK，權重設置為：退出狀態碼-2，比如返回255，那么weight=255-2=253 } 工具genhash使用 [root@localhost bin]# ./genhash -h genhash v1.0.0 (18/11, 2002) Usage: ./genhash -s server-address -p port -u url ./genhash -S -s server-address -p port -u url ./genhash -h ./genhash -r Commands: Either long or short options are allowed. ./genhash --use-ssl-SUse SSL connection to remote server. ./genhash --server-sUse the specified remote server address. ./genhash --port-pUse the specified remote server port. ./genhash --url-uUse the specified remote server url. ./genhash --use-virtualhost -VUse the specified virtualhost in GET query. ./genhash --verbose-vUse verbose mode output. ./genhash --help-hDisplay this short inlined help screen. ./genhash --release-rDisplay the release number 工具產生結果如下： [root@localhost bin]# ./genhash -s10.7.11.12 -p 80 -u http://10.7.11 .40/index.html MD5SUM = b7bd8391367e4cf9e4e85263ce313ae8 配置如下： real_server 10.7.11.12 80 { weight 1 TCP_CHECK { connect_timeout 5 nb_get_retry 3 delay_before_retry 3 connect_port 80 } HTTP_GET { url { path / digest b7bd8391367e4cf9e4e85263ce313ae8 status_code 200 } #url { #path /mrtg/ #digest 9b3a0c85a887a256d6939da88aabd8cd #} connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } TCP健康檢查方式配置例子： real_server 192.168.191.130 80 { weight 3 inhibit_on_failure #在服務器健康檢查失效時，將其設為0 TCP_CHECK { connect_timeout 5 #連接超時時間 nb_get_retry 3#重連次數 delay_before_retry 3 #重連間隔時間 connect_port 80 #健康檢查的端口 } } SSL健康檢查方式同HTTP，例子如下： virtual_server 192.168.200.100 443 { delay_loop 6 lb_algo rr lb_kind NAT persistence_timeout 50 protocol TCP real_server 192.168.201.100 443 { weight 1 SSL_GET { url { path / digest ff20ad2481f97b1754ef3e12ecd3a9cc } url { path /mrtg/ digest 9b3a0c85a887a256d6939da88aabd8cd } connect_timeout 3 nb_get_retry 3 delay_before_retry 3 } } } SNMP方式例子： real_server 172.16.1.12 25 { weight 1 SMTP_CHECK { connect_timeout 10 retry 2 delay_before_retry 5 helo_name "foo.bar.com" host { connect_ip 172.16.1.12 connect_port 25 bindto 172.16.1.2 } host { connect_ip192.168.155.11 connect_port 25 bindto 192.168.155.2 } host { connect_ip64.233.167.100 connect_port 587 } } } MISC方式腳本帶參數例子： real_server 192.168.200.6 1358 { weight 1 MISC_CHECK { misc_path "/usr/local/bin/script.sh arg1 arg2" } } MISC方式腳本不帶參數例子： real_server 192.168.200.6 1358 { weight 1 MISC_CHECK { misc_path /usr/local/bin/script.sh !misc_dynamic } }