成人无码视频,亚洲精品久久久久av无码,午夜精品久久久久久毛片,亚洲 中文字幕 日韩 无码

資訊專欄INFORMATION COLUMN

Keepalived高可用切換過程

IT那活兒 / 860人閱讀
Keepalived高可用切換過程
點擊上方“IT那活兒”公眾號，關注后了解更多內(nèi)容，不管IT什么活兒，干就完了?。。?/strong>
一

keepalived簡介

Keepalived對于運維人員來說是一款熟悉的高可用工具，在很多沒有原生實現(xiàn)分布式高可用的中間件和數(shù)據(jù)庫中都得到了廣泛的使用，例如keepalived+nginx實現(xiàn)對nginx的高可用，keepalived+MySQL實現(xiàn)對MySQL的高可用。
在各種分布式集群通過多副本多節(jié)點方式或者微服務的服務發(fā)現(xiàn)機制實現(xiàn)高可用大行其道的今天，keepalived實現(xiàn)高可用的方式較為傳統(tǒng)，通過VIP飄逸的方式實現(xiàn)應用的高可用。雖然這種方式有其存在的問題，例如切換動作較慢；沒有分布式選舉機制，容易在網(wǎng)絡環(huán)境較差的場景下產(chǎn)生腦裂等問題；但也有其優(yōu)勢，就是對中間件幾乎做到了0侵入，上手容易且適配簡單。

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

二

Keepalived模式分類

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

2.1 非搶占模式

非搶占意思為當master宕機，在backup中選取主機為新的master，并修改將VIP給予新的master后。當原來的master恢復后，VIP依舊保持在新的master上，不再遷移。
這種情況主要針對崩潰主機恢復后依然會崩潰的場景下，例如需要對舊master的MySQL進行檢查修復，此時需要啟動MySQL，防止啟動后VIP進行切換。

2.1.1 配置方式

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

2.1.2 適用場景

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

2.2 搶占模式

搶占意思為當master宕機，在backup中選取主機為新的master，并修改將VIP給予新的master后。當原來的master恢復后，VIP從新的master轉(zhuǎn)移到舊的master上面。
這樣配置有缺點：如果短時間內(nèi)網(wǎng)絡抖動頻繁，vip會頻繁飄移，而vip的飄逸需要時間，進而可能會影響業(yè)務。

2.2.1 配置方式

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

2.2.2 適用場景

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

2.3 靈活模式

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

2.3.1 配置方式

  • 1）將master主機的優(yōu)先級大于其他的BACKUP。
  • 2）在檢測腳本中配置weight值，可以影響每個節(jié)點的優(yōu)先級。
注：當兩個節(jié)點優(yōu)先級相同時，發(fā)送VRRP通告報文的IP作為比較對象，IP較大者為MASTER。

2.3.2 適用場景

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

2.4 組播模式

組播模式是指keepalived發(fā)送VRRP心跳報文是通過組播的方式。
默認情況下keepalived啟動后會自動加入設置的組播地址，進而就能收到來自master的VRRP組播報文。組播地址可以在配置文件中通過 vrrp_mcast_group 配置。同一虛擬路由組播地址必須配置相同，默認的組播地址為 224.0.0.18。master每隔固定頻率向組播地址發(fā)送VRRP報文。BACKUP收到master的VRRP報文根據(jù)優(yōu)先級判斷是否需要搶占VIP，如果在規(guī)定時間3倍時間內(nèi)未收到來自master的VRRP報文，也會判斷master宕機，進而搶占VIP。
所有BACKUP節(jié)點只負責處理MASTER發(fā)出的多播包，當發(fā)現(xiàn)master的優(yōu)先級沒自己高，或者沒收到master的VRRP通告時，BACKUP將自己切換到master狀態(tài)。
#以下示例為三臺服務器都部署了keepalived組播模式，我們查看三臺服務器的組播地址發(fā)現(xiàn)，三臺服務器都加入了組播地址。

2.4.1 組播的優(yōu)勢

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

2.4.2 適用場景

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

2.5 單播模式

keepalived不僅支持組播，還支持單播。組播是master在局域網(wǎng)內(nèi)向組播地址進行發(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在不同虛擬路由組不能重復。但是在單播中，采用的是點對點模式，所以在一個局域網(wǎng)內(nèi)virtual_router_id重復也是可以的。
  • 2）對環(huán)境的要求更低。可能某些環(huán)境下不支持組播。

2.5.2 適用場景

  • 1）適用于不支持組播的網(wǎng)絡環(huán)境，例如有些公有云不支持組播。

  • 2）適用于keepalived組內(nèi)成員后期變動小場景。

三

組播模式配置

#這里進行了配置的簡化，只對關鍵的配置進行了整理：
global_defs {
router_id k8s-11 #表示這臺主機的ID，默認情況下為主機名
vrrp_skip_check_adv_addr #此配置為如果收到的報文和上一個報文是同一個路由器則跳過檢查報文中的源地址。主要為了提高性能
vrrp_iptables #避免生成iptables input鏈 規(guī)則
vrrp_strict #嚴格遵守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地址，默認為224.0.0.18
}

vrrp_script check_nginx { #腳本配置
pass
}

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

virtual_ipaddress { #配置虛擬IP
192.168.200.16 #指定VIP，不指定網(wǎng)卡，默認為eth0。默認為/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
}
}
注：最開始學習keepalived的時候很好奇，keepalived是怎么知道其他BACKUP節(jié)點的。后來發(fā)現(xiàn)默認情況下keepalived的組播地址為224.0.0.18，master只需要將VRRP報文發(fā)送到這個地址就能被同一局域網(wǎng)內(nèi)所有其他啟動keepalived并加入相同組播地址的服務器接收到。

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

以下三臺服務器192.168.100.11-13服務器配置了keepalived組播模式，分別對三臺服務器進行了抓包。
我們可以看到，由于三臺服務器都加入了224.0.0.18這個組播地址，此時192.168.100.11為MASTER，192.168.100.11服務器向組播地址224.0.0.18發(fā)送了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組內(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
}
}

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

以下三臺服務器192.168.100.21-23服務器配置了keepalived單播模式，此時192.168.100.21服務器為MASTER，我們在其上進行抓包。發(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）默認情況下會master會一直發(fā)送組播消息，每隔一秒鐘向配置的組播地址發(fā)送報文，報文信息會包含此時master的優(yōu)先級的值。組播的默認地址為224.0.0.18。
2）當master上的檢測腳本發(fā)現(xiàn)nginx服務宕機，此時master的優(yōu)先級由100變?yōu)?0。master還是依舊每秒一次向組播地址發(fā)送自己的優(yōu)先級報文，此時BACKUP收到網(wǎng)絡中優(yōu)先級變化（優(yōu)先級不高于自己）的VRRP組播報文，所有BACKUP會立即激活搶占功能，向組播地址發(fā)送VRRP報文，報文包含自身目前的優(yōu)先級。
注：可以看到，當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 組播模式下當BACKUP超時未收到master的報文

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

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

六

VRRP協(xié)議報文頭

#共20byte。
6.1 通過抓包可以發(fā)現(xiàn)，VRRP協(xié)議是屬于網(wǎng)絡層上面的協(xié)議，不基于傳統(tǒng)的傳輸層TCP和UDP，所以它的通訊沒有端口的概念。VRRP協(xié)議內(nèi)置在Linux內(nèi)核的網(wǎng)絡協(xié)議棧中。
6.2 通過抓包我們可以發(fā)現(xiàn)VRRP報文只有20byte，但是包含了Virtual_ID，優(yōu)先級等信息。所以配置文件中這些配置非常重要。

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

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


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

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

文章版權歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/129108.html

相關文章

  • Nginx+Keepalived實現(xiàn)站點高可用

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

    Songlcy 評論0 收藏0

  • MySQL高可用方案測試

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

    IT那活兒 評論0 收藏2496

  • 基于騰訊云CVM自建高可用Redis實踐

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

    DataPipeline 評論0 收藏0

  • 實現(xiàn)高可用的兩種方案與實戰(zhàn)

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

    seal_de 評論0 收藏0

發(fā)表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<