一、簡介
keepalived是一個基於VRRP協議來實現的WEB服務高可用方案，可以利用其來避免單點故障，用於web服務器的健康狀態檢測，如果有一臺web服務器工作出現故障，keepalived將檢測到，並將有故障的web服務器從系統中下線，等待服務器故障排除之後，將服務器重新添加至系統中。
要想學習keepalived，必須先了解VRRP協議，keepalived就是在VRRP協議的基礎之上實現的。
二、VRRP協議簡介
1.VRRP協議
虛擬路由冗餘協議 VRRP（Virtual Router Redundancy Protocol）通過把幾臺路由設備聯合組成一臺虛擬的路由設備，使用一定的機制保證當主機的下一跳路由器出現故障時，及時將業務切換到備份路由器，從而保持業務的連續性和可靠性。
2.VRRP協議備份示意圖：
3.VRRP協議工作過程：
VRRP 備份組中的交換機根據優先級選舉出 Master。Master交換機通過發送ARP 報文，將虛擬MAC地址通知給與它連接的設備或者主機，從而承擔報文轉發任務。
Master 交換機週期性向備份組內所有 Backup 交換機發送 VRRP 通告報文，以公佈其配 置信息（優先級等）和工作狀況。
如果 Master 交換機出現故障，VRRP 備份組中的 Backup 交換機將根據優先級重新選舉 新的 Master。
VRRP 備份組狀態切換時，Master 交換機由一臺設備切換爲另外一臺設備，新的Master 交換機會立即發送攜帶虛擬路由器的虛擬MAC地址和虛擬IP（Virtual IP以下簡稱VIP）地址信息的ARP報文，刷新與它連接的主機或設備中的MAC表項，從而把用戶流量引到新的 Master 交換機上來，整個過程對用戶完全透明。
三、keepalived組件
Core compeonentd（核心組件）：
Checkers：健康狀態檢測
Vrrp Stack：虛擬路由棧
IPVS wrapper：ipvs規則添加
WatchDog：監控器
Scheduler - I/O Multiplexer : IO複用器
Memory Management：內存管理
Control Plane Configuration file parser：配置文件分析器
四、keepalived的安裝
1.實驗環境（兩臺CentOS 7主機）
(1)兩個節點時間同步；
分別在兩臺主機上執行
# crontab -e */5* * * * /usr/sbin/ntpdate 172.16.0.1 &> /dev/null # 設定爲每5分鐘同步一次
(2) 確保iptables和selinux 不會成爲障礙；
(3) 各節點之間可通過主機名互相通信；（可選）
節點的名稱設定與hosts文件中解析的主機名都要保持一致；
#uname -n 獲得的主機，與解析的主機名要相同
(4)各節點之間基於密鑰認證的方式通過ssh互信通信；（可選）
2.安裝keepalived
(1) 源碼安裝
[root@node1 ~]# cd /usr/local/src [root@node1 ~]# wget http://www.keepalived.org/software/keepalived-1.2.19.tar.gz [root@node1 ~]# tar zxf keepalived-1.2.6.tar.gz [root@node1 ~]# cd keepalived-1.2.6 [root@node1 ~]# ./configure --prefix=/usr/local/keepalived [root@node1 ~]# make & make install
(2) rpm包安裝（在CentOS 7系統的epel源提供了rpm包，以下實驗爲rpm包安裝）
[root@node1 ~]# yum install -y keepalive
五、配置文件
1.keepalived的程序環境：
主配置文件：/etc/keepalived/keepalived.conf
Unit file: /usr/lib/systemd/system/keepalived.service2.keepalived的配置文件：
GLOBAL CONFIGURATION：全局配置
global_defs # Block id
{
...
}
VRRPD CONFIGURATION：配置vrrp實例
vrrp instance：虛擬路由器
vrrp_instance NAME {
...
}
vrrp synchronization group
vrrp_sync_group NAME {
...
}
LVS CONFIGURATION：ipvs的相關配置
集羣服務，服務內的RS；
(1)全局配置：
global_defs {
notification_email {
...
}：收件人郵箱地址
notification_email_from：發件人郵箱地址
smtp_server：郵件發送服務器IP；
smtp_connect_timeout：郵件服務器建立連接的超時時長；
router_id LVS_DEVEL：物理節點的標識符；建立使用主機名；
vrrp_mcast_group4：IPV4多播地址，默認224.0.0.18；
(2) VRRP實例配置：
vrrp_instance NAME {
...
}
常用配置：
state MASTER|BACKUP：在當前VRRP實例中此節點的初始狀態；
interface IFACE_NAME：vrrp用於綁定vip的接口；
virtual_router_id #：當前VRRP實例的VRID，可用範圍爲0-255；
priority #：當前節點的優先級，可用範圍0-255；
advert_int 1：通告時間間隔；
authentication { # Authentication block
auth_type PASS
auth_pass 1234
}
virtual_ipaddress {...
}
六、配置實例詳解
1.主備模型
虛擬IP在屬於主節點，另一個節點作爲備用節點存在。當主節點不可用時，備用節點接管虛擬IP，提供正常服務。
(1) 主備模型拓撲圖
(2)編輯配置文件
在node1上編輯配置文件
[root@node1 ~]# vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs{ #全局配置段
notification_email {
[email protected]
} #收件人郵箱
notification_email_from [email protected] #發件人郵箱
smtp_server 127.0.0.1 #郵件發送服務器IP，此處設置爲本地
smtp_connect_timeout 30 #郵件服務器建立連接的超時時長；
router_id node1 #物理節點的標識符，此處使用主機名；
vrrp_mcast_group4 224.100.0.1 #IPV4多播地址，此處爲默認；
}
vrrp_instanceVI_1 {
state MASTER #節點的初始狀態，主節點爲MASTER；
interface eno16777736 ##綁定虛擬IP的網絡接口
virtual_router_id 80 #VRRP組名，指明各個節點屬於同一VRRP組，主從一致；
priority 100 #當前節點的優先級，可用範圍0-255；
advert_int 1 #通告時間間隔，此處設置爲1s，主從節點一致；
authentication { #主從服務器驗證方式
auth_type PASS
auth_pass 5QbqkQJj
}
virtual_ipaddress { #虛擬IP,格式爲ADDR/NETMASK
172.16.22.5/16
}
}將此文件複製至node2主機，並修改；
[root@node2 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs{ notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node2 #修改標識符爲node2； vrrp_mcast_group4 224.100.0.1 } vrrp_instanceVI_1 { state BACKUP ##節點的初始狀態，主節點爲MASTER； interface eno16777736 virtual_router_id 80 priority 99 #備用節點的優先級應該比主節點低； advert_int 1 authentication { auth_type PASS auth_pass 5QbqkQJj } virtual_ipaddress { 172.16.22.5/16 } }(3) 驗證並測試
啓動node1，node2上配置好的keepalived服務，查看node1是否有VIP：
關閉node1的keepalived服務，查看日誌，顯示如下：
此時node1停止keepalived服務，發送通告，移除地址；查看node2已配置VIP，成爲主節點；
2.雙主模型
主備模型存在一個缺點：始終只有主節點處於工作狀態，備用節點一直空閒，造成資源浪費。雙主模式就是每個節點必須有兩個VIP, 分別綁定至兩個節點上。作爲第一個VIP的主節點，並同時作爲另外一個VIP的備用節點。兩節點互相交叉備份，當一個節點發生故障，兩個VIP將自動綁定至另外一個節點。
(1) 雙主模型拓撲圖
(2) 在node1上編輯配置文件
[root@node1 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs{ notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.100.0.1 } vrrp_instanceVI_1 { state MASTER #對應vrrp_instanceVI_1組中的主節點 interface eno16777736 virtual_router_id 80 #本機兩個vrrp_instance組的此值不能相同，對應備用節點的此值必須相同 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 5QbqkQJj } virtual_ipaddress { 172.16.22.5/16 } } vrrp_instanceVI_2 { state BACKUP #對應vrrp_instanceVI_2組中的備用節點 interface eno16777736 virtual_router_id 81 #本機兩個vrrp_instance組的此值不能相同，對應主節點的值必須相同 priority 99 #優先級比對應主節點小1 advert_int 1 authentication { auth_type PASS auth_pass c2Wyk1Dz } virtual_ipaddress { 172.16.22.6/16 } }將配置文件複製至node2，修改爲；
[root@node1 ~]# vim /etc/keepalived/keepalived.conf ! Configuration File for keepalived global_defs{ notification_email { [email protected] } notification_email_from [email protected] smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id node1 vrrp_mcast_group4 224.100.0.1 } vrrp_instanceVI_1 { state BACKUP #對應vrrp_instanceVI_1組中的備用節點 interface eno16777736 virtual_router_id 80 #對應vrrp_instanceVI_1組的節點值 priority 99 #優先級比對應主節點小1 advert_int 1 authentication { auth_type PASS auth_pass 5QbqkQJj } virtual_ipaddress { 172.16.22.5/16 } } vrrp_instanceVI_2 { state MASTER #對應vrrp_instanceVI_2組中的主節點 interface eno16777736 virtual_router_id 81 #對應vrrp_instanceVI_2組的節點值 priority 100 #優先級比對應主節點大1 advert_int 1 authentication { auth_type PASS auth_pass c2Wyk1Dz } virtual_ipaddress { 172.16.22.6/16 } }(3) 驗證並測試
啓動node1和node2上的keepalived服務，分別查看兩節點的VIP；
手動停止node1的keepalived服務，node1的VIP將漂移至node2；
同樣，停止node2上的keepalived服務，node2的VIP將漂移至node1；此處將不再進行測試，請各位讀者自行測試；
[Warning]: 上面示例中的主備模型存在嚴重問題，這種方式存在腦裂的可能，即兩個節點實際都處於正常工作狀態，但是無法接收到彼此的組播通知，這時兩個節點均強行綁定虛擬IP，導致不可預料的後果。
在實際的生產環境中可能會存在上圖中的問題，node1爲備用節點，node2爲主節點，node2網絡發生故障，node1收不到node2的組播信息，此時node1搶佔node2的VIP，node1和node2同時擁有VIP將會導致腦裂(split-brain)。此時就需要我們設置仲裁機制。例如設置網關，當心跳線完全斷開時，2個節點都各自ping一下網關，不通則表明斷點就出在本節點，不僅“心跳”、還兼對外“服務”的本節點網絡鏈路斷了，即使啓動（或繼續）應用服務也沒有用了，那就主動放棄競爭，讓能夠ping通網關的啓動服務。