1. Keepalived介紹
Keepalived是一個基於VRRP協議來實現的服務高可用方案，可以利用其來避免IP單點故障，類似的工具還有heartbeat、corosync、pacemaker。但是它一般不會單獨出現，而是與其它負載均衡技術（如lvs、haproxy、nginx）一起工作來達到集羣的高可用。
1.1 VRRP協議
VRRP全稱 Virtual Router Redundancy Protocol，即 虛擬路由冗餘協議。可以認爲它是實現路由器高可用的容錯協議，即將N臺提供相同功能的路由器組成一個路由器組(Router Group)，這個組裏面有一個master和多個backup，但在外界看來就像一臺一樣，構成虛擬路由器，擁有一個虛擬IP（vip，也就是路由器所在局域網內其他機器的默認路由），佔有這個IP的master實際負責ARP相應和轉發IP數據包，組中的其它路由器作爲備份的角色處於待命狀態。master會發組播消息，當backup在超時時間內收不到vrrp包時就認爲master宕掉了，這時就需要根據VRRP的優先級來選舉一個backup當master，保證路由器的高可用。
在VRRP協議實現裏，虛擬路由器使用 00-00-5E-00-01-XX 作爲虛擬MAC地址，XX就是唯一的 VRID （Virtual Router IDentifier），這個地址同一時間只有一個物理路由器佔用。在虛擬路由器裏面的物理路由器組裏面通過多播IP地址 224.0.0.18 來定時發送通告消息。每個Router都有一個 1-255 之間的優先級別，級別最高的（highest priority）將成爲主控（master）路由器。通過降低master的優先權可以讓處於backup狀態的路由器搶佔（pro-empt）主路由器的狀態，兩個backup優先級相同的IP地址較大者爲master，接管虛擬IP。
與heartbeat/corosync等比較
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是最佳組合。
1.2 Keepalived 總體介紹
keepalive是由一個主進程(Control Plane) , 生成兩個子進程(Checkers & VRRP Stack)
VRRP Stack : 是整個keepalive功能實現的核心子進程 ;
Checkers : 主要用於檢測real server的健康狀態 , 可以基於TCP Check , http_get , https_get , misc_get等多種方法;
除了上述的兩個重要的子進程 , 還有其他輔助組件 :
控制組件 : 主進程 (Control Plane) , 主進程除了生成兩個子進程工作外 , 其本身也是配置文件分析器 ;
ipvs wrapper : 起初keepalive 是爲了ipvs而生 , 所以 ipvs wrapper 是用於生成ipvs規則的工具(此處不用安裝ipvsadm也能生成ipvs規則)
watch dog : 負責替主進程檢測兩個子進程 ( Checkers 和 VRRP Stack ) 的健康狀態
1.3 HA Cluster的配置前提
(1) 各節點時間必須同步 ; (可使用ntp , chrony 命令 , 與時鐘服務器進行時間同步 , 時間可以不是國際時間等實際時間 , 但各HA Cluster的時間必須一樣 )
(2) 確保iptables 及selinux 不會成爲阻礙 ;
(3) 各節點之間可以通過主機名互相通信 ( 對KA 並非必須 ) ;
(4) 各節點之間的root 用戶基於密鑰認證的ssh互相通信 ;
==========================================================
2. keepalived實現LA Cluster高可用
2.1 安裝
~]# yum install -y keepalived
~]# keepalived -v
Keepalived v1.2.13 (11/20,2015)
2.2 編輯配置文件 /etc/keepalived/keepalived.conf
首先需要說明一下keepalived.conf的配置語法
配置虛擬路由器：
vrrp_instance <STRING> {
....
}
專用參數：
state MASTER|BACKUP：當前節點在此虛擬路由器上的初始狀態；只能有一個是MASTER，餘下的都應該爲BACKUP；
interface IFACE_NAME：綁定爲當前虛擬路由器使用的物理接口；
virtual_router_id VRID：當前虛擬路由器的惟一標識，範圍是0-255；
priority 100：當前主機在此虛擬路徑器中的優先級；範圍1-254；
advert_int 1：vrrp通告的時間間隔；
authentication {
auth_type AH|PASS
auth_pass <PASSWORD>
}
virtual_ipaddress {
<IPADDR>/<MASK> brd <IPADDR> dev <STRING> scope <SCOPE> label <LABEL>
192.168.200.17/24 dev eth1
192.168.200.18/24 dev eth2 label eth2:1
}
-track_interface {
eth0
eth1
...
}
配置要監控的網絡接口，一旦接口出現故障，則轉爲FAULT狀態；
nopreempt：定義工作模式爲非搶佔模式；
preempt_delay 300：搶佔式模式下，節點上線後觸發新選舉操作的延遲時長；
定義通知腳本：
notify_master <STRING>|<QUOTED-STRING>：當前節點成爲主節點時觸發的腳本；
notify_backup <STRING>|<QUOTED-STRING>：當前節點轉爲備節點時觸發的腳本；
notify_fault <STRING>|<QUOTED-STRING>：當前節點轉爲“失敗”狀態時觸發的腳本；
notify <STRING>|<QUOTED-STRING>：通用格式的通知觸發機制，一個腳本可完成以上三種狀態的轉換時的通知；
虛擬服務器：
配置參數：
virtual_server IP port |
virtual_server fwmark int
{
...
real_server {
...
}
...
}
常用參數：
delay_loop <INT>：服務輪詢的時間間隔；
lb_algo rr|wrr|lc|wlc|lblc|sh|dh：定義調度方法；
lb_kind NAT|DR|TUN：集羣的類型；
persistence_timeout <INT>：持久連接時長；
protocol TCP：服務協議，僅支持TCP；
sorry_server <IPADDR> <PORT>：備用服務器地址；
real_server <IPADDR> <PORT> {
weight <INT>
notify_up <STRING>|<QUOTED-STRING>
notify_down <STRING>|<QUOTED-STRING>
HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK { ... }：定義當前主機的健康狀態檢測方法；
}
HTTP_GET|SSL_GET(需要定義在real server配置段中) {
url {
path <URL_PATH>：定義要監控的URL；
status_code <INT>：判斷上述檢測機制爲健康狀態的響應碼；
digest <STRING>：判斷上述檢測機制爲健康狀態的響應的內容的校驗碼；
}
nb_get_retry <INT>：重試次數；
delay_before_retry <INT>：重試之前的延遲時長；
connect_ip <IP ADDRESS>：向當前RS的哪個IP地址發起健康狀態檢測請求
connect_port <PORT>：向當前RS的哪個PORT發起健康狀態檢測請求
bindto <IP ADDRESS>：發出健康狀態檢測請求時使用的源地址；
bind_port <PORT>：發出健康狀態檢測請求時使用的源端口；
connect_timeout <INTEGER>：連接請求的超時時長；
}
TCP_CHECK (需要定義在real server配置段中) {
connect_ip <IP ADDRESS>：向當前RS的哪個IP地址發起健康狀態檢測請求
connect_port <PORT>：向當前RS的哪個PORT發起健康狀態檢測請求
bindto <IP ADDRESS>：發出健康狀態檢測請求時使用的源地址；
bind_port <PORT>：發出健康狀態檢測請求時使用的源端口；
connect_timeout <INTEGER>：連接請求的超時時長；
}
在第一臺director配置keepalived.conf , 第一個vrrp中state爲master , 第二個vrrp中state爲backup , 以達到互爲主備狀態
將配置文件複製給第二臺 , 當然state , 以及 priority 中的值需要調整過來 ;
兩邊服務均啓動
第一臺director日誌 , 如下圖 :
從日誌文件中可以看出 , 進程會先讀取配置文件 , 人後調整狀態爲master , 繼而發送arp廣播
第二臺director日誌 :
從日誌可看出 , 讀取配置文件 , 由於檢測到從組播地址中獲取到優先級比它高的心跳信息 , 所以status轉爲BACKUP
回看director no:1 的 IP 地址可知道 (使用命令 ip a l 或者 ifconfig )
vip已按照在配置文件所設定的進行配置了
2.3 編寫通知腳本,並將通知腳本添加到vrrp配置段中 :
編寫通知腳本 , 當vrrp發生變化時 , 以郵件方式通知管理人員(在實際生產環境 , contact可填寫實際的郵箱地址)
通知腳本直接添加在vrrp定義配置文中
當運行命令停止或者啓動keepalived.service時 , 都會觸發腳本 , 通知管理員
2.4 添加real server
準備兩real server (web1 : 10.1.252.3 ; web2 : 10.1.35.11 ) , 分別安裝httpd已作web應用 ,兩web服務上的頁面分別標編輯不同內容 , 以便檢測測試效果
編輯keepalived.conf文件 , 添加real server配置段
real server 要事前設置好vip等配置 , 以及限制arp廣播及禁止arp響應(特別重要)
配置好則再次啓動( 注意keepalived.service 不支持 reloa , 必須先stop 然後再start ,以達到重啓服務來再次讀取配置文件 )
安裝ipvsadm來查看ipvs規則生成
~]# yum install -y ipvsadm
~]# ipvsadm -Ln
在客戶機檢測調度效果
關閉第一臺director的keepalived.service , 第二臺direc 便會檢測不到第一臺director的keepalived.service的心跳信息 , 會立即將資源搶佔過來 :
但是web服務絲毫不受影響
而且兩臺director也會受到郵件通知
2.5 添加腳本 , 監控director
在配置文件中 , 腳本定義以及調用腳本的語法 ( 切記 : 使用腳本的順序爲 : 先定義 , 後使用 )
vrrp_script <SCRIPT_NAME> {
script ""
interval INT
weight -INT
}
track_script {
SCRIPT_NAME_1
SCRIPT_NAME_2
...
}
腳本的意思爲 :
每隔1秒鐘(interval 1) , 檢測 /etc/keepalived/down 文件是否存在 , 存在退出碼爲1 , 且權重值減5(weight -5) ; 否則正常退出
實例 :
當touch down 文件的時候 , 權重值減5 , 比backup的權重值要小 , 也因爲之前已經定義了notify_backup通知機制 , 會立即收到郵件通知 , 而且ip也發生了轉移
將down文件刪除後 , 權重值恢復 , 資源回搶 , 可實現無需stop 後又 start 將服務進行上下線 ;
最後在vrrp_instance 實例中調用腳本 ; 日常維護工作量的大小 , 有時候取決於腳本的強大與否 ;