Keepalived高可用切換過程

IT那活兒發布于2023-01-11 11:34 / 825人閱讀

Keepalived高可用切換過程

點擊上方“IT那活兒”公眾號，關注后了解更多內容，不管IT什么活兒，干就完了！！！

一

keepalived簡介

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

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

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

二

Keepalived模式分類

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

2.1 非搶占模式

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

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

2.1.1 配置方式

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

2.1.2 適用場景

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

2.2 搶占模式

搶占意思為當master宕機，在backup中選取主機為新的master，并修改將VIP給予新的master后。當原來的master恢復后，VIP從新的master轉移到舊的master上面。

這樣配置有缺點：如果短時間內網絡抖動頻繁，vip會頻繁飄移，而vip的飄逸需要時間，進而可能會影響業務。

2.2.1 配置方式

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

2.2.2 適用場景

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

2.3 靈活模式

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

2.3.1 配置方式

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

注：當兩個節點優先級相同時，發送VRRP通告報文的IP作為比較對象，IP較大者為MASTER。

2.3.2 適用場景

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

2.4 組播模式

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

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

所有BACKUP節點只負責處理MASTER發出的多播包，當發現master的優先級沒自己高，或者沒收到master的VRRP通告時，BACKUP將自己切換到master狀態。

#以下示例為三臺服務器都部署了keepalived組播模式，我們查看三臺服務器的組播地址發現，三臺服務器都加入了組播地址。

2.4.1 組播的優勢

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

2.4.2 適用場景

1）適用于支持組播的網絡的場景。
2）適用于后期需要向keepalived組內添加其他節點的場景。可以不用修改重啟其他的keepalived，可以作為無感添加。

2.5 單播模式

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

2.5.1 單播的優勢

1）虛擬路由ID只是在組播的模式下有意義，因為在組播模式下，BACKUP用來區分收到的組播VRRP報文是不是給自己的，所以在組播的模式下virtual_router_id在不同虛擬路由組不能重復。但是在單播中，采用的是點對點模式，所以在一個局域網內virtual_router_id重復也是可以的。
2）對環境的要求更低。可能某些環境下不支持組播。

2.5.2 適用場景

1）適用于不支持組播的網絡環境，例如有些公有云不支持組播。
2）適用于keepalived組內成員后期變動小場景。

三

組播模式配置

#這里進行了配置的簡化，只對關鍵的配置進行了整理：

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

vrrp_script check_nginx { #腳本配置
pass
}

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

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

track_script { #執行腳本
check_nginx
}
}

注：最開始學習keepalived的時候很好奇，keepalived是怎么知道其他BACKUP節點的。后來發現默認情況下keepalived的組播地址為224.0.0.18，master只需要將VRRP報文發送到這個地址就能被同一局域網內所有其他啟動keepalived并加入相同組播地址的服務器接收到。

組播模式下服務器抓包情況：

以下三臺服務器192.168.100.11-13服務器配置了keepalived組播模式，分別對三臺服務器進行了抓包。

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

四

單播模式配置

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

global_defs {
router_id k8s-21
vrrp_skip_check_adv_addr
vrrp_iptables
# vrrp_strict #此選項必須關閉
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組內其他節點IP地址
192.168.100.23 #同一keepalived組內其他節點IP地址
}

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

track_script {
check_nginx
}
}

單播模式下服務器抓包情況：

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

五

keepalived切換選舉過程

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

5.1 組播模式下master優先級降低選舉過程

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

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

2）當master上的檢測腳本發現nginx服務宕機，此時master的優先級由100變為70。master還是依舊每秒一次向組播地址發送自己的優先級報文，此時BACKUP收到網絡中優先級變化（優先級不高于自己）的VRRP組播報文，所有BACKUP會立即激活搶占功能，向組播地址發送VRRP報文，報文包含自身目前的優先級。

注：可以看到，當BACKUP收到master優先級變化的報文，幾乎是立即向組播地址內發送自己優先級的VRRP報文。

3）兩個BACKUP經過優先級對比，最終由于192.168.100.12優先級為80，獲得VIP。并開始向組播地址發送優先級VRRP報文。

5.2 組播模式下當BACKUP超時未收到master的報文

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

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

六

VRRP協議報文頭

#共20byte。

6.1 通過抓包可以發現，VRRP協議是屬于網絡層上面的協議，不基于傳統的傳輸層TCP和UDP，所以它的通訊沒有端口的概念。VRRP協議內置在Linux內核的網絡協議棧中。

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

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

感謝大家的閱讀，VRRP還有一些小的細節處，需要大家共同的發掘探討。

本文作者：王旭東(上海新炬中北團隊）

本文來源：“IT那活兒”公眾號

GPU云服務器云服務器 ECS可用區切換高可用高可用集群云計算高可用

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129108.html

Nginx+Keepalived實現站點高可用

摘要：在協議實現里，虛擬路由器使用作為虛擬地址，就是唯一的，這個地址同一時間只有一個物理路由器占用。在虛擬路由器里面的物理路由器組里面通過多播地址來定時發送通告消息。負責健康檢查，包括常見的各種檢查方式。公司內部 OA 系統要做線上高可用，避免單點故障，所以計劃使用2臺虛擬機通過 Keepalived 工具來實現 nginx 的高可用（High Avaiability），達到一臺nginx...

Songlcy 2019-07-25 13:32 評論0 收藏0
MySQL高可用方案測試

MySQL高可用方案測試 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin...

IT那活兒 2023-01-11 13:19 評論0 收藏2496
基于騰訊云CVM自建高可用Redis實踐

摘要：環境說明需求與目標本文將通過對目前主流的幾種高可用方案進行對比分析，并基于騰訊云和等基礎產品進行搭建配置測試總結。本文來源 | 云+社區專欄文章作者 | 萬守兵，騰訊云資深架構師。8年以上大型互聯網公司運維工作經驗，騰訊云資深遷云架構師，一直從事大型互聯網服務端架構設計和優化工作。個人專注于云計算、k8s和 DevOps領域。導讀：在企業實際生產環境中為了能夠給業務上層應用提供高...

DataPipeline 2019-06-24 18:23 評論0 收藏0
實現高可用的兩種方案與實戰

摘要：高可用的首要想法就是雙機熱備，故障時自動切換，所以我們要給加一個備機。注下面實現高可用都用的是雙機熱備，為了方便，把調度服務器簡稱為主機，把調度服務器的備機簡稱為備機。我之前在一片文章用Nginx+Redis實現session共享的均衡負載中做了一個負載均衡的實驗，其主要架構如下： showImg(https://segmentfault.com/img/bVushO); 把de...

seal_de 2019-08-15 17:45 評論0 收藏0