Keepalived高可用切換過程

IT那活兒發(fā)布于2023-01-11 13:19 / 2036人閱讀

Keepalived高可用切換過程

點擊上方“IT那活兒”公眾號，關(guān)注后了解更多內(nèi)容，不管IT什么活兒，干就完了?。?！

一

keepalived簡介

Keepalived對于運維人員來說是一款熟悉的高可用工具，在很多沒有原生實現(xiàn)分布式高可用的中間件和數(shù)據(jù)庫中都得到了廣泛的使用，例如keepalived+nginx實現(xiàn)對nginx的高可用，keepalived+MySQL實現(xiàn)對MySQL的高可用。

在各種分布式集群通過多副本多節(jié)點方式或者微服務(wù)的服務(wù)發(fā)現(xiàn)機制實現(xiàn)高可用大行其道的今天，keepalived實現(xiàn)高可用的方式較為傳統(tǒng)，通過VIP飄逸的方式實現(xiàn)應(yīng)用的高可用。雖然這種方式有其存在的問題，例如切換動作較慢；沒有分布式選舉機制，容易在網(wǎng)絡(luò)環(huán)境較差的場景下產(chǎn)生腦裂等問題；但也有其優(yōu)勢，就是對中間件幾乎做到了0侵入，上手容易且適配簡單。

由于keepalived存在的時間很長，所以網(wǎng)絡(luò)上對于其部署和應(yīng)用的案例很多，這里我不再贅述其安裝步驟，這里主要介紹其一些模式和使用場景，以及通過抓包的方式展現(xiàn)其高可用切換的流程。

二

Keepalived模式分類

Keepalived可以按照搶占模式和心跳機制分為5種模式。

2.1 非搶占模式

非搶占意思為當(dāng)master宕機，在backup中選取主機為新的master，并修改將VIP給予新的master后。當(dāng)原來的master恢復(fù)后，VIP依舊保持在新的master上，不再遷移。

這種情況主要針對崩潰主機恢復(fù)后依然會崩潰的場景下，例如需要對舊master的MySQL進(jìn)行檢查修復(fù)，此時需要啟動MySQL，防止啟動后VIP進(jìn)行切換。

2.1.1 配置方式

1）將所有主機的優(yōu)先級priority配置相同；
2）將所有主機的主備模式配置為BACKUP。

2.1.2 適用場景

1）適合master和backup的服務(wù)器配置相同，backup具有master相同的承載能力，能長時間穩(wěn)定承載業(yè)務(wù)的場景。
2）適合master與backup網(wǎng)絡(luò)波動較大的場景，減少vip在master和backup上頻繁飄逸。

2.2 搶占模式

搶占意思為當(dāng)master宕機，在backup中選取主機為新的master，并修改將VIP給予新的master后。當(dāng)原來的master恢復(fù)后，VIP從新的master轉(zhuǎn)移到舊的master上面。

這樣配置有缺點：如果短時間內(nèi)網(wǎng)絡(luò)抖動頻繁，vip會頻繁飄移，而vip的飄逸需要時間，進(jìn)而可能會影響業(yè)務(wù)。

2.2.1 配置方式

1）將master主機的優(yōu)先級大于其他的BACKUP。
2）將master主機的主備模式配置為BACKUP，將其他主機主備模式配置為BACKUP。

2.2.2 適用場景

1）適合master與backup服務(wù)器配置不同，backup性能低于master，無法長時間承載業(yè)務(wù)。backup僅作為master臨時備份的場景。
2）適合master與backup網(wǎng)絡(luò)波動較小的場景，當(dāng)master恢復(fù)后能及時切換回去。

2.3 靈活模式

靈活模式就是利用vrrp_script的weight值對節(jié)點的優(yōu)先級priority進(jìn)行重新計算。這種場景適用于腳本監(jiān)聽的情況，例如當(dāng)腳本檢測到應(yīng)用宕機后，就給master優(yōu)先級減去相應(yīng)的優(yōu)先級，此時就會發(fā)生切換。

2.3.1 配置方式

1）將master主機的優(yōu)先級大于其他的BACKUP。
2）在檢測腳本中配置weight值，可以影響每個節(jié)點的優(yōu)先級。

注：當(dāng)兩個節(jié)點優(yōu)先級相同時，發(fā)送VRRP通告報文的IP作為比較對象，IP較大者為MASTER。

2.3.2 適用場景

適合需要靈活配置的場景。

2.4 組播模式

組播模式是指keepalived發(fā)送VRRP心跳報文是通過組播的方式。

默認(rèn)情況下keepalived啟動后會自動加入設(shè)置的組播地址，進(jìn)而就能收到來自master的VRRP組播報文。組播地址可以在配置文件中通過 vrrp_mcast_group 配置。同一虛擬路由組播地址必須配置相同，默認(rèn)的組播地址為 224.0.0.18。master每隔固定頻率向組播地址發(fā)送VRRP報文。BACKUP收到master的VRRP報文根據(jù)優(yōu)先級判斷是否需要搶占VIP，如果在規(guī)定時間3倍時間內(nèi)未收到來自master的VRRP報文，也會判斷master宕機，進(jìn)而搶占VIP。

所有BACKUP節(jié)點只負(fù)責(zé)處理MASTER發(fā)出的多播包，當(dāng)發(fā)現(xiàn)master的優(yōu)先級沒自己高，或者沒收到master的VRRP通告時，BACKUP將自己切換到master狀態(tài)。

#以下示例為三臺服務(wù)器都部署了keepalived組播模式，我們查看三臺服務(wù)器的組播地址發(fā)現(xiàn)，三臺服務(wù)器都加入了組播地址。

2.4.1 組播的優(yōu)勢

配置方便，由于配置文件中并未指定BACKUP的IP地址，而是通過組播的方式來進(jìn)行通訊。所以我們可以隨時向集群中添加節(jié)點，而不用重啟已運行的節(jié)點。

2.4.2 適用場景

1）適用于支持組播的網(wǎng)絡(luò)的場景。
2）適用于后期需要向keepalived組內(nèi)添加其他節(jié)點的場景?？梢圆挥眯薷闹貑⑵渌膋eepalived，可以作為無感添加。

2.5 單播模式

keepalived不僅支持組播，還支持單播。組播是master在局域網(wǎng)內(nèi)向組播地址進(jìn)行發(fā)送VRRP報文，加入組播地址的BACKUP主機就會收到來自master的VRRP心跳報文，就可以判斷目前master的狀態(tài)。單播就是master通過點對點只向配置文件中指定的BACKUP發(fā)送VRRP報文。

2.5.1 單播的優(yōu)勢

1）虛擬路由ID只是在組播的模式下有意義，因為在組播模式下，BACKUP用來區(qū)分收到的組播VRRP報文是不是給自己的，所以在組播的模式下virtual_router_id在不同虛擬路由組不能重復(fù)。但是在單播中，采用的是點對點模式，所以在一個局域網(wǎng)內(nèi)virtual_router_id重復(fù)也是可以的。
2）對環(huán)境的要求更低?？赡苣承┉h(huán)境下不支持組播。

2.5.2 適用場景

1）適用于不支持組播的網(wǎng)絡(luò)環(huán)境，例如有些公有云不支持組播。
2）適用于keepalived組內(nèi)成員后期變動小場景。

三

組播模式配置

#這里進(jìn)行了配置的簡化，只對關(guān)鍵的配置進(jìn)行了整理：

global_defs {
router_id k8s-11 #表示這臺主機的ID，默認(rèn)情況下為主機名
vrrp_skip_check_adv_addr #此配置為如果收到的報文和上一個報文是同一個路由器則跳過檢查報文中的源地址。主要為了提高性能
vrrp_iptables #避免生成iptables input鏈 規(guī)則
vrrp_strict #嚴(yán)格遵守VRRP協(xié)議,不允許狀況:1,沒有VIP地址,2.配置了單播,3.在VRRP版本2中有IPv6地址
vrrp_garp_interval 0 #ARP報文發(fā)送延遲
vrrp_gna_interval 0 #消息發(fā)送延遲
vrrp_mcast_group 224.0.0.18    #指定組播IP地址，默認(rèn)為224.0.0.18
}

vrrp_script check_nginx { #腳本配置
pass
}

vrrp_instance VI_1 {
state BACKUP #當(dāng)前節(jié)點在此虛擬路由器上的狀態(tài)，狀態(tài)為MASTER或者BACKUP，一般都配置為backup，最終需要權(quán)重來進(jìn)行比較
interface ens33 #綁定為當(dāng)前虛擬路由器使用的物理接口，如eth0
virtual_router_id 11 #每個虛擬路由器唯一標(biāo)識，范圍0-255。同一組虛擬路由器的vrid需要保持一致。
priority 100 #當(dāng)前物理節(jié)點在此虛擬路由器的優(yōu)先級，范圍1-254
advert_int 1 #vrrp通告的時間間隔（心跳），默認(rèn)1s
authentication { #認(rèn)證機制
auth_type PASS
auth_pass 88888888
}

virtual_ipaddress { #配置虛擬IP
192.168.200.16 #指定VIP，不指定網(wǎng)卡，默認(rèn)為eth0。默認(rèn)為/32
192.168.200.17/24 dev ens33
#指定VIP的網(wǎng)卡
192.168.200.18/24 dev ens33 label ens33:1
#指定VIP的網(wǎng)卡label
}

track_script { #執(zhí)行腳本
check_nginx
}
}

注：最開始學(xué)習(xí)keepalived的時候很好奇，keepalived是怎么知道其他BACKUP節(jié)點的。后來發(fā)現(xiàn)默認(rèn)情況下keepalived的組播地址為224.0.0.18，master只需要將VRRP報文發(fā)送到這個地址就能被同一局域網(wǎng)內(nèi)所有其他啟動keepalived并加入相同組播地址的服務(wù)器接收到。

組播模式下服務(wù)器抓包情況：

以下三臺服務(wù)器192.168.100.11-13服務(wù)器配置了keepalived組播模式，分別對三臺服務(wù)器進(jìn)行了抓包。

我們可以看到，由于三臺服務(wù)器都加入了224.0.0.18這個組播地址，此時192.168.100.11為MASTER，192.168.100.11服務(wù)器向組播地址224.0.0.18發(fā)送了VRRP心跳報文，所以加入此組播地址的三臺服務(wù)器都收到了VRRP心跳報文。

四

單播模式配置

#和上面組播模式相似的配置不再進(jìn)行解釋。

global_defs {
router_id k8s-21
vrrp_skip_check_adv_addr
vrrp_iptables
# vrrp_strict #此選項必須關(guān)閉
vrrp_garp_interval 0
vrrp_gna_interval 0
}

vrrp_script check_nginx {
pass
}

vrrp_instance VI_2 {
state MASTER
interface ens33
virtual_router_id 21
priority 100
advert_int 2

authentication {
auth_type PASS
auth_pass 88888888
}

unicast_src_ip 192.168.100.21 #本機IP地址
unicast_peer {
192.168.100.22 #同一keepalived組內(nèi)其他節(jié)點IP地址
192.168.100.23 #同一keepalived組內(nèi)其他節(jié)點IP地址
}

virtual_ipaddress {
192.168.100.200/24 dev ens33 #虛擬VIP地址
}

track_script {
check_nginx
}
}

單播模式下服務(wù)器抓包情況：

以下三臺服務(wù)器192.168.100.21-23服務(wù)器配置了keepalived單播模式，此時192.168.100.21服務(wù)器為MASTER，我們在其上進(jìn)行抓包。發(fā)現(xiàn)在同一時刻，192.168.100.21分別向192.168.100.22-23發(fā)送了單播的VRRP心跳報文。

五

keepalived切換選舉過程

這里通過抓包的方式簡單分析keepalived一些切換場景。

5.1 組播模式下master優(yōu)先級降低選舉過程

此處模擬192.168.100.11-13為一組keepalived，且192.168.11為master。

1）默認(rèn)情況下會master會一直發(fā)送組播消息，每隔一秒鐘向配置的組播地址發(fā)送報文，報文信息會包含此時master的優(yōu)先級的值。組播的默認(rèn)地址為224.0.0.18。

2）當(dāng)master上的檢測腳本發(fā)現(xiàn)nginx服務(wù)宕機，此時master的優(yōu)先級由100變?yōu)?0。master還是依舊每秒一次向組播地址發(fā)送自己的優(yōu)先級報文，此時BACKUP收到網(wǎng)絡(luò)中優(yōu)先級變化（優(yōu)先級不高于自己）的VRRP組播報文，所有BACKUP會立即激活搶占功能，向組播地址發(fā)送VRRP報文，報文包含自身目前的優(yōu)先級。

注：可以看到，當(dāng)BACKUP收到master優(yōu)先級變化的報文，幾乎是立即向組播地址內(nèi)發(fā)送自己優(yōu)先級的VRRP報文。

3）兩個BACKUP經(jīng)過優(yōu)先級對比，最終由于192.168.100.12優(yōu)先級為80，獲得VIP。并開始向組播地址發(fā)送優(yōu)先級VRRP報文。

5.2 組播模式下當(dāng)BACKUP超時未收到master的報文

#這種情況為master宕機，或者master的keepalived進(jìn)程被kill。當(dāng)BACKUP超過配置文件中配置的VRRP報文頻率advert_int 3倍時長后，BACKUP會發(fā)出VRRP報文，將VIP搶占。

通過以上抓包分析可見，keepalived的選舉機制是很簡單的，就是簡單利用心跳報文+節(jié)點優(yōu)先級進(jìn)行選舉master，這種方式不可避免的會產(chǎn)生分區(qū)腦裂的故障。如果要避免分區(qū)腦裂的問題，目前成熟的解決方案是采用分布式選舉算法，例如zookeeper使用的ZAB算法，kafka使用的Raft算法。

六

VRRP協(xié)議報文頭

#共20byte。

6.1 通過抓包可以發(fā)現(xiàn)，VRRP協(xié)議是屬于網(wǎng)絡(luò)層上面的協(xié)議，不基于傳統(tǒng)的傳輸層TCP和UDP，所以它的通訊沒有端口的概念。VRRP協(xié)議內(nèi)置在Linux內(nèi)核的網(wǎng)絡(luò)協(xié)議棧中。

6.2 通過抓包我們可以發(fā)現(xiàn)VRRP報文只有20byte，但是包含了Virtual_ID，優(yōu)先級等信息。所以配置文件中這些配置非常重要。

6.3 通過抓包我們也可以很容易解釋為什么網(wǎng)上說keepalived配置文件中的Virtual_ID必須要配置一樣，因為在同一個組播地址中同一組keepalived的其他節(jié)點只會識別Virtual_ID與自己相同的VRRP報文。當(dāng)然，在同一個局域網(wǎng)中如果有多組keepalived都采用組播模式，那么必須滿足不同組keepalived的Virtual_ID必須不同，或者不同組keepalived的組播地址配置不同。不然會發(fā)生干擾，VIP可能會出現(xiàn)”跨組飄移”。

感謝大家的閱讀，VRRP還有一些小的細(xì)節(jié)處，需要大家共同的發(fā)掘探討。