什么是keepalived呢？keepalived是實現高可用的一種輕量級的技術手段，主要用來防止單點故障(單點故障是指一旦某一點出現故障就會導致整個系統架構的不可用)的發生。
1. VRRP
VRRP是一種容錯性協議，它是通過將多台設備虛擬化成一台設備，如果其中一台設備出現故障，那么另一台設備可以迅速接替其工作，已保證通訊的可靠性和連續性。
1.1. 工作原理
在企業網當中，PC一般是需要使用"網關"來與外部網絡進行通訊，這樣如果網關出現了故障那么整一個子網的對外通訊都會被切斷，VRRP的出現就能把這個問題很好地解決了，VRRP可以通過把多台設備（路由器、交換機、防火牆等）虛擬化成一台設備，然后通過配置虛擬IP地址作為網關就能實現對網關的備份（這虛擬IP地址是代表整個VRRP組內的所有設備），當其中一台設備出現故障之后，VRRP組內其他設備會通過某些機制來接替故障設備的工作。
如上圖所示，SW7和SW8若配置了VRRP 那么SW7和SW8就是一個整體，其中一台出現故障都不會對業務造成很大的影響。
1.1.1. VRRP概念
虛擬設備：由一個"主（Master）"設備和多個"備（Backup）"設備組成的一個虛擬網關。
主設備（Master）：負責轉發數據報文和周期性向備設備發送VRRP協議報文。
備設備（Backup）：不負責轉發數據報文，在Master設備發生故障的時候會通過選舉形式成為新的Master設備，該角色會接收來自Master設備的VRRP報文並加以分析。
VRID：用來表示一個VRRP組。
虛擬IP：配置在虛擬設備上的虛擬IP地址，一個虛擬設備可以擁有一個或者多個虛擬IP地址。
IP地址擁有者：分配給虛擬設備的虛擬IP的真實擁有者（例如：分配個虛擬路由的IP為192.168.1.1，但是這個IP已經分配給物理接口G0/0/1這個接口那么這個接口就是"IP擁有者"），IP擁有者會直接跳過選舉成為Master，並且是不可搶占的。
虛擬MAC地址：由虛擬設備生成的虛擬MAC地址，每一個虛擬設備都會自動生成一個虛擬MAC地址，這個MAC地址是用於虛擬設備處理ARP報文的。
優先級：用於表示物理設備的優先級，這個參數用於Master的選舉，取值范圍是1-254，這個有優先級有兩個比較特殊的值，分別是0和255，優先級0是由原來Master設備發送的，這個優先級是聲明此設備不再參與VRRP組。優先級為255的是IP擁有者的優先級，擁有這個優先級會直接成為Master。（優先級數值越低優先級則越高）
搶占模式：當Backup 設備接收到的VRRP報文通過分析得出當前Master設備的優先級低於Backup設備，則Backup設備會切換為Master設備。
1.1.2. VRRP狀態機
VRRP一共有三種狀態，分別是：初始狀態（Initialize）、活動狀態（Master）、備份狀態（Backup）。
初始狀態：在這個狀態下VRRP是不可用的，在這個狀態下的設備是不會處理VRRP報文的，通常是剛配置VRRP時和檢測到故障是會是這個狀態。
活動狀態：處於Master狀態下的設備將會做下列工作：
- 定期發送VRRP報文。
- 以虛擬MAC地址響應對虛擬IP地址的ARP請求。
- 轉發目的MAC地址為虛擬MAC地址的IP報文。
- 如果它是這個虛擬IP地址的擁有者，則接收目的IP地址為這個虛擬IP地址的IP報文。否則，丟棄這個IP報文。
- 如果收到比自己優先級大的報文則轉為Backup狀態。
- 如果收到優先級和自己相同的報文，並且發送端的IP地址比自己的IP地址大，則轉為Backup狀態。
- 當接收到接口的Shutdown事件時，轉為Initialize。
備份狀態：處於Backup狀態下的設備，它將會做下列工作：
- 接收Master發送的VRRP報文，判斷Master的狀態是否正常。
- 對虛擬IP地址的ARP請求，不做響應。
- 丟棄目的MAC地址為虛擬MAC地址的IP報文。
- 丟棄目的IP地址為虛擬IP地址的IP報文。
- Backup狀態下如果收到比自己優先級小的報文時，丟棄報文，立即切換為Master（僅在搶占模式下生效）。
- 如果收到優先級和自己相同或者比自己高的報文，則重置定時器，不進一步比較IP地址。
- 當接收到接口的Shutdown事件時，轉為Initialize。
- 如果MASTER_DOWN_INTERVAL定時器超時，則切換為Master。
三種狀態機的關系如下圖：
1.2. 工作流程
VRRP備份組會通過優先級選舉出Master，Master會使用虛擬MAC發送ARP報文，使與Master連接的主機或者客戶端建立與虛擬MAC對應的ARP映射表，同時Master會周期性發布VRRP報文向所有Backup通告其配置信息與工作狀態。
如果當前Master出現故障，Backup設備將會在MASTER_DOWN_INTERVAL定時器超時或者其他聯動技術檢測到Master出現故障時則會根據Backup組內的成員的優先級選舉出新的Master，如果Backup只有一台設備則直接成為Master。
新的Master使用虛擬MAC發送ARP報文，使連接在當前VRRP組內的客戶端或者設備刷新其ARP映射表。
如果原來的Master從故障中恢復過來，如果其優先級為255則會直接切換到Master，若不是則會恢復到Backup狀態，如果當前為搶占模式，當原Master接收到新Master的VRRP報文發現其優先級高於原Master則原Master會直接成為Master。如果處於非搶占模式，則原Master會在新Master出現故障時通過選舉等方式成為Master。
1.2.1. VRRP選舉
VRRP通過優先級來確定設備成為Master或者Backup，優先級取值越低，則優先級越高。
初始創建的VRRP設備都處於初始狀態，在該狀態下，如果設備的優先級為255，則直接成為Master並且跳過接下來的選舉，若不是則會切換到Backup狀態，然后會等待MASTER_DOWN_INTERVAL超時后成為Master。
首先切換到Master的設備會通過VRRP報文獲取其他設備的優先級，然后通過以下規則進行選舉：
- 如果Backup設備接收到來自Master的VRRP報文，發現其優先級數值低於自身，則繼續處於Backup狀態。
- 如果Backup設備接收到來自Master的VRRP報文，發現其優先級數值高於自身，則當前Backup設備會切換到Master，而原Master設備會切換到Backup。如果在非搶占模式下，Backup設備仍然會處於Backup狀態。
- 如果同時有多個設備切換到Master，則會互相通過VRRP報文確定其優先級，優先級高的則成為Master，若優先級一樣，則對比IP地址，IP地址大的則成為Master。
1.2.2. VRRP狀態通告
Master設備會周期性發送VRRP報文，通告其配置信息與工作狀態，Backup則會接收並處理VRRP報文確定Master設備的工作狀態。
當Master主動退出VRRP組是，會發送優先級為0的報文通知所有的Backup設備，Backup設備接收到之后會直接切換到Master狀態，若Backup組內有多台設備則通過上述選舉選出新的Master設備，而不需要等待MASTER_DOWN_INTERVAL超時后再進行切換或者選舉。
當Master設備由於故障不能發送VRRP報文，所有的Backup設備都需要等待MASTER_DOWN_INTERVAL 超時后才會認為Master設備出現故障，之后才切換到Master。
1.2.3. VRRP兩種模式
1、 主備備份模式
主備備份模式就是只由Master設備負責轉發數據，而Backup設備則處於待機備份模式不參與數據轉發，當Master設備出現故障時才會切換到Master進行數據轉發。
參照下圖，正常情況下只有SW1轉發數據，而SW2則處於待機狀態，SW1會周期發送VRRP報文告知SW2自身的配置信息和工作狀態，如果SW1發生故障，則SW2會自動切換到到Master繼續進行數據轉發等。
而當SW1恢復之后，若當前為搶占模式，若SW1的優先級為255那么SW1會直接成為Master否則會先切換到Backup然后再切換到Master。
主備模式
2、 負載分擔模式
上述的主備備份模式，若SW1一直正常工作，那么SW2則長期處於待機狀態，顯然這種做法比較浪費，所以一般會采用負載分擔模式，負載分到模式會是SW2都處於工作狀態。
參照下圖，負載分擔模式是創建兩個VRRP組分別為A組和B組，A組的Master為SW1，Backup為SW2，而B組的Master為SW2，Backup為SW1，通過創建多個擁有不同虛擬IP的VRRP組，為不同的VLAN指定網關實現負載分擔。
負載分擔模式
參照上圖，在VLAN10當中Master是SW1，Backup為SW2，兩台交換機都分別創建vlan10和vlan20 並且分配好IP地址，正常情況下vlan10的客戶端會通過SW1訪問R1，vlan20的客戶端會通過SW2訪問R1這樣就實現了負載分擔，如果SW1出現故障，那么SW2會成為vlan10的Master（同時也是vlan20的Master），接替SW1的工作，而vlan10的客戶端也會通過SW2訪問R1，而SW2故障則同理。
2. Keepalived
2.1. 配置說明
keepalived的配置位於/etc/keepalived/keepalived.conf，配置文件格式包含多個必填/可選的配置段，部分重要配置含義如下：
#全局定義塊，定義主從切換時通知郵件的SMTP配置
global_defs {
#郵件告警列表
notification_email {
897807300@qq.com
}
#指定發件人
notification_email_from keepalived@localhost
#指定smtp服務器地址
smtp_server 127.0.0.1
#指定smtp連接超時時間
smtp_connect_timeout 30
#負載均衡標識，在局域網內應該是唯一的
router_id waf_lvs_master_01
}
#作用：添加一個周期性執行的腳本。腳本的退出狀態碼會被調用它的所有的VRRP Instance記錄。
#注意：至少有一個VRRP實例調用它並且優先級不能為0.優先級范圍是1-254.
vrrp_script chk_nginx
{
script "/home/check.sh"
#重試次數
interval 3
#范圍[-254到254]
weight -50
}
vrrp_instance VI_1 {
#實例角色。分為一個MASTER和一(多)個BACKUP。
state BACKUP
#綁定VIP的網絡接口
interface eth0
#標識虛擬路由的ID號，兩個節點設置必須一樣，有效范圍為0-255
virtual_router_id 230
#節點優先級，值范圍0~254，MASTER>BACKUP
priority 90
#組播信息或者VRRP協議發送時間間隔，兩個節點必須設置一樣，默認為1秒
advert_int 5
#設置驗證信息，兩個節點必須一致
authentication {
auth_type PASS
auth_pass 1111
}
#虛擬IP（VIP），兩個節點設置必須一致，可以設置多個
virtual_ipaddress {
172.26.130.184
}
#存活狀態檢測腳本
track_script {
chk_nginx
}
}
virtual_server 172.26.130.184 80 {
#健康檢查的時間間隔
delay_loop 60
#rr|wrr|lc|wlc|lblc|sh|dh：LVS調度算法
lb_algo rr
#LVS模式（NAT|DR|TUN）
lb_kind DR
nat_mask 255.255.255.0
#持久化超時時間，單位是秒。默認是6分鍾
persistence_timeout 50
#4層協議TCP|UDP|SCTP
protocol TCP
real_server 172.26.130.109 80 {
#給服務器指定權重
weight 50
TCP_CHECK { # 通過TcpCheck判斷RealServer的健康狀態，其他SMTP_CHECK支持SMTP和DNS_CHECK支持DNS
connect_timeout 10 # 連接超時時間
nb_get_retry 3 # 重連次數
delay_before_retry 3 # 重連時間間隔
connect_port 80 # 檢測端口
}
}
real_server 172.26.130.126 80 {
weight 50
TCP_CHECK { # 通過TcpCheck判斷RealServer的健康狀態
connect_timeout 10 # 連接超時時間
nb_get_retry 3 # 重連次數
delay_before_retry 3 # 重連時間間隔
connect_port 80 # 檢測端口
}
}
}
2.2. vrrp_script詳解
1、vrrp_script能做什么
keepalived只能做到對網絡故障和keepalived本身的監控，即當出現網絡故障或者keepalived本身出現問題時，進行切換。但是這些還不夠，我們還需要監控keepalived所在服務器上的其他業務進程，比如說nginx，keepalived+nginx實現nginx的負載均衡高可用，如果nginx異常，僅僅keepalived保持正常，是無法完成系統的正常工作的，因此需要根據業務進程的運行狀態決定是否需要進行主備切換。這個時候，我們可以通過編寫腳本對業務進程進行檢測監控。
例如：編寫個簡單腳本查看haproxy進程是否存活
#!/bin/bash
count = `ps aux | grep -v grep | grep haproxy | wc -l`
if [ $count > 0 ]; then
exit 0
else
exit 1
fi
在keepalived的配置文件中增加相應配置項
vrrp_script checkhaproxy
{
script "/home/check.sh"
interval 3
weight -20
}
vrrp_instance test
{
...
track_script
{
checkhaproxy
}
...
}
2、優先級更新策略
keepalived會定時執行腳本並對腳本執行的結果進行分析，動態調整vrrp_instance的優先級。
如果腳本執行結果為0，並且weight配置的值大於0，則優先級相應的增加 ;如果腳本執行結果非0，並且weight配置的值小於0，則優先級相應的減少
其他情況，維持原本配置的優先級，即配置文件中priority對應的值。
這里需要注意的是：
1） 優先級不會不斷的提高或者降低
2） 可以編寫多個檢測腳本並為每個檢測腳本設置不同的weight
3） 不管提高優先級還是降低優先級，最終優先級的范圍是在[1,254]，不會出現優先級小於等於0或者優先級大於等於255的情況
這樣可以做到利用腳本檢測業務進程的狀態，並動態調整優先級從而實現主備切換。
3、vrrp_script中節點權重改變算法
在Keepalived集群中，其實並沒有嚴格意義上的主、備節點，雖然可以在Keepalived配置文件中設置“state”選項為“MASTER”狀態，但是這並不意味着此節點一直就是Master角色。控制節點角色的是Keepalived配置文件中的“priority”值，但並它並不控制所有節點的角色，另一個能改變節點角色的是在vrrp_script模塊中設置的“weight”值，這兩個選項對應的都是一個整數值，其中“weight”值可以是個負整數，一個節點在集群中的角色就是通過這兩個值的大小決定的。
3.1、不設置weight
在vrrp_script模塊中，如果不設置“weight”選項值，那么集群優先級的選擇將由Keepalived配置文件中的“priority”值決定，而在需要對集群中優先級進行靈活控制時，可以通過在vrrp_script模塊中設置“weight”值來實現。
3.2、設置weight
vrrp_script 里的script返回值為0時認為檢測成功，其它值都會當成檢測失敗；weight 為正時，腳本檢測成功時此weight會加到priority上，檢測失敗時不加.
主失敗:
主 priority < 從 priority + weight 時會切換。
主成功：
主 priority + weight > 從 priority + weight 時，主依然為主
weight 為負時，腳本檢測成功時此weight不影響priority，檢測失敗時priority – abs(weight)
主失敗:
主 priority – abs(weight) < 從priority 時會切換主從
主成功:
主 priority > 從priority 主依然為主
4、配置不搶占nopreempt帶來的問題
例如：A,B兩台keepalived
A的配置大概為：
vrrp_script checkhaproxy
{
script "/etc/check.sh"
interval 3
weight -20
}
vrrp_instance test
{
....
state backup
priority 80
nopreempt
track_script
{
checkhaproxy
}
....
}
B的配置大概為：
vrrp_script checkhaproxy
{
script "/etc/check.sh"
interval 3
weight -20
}
vrrp_instance test
{
....
state backup
priority 70
track_script
{
checkhaproxy
}
....
}
A,B同時啟動后，由於A的優先級較高，因此通過選舉會成為master。當A上的業務進程出現問題時，優先級會降低到60。此時B收到優先級比自己低的vrrp廣播包時，將切換為master狀態。那么當B上的業務出現問題時，優先級降低到50，盡管A的優先級比B的要高，但是由於設置了nopreempt，A不會再搶占成為master狀態。
所以，可以在檢測腳本中增加殺掉keepalived進程（或者停用keepalived服務）的方式，做到業務進程出現問題時完成主備切換。