我遇到過(guò)不止一次Nginx進(jìn)程悄悄退出的情況。最難忘的是某天凌晨?jī)牲c(diǎn)爆出的那通告警——某業(yè)務(wù)系統(tǒng)前端的Nginx突然完全無(wú)響應(yīng)用戶請(qǐng)求全部卡在連接階段等我們摸黑登錄服務(wù)器、檢查日志、重啟服務(wù)、確認(rèn)恢復(fù)業(yè)務(wù)已經(jīng)斷了將近四十分鐘。那臺(tái)Nginx就是典型的單機(jī)部署沒有任何冗余俗稱單點(diǎn)。那次事故之后我所在的團(tuán)隊(duì)老老實(shí)實(shí)地把Nginx高可用集群排上了日程做的就是經(jīng)典的NginxKeepalived主從熱備方案。今天這篇文章我就把從方案選型、環(huán)境規(guī)劃、配置落地到模擬故障切換、處理各種真實(shí)坑的完整過(guò)程整理出來(lái)希望對(duì)正在計(jì)劃給Nginx加一層保障的運(yùn)維或后端同學(xué)有實(shí)際參考價(jià)值。1. 單點(diǎn)事故的代價(jià)Nginx高可用到底在解決什么問(wèn)題1.1 Nginx進(jìn)程退出之后的連鎖反應(yīng)單點(diǎn)故障這件事聽起來(lái)很簡(jiǎn)單——一臺(tái)機(jī)器壞了服務(wù)就斷了。但真正實(shí)施下來(lái)連鎖反應(yīng)遠(yuǎn)比想象中麻煩。那次事故里Nginx不只是負(fù)責(zé)轉(zhuǎn)發(fā)請(qǐng)求它前面連著用戶入口后面連著應(yīng)用服務(wù)器。Nginx一掛所有請(qǐng)求進(jìn)不來(lái)后端的應(yīng)用其實(shí)還活著但用戶根本夠不著。業(yè)務(wù)側(cè)反饋過(guò)來(lái)的時(shí)候我們連到底是網(wǎng)絡(luò)問(wèn)題、DNS問(wèn)題、防火墻問(wèn)題還是Nginx問(wèn)題都排查了好一會(huì)兒。復(fù)盤時(shí)我們發(fā)現(xiàn)單點(diǎn)Nginx的問(wèn)題不只是進(jìn)程掛掉這一種可能。機(jī)器硬件故障、內(nèi)核崩潰、磁盤寫滿導(dǎo)致的異常、被人誤操作改了配置后reload失敗、機(jī)房網(wǎng)絡(luò)閃斷……任何一種情況都能讓Nginx從正常變?yōu)椴豢捎谩Ｓ械膱?chǎng)景下服務(wù)器可能還開著但進(jìn)程已經(jīng)不在了有的場(chǎng)景下機(jī)器徹底失聯(lián)。想要應(yīng)對(duì)這一整類問(wèn)題就必須從架構(gòu)層面做冗余讓故障發(fā)生時(shí)業(yè)務(wù)能自動(dòng)切走而不是等工程師被叫起來(lái)手動(dòng)恢復(fù)。1.2 主從熱備模型虛擬IP與故障漂移主從熱備的基本思路通俗地說(shuō)就是讓兩臺(tái)Nginx節(jié)點(diǎn)組成一個(gè)雙人值守的小組。對(duì)外只暴露一個(gè)虛擬IPVIP平時(shí)由主節(jié)點(diǎn)MASTER持有這個(gè)VIP并處理全部流量備節(jié)點(diǎn)BACKUP在主節(jié)點(diǎn)正常時(shí)處于待命狀態(tài)不接流量只通過(guò)心跳監(jiān)控主節(jié)點(diǎn)的健康狀況。一旦主節(jié)點(diǎn)失聯(lián)或Nginx進(jìn)程異常備節(jié)點(diǎn)會(huì)迅速把VIP搶到本機(jī)上接管服務(wù)整個(gè)過(guò)程對(duì)調(diào)用方基本不可見。這里最關(guān)鍵的設(shè)計(jì)就是虛擬IP?？蛻舳嗽L問(wèn)的始終是這個(gè)固定的VIP而不是某一臺(tái)具體服務(wù)器的IP。所以無(wú)論VIP落在主節(jié)點(diǎn)還是備節(jié)點(diǎn)上對(duì)用戶來(lái)說(shuō)入口沒有變。這套思路可以類比小區(qū)配置兩個(gè)值班保安住戶進(jìn)出只認(rèn)門衛(wèi)室這個(gè)位置今天A保安在崗還是B保安在崗住戶不需要關(guān)心只要門衛(wèi)室始終有人就行。兩臺(tái)Nginx之間怎么知道對(duì)方還活著這就是Keepalived的工作了。Keepalived基于VRRP協(xié)議實(shí)現(xiàn)節(jié)點(diǎn)間的狀態(tài)同步和自動(dòng)failover它會(huì)在兩臺(tái)設(shè)備之間周期性地發(fā)送心跳報(bào)文。心跳連續(xù)丟失達(dá)到閾值備節(jié)點(diǎn)就判定主節(jié)點(diǎn)故障立刻在本機(jī)綁定VIP、對(duì)外發(fā)送免費(fèi)ARP通告讓交換機(jī)把虛擬IP對(duì)應(yīng)的流量切換到本機(jī)。1.3 為什么鎖定了Keepalived而不是其他高可用方案很多人問(wèn)過(guò)我高可用方案那么多為什么不直接用DNS輪詢、云廠商的負(fù)載均衡或者干脆上LVS我的體會(huì)是方案沒有絕對(duì)的好壞關(guān)鍵是看場(chǎng)景。DNS輪詢的做法是給域名解析多個(gè)A記錄指向不同Nginx節(jié)點(diǎn)。好處是配置簡(jiǎn)單但壞處也很明顯——DNS解析結(jié)果存在客戶端和Local DNS緩存里某一臺(tái)節(jié)點(diǎn)宕機(jī)后仍然會(huì)有大量請(qǐng)求打到故障IP上。而且這種方案本質(zhì)上是負(fù)載均衡不是主備容災(zāi)單個(gè)節(jié)點(diǎn)故障時(shí)受影響的范圍不好控制。云負(fù)載均衡比如各種云SLB在公有云環(huán)境里確實(shí)好用托管維護(hù)、自帶健康檢查。但如果你所在的環(huán)境是自有機(jī)房或者客戶明確要求內(nèi)網(wǎng)閉環(huán)再或者出于成本考慮不想引入額外的LB層Keepalived這種輕量級(jí)方案就很有優(yōu)勢(shì)。它不需要額外硬件不改變現(xiàn)有Nginx架構(gòu)兩臺(tái)服務(wù)器裝上軟件、寫好配置就具備故障漂移能力學(xué)習(xí)和維護(hù)成本都不高。2. 環(huán)境規(guī)劃與基礎(chǔ)準(zhǔn)備主備節(jié)點(diǎn)、VIP和系統(tǒng)參數(shù)2.1 節(jié)點(diǎn)與IP規(guī)劃動(dòng)手之前一定要畫一張清晰的規(guī)劃表別等配置寫完了才發(fā)現(xiàn)VIP網(wǎng)段和業(yè)務(wù)網(wǎng)段沖突或者兩臺(tái)節(jié)點(diǎn)根本不在同一個(gè)二層網(wǎng)絡(luò)里。以我們當(dāng)時(shí)的部署為例兩臺(tái)Nginx節(jié)點(diǎn)跑在同一個(gè)交換機(jī)二層網(wǎng)絡(luò)中使用私有地址段。規(guī)劃如下角色主機(jī)名物理IP虛擬IP用途MASTERngx-node-01192.168.1.10192.168.1.100接收VIP流量主節(jié)點(diǎn)BACKUPngx-node-02192.168.1.11192.168.1.100主節(jié)點(diǎn)故障時(shí)接管VIP虛擬IP必須和兩臺(tái)節(jié)點(diǎn)處于同一廣播域內(nèi)Keepalived的VRRP報(bào)文依賴組播或多播廣播跨了網(wǎng)段就會(huì)失效。生產(chǎn)環(huán)境中建議把Keepalived的心跳通信單獨(dú)規(guī)劃一條網(wǎng)線或獨(dú)立網(wǎng)段避免業(yè)務(wù)流量高峰期把心跳報(bào)文也擠丟了這是后話。操作系統(tǒng)我們用的是CentOS 7.9內(nèi)核版本3.10Keepalived版本1.3.5。當(dāng)然你用其他主流Linux發(fā)行版也完全可以配置思路一致只是包管理命令和部分系統(tǒng)路徑會(huì)有差異。2.2 安裝Nginx并準(zhǔn)備差異測(cè)試頁(yè)Nginx的安裝這里不展開細(xì)說(shuō)yum源直接裝即可。裝完之后我給兩臺(tái)節(jié)點(diǎn)分別準(zhǔn)備了一個(gè)不同的首頁(yè)文件用于后面的切換測(cè)試。主節(jié)點(diǎn)的/usr/share/nginx/html/index.html內(nèi)容h1Node: ngx-node-01/h1 pThis is MASTER nginx instance./p備節(jié)點(diǎn)的/usr/share/nginx/html/index.html內(nèi)容h1Node: ngx-node-02/h1 pThis is BACKUP nginx instance./p同時(shí)把Nginx設(shè)為開機(jī)自啟systemctl enable nginx systemctl start nginx這樣設(shè)置的目的是為了在驗(yàn)證故障切換時(shí)能通過(guò)curl http://192.168.1.100返回的不同頁(yè)面內(nèi)容直觀地判斷當(dāng)前VIP到底落在哪臺(tái)節(jié)點(diǎn)上。2.3 系統(tǒng)基礎(chǔ)配置防火墻、SELinux和時(shí)間同步這塊最容易在部署時(shí)被忽略卻在關(guān)鍵時(shí)刻拖后腿。首先是防火墻很多人的Keepalived一直報(bào)不出心跳排查了一圈發(fā)現(xiàn)是防火墻把VRRP協(xié)議擋了。VRRP使用的不是普通的TCP/UDP端口而是IP協(xié)議號(hào)112CentOS中需要放行對(duì)應(yīng)的規(guī)則。firewall-cmd --permanent --add-protocolvrrp firewall-cmd --permanent --add-servicehttp firewall-cmd --reload如果是舊版iptables要放行VRRP協(xié)議可以參照iptables -A INPUT -p vrrp -i eth0 -j ACCEPT然后是SELinux。默認(rèn)的enforcing模式下Keepalived調(diào)用外部腳本、綁定虛擬IP、發(fā)送通告都可能被攔截排查起來(lái)非常隱蔽。我們當(dāng)時(shí)直接設(shè)置為permissive模式保證功能先跑通生產(chǎn)環(huán)境需要按自己公司的安全基線來(lái)權(quán)衡。setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config時(shí)間同步也必須做好。Keepalived自身對(duì)時(shí)間不是特別敏感但整個(gè)集群里的日志時(shí)間線、證書有效期判斷、業(yè)務(wù)系統(tǒng)時(shí)間戳都依賴一致的時(shí)間源。用chrony統(tǒng)一對(duì)時(shí)避免后面排查問(wèn)題時(shí)日志時(shí)間對(duì)不上。3. Keepalived安裝與核心配置拆解心跳、優(yōu)先級(jí)和檢測(cè)腳本3.1 VRRP的工作機(jī)制與Keepalived的角色切換Keepalived的核心是VRRP虛擬路由冗余協(xié)議。協(xié)議的思想很簡(jiǎn)單一組路由器這里就是Nginx節(jié)點(diǎn)共同對(duì)外提供一個(gè)虛擬IP其中優(yōu)先級(jí)最高的節(jié)點(diǎn)成為Master負(fù)責(zé)響應(yīng)VIP上的請(qǐng)求Master周期性發(fā)送VRRP廣告報(bào)文其余節(jié)點(diǎn)收到后確認(rèn)Master還活著繼續(xù)待在Backup狀態(tài)。如果Backup在連續(xù)幾個(gè)廣告周期內(nèi)都沒收到Master的報(bào)文就會(huì)認(rèn)為Master已經(jīng)不可用于是按照優(yōu)先級(jí)最高的Backup順序進(jìn)入Master狀態(tài)接管VIP。Keepalived在這個(gè)基礎(chǔ)上又增加了track_script機(jī)制——不僅檢測(cè)網(wǎng)絡(luò)狀態(tài)還能定期執(zhí)行自定義腳本根據(jù)腳本返回值決定是否降低本節(jié)點(diǎn)優(yōu)先級(jí)甚至主動(dòng)移交VIP。理解這個(gè)機(jī)制之后再回來(lái)看配置就會(huì)非常清晰優(yōu)先級(jí)、心跳間隔、檢測(cè)腳本這三個(gè)要素決定了整個(gè)集群的切換行為。3.2 主節(jié)點(diǎn)Keepalived配置全解析安裝Keepalivedyum install -y keepalived主節(jié)點(diǎn)的配置文件/etc/keepalived/keepalived.conf如下global_defs { router_id ngx-node-01 enable_script_security } vrrp_script check_nginx { script /usr/local/bin/check_nginx.sh interval 2 timeout 2 weight -20 fall 2 rise 2 } vrrp_instance VI_NGX { state MASTER interface eth0 virtual_router_id 51 priority 150 advert_int 1 authentication { auth_type PASS auth_pass 123456 } track_script { check_nginx } virtual_ipaddress { 192.168.1.100/24 dev eth0 } }逐段解釋一下關(guān)鍵配置的含義。global_defs里面的router_id是當(dāng)前節(jié)點(diǎn)的標(biāo)識(shí)在兩臺(tái)節(jié)點(diǎn)上必須不同。enable_script_security用于限制Keepalived執(zhí)行外部腳本時(shí)的安全性避免腳本環(huán)境變量被濫用官方文檔建議開啟。vrrp_script check_nginx定義了一個(gè)檢測(cè)任務(wù)。script指定檢測(cè)腳本絕對(duì)路徑interval 2表示每2秒執(zhí)行一次timeout 2表示腳本執(zhí)行超過(guò)2秒視為超時(shí)weight -20表示腳本返回非0時(shí)當(dāng)前節(jié)點(diǎn)優(yōu)先級(jí)降低20fall 2和rise 2表示連續(xù)失敗2次才判定服務(wù)異常連續(xù)成功2次才判定恢復(fù)這是為了防止腳本偶發(fā)抖動(dòng)導(dǎo)致頻繁切換。vrrp_instance VI_NGX是VRRP實(shí)例的配置。state MASTER聲明該節(jié)點(diǎn)初始角色是主節(jié)點(diǎn)interface eth0指定心跳報(bào)文走哪塊網(wǎng)卡一定是物理網(wǎng)卡而不是VIP所在的虛擬網(wǎng)卡virtual_router_id 51是一個(gè)虛擬路由器ID同一組主備節(jié)點(diǎn)必須保持一致priority 150是節(jié)點(diǎn)優(yōu)先級(jí)數(shù)字越大越優(yōu)先成為Masteradvert_int 1是心跳報(bào)文發(fā)送間隔單位秒通常保持默認(rèn)1秒即可。authentication塊配置節(jié)點(diǎn)間認(rèn)證。auth_type PASS表示密碼認(rèn)證auth_pass是明文密碼。注意Keepalived只取密碼前8位所以密碼不要超過(guò)8個(gè)字符否則超出部分會(huì)被忽略反而容易造成兩臺(tái)節(jié)點(diǎn)配置不一致。virtual_ipaddress配置虛擬IP。192.168.1.100/24 dev eth0表示VIP綁定在eth0上子網(wǎng)掩碼24位。這里有個(gè)細(xì)節(jié)寫成帶掩碼和dev的形式比只寫一個(gè)IP更明確能避免某些系統(tǒng)下路由和ARP異常。3.3 備節(jié)點(diǎn)配置與主節(jié)點(diǎn)的差異備節(jié)點(diǎn)的配置大體復(fù)制主節(jié)點(diǎn)只需要改動(dòng)四個(gè)地方router_id、state、priority和節(jié)點(diǎn)自身標(biāo)識(shí)。備節(jié)點(diǎn)配置如下global_defs { router_id ngx-node-02 enable_script_security } vrrp_script check_nginx { script /usr/local/bin/check_nginx.sh interval 2 timeout 2 weight -20 fall 2 rise 2 } vrrp_instance VI_NGX { state BACKUP interface eth0 virtual_router_id 51 priority 120 advert_int 1 authentication { auth_type PASS auth_pass 123456 } track_script { check_nginx } virtual_ipaddress { 192.168.1.100/24 dev eth0 } }兩個(gè)節(jié)點(diǎn)優(yōu)先級(jí)相差30這個(gè)差值必須大于檢測(cè)腳本的weight絕對(duì)值。主節(jié)點(diǎn)檢測(cè)失敗時(shí)優(yōu)先級(jí)從150降到130仍然大于備節(jié)點(diǎn)的120主節(jié)點(diǎn)不會(huì)因?yàn)橐淮螜z測(cè)失敗就把VIP讓出去。但如果主節(jié)點(diǎn)整體宕機(jī)網(wǎng)絡(luò)斷開、機(jī)器失聯(lián)備節(jié)點(diǎn)收不到任何VRRP報(bào)文就會(huì)直接接管VIP此時(shí)優(yōu)先級(jí)差就不再重要。理解這個(gè)優(yōu)先級(jí)與weight之間的數(shù)值關(guān)系才能靈活設(shè)計(jì)進(jìn)程異常時(shí)切換、機(jī)器宕機(jī)時(shí)切換、輕微故障時(shí)不來(lái)回抖的預(yù)期行為。3.4 檢測(cè)腳本Nginx是否活著的準(zhǔn)確判斷檢測(cè)腳本是Keepalived配置中靈魂般的存在它決定了故障到底是整機(jī)失聯(lián)還是Nginx進(jìn)程掛了。我們的腳本如下#!/bin/bash # 檢測(cè) nginx master 進(jìn)程是否存在 if pidof nginx /dev/null 21; then exit 0 else exit 1 fi腳本邏輯很簡(jiǎn)單pidof nginx能查到nginx進(jìn)程就返回0否則返回1。寫完一定要加上執(zhí)行權(quán)限chmod x /usr/local/bin/check_nginx.sh這個(gè)腳本有兩個(gè)常見的坑。一個(gè)是不要用ps -ef | grep nginx | grep -v grep | wc -l這類方式因?yàn)間rep自身進(jìn)程可能匹配到關(guān)鍵字而且統(tǒng)計(jì)數(shù)量容易誤判另一個(gè)是腳本路徑不要放在/etc/keepalived/目錄下有些Keepalived版本在啟動(dòng)或重載時(shí)會(huì)清理該目錄下的非配置文件內(nèi)容腳本容易莫名其妙消失。放在/usr/local/bin這類系統(tǒng)路徑里更安全。也可以做得更嚴(yán)格一點(diǎn)比如用Nginx的健康檢查接口配合curl來(lái)判斷進(jìn)程是否真的在服務(wù)請(qǐng)求而不只是進(jìn)程存在。但對(duì)于主從熱備場(chǎng)景進(jìn)程級(jí)檢測(cè)通常夠用過(guò)度復(fù)雜的健康檢查反而會(huì)引入新的誤判因素。4. 主從熱備的驗(yàn)證實(shí)驗(yàn)?zāi)M宕機(jī)、切換和回切全流程4.1 啟動(dòng)集群并確認(rèn)VIP歸屬配置全部就緒后在兩臺(tái)節(jié)點(diǎn)上啟動(dòng)Keepalivedsystemctl enable keepalived systemctl start keepalived先看主節(jié)點(diǎn)上VIP是否綁定成功ip addr show eth0正常情況下主節(jié)點(diǎn)的eth0上除了物理IP192.168.1.10還會(huì)多出一個(gè)192.168.1.100/24的地址。備節(jié)點(diǎn)上不應(yīng)該出現(xiàn)這個(gè)VIP。此時(shí)訪問(wèn)VIP應(yīng)該返回主節(jié)點(diǎn)的頁(yè)面curl http://192.168.1.100返回內(nèi)容Node: ngx-node-01說(shuō)明流量確實(shí)打在主節(jié)點(diǎn)上。再確認(rèn)心跳狀態(tài)systemctl status keepalived或者看消息日志tail -f /var/log/messages | grep VRRP能看到類似VRRP_Instance(VI_NGX) Entering MASTER STATE的日志說(shuō)明節(jié)點(diǎn)正常進(jìn)入了Master狀態(tài)。4.2 場(chǎng)景一Nginx進(jìn)程異常觸發(fā)切換生產(chǎn)環(huán)境中進(jìn)程被誤殺、內(nèi)存不足被OOM殺掉、配置文件錯(cuò)誤導(dǎo)致worker進(jìn)程退出這些都是比較常見的故障。我們先用最直接的方式模擬在主節(jié)點(diǎn)上停掉Nginx。systemctl stop nginx然后觀察主節(jié)點(diǎn)的日志會(huì)看到檢測(cè)腳本連續(xù)執(zhí)行失敗觸發(fā)優(yōu)先級(jí)降低最終退出Master狀態(tài)。同時(shí)在備節(jié)點(diǎn)上能看到進(jìn)入Master狀態(tài)的日志。幾條典型的日志片段VRRP_Script(check_nginx) failed VRRP_Instance(VI_NGX) Received lower prio advert, forcing new election VRRP_Instance(VI_NGX) Entering BACKUP STATE備節(jié)點(diǎn)日志VRRP_Instance(VI_NGX) Transition to MASTER STATE VRRP_Instance(VI_NGX) Sending gratuitous ARP on eth0 VRRP_Instance(VI_NGX) Entering MASTER STATE備節(jié)點(diǎn)進(jìn)入Master后執(zhí)行ip addr show eth0可以看到VIP192.168.1.100已經(jīng)出現(xiàn)在備節(jié)點(diǎn)上而主節(jié)點(diǎn)上的VIP已經(jīng)消失。再次訪問(wèn)VIPcurl http://192.168.1.100返回內(nèi)容Node: ngx-node-02。整個(gè)切換過(guò)程從Nginx停止到VIP漂移完成大約3到5秒取決于檢測(cè)腳本的間隔和失敗次數(shù)設(shè)置。用戶側(cè)最多只會(huì)感覺到一次短暫的連接抖動(dòng)不會(huì)出現(xiàn)長(zhǎng)時(shí)間無(wú)法訪問(wèn)。4.3 場(chǎng)景二整機(jī)宕機(jī)與恢復(fù)后的搶占回切更嚴(yán)重的故障是主節(jié)點(diǎn)整臺(tái)機(jī)器宕機(jī)比如斷電、硬件故障、系統(tǒng)崩潰。這時(shí)主節(jié)點(diǎn)連心跳報(bào)文都不再發(fā)送備節(jié)點(diǎn)等待超時(shí)后直接接管VIP和上面觀察到的現(xiàn)象基本一致。區(qū)別在于整機(jī)宕機(jī)時(shí)備節(jié)點(diǎn)完全收不到Master的VRRP報(bào)文所以它在advert_int乘以幾倍的超時(shí)窗口之后就會(huì)切換通常也是一到三秒級(jí)別。接下來(lái)看回切行為。把主節(jié)點(diǎn)的Nginx和Keepalived都恢復(fù)起來(lái)systemctl start nginx systemctl start keepalived在默認(rèn)配置下主節(jié)點(diǎn)啟動(dòng)后會(huì)重新以150的優(yōu)先級(jí)參與選舉備節(jié)點(diǎn)收到更高優(yōu)先級(jí)的報(bào)文后自動(dòng)退出Master狀態(tài)VIP會(huì)回切到主節(jié)點(diǎn)。這個(gè)行為叫搶占preempt。從高可用角度來(lái)說(shuō)搶占能保證流量回到配置更完善、資源更充裕的主節(jié)點(diǎn)上但也會(huì)帶來(lái)一個(gè)問(wèn)題如果主節(jié)點(diǎn)反復(fù)抖動(dòng)每次回切都會(huì)造成一次連接中斷。如果業(yè)務(wù)不希望主節(jié)點(diǎn)恢復(fù)后立刻搶回VIP可以在備節(jié)點(diǎn)配置中加入nopreempt讓角色切換只在故障發(fā)生時(shí)觸發(fā)正常情況下VIP穩(wěn)定在當(dāng)前節(jié)點(diǎn)。但要注意nopreempt的使用有講究需要在vrrp_instance中配置并且主節(jié)點(diǎn)通常也要把state設(shè)為BACKUP單純通過(guò)優(yōu)先級(jí)區(qū)分誰(shuí)是事實(shí)主節(jié)點(diǎn)否則搶占行為不會(huì)被完全抑制。4.4 切換過(guò)程中的連接保持問(wèn)題主從熱備能解決服務(wù)入口不中斷但它解決不了正在進(jìn)行的請(qǐng)求不中斷。舉個(gè)例子用戶正在通過(guò)VIP下載一個(gè)大文件或者長(zhǎng)輪詢接口正在等待數(shù)據(jù)。切換發(fā)生時(shí)TCP連接的狀態(tài)存儲(chǔ)在主節(jié)點(diǎn)的內(nèi)核協(xié)議棧上而備節(jié)點(diǎn)上并沒有這些連接狀態(tài)所以VIP漂移后這些存量連接會(huì)全部斷開用戶需要重新發(fā)起請(qǐng)求。對(duì)于大多數(shù)HTTP短連接業(yè)務(wù)來(lái)說(shuō)影響的只是切換瞬間的少量請(qǐng)求重試一次就夠了。如果業(yè)務(wù)對(duì)中斷容忍度極低單純NginxKeepalived是不夠的還需要在更上層配合會(huì)話保持策略、客戶端重試機(jī)制或者引入四層負(fù)載均衡方案把連接層的狀態(tài)管理從Nginx節(jié)點(diǎn)中抽離出來(lái)。搞清楚主從熱備的邊界比盲目追求零切換更實(shí)際。5. 實(shí)際部署中容易踩的坑與調(diào)優(yōu)建議5.1 那些隱蔽的坑防火墻、SELinux、腳本權(quán)限和腦裂每次幫別人排查Keepalived問(wèn)題最后發(fā)現(xiàn)的大多不是配置理解問(wèn)題而是這些不起眼的環(huán)境問(wèn)題。防火墻不放行VRRP是最常見的一個(gè)?，F(xiàn)象是兩臺(tái)節(jié)點(diǎn)都認(rèn)為自己是Master或者備節(jié)點(diǎn)一直收不到心跳日志里沒有任何切換動(dòng)作。檢查方法很簡(jiǎn)單在兩臺(tái)節(jié)點(diǎn)上tcpdump -i eth0 vrrp看能否抓到對(duì)方的VRRP報(bào)文。抓不到基本就是被防火墻或交換機(jī)策略擋住了。SELinux影響的是腳本執(zhí)行。我遇到過(guò)檢測(cè)腳本明明有執(zhí)行權(quán)限手動(dòng)跑也沒問(wèn)題但Keepalived執(zhí)行時(shí)就是失敗的情況日志里只顯示腳本超時(shí)或返回異常。后來(lái)發(fā)現(xiàn)是SELinux攔截了對(duì)腳本文件的訪問(wèn)。要么把腳本所在目錄的權(quán)限調(diào)整好要么直接臨時(shí)改成permissive模式驗(yàn)證。腳本權(quán)限更基礎(chǔ)卻最容易犯。chmod x少了配置寫錯(cuò)了路徑腳本用了#!/bin/bash但文件格式是CRLF這些都會(huì)導(dǎo)致檢測(cè)腳本不可用。建議寫完腳本先手動(dòng)跑一次確認(rèn)返回碼符合預(yù)期再交給Keepalived去調(diào)用。腦裂是雙節(jié)點(diǎn)集群最怕的問(wèn)題即兩個(gè)節(jié)點(diǎn)都認(rèn)為自己是MasterVIP同時(shí)出現(xiàn)在兩臺(tái)機(jī)器上。這種情況會(huì)導(dǎo)致流量在不同節(jié)點(diǎn)之間來(lái)回抖動(dòng)甚至出現(xiàn)數(shù)據(jù)不一致。觸發(fā)原因通常是心跳網(wǎng)絡(luò)中斷而業(yè)務(wù)網(wǎng)絡(luò)正?；蛘叻阑饓Π腴_只放行了部分方向。緩解措施包括心跳線用獨(dú)立網(wǎng)段或直連網(wǎng)線檢測(cè)腳本里加上對(duì)端IP連通性檢查以及利用告警機(jī)制及時(shí)察覺雙Master狀態(tài)。5.2 調(diào)優(yōu)參數(shù)與狀態(tài)通知讓集群可控可觀測(cè)Keepalived配置文件里值得優(yōu)化的參數(shù)不少我挑幾個(gè)重點(diǎn)說(shuō)說(shuō)。advert_int決定心跳頻率。默認(rèn)1秒適合大多數(shù)場(chǎng)景調(diào)小到0.5秒能加快故障感知但會(huì)增加網(wǎng)絡(luò)壓力和誤判概率調(diào)大到2秒以上則切換變慢適合心跳網(wǎng)絡(luò)帶寬受限的場(chǎng)景。這個(gè)值需要和檢測(cè)腳本的interval配合考慮不要為了追求極端速度犧牲穩(wěn)定性。weight的取值直接影響切換行為。如果你希望只有進(jìn)程死掉才切換weight的絕對(duì)值必須小于主備優(yōu)先級(jí)差值如果你希望檢測(cè)失敗就立即切換weight可以把主節(jié)點(diǎn)優(yōu)先級(jí)壓到備節(jié)點(diǎn)之下。我們配置里主備優(yōu)先級(jí)相差30、weight是20就意味著進(jìn)程異常時(shí)主節(jié)點(diǎn)還在只是優(yōu)先級(jí)降到130繼續(xù)留著。但如果加上fall 2的連續(xù)失敗判定實(shí)際效果比單純看weight更可靠因?yàn)樗腔谶B續(xù)失敗次數(shù)的綜合判斷。狀態(tài)通知是個(gè)容易被忽略但非常實(shí)用的功能?？梢栽趘rrp_instance中配合notify_master、notify_backup、notify_fault在角色切換時(shí)觸發(fā)自定義腳本發(fā)送釘釘、企業(yè)微信或郵件告警。實(shí)現(xiàn)故障發(fā)生時(shí)第一時(shí)間知道而不是等業(yè)務(wù)側(cè)反饋才知道。一個(gè)簡(jiǎn)單的通知腳本示例如下#!/bin/bash # /usr/local/bin/notify_keepalived.sh case $1 in master) echo $(date) become MASTER /var/log/keepalived-notify.log # 在這里調(diào)用 curl 發(fā)送 webhook 告警 ;; backup) echo $(date) become BACKUP /var/log/keepalived-notify.log ;; fault) echo $(date) enter FAULT /var/log/keepalived-notify.log ;; esac配置中對(duì)應(yīng)加入notify_master /usr/local/bin/notify_keepalived.sh master notify_backup /usr/local/bin/notify_keepalived.sh backup notify_fault /usr/local/bin/notify_keepalived.sh fault有了通知主從切換不再是一個(gè)黑盒事件每次切換都有跡可循。5.3 從主從到更復(fù)雜的形態(tài)雙活與熱備的擴(kuò)展主從熱備是一個(gè)很好的起點(diǎn)但不是終點(diǎn)。當(dāng)兩臺(tái)Nginx機(jī)器跑在主從模式下時(shí)備機(jī)大部分時(shí)間都是空閑的從資源利用率角度看有點(diǎn)浪費(fèi)。如果業(yè)務(wù)量增長(zhǎng)可以考慮把架構(gòu)演進(jìn)為互為主備的雙活模式兩臺(tái)節(jié)點(diǎn)各自帶一個(gè)VIP分別承接一部分業(yè)務(wù)流量同時(shí)互為對(duì)方的備份。Keepalived配置里增加第二個(gè)vrrp_instance讓A節(jié)點(diǎn)在實(shí)例1中是MASTER、在實(shí)例2中是BACKUPB節(jié)點(diǎn)則反著來(lái)這樣兩臺(tái)機(jī)器的資源都利用起來(lái)了。還可以在Nginx前面加LVS或四層負(fù)載均衡形成兩級(jí)的高可用體系?；蛘甙袺eepalived的檢測(cè)腳本擴(kuò)展成更完整的健康檢查比如檢查后端應(yīng)用端口、檢查磁盤空間、檢查系統(tǒng)負(fù)載讓集群的故障切換決策更聰明。但這些都屬于有了主從熱備之后的下一步延伸先把基礎(chǔ)的主從熱備穩(wěn)定跑通再根據(jù)業(yè)務(wù)需要逐層加碼才是穩(wěn)妥的演進(jìn)路徑。最后分享一個(gè)我個(gè)人的習(xí)慣每半年至少手動(dòng)做一次主從切換演練把切換腳本、通知腳本、備節(jié)點(diǎn)上的配置一致性全部驗(yàn)證一遍。人類是健忘的動(dòng)物集群也一樣——太久不切換真的到了需要切換的那天往往會(huì)發(fā)現(xiàn)備節(jié)點(diǎn)配置文件早就過(guò)期了或者腳本權(quán)限被人動(dòng)過(guò)或者防火墻策略早就變了。演練不一定能完全避免事故但至少能保證在事故來(lái)臨時(shí)你不需要一邊盯著日志一邊祈禱。