Keepalived這套工具我第一次在Linux服務(wù)器上安裝配置時是給Nginx做VIP入口的。當(dāng)時想法特別簡單兩臺機(jī)器一個IP誰掛了另一個頂上。結(jié)果配置完啟動之后兩臺節(jié)點(diǎn)完全感知不到對方查了大半天才發(fā)現(xiàn)是防火墻沒放行VRRP協(xié)議。接下來我就把Keepalived在Linux環(huán)境下的安裝、配置、啟動整條鏈路寫清楚附帶這些年跌過的坑和常用的驗(yàn)證方法。不管你是要給Nginx、MySQL還是RabbitMQ做高可用Keepalived都是Linux上最經(jīng)典、最輕量、最容易上手的一層方案值得花時間徹底搞明白。1. 高可用不是玄學(xué)Keepalived與VIP的核心機(jī)制1.1 單點(diǎn)故障問題的本質(zhì)任何一臺服務(wù)器、任何一個進(jìn)程都有概率發(fā)生故障。硬件老化、系統(tǒng)崩潰、進(jìn)程被殺、網(wǎng)絡(luò)分區(qū)隨便一個原因都可能讓服務(wù)不可用。在Keepalived出現(xiàn)之前解決單點(diǎn)故障最樸素的想法是“多加一臺機(jī)器”但加完機(jī)器后問題就來了客戶端訪問的IP只有一個怎么讓請求自動切換到備用機(jī)器這時候虛擬IPVIP的概念就出來了——對外只暴露一個VIP這個VIP由主備節(jié)點(diǎn)中的一臺持有主節(jié)點(diǎn)故障后VIP自動漂移到備用節(jié)點(diǎn)客戶端完全無感知。Keepalived干的就是這件事把VIP的持有權(quán)做成一種可以被“選舉、移交、接管”的資源。1.2 VRRP協(xié)議的核心工作過程Keepalived的底層協(xié)議是VRRPVirtual Router Redundancy Protocol這個協(xié)議最早是為路由器高可用設(shè)計(jì)的思路和我們現(xiàn)在講的服務(wù)器高可用完全一致。每個參與高可用的節(jié)點(diǎn)會周期性地向同一個網(wǎng)段發(fā)送VRRP通告報(bào)文報(bào)文中包含優(yōu)先級、virtual_router_id等信息。收到通告后每個節(jié)點(diǎn)會比較自己和對方的優(yōu)先級優(yōu)先級高的成為MASTER持有VIP優(yōu)先級低的進(jìn)入BACKUP狀態(tài)只是不停監(jiān)聽MASTER的通告。當(dāng)BACKUP連續(xù)一段時間默認(rèn)是3倍advert_int沒有收到MASTER的通告就會認(rèn)為MASTER已經(jīng)失聯(lián)立即重新選舉——如果它的優(yōu)先級最高就把VIP接管過來。這個過程中有兩點(diǎn)值得注意。第一state字段里寫的MASTER或BACKUP并不是最終決定誰是主的唯一依據(jù)priority的數(shù)值才是。你寫MASTER但priority寫得比對方低照樣會退讓。所以我在配置時習(xí)慣把主節(jié)點(diǎn)priority設(shè)為100備節(jié)點(diǎn)設(shè)為90既保證主備穩(wěn)定又留出足夠差距避免因網(wǎng)絡(luò)瞬斷導(dǎo)致的反復(fù)橫跳。第二VRRP默認(rèn)采用組播方式發(fā)送通告目標(biāo)地址是224.0.0.18。這意味著同一網(wǎng)段內(nèi)所有的Keepalived節(jié)點(diǎn)理論上都能收到彼此的報(bào)文而這也帶來了防火墻放行和virtual_router_id隔離這兩個后續(xù)要重點(diǎn)處理的問題。1.3 從“機(jī)器活著”到“服務(wù)可用”Keepalived只做VRRP的話只能感知“對端機(jī)器是否在線”感知不到“本機(jī)Nginx進(jìn)程是不是掛了”。因此有了vrrp_script健康檢查機(jī)制定期執(zhí)行一段腳本腳本返回0表示正常返回非0判定為故障。當(dāng)腳本檢測到業(yè)務(wù)進(jìn)程異常時本節(jié)點(diǎn)會主動降低優(yōu)先級、退出MASTER狀態(tài)把VIP讓給備用節(jié)點(diǎn)。這種設(shè)計(jì)把“高可用”從機(jī)器層面下沉到了服務(wù)層面也是我在實(shí)際配置中一定會加上的一環(huán)。沒有健康檢查的Keepalived只能算半個高可用。1.4 狀態(tài)機(jī)與切換觸發(fā)條件小結(jié)Keepalived節(jié)點(diǎn)通常會在Initialize、Backup、Master、Fault幾個狀態(tài)之間流轉(zhuǎn)。啟動時進(jìn)入Initialize隨后如果判斷自己是MASTER就直接進(jìn)入Master狀態(tài)并開始發(fā)送VRRP通告否則進(jìn)入Backup狀態(tài)等待。Fault狀態(tài)代表本節(jié)點(diǎn)出現(xiàn)異常比如配置錯誤、腳本檢測失敗、網(wǎng)卡故障此時不會持有VIP。梳理清楚這幾個狀態(tài)再看后面的日志時就會順暢很多。日志里出現(xiàn)的Entering MASTER STATE、Entering BACKUP STATE、Entering FAULT STATE分別對應(yīng)一次完整的狀態(tài)切換過程。2. 從空白系統(tǒng)到Keepalived就緒安裝全流程2.1 安裝方式選型yum/apt優(yōu)先還是源碼編譯Keepalived的安裝方式主要有三種系統(tǒng)包管理器安裝、源碼編譯安裝、容器部署。我個人對生產(chǎn)環(huán)境的建議是能直接用yum或apt就用別一開始就上源碼。原因很簡單包管理器安裝會自動處理好依賴、配置文件路徑和systemd服務(wù)文件一條命令之后就能用后續(xù)升級也方便。源碼編譯的優(yōu)勢在于版本新、可定制參數(shù)但需要自己處理依賴和服務(wù)文件對新手不夠友好。容器化部署Keepalived不是不能做但在“給物理機(jī)或云主機(jī)上的業(yè)務(wù)提供VIP漂移”這個場景下直接用宿主機(jī)進(jìn)程的方式更簡單也少一層網(wǎng)絡(luò)映射的復(fù)雜性。2.2 yum/apt安裝的具體操作在CentOS、RHEL系上安裝Keepalived只需要一行yum install -y keepalived安裝完成后二進(jìn)制文件默認(rèn)在/usr/sbin/keepalived配置文件自動生成在/etc/keepalived/keepalived.confsystemd服務(wù)文件也注冊好了。Ubuntu/Debian系上對應(yīng)的是apt update apt install -y keepalived安裝完成后同樣可以用systemctl管理。這里特別提一下很多同學(xué)喜歡“裝完立刻啟動”但Keepalived此時只有一個默認(rèn)的空配置模板直接啟動不會報(bào)錯但也什么都干不了。正確順序是先檢查配置目錄、確認(rèn)二進(jìn)制版本再動手改配置。2.3 源碼編譯安裝的完整過程如果系統(tǒng)源里沒有Keepalived或者你需要特定版本源碼編譯也不難但前置依賴一定要裝齊。在CentOS系上至少需要這些包yum install -y gcc gcc-c make openssl-devel popt-devel libnl3-devel這些都是Keepalived編譯時要用到的頭文件和工具鏈。缺失libnl3-devel時configure階段會報(bào)libnl headers not found這種情況不是Keepalived本身的問題而是依賴沒補(bǔ)齊。Ubuntu系上對應(yīng)apt install -y build-essential libssl-dev libpopt-dev libnl-3-dev libnl-genl-3-dev依賴裝好之后進(jìn)入源碼目錄./configure --prefix/usr/local/keepalived --sysconfdir/etc/keepalived make make install--sysconfdir/etc/keepalived這一步非常關(guān)鍵它把配置文件的默認(rèn)路徑固定到/etc/keepalived和后面systemd服務(wù)文件里ExecStart的默認(rèn)配置路徑保持一致。如果漏了默認(rèn)配置路徑會變成/usr/local/etc/keepalived啟動時服務(wù)找不到配置文件排查又浪費(fèi)一輪時間。2.4 安裝后的驗(yàn)證與環(huán)境自檢安裝完成后用下面幾條命令確認(rèn)環(huán)境keepalived --version which keepalived ls -l /etc/keepalived/keepalived.conf systemctl status keepalived接著確認(rèn)網(wǎng)卡名這一步直接決定后面interface參數(shù)怎么寫ip link我看到太多人直接把網(wǎng)上教程的eth0抄進(jìn)配置結(jié)果自己機(jī)器網(wǎng)卡是ens33VRRP通告根本發(fā)不出去。確認(rèn)完網(wǎng)卡再在兩個節(jié)點(diǎn)之間互相ping一下確認(rèn)基礎(chǔ)網(wǎng)絡(luò)是通的。這幾件事做完才算真正具備配置Keepalived的前提條件。3. 配置文件的正確打開方式主備節(jié)點(diǎn)的每項(xiàng)關(guān)鍵參數(shù)3.1 配置文件整體結(jié)構(gòu)Keepalived的配置文件通常包含幾個段global_defs是全局定義vrrp_script是健康檢查腳本定義vrrp_instance是虛擬IP實(shí)例virtual_server是與LVS集成時的配置段。日常使用中最核心的是vrrp_script和vrrp_instance。一個配置可以同時包含多個vrrp_instance一臺機(jī)器上跑多個實(shí)例就能實(shí)現(xiàn)“我是A組的主、B組的備”這種互備架構(gòu)。這也是Keepalived比較靈活的地方高可用不一定是兩臺機(jī)器一主一閑資源可以互為備份。3.2 global_defs里的關(guān)鍵參數(shù)global_defs里最常用的就是router_id它是一個字符串標(biāo)識建議兩臺節(jié)點(diǎn)設(shè)置成不同值比如主節(jié)點(diǎn)叫LVS_MASTER備節(jié)點(diǎn)叫LVS_BACKUP。雖然它不參與選舉但會在日志里出現(xiàn)設(shè)置成有意義的名稱后期排查多實(shí)例時能一眼看出是哪臺機(jī)器。另一個值得了解的是enable_script_security如果健康檢查腳本里會執(zhí)行較復(fù)雜的命令加上這個參數(shù)并配合script_user指定用戶可以限制腳本的執(zhí)行權(quán)限。不過我的實(shí)際經(jīng)驗(yàn)是健康檢查腳本越簡單越好盡量別在腳本里做復(fù)雜的邏輯否則腳本本身就會變成新的故障源。3.3 vrrp_instance逐參數(shù)拆解下面是一份最典型的主節(jié)點(diǎn)配置global_defs { router_id LVS_MASTER } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.10.100/24 dev eth0 } }備份節(jié)點(diǎn)大部分參數(shù)相同只有state、router_id、priority不同。下面這張表可以直接對照著寫參數(shù)主節(jié)點(diǎn)備份節(jié)點(diǎn)stateMASTERBACKUPpriority10090virtual_router_id5151interface實(shí)際網(wǎng)卡名實(shí)際網(wǎng)卡名authentication與主節(jié)點(diǎn)一致與主節(jié)點(diǎn)一致三個容易出問題的點(diǎn)第一interface必須寫本機(jī)實(shí)際網(wǎng)卡名別照抄示例里的eth0。第二如果同一網(wǎng)段里部署了多套Keepalived集群virtual_router_id絕對不能重復(fù)否則會互相搶VIP。第三auth_pass官方限制最多8位建議就寫8位以內(nèi)的純數(shù)字或字母別學(xué)網(wǎng)上某些教程寫一長串否則可能因認(rèn)證報(bào)文不符合預(yù)期導(dǎo)致節(jié)點(diǎn)之間無法正常協(xié)商。advert_int默認(rèn)1秒表示每隔1秒發(fā)送一次VRRP通告建議保持默認(rèn)。virtual_ipaddress里的VIP必須和業(yè)務(wù)網(wǎng)卡在同一網(wǎng)段否則外部訪問不通。3.4 健康檢查腳本與track_script聯(lián)動健康檢查是Keepalived真正體現(xiàn)業(yè)務(wù)感知的模塊。假設(shè)要給Nginx做健康檢查先寫一個腳本#!/bin/bash if pgrep -x nginx /dev/null 21; then exit 0 else exit 1 fi給腳本加執(zhí)行權(quán)限后在配置文件中定義vrrp_script check_nginx { script /etc/keepalived/check_nginx.sh interval 2 timeout 2 rise 2 fall 2 }然后在vrrp_instance里引用track_script { check_nginx }這里幾個參數(shù)的實(shí)際含義需要說清楚interval是健康檢查執(zhí)行間隔秒數(shù)timeout是單次腳本執(zhí)行超時時間超過就按失敗處理rise表示連續(xù)成功多少次才把狀態(tài)從故障恢復(fù)為正常fall表示連續(xù)失敗多少次才判定故障。默認(rèn)情況下rise和fall都是1但在網(wǎng)絡(luò)或服務(wù)恢復(fù)場景下很容易出現(xiàn)“剛恢復(fù)就切換”的抖動現(xiàn)象所以我通常會把fall設(shè)成2甚至3避免一次偶發(fā)失敗就造成VIP來回漂。腳本返回值0表示健康非0表示不健康這個約定是Keepalived判定狀態(tài)的唯一依據(jù)。3.5 notify腳本讓切換動作可感知、可追蹤VIP漂移只是一層表象實(shí)際運(yùn)維中我更關(guān)心切換發(fā)生之后系統(tǒng)做了什么。在vrrp_instance里配置三個notify參數(shù)notify_master /etc/keepalived/notify_master.sh notify_backup /etc/keepalived/notify_backup.sh notify_fault /etc/keepalived/notify_fault.sh三個腳本分別在節(jié)點(diǎn)變成MASTER、BACKUP、FAULT狀態(tài)時被調(diào)用。最常見的用法是notify_master里reload業(yè)務(wù)進(jìn)程、刷新ARP緩沖notify_backup里把機(jī)器上不屬于自己的VIP清理干凈notify_fault里調(diào)用告警接口做通知。腳本務(wù)必使用絕對路徑加執(zhí)行權(quán)限腳本內(nèi)部如果有輸出最好重定向到日志文件。我在notify_master腳本里通常會這樣寫#!/bin/bash echo $(date %F %T) [notify_master] /var/log/keepalived_notify.log systemctl reload nginx 2/dev/null || true這樣既能確認(rèn)切換邏輯觸發(fā)又不會讓script腳本的輸出干擾Keepalived主進(jìn)程的日志。4. 啟動、驗(yàn)證與主備切換演練4.1 啟動前先做配置語法檢查改完配置后不要急著start先讓Keepalived自檢一下keepalived -t -f /etc/keepalived/keepalived.conf輸出里出現(xiàn)語法正常之類的提示后再用systemctl啟動。語法檢查這一步看似多余實(shí)際上能幫你攔截一大半的“服務(wù)起不來”問題。配置文件的括號、分號、參數(shù)名只要有一處錯誤服務(wù)都可能直接失敗而這類錯誤恰好是最讓人頭大的。4.2 啟動的正確姿勢與進(jìn)程判斷systemd下啟動很簡單systemctl start keepalived systemctl enable keepalived啟動后我通常第一時間看兩樣?xùn)|西進(jìn)程是否完整、狀態(tài)是否正常。ps -ef | grep keepalived systemctl status keepalived正常情況下ps能看到主進(jìn)程加VRRP子進(jìn)程如果配置了健康檢查還會看到check子進(jìn)程也就是三條記錄。如果只有一條或者兩條異常多半是子進(jìn)程啟動失敗了這時馬上看日志journalctl -u keepalived -f日志是Keepalived排錯的第一手資料比到處猜強(qiáng)得多?？吹紼ntering MASTER STATE就說明這臺已經(jīng)成為主節(jié)點(diǎn)VIP應(yīng)該很快會出現(xiàn)在網(wǎng)卡上。4.3 VIP驗(yàn)證這幾條命令最直接判斷VIP是否生效不需要看管理界面命令行就夠了ip addr show ip addr show dev eth0如果VIP已經(jīng)配置成功能看到類似192.168.10.100/24 scope global eth0這樣的地址。如果看不到按這個順序排查interface參數(shù)寫沒寫對防火墻有沒有放行VRRP兩臺節(jié)點(diǎn)之間的網(wǎng)絡(luò)通不通。協(xié)議層面可以用tcpdump驗(yàn)證tcpdump -ni eth0 vrrpMASTER節(jié)點(diǎn)應(yīng)該每隔1秒就發(fā)一個VRRP通告包。如果你在BACKUP節(jié)點(diǎn)上也頻繁抓到通告說明兩臺節(jié)點(diǎn)至少能從協(xié)議層發(fā)現(xiàn)對方問題大概率出在配置細(xì)節(jié)上。4.4 主備切換演練不能只在理論上說Keepalived配完必須做真實(shí)切換演練不然你永遠(yuǎn)不知道哪一步配置其實(shí)有問題。我的標(biāo)準(zhǔn)流程是在主節(jié)點(diǎn)執(zhí)行systemctl stop keepalived模擬進(jìn)程異常退出。到備用節(jié)點(diǎn)執(zhí)行ip addr showVIP應(yīng)該幾秒內(nèi)出現(xiàn)在備用節(jié)點(diǎn)網(wǎng)卡上。查看備用節(jié)點(diǎn)notify_master腳本日志確認(rèn)切換通知觸發(fā)。重新啟動主節(jié)點(diǎn)Keepalived觀察VIP是否按預(yù)期搶占回來。再一次執(zhí)行ip addr show和日志檢查確認(rèn)主備狀態(tài)恢復(fù)。演練時如果發(fā)現(xiàn)VIP沒有切換先不要急著改配置而是按“網(wǎng)絡(luò)是否通-防火墻是否放行-配置是否一致-日志是否報(bào)錯”的順序逐步排查。我見過最隱蔽的問題是兩個節(jié)點(diǎn)的時間差太大導(dǎo)致日志和故障時序?qū)Σ簧吓挪闀r硬是繞了很久所以也建議大家配置NTP同步雖然VRRP本身不強(qiáng)依賴時間但日志對不上真的太痛苦了。5. 踩坑復(fù)盤從防火墻到云主機(jī)的常見翻車現(xiàn)場5.1 防火墻與SELinux占翻車案例的一半Keepalived部署后最容易翻車的地方就是防火墻。VRRP使用的協(xié)議號是112既不是TCP也不是UDP所以常規(guī)的放行80端口、443端口的規(guī)則對它不起作用。firewalld下可以這樣放行firewall-cmd --permanent --add-rich-rulerule protocol valuevrrp accept firewall-cmd --reloadiptables下則是iptables -I INPUT -p vrrp -j ACCEPTSELinux也經(jīng)常會成為隱性攔路虎。如果你發(fā)現(xiàn)配置完全正確但VRRP報(bào)文就是發(fā)不出去可以用setenforce 0臨時驗(yàn)證一下確認(rèn)是SELinux之后再考慮是否永久關(guān)閉或者調(diào)整對應(yīng)的布爾值。這里補(bǔ)一句修改防火墻或SELinux之后建議把Keepalived服務(wù)重啟一次讓進(jìn)程重新建立網(wǎng)絡(luò)綁定否則可能出現(xiàn)規(guī)則已經(jīng)放行了但連接還是不通的怪現(xiàn)象。5.2 網(wǎng)卡名不一致最常見的低級錯誤現(xiàn)代Linux發(fā)行版和云主機(jī)的網(wǎng)卡命名已經(jīng)不一定是eth0了ens33、ens5、eth1都很常見。interface參數(shù)填錯后Keepalived進(jìn)程可能正常啟動但完全監(jiān)聽不到正確的網(wǎng)卡導(dǎo)致VRRP通告發(fā)不出、收不到主備互不感知。我建議在配置前先在每個節(jié)點(diǎn)上執(zhí)行ip link把真實(shí)的網(wǎng)卡名記下來兩臺節(jié)點(diǎn)各自填各自的interface不需要強(qiáng)求一致。比如主節(jié)點(diǎn)是ens33備節(jié)點(diǎn)是eth0只要各自填對VRRP照樣能工作。5.3 virtual_router_id沖突跨集群的干擾virtual_router_id是0到255之間的整數(shù)它的作用是在同一網(wǎng)段內(nèi)區(qū)分不同的VRRP虛擬路由器。同一個高可用集群的兩臺節(jié)點(diǎn)必須寫同一個ID但不同集群之間絕對不能重復(fù)。如果同一網(wǎng)段里有兩組Keepalived都用了ID 51這兩組會互相干擾輕則日志怪異重則VIP被誤搶。這個問題的隱蔽性在于日志里往往不會有明顯的報(bào)錯只有用tcpdump抓包后才能看到不同集群之間發(fā)送了相同virtual_router_id的VRRP報(bào)文。我的習(xí)慣是給每個集群規(guī)劃獨(dú)立的ID同時在配置文件里用注釋寫明這個ID屬于哪套業(yè)務(wù)避免后續(xù)維護(hù)時撞車。5.4 腦裂高可用最怕的兩個字腦裂是所有高可用方案的噩夢Keepalived也不例外。腦裂發(fā)生后兩臺節(jié)點(diǎn)同時認(rèn)為自己是MASTER同時持有同一個VIP流量被打散到兩臺機(jī)器上如果后面連的是數(shù)據(jù)庫后果不堪設(shè)想。判斷腦裂的標(biāo)準(zhǔn)動作有兩個第一在兩臺節(jié)點(diǎn)上分別執(zhí)行ip addr show看VIP是否同時存在第二在兩臺節(jié)點(diǎn)上分別抓VRRP包看到底是誰在正常發(fā)通告。定位到腦裂后按順序檢查兩臺節(jié)點(diǎn)priority是否設(shè)置正確、防火墻是否放行了VRRP、interface是否填寫正確、三層網(wǎng)絡(luò)是否互通。腦裂的根源幾乎都是“一個節(jié)點(diǎn)能正常發(fā)通告但另一個節(jié)點(diǎn)收不到”所以重點(diǎn)永遠(yuǎn)是排查通信鏈路而不是懷疑Keepalived本身。5.5 非搶占模式nopreempt寫在哪很有講究默認(rèn)的Keepalived是搶占行為主節(jié)點(diǎn)恢復(fù)后會立刻把VIP搶回來。但有些業(yè)務(wù)場景不允許VIP頻繁切換比如長連接服務(wù)一旦切換就要斷連重連。這時需要配置非搶占模式。網(wǎng)上很多配置都寫錯了。注意nopreempt只能寫在BACKUP節(jié)點(diǎn)的vrrp_instance里并且兩個節(jié)點(diǎn)的state都要寫B(tài)ACKUP只靠priority區(qū)分主次。原因在于Keepalived只在BACKUP狀態(tài)下才會處理nopreempt邏輯。如果你在MASTER節(jié)點(diǎn)上寫nopreempt根本不會生效。還有一種更平滑的方案是preempt_delay主節(jié)點(diǎn)恢復(fù)后等待一段時間再搶占比如300秒給業(yè)務(wù)和網(wǎng)絡(luò)一個穩(wěn)定窗口期。5.6 健康檢查腳本的隱性坑健康檢查腳本看起來簡單實(shí)際上坑不少。第一個坑是權(quán)限腳本沒有執(zhí)行權(quán)限Keepalived會直接判定腳本執(zhí)行失敗。第二個坑是環(huán)境變量比如腳本里用到某個軟件的絕對路徑但Keepalived的systemd環(huán)境里PATH和交互式shell不一致導(dǎo)致命令找不到。第三個坑是超時如果腳本執(zhí)行時間超過了timeout配置會被直接判為失敗。我的建議是腳本先用root手動執(zhí)行一遍確認(rèn)返回碼正確腳本里所有命令用絕對路徑腳本執(zhí)行時間務(wù)必小于配置的timeout如果腳本在業(yè)務(wù)高峰期可能變慢就把timeout適當(dāng)調(diào)大同時把fall閾值調(diào)大避免CPU抖動導(dǎo)致誤判。5.7 云主機(jī)上的單播改造云環(huán)境是當(dāng)前部署Keepalived的重要場景。傳統(tǒng)物理機(jī)環(huán)境下VRRP用組播方式互發(fā)通告組播地址是224.0.0.18交換機(jī)默認(rèn)會轉(zhuǎn)發(fā)同網(wǎng)段組播。但許多公有云的VPC網(wǎng)絡(luò)并不支持VRRP組播兩臺節(jié)點(diǎn)互相收不到報(bào)文結(jié)果都認(rèn)為自己該當(dāng)MASTER。解決辦法是把Keepalived改成單播模式在vrrp_instance里寫unicast_src_ip 192.168.10.10 unicast_peer { 192.168.10.11 }這樣本節(jié)點(diǎn)只向指定的對端IP發(fā)送VRRP通告不再依賴組播。同時云平臺安全組也要放行對應(yīng)協(xié)議和端口。我在任何云主機(jī)上部署Keepalived時不管平臺是否支持組播都會直接使用單播配置寧可多寫兩行也不給自己留隱患。6. 場景延伸Keepalived在Nginx、MySQL、RabbitMQ高可用中的接入方式6.1 Keepalived不具備業(yè)務(wù)感知感知邏輯都在腳本里搞清楚這一點(diǎn)你就能理解為什么Keepalived能接那么多不同場景。它自身只負(fù)責(zé)VRRP協(xié)議和VIP漂移而對業(yè)務(wù)進(jìn)程是否正常的判斷全部交給vrrp_script里的腳本。所以要想讓Keepalived監(jiān)控某種服務(wù)只需要寫對應(yīng)的檢測腳本檢測Nginx就檢查nginx進(jìn)程和80端口檢測MySQL就檢查mysqld進(jìn)程和3306端口檢測RabbitMQ就檢查rabbitmq-server和5672端口。框架完全一樣只需要改腳本內(nèi)容。這也是Keepalived在Linux運(yùn)維體系里長盛不衰的原因它足夠底層、足夠通用。6.2 Nginx高可用最標(biāo)準(zhǔn)的一套組合NginxKeepalived是目前最常見的組合做法也最簡單。兩臺Nginx服務(wù)器各自啟動Nginx監(jiān)聽自己的本機(jī)IPKeepalived提供VIP。客戶端訪問VIPVIP落在哪臺機(jī)器上請求就打到哪臺機(jī)器的Nginx。當(dāng)MASTER的Nginx進(jìn)程異常退出check腳本返回非0Keepalived主動讓出VIPBACKUP接管VIP后通過notify_master里的腳本確保本機(jī)Nginx也在運(yùn)行。這樣整體對外提供的服務(wù)地址始終不變。需要提醒的是不要在notify_master里只做“切換VIP”這件事一定要確認(rèn)業(yè)務(wù)進(jìn)程本身可用否則就是VIP切過去了業(yè)務(wù)反而不可用這種“假高可用”我在生產(chǎn)上見過不止一次。6.3 MySQL和RabbitMQ等中間件的高可用思路很多接觸Keepalived的人都是為了解決MySQL、RabbitMQ這類中間件的高可用問題。以MySQL主從場景為例正常情況下VIP掛在主庫上應(yīng)用連接串里寫的是VIP主庫故障后VIP漂移到從庫應(yīng)用不需要改配置。健康檢查腳本要同時探測本機(jī)IP的3306端口和數(shù)據(jù)庫進(jìn)程狀態(tài)避免只檢測進(jìn)程存活而端口已經(jīng)不可用的情況。RabbitMQ類似腳本里檢查5672端口或進(jìn)程狀態(tài)配合notify腳本做集群節(jié)點(diǎn)止損。但要直說Keepalived只解決了“入口漂移”解決不了中間件內(nèi)部的數(shù)據(jù)同步、腦裂等問題。MySQL的數(shù)據(jù)一致性得靠半同步復(fù)制或額外的高可用編排工具RabbitMQ的鏡像隊(duì)列、仲裁隊(duì)列也有自己的高可用機(jī)制。Keepalived適合作為最上層的接入入口別指望它包辦一切。6.4 給生產(chǎn)環(huán)境的幾條配置建議最后把這些年看到的問題匯總成幾條生產(chǎn)建議第一雙節(jié)點(diǎn)的Keepalived配置一定要放在版本控制里配置文件改動需要可回溯不然線上有一次手誤改錯了優(yōu)先級就是一次隱蔽故障。第二VIP的地址要提前規(guī)劃好不要用DHCP可能分配的地址否則IP沖突時候的故障極其難查。第三advert_int不要為了追求切換速度無限調(diào)小網(wǎng)絡(luò)抖動會引起VIP反復(fù)漂移我一般保持默認(rèn)1秒即可。第四每個節(jié)點(diǎn)的日志和notify日志要有獨(dú)立文件并配置輪轉(zhuǎn)Keepalived本身日志量不大但vrrp通告在故障期間會連續(xù)輸出不輪轉(zhuǎn)的話可能撐爆磁盤。第五高可用演練要定期做不要只在剛部署時做一次。Keepalived這套東西配置本身不復(fù)雜真正考驗(yàn)人的是故障發(fā)生時的判斷力而這種判斷力只能靠一次次真實(shí)演練積累出來。