第一次在生產(chǎn)環(huán)境同時(shí)面對(duì)LVS、Keepalived、HAProxy這三兄弟時(shí)很多人第一反應(yīng)是這仨不都是做負(fù)載均衡的嗎為什么一臺(tái)機(jī)器上要裝兩三個(gè)這個(gè)問(wèn)題我當(dāng)年也糾結(jié)了很久直到某個(gè)凌晨被線上告警炸醒——兩臺(tái)后端同時(shí)宕機(jī)Keepalived沒(méi)把VIP切走流量全部打到一臺(tái)半死的機(jī)器上我才真正明白它們根本不是競(jìng)爭(zhēng)關(guān)系而是完全不同的三個(gè)角色。這篇文章就用我踩過(guò)的坑和實(shí)際在跑的生產(chǎn)配置把這幾個(gè)組件的分工、選型和避坑一次性說(shuō)透。不管你是剛?cè)腴T要搭第一套高可用架構(gòu)還是已經(jīng)在維護(hù)線上環(huán)境想排查疑難問(wèn)題這里面的內(nèi)容都應(yīng)該能幫到你。1. 先把三兄弟的分工一次說(shuō)清楚1.1 用物流分揀中心理解三個(gè)角色先忘掉技術(shù)名詞想象一個(gè)大型物流分揀中心。貨車到了園區(qū)門口保安先看車牌和貨物類型能放行的直接放行到對(duì)應(yīng)月臺(tái)這是四層轉(zhuǎn)發(fā)只認(rèn)網(wǎng)絡(luò)層和傳輸層的信息速度快到幾乎沒(méi)有存在感——這就是LVS的角色。園區(qū)里邊有個(gè)調(diào)度臺(tái)值班人員不僅看貨物類型還要看收件人地址、偏好甚至指定日期再?zèng)Q定送哪個(gè)倉(cāng)庫(kù)這是七層分發(fā)功能強(qiáng)、能感知應(yīng)用層內(nèi)容——這就是HAProxy的角色。而保安和調(diào)度臺(tái)背后還有一套考勤和輪崗制度主值班員倒班時(shí)副值班員要無(wú)縫頂上這個(gè)保證“關(guān)鍵時(shí)刻有人管事”的機(jī)制——就是Keepalived。把這三個(gè)角色放到同一套架構(gòu)里分工就很清楚了LVS負(fù)責(zé)在數(shù)據(jù)鏈路層/網(wǎng)絡(luò)層把海量連接快速分散到多臺(tái)機(jī)器HAProxy負(fù)責(zé)在七層做精細(xì)化流量調(diào)度Keepalived則負(fù)責(zé)監(jiān)控并保證入口VIP不因?yàn)閱吸c(diǎn)故障而失效。理解了這層關(guān)系你就不會(huì)糾結(jié)“能不能只用HAProxy不用LVS”這種問(wèn)題了——當(dāng)然能取決于你的規(guī)模和需求但你也得知道大流量場(chǎng)景下LVS那層“無(wú)狀態(tài)轉(zhuǎn)發(fā)”的動(dòng)作HAProxy無(wú)論如何也替代不了。1.2 LVS四層轉(zhuǎn)發(fā)的效率之王LVS的全稱是Linux Virtual Server工作在四層支持TCP/UDP的負(fù)載均衡。它最核心的產(chǎn)品力是“快”。因?yàn)椴恍枰馕鯤TTP頭部不需要維護(hù)復(fù)雜的會(huì)話狀態(tài)多數(shù)模式下LVS的轉(zhuǎn)發(fā)吞吐量可以做到逼近網(wǎng)卡物理上限。生產(chǎn)中最常用的是DR模式Direct Routing它的原理是客戶端請(qǐng)求到達(dá)LVS的VIP后LVS通過(guò)MAC地址把報(bào)文原封不動(dòng)地發(fā)給選中的后端真實(shí)服務(wù)器后端處理完以后直接把響應(yīng)回給客戶端回程流量根本不再經(jīng)過(guò)LVS。這種“請(qǐng)求經(jīng)過(guò)、響應(yīng)不走”的方式讓LVS在巨大流量面前依然從容。DR模式雖然高效代價(jià)是配置有門檻。需要調(diào)整的不僅LVS本身還有后端兩臺(tái)真實(shí)服務(wù)器的內(nèi)核參數(shù)和回程路由壞消息是這部分網(wǎng)上資料很多都含糊其辭。我在生產(chǎn)里見(jiàn)過(guò)最典型的翻車現(xiàn)場(chǎng)realserver沒(méi)有抑制ARP導(dǎo)致VIP在局域網(wǎng)內(nèi)被真實(shí)服務(wù)器“搶答”客戶端訪問(wèn)VIP時(shí)請(qǐng)求走到了其中一臺(tái)后端但LVS的轉(zhuǎn)發(fā)規(guī)則也好、健康檢查也好全部失效看起來(lái)就是集群時(shí)好時(shí)壞。所以提到LVS千萬(wàn)不要只把它當(dāng)一條ipvsadm命令來(lái)記它背后是一套需要配合內(nèi)核網(wǎng)絡(luò)策略的完整鏈路。1.3 Keepalived不是為了負(fù)載均衡是為了不宕機(jī)Keepalived這個(gè)命名本身就點(diǎn)出了它的核心任務(wù)讓服務(wù)“一直活著”。它基于VRRP協(xié)議實(shí)現(xiàn)高可用常見(jiàn)形態(tài)是一主一備兩臺(tái)機(jī)器綁定同一個(gè)VIP正常情況下VIP掛在主節(jié)點(diǎn)上主節(jié)點(diǎn)掛掉后備節(jié)點(diǎn)通過(guò)優(yōu)先級(jí)競(jìng)選把VIP和對(duì)應(yīng)服務(wù)接管過(guò)來(lái)。它本身不做負(fù)載均衡決策只做一件事故障時(shí)保證VIP不丟、服務(wù)不中斷。理解Keepalived的關(guān)鍵在于“虛擬”二字。VIP不是物理網(wǎng)卡上的固定地址而是通過(guò)VRRP協(xié)議在兩臺(tái)機(jī)器之間“飄”的;客戶端感知不到這個(gè)漂移過(guò)程只知道自己訪問(wèn)的IP一直有人在響應(yīng)。Keepalived除了漂移VIP還承擔(dān)對(duì)后端真實(shí)服務(wù)器的健康檢查任務(wù)在LVS場(chǎng)景下它會(huì)把多個(gè)real_server配置到一起哪個(gè)掛了就把它從轉(zhuǎn)發(fā)列表里摘掉恢復(fù)后自動(dòng)加回。也就是說(shuō)Keepalived其實(shí)干了兩件事管VIP漂移同時(shí)管后端狀態(tài)同步到轉(zhuǎn)發(fā)規(guī)則。1.4 HAProxy七層世界的規(guī)則處理器HAProxy是目前最流行的開(kāi)源七層負(fù)載均衡器支持HTTP和TCP協(xié)議配置靈活內(nèi)置豐富的ACL規(guī)則、健康檢查和會(huì)話保持能力。很多中小團(tuán)隊(duì)第一套高可用架構(gòu)就是“Keepalived HAProxy”前面Keepalived?；詈竺鍴AProxy把請(qǐng)求按域名、URI、Header甚至Cookie規(guī)則分發(fā)到后端。和LVS相比HAProxy能感知應(yīng)用層內(nèi)容可以做更細(xì)粒度的灰度發(fā)布、路徑路由、請(qǐng)求改寫這是四層轉(zhuǎn)發(fā)做不到的。HAProxy的快不僅體現(xiàn)在吞吐上還體現(xiàn)在它對(duì)連接的生命周期管理上。它把連接分成前端和后端來(lái)維護(hù)可以緩存空閑連接、限制慢客戶端占用資源降低“慢請(qǐng)求拖垮正常服務(wù)”的概率。但也正因?yàn)楣ぷ髟谄邔親AProxy需要做更多的報(bào)文解析內(nèi)存占用和CPU開(kāi)銷都要高于LVS。生產(chǎn)上很多團(tuán)隊(duì)會(huì)在HAProxy前面再擋一層LVS就是為了讓七層機(jī)器盡量只干“精細(xì)活”海量連接交給四層去扛。到這里三者的位置基本清楚了Keepalived負(fù)責(zé)“活著”LVS負(fù)責(zé)“快”HAProxy負(fù)責(zé)“懂規(guī)則”。接下來(lái)真正的核心問(wèn)題是這三者怎么排列組合才合理2. 架構(gòu)選型到底該用哪種組合2.1 雙節(jié)點(diǎn)起步Keepalived HAProxy 的高可用入口如果你的業(yè)務(wù)量目標(biāo)是每日百萬(wàn)級(jí)別以內(nèi)后端服務(wù)是HTTP接口且需要細(xì)粒度路由那么最經(jīng)典的組合就是兩臺(tái)HAProxy節(jié)點(diǎn)前面掛一個(gè)Keepalived漂移VIP后面接若干個(gè)應(yīng)用服務(wù)器。這個(gè)架構(gòu)的好處是簡(jiǎn)單、直觀、好排查Keepalived配置只管VIP和健康檢查HAProxy只管轉(zhuǎn)發(fā)規(guī)則兩層互不干擾。出了問(wèn)題無(wú)非就是看“是VIP沒(méi)飄成功”還是“轉(zhuǎn)發(fā)規(guī)則有問(wèn)題”一條日志追到底。但這套架構(gòu)有一個(gè)容易被忽視的瓶頸——HAProxy本身的狀態(tài)。即使Keepalived健康檢查手段再豐富它也只能知道HAProxy進(jìn)程還活著無(wú)法感知進(jìn)程是否處于半死狀態(tài)比如處理線程卡死、accept隊(duì)列堆積、后端連接全滿。遇到這種“進(jìn)程沒(méi)死但干活越來(lái)越慢”的情況Keepalived不會(huì)觸發(fā)切換用戶實(shí)際感受到的依然是故障。我以前就碰到過(guò)HAProxy的連接數(shù)被慢客戶端吃光進(jìn)程還在但新請(qǐng)求全部排隊(duì)超時(shí)?；顧C(jī)制完全沒(méi)有反應(yīng)。所以用Keepalived做HAProxy的?；顣r(shí)健康檢查必須設(shè)計(jì)成“業(yè)務(wù)探活”不能只做進(jìn)程級(jí)檢查。2.2 大流量入口雙LVS在前HAProxy在后當(dāng)流量再往上走單靠HAProxy扛不住需要引入LVS做入口卸載。典型架構(gòu)是最前面兩臺(tái)LVS服務(wù)器跑Keepalived綁定VIP后面掛一組HAProxy集群也是兩臺(tái)或更多各自再接KeepalivedHAProxy再把流量分發(fā)給后端的應(yīng)用服務(wù)器?？蛻舳酥徽J(rèn)VIPLVS把流量轉(zhuǎn)發(fā)到HAProxy節(jié)點(diǎn)HAProxy做完七層路由后再往后拋——兩層負(fù)載均衡各司其職HAProxy不會(huì)再被海量并發(fā)連接壓垮。很多朋友會(huì)問(wèn)既然LVS都能扛住大量并發(fā)為什么HAProxy這層不干脆去掉答案在于“精細(xì)化”和“規(guī)?；笔莾蓷l線。LVS的DR模式轉(zhuǎn)發(fā)效率極高但它只認(rèn)IP和端口做不了“根據(jù)URI把流量切到不同版本的后端”這種需求。而HAProxy的ACL和調(diào)度策略非常成熟在七層灰度、多域名共存的環(huán)境下幾乎不可替代。所以這個(gè)組合不是冗余而是讓每層都只做自己擅長(zhǎng)的事。如果你有跨機(jī)房容災(zāi)需求LVS在前也能更方便地和交換機(jī)策略聯(lián)動(dòng)比如宣告VIP路由調(diào)試起來(lái)比HAProxy要平滑。2.3 選型決策的四個(gè)核心考量點(diǎn)第一看規(guī)模。日請(qǐng)求量在千萬(wàn)級(jí)以內(nèi)QPS峰值幾千到幾萬(wàn)單層HAProxy足夠不必硬上LVS。第二看流量特征。如果業(yè)務(wù)是長(zhǎng)連接數(shù)據(jù)庫(kù)代理、WebSocket、TCP隧道四層負(fù)載更合適LVS或HAProxy的tcp模式都可以如果是HTTP短連接且要按域名和路徑分流必須上七層。第三看團(tuán)隊(duì)運(yùn)維水平。LVS的DR模式對(duì)網(wǎng)絡(luò)參數(shù)、后端系統(tǒng)配置的要求更高排錯(cuò)時(shí)涉及tcpdump、ARP表、ipvs內(nèi)核表新手團(tuán)隊(duì)貿(mào)然上LVS容易在細(xì)節(jié)上踩坑。第四看業(yè)務(wù)對(duì)故障恢復(fù)的要求。Keepalived能做到的切換時(shí)間通常2秒以內(nèi)LVSKeepalivedHAProxy這套架構(gòu)可以將切換做到秒級(jí)且?guī)缀鯚o(wú)感知但配置和測(cè)試成本也相應(yīng)增加。2.4 演進(jìn)路線從小規(guī)模到大規(guī)模的平滑升級(jí)我的建議是不要一上來(lái)就上最重的方案而是隨著流量增長(zhǎng)逐步演進(jìn)出層次。初期使用單臺(tái)HAProxy做反代過(guò)段時(shí)間加一臺(tái)做Keepalived高可用業(yè)務(wù)快速增長(zhǎng)、HAProxy成為瓶頸時(shí)在前面插入LVS卸載連接再往后如果有多活需求再在DNS或全局負(fù)載層引入多機(jī)房調(diào)度。每一次演進(jìn)都應(yīng)該單一變更可回滾不追求一步到位。我見(jiàn)過(guò)團(tuán)隊(duì)一開(kāi)始就搭了三層負(fù)載均衡結(jié)果線上排故障時(shí)排查鏈路太長(zhǎng)性能沒(méi)成為問(wèn)題人的認(rèn)知先成了瓶頸——架構(gòu)演進(jìn)要跟著業(yè)務(wù)節(jié)奏走不是越復(fù)雜越好。3. 核心實(shí)操雙LVS Keepalived HAProxy架構(gòu)完整落地3.1 整體拓?fù)渑c角色分配為了講清楚落地細(xì)節(jié)我給出一個(gè)對(duì)應(yīng)章節(jié)2.2的參考拓?fù)渖a(chǎn)完全可以照抄改IP。前面的兩臺(tái)LVS節(jié)點(diǎn)一臺(tái)MASTER一臺(tái)BACKUP跑VRRP綁定VIP后面兩臺(tái)HAProxy節(jié)點(diǎn)也組成一個(gè)VRRP組綁定后端VIP組再往后是兩臺(tái)Nginx應(yīng)用服務(wù)器。LVS通過(guò)DR模式把VIP上的80端口流量轉(zhuǎn)發(fā)給兩臺(tái)HAProxyHAProxy再按域名規(guī)則把請(qǐng)求分給Nginx。這樣任意一臺(tái)LVS或HAProxy宕機(jī)業(yè)務(wù)都不會(huì)中斷——LVS層面由Keepalived切換HAProxy層面由它自己的Keepalived切換。具體IP規(guī)劃如下VIP為192.168.1.100LVS主節(jié)點(diǎn)192.168.1.11LVS備節(jié)點(diǎn)192.168.1.12HAProxy節(jié)點(diǎn)分別192.168.1.21和192.168.1.22后端Nginx分別為192.168.1.31和192.168.1.32。所有機(jī)器在同一個(gè)二層網(wǎng)絡(luò)這是DR模式能工作的前提。生產(chǎn)環(huán)境如果跨VLANDR模式的廣播和ARP策略會(huì)變得很麻煩這也是為什么有些場(chǎng)景會(huì)改用NAT模式的原因。3.2 配置LVS節(jié)點(diǎn)上的Keepalived安裝Keepalived的過(guò)程這里不贅述yum或apt直接裝就行重點(diǎn)看keepalived.conf的寫法。以下是我的生產(chǎn)實(shí)例vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass yourpassword } virtual_ipaddress { 192.168.1.100/24 dev eth0 label eth0:0 } } virtual_server 192.168.1.100 80 { delay_loop 5 lb_algo wrr lb_kind DR protocol TCP # LVS會(huì)轉(zhuǎn)發(fā)流量到這組真實(shí)服務(wù)器也就是后面的HAProxy節(jié)點(diǎn) real_server 192.168.1.21 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } real_server 192.168.1.22 80 { weight 1 HTTP_GET { url { path /healthz status_code 200 } connect_timeout 3 nb_get_retry 3 delay_before_retry 2 } } }backup節(jié)點(diǎn)的配置只需要把state改成BACKUP、priority改成90其他保持一致。這里有兩個(gè)關(guān)鍵點(diǎn)lb_kind一定要寫DR否則LVS會(huì)走NAT模式轉(zhuǎn)發(fā)邏輯完全不同real_server的健康檢查建議用HTTP_GET而不要用TCP_CHECK因?yàn)門CP能連通不代表HAProxy真的能返回正常的業(yè)務(wù)響應(yīng)尤其要確保HAProxy上有/healthz這個(gè)探活地址并且該接口不依賴后端的數(shù)據(jù)庫(kù)或緩存否則容易出現(xiàn)“健康檢查跟著后端一起抖動(dòng)”的連鎖問(wèn)題。注意vrrp_instance中virtual_router_id必須兩機(jī)一致keepalived才能互相認(rèn)出彼此是同一個(gè)VRRP組的成員不一致會(huì)導(dǎo)致兩邊都認(rèn)為自己該持有VIP直接造成腦裂。authentication_pass這個(gè)參數(shù)也是寫錯(cuò)了日志里會(huì)出現(xiàn)不斷的VRRP包校驗(yàn)失敗。3.3 配置后端HAProxy節(jié)點(diǎn)的內(nèi)核網(wǎng)絡(luò)參數(shù)這一節(jié)是最容易翻車的也是LVS的DR模式之所以勸退很多新手的地方。DR模式下LVS轉(zhuǎn)發(fā)給后端的數(shù)據(jù)包目標(biāo)MAC地址是后端網(wǎng)卡但目標(biāo)IP依然是VIP192.168.1.100。后端收到這個(gè)包后如果按照正常工作流程本機(jī)網(wǎng)卡發(fā)現(xiàn)目標(biāo)IP不是自己的IP比如本機(jī)只有192.168.1.21會(huì)直接把包丟棄——所以必須在每臺(tái)HAProxy節(jié)點(diǎn)上把VIP綁定到lo這塊虛擬網(wǎng)卡上ifconfig lo:0 192.168.1.100 netmask 255.255.255.255 up這里用了32位掩碼而不是常見(jiàn)的24位。原因很微妙如果掩碼是24位系統(tǒng)會(huì)認(rèn)為整個(gè)192.168.1.0/24網(wǎng)段的流量都應(yīng)該通過(guò)lo轉(zhuǎn)發(fā)反而會(huì)干擾正常的東西向流量甚至路由決策用32位掩碼則只宣告VIP本身屬于本機(jī)精準(zhǔn)且安全。光綁定地址還不夠必須抑制ARP響應(yīng)。如果不做后端節(jié)點(diǎn)會(huì)響應(yīng)客戶端發(fā)往VIP的ARP請(qǐng)求告訴“VIP在這臺(tái)機(jī)器上”流量就被引流到了某一臺(tái)后端LVS完全失去意義。需要在sysctl.conf中修改四個(gè)參數(shù)net.ipv4.conf.lo.arp_ignore 1 net.ipv4.conf.lo.arp_announce 2 net.ipv4.conf.all.arp_ignore 1 net.ipv4.conf.all.arp_announce 2執(zhí)行sysctl -p后再用arping或ip neigh看一遍VIP對(duì)應(yīng)的MAC地址確認(rèn)它只在LVS主節(jié)點(diǎn)上。還有一個(gè)坑是回程路由。DR模式要求后端響應(yīng)直接返回給客戶端但后端本身并沒(méi)有VIP它響應(yīng)的源地址應(yīng)該是VIP所以必須添加一個(gè)路由確保發(fā)送給VIP所在網(wǎng)段的包通過(guò)本機(jī)lo處理route add -host 192.168.1.100 dev lo這三個(gè)步驟做完后端節(jié)點(diǎn)才算真正能接住LVS丟過(guò)來(lái)的流量。我當(dāng)年遺漏了route add這一步結(jié)果是LVS不斷轉(zhuǎn)發(fā)、后端不斷丟包健康檢查還顯示正常因?yàn)榻】禉z查走的是單獨(dú)IP線上故障全靠用戶來(lái)報(bào)告狼狽極了。3.4 配置HAProxy的關(guān)鍵性能參數(shù)HAProxy的核心配置分成global、defaults、frontend、backend幾個(gè)塊。為了保證在高并發(fā)下不拖后腿我習(xí)慣在生產(chǎn)里這樣寫global maxconn 100000 nbproc 2 nbthread 4 pidfile /var/run/haproxy.pid defaults mode http timeout connect 5s timeout client 30s timeout server 30s timeout http-keep-alive 2s option httplog option forwardfor frontend main bind *:80 # 簡(jiǎn)單按域名分流的例子 acl is_payment hdr_dom(host) -i pay.example.com use_backend payment_servers if is_payment default_backend web_servers backend payment_servers balance roundrobin option httpchk GET /healthz server web1 192.168.1.31:80 check inter 3s fall 3 rise 2 server web2 192.168.1.32:80 check inter 3s fall 3 rise 2 backend web_servers balance leastconn option httpchk GET /healthz server web1 192.168.1.31:80 check inter 3s fall 3 rise 2 server web2 192.168.1.32:80 check inter 3s fall 3 rise 2這里值得展開(kāi)的是timeout與maxconn設(shè)置。前端和后端的timeout決不能照抄默認(rèn)值必須結(jié)合業(yè)務(wù)特征設(shè)置。比如你的頁(yè)面偶爾有慢查詢超過(guò)30秒那server timeout設(shè)30s就太短會(huì)造成正常請(qǐng)求被斷開(kāi)、用戶看到502但timeout設(shè)得過(guò)長(zhǎng)又會(huì)導(dǎo)致大量慢連接占住進(jìn)程資源。一個(gè)比較接地氣的做法是先看后端P99響應(yīng)時(shí)間再在這個(gè)基礎(chǔ)上加一倍作為server timeout參考值。maxconn同理100000這個(gè)值如果你們機(jī)器只有2C4G很可能內(nèi)存先爆掉實(shí)際應(yīng)該壓測(cè)后根據(jù)內(nèi)存使用率來(lái)反推。option forwardfor這行很容易被忽略但沒(méi)有它后端Nginx拿不到客戶端真實(shí)IP日志里全是HAProxy節(jié)點(diǎn)的地址排查訪問(wèn)來(lái)源會(huì)非常痛苦。3.5 驗(yàn)證與切換演練架構(gòu)搭完不是能通就收工一定要做幾輪故障演練。第一步在LVS主節(jié)點(diǎn)上執(zhí)行ip addr show確認(rèn)VIP掛在eth0:0上在LVS備節(jié)點(diǎn)上執(zhí)行ipvsadm -L -n確認(rèn)內(nèi)核轉(zhuǎn)發(fā)規(guī)則已經(jīng)從主節(jié)點(diǎn)同步過(guò)來(lái)。第二步模擬主節(jié)點(diǎn)宕機(jī)可以執(zhí)行systemctl stop keepalived來(lái)驗(yàn)證VIP是否在3秒內(nèi)漂移到備份節(jié)點(diǎn)。第三步做真實(shí)流量測(cè)試用ab或wrk打壓力同時(shí)kill掉一臺(tái)HAProxy觀察業(yè)務(wù)中斷時(shí)間。我建議把這套演練寫成固定腳本每次架構(gòu)變更后都自動(dòng)跑一遍。不要過(guò)度相信Keepalived本身任何VIP漂移機(jī)制的可靠性都必須在實(shí)際演練中驗(yàn)證因?yàn)槟悴恢澜粨Q機(jī)上有沒(méi)有開(kāi)啟STP、ARP緩存老化時(shí)間是多久等外部因素。生產(chǎn)中很多“Keepalived沒(méi)起作用”的案例并不是Keepalived的問(wèn)題而是二層環(huán)境的變化導(dǎo)致VRRP報(bào)文或VIP的ARP廣播被交換機(jī)策略攔截了這些只有演練才能暴露。4. 生產(chǎn)環(huán)境避坑指南那些文檔里不會(huì)寫的坑4.1 最隱蔽的坑ARP表緩存和VIP位置漂移DR模式下客戶端訪問(wèn)VIP時(shí)需要解析VIP的MAC地址。正常情況下VIP在LVS主節(jié)點(diǎn)上客戶端ARP表里記錄的就是LVS主節(jié)點(diǎn)網(wǎng)卡的MAC。主節(jié)點(diǎn)宕機(jī)后備節(jié)點(diǎn)廣播VRRP報(bào)文并接管VIP備節(jié)點(diǎn)會(huì)發(fā)送免費(fèi)的ARP廣播來(lái)刷新客戶端的ARP表。但有些交換機(jī)或云網(wǎng)絡(luò)環(huán)境會(huì)把這種免費(fèi)ARP包過(guò)濾掉客戶端依然往老MAC發(fā)請(qǐng)求結(jié)果就是VIP明明已經(jīng)漂移到備機(jī)線上還是大面積超時(shí)直到客戶的ARP表老化。這個(gè)問(wèn)題在物理機(jī)之間可以用ping一個(gè)廣播地址來(lái)強(qiáng)制刷新但更穩(wěn)妥的做法是在Keepalived的配置里加上vrrp_skip_check_adv_addr和vrrp_strict參數(shù)的理解同時(shí)確認(rèn)交換機(jī)的組播和未知單播洪泛策略放行了VRRP報(bào)文。云環(huán)境則更復(fù)雜因?yàn)楹芏嘣茝S商的虛擬網(wǎng)絡(luò)不標(biāo)準(zhǔn)支持VRRP這也是我后來(lái)在云上更傾向用SLB而不是自建LVS的原因。4.2 Keepalived腦裂主備同時(shí)持有VIP腦裂是指主備兩臺(tái)機(jī)器同時(shí)認(rèn)為自己是MASTER、同時(shí)持有VIP造成網(wǎng)絡(luò)上出現(xiàn)兩個(gè)相同IP的設(shè)備ARP混亂流量時(shí)好時(shí)壞非常隱蔽。誘發(fā)腦裂最常見(jiàn)的原因是VRRP組播報(bào)文被防火墻或安全組攔掉了主備之間收不到對(duì)方的hello包各自都認(rèn)為對(duì)方掛了于是各自搶占VIP。解決思路有三個(gè)維度網(wǎng)絡(luò)層面放行VRRP協(xié)議Keepalived內(nèi)部增加對(duì)端檢查腳本外部用仲裁機(jī)制兜底。我目前在生產(chǎn)里比較務(wù)實(shí)的方案是給Keepalived加一個(gè)自定義的smtp或script告警一旦檢測(cè)到本機(jī)持有VIP但VIP無(wú)法正常提供服務(wù)比如調(diào)用本地健康檢查腳本失敗就主動(dòng)降低本機(jī)優(yōu)先級(jí)并釋放VIP。這比指望防火墻規(guī)則永遠(yuǎn)正確要可靠得多。4.3 HAProxy后端的連接堆積與排隊(duì)七層負(fù)載均衡還有一個(gè)獨(dú)特的坑連接隊(duì)列堆積。HAProxy的maxconn設(shè)得再大后端應(yīng)用服務(wù)器也有自己的TCP連接上限。當(dāng)后端響應(yīng)變慢后端隊(duì)列滿了之后HAProxy會(huì)持續(xù)把新連接掛在自己的隊(duì)列里等待用戶感覺(jué)就像頁(yè)面卡死。這種現(xiàn)象在監(jiān)控圖上表現(xiàn)為HAProxy的qcur值一直往上爬。排查時(shí)先看HAProxy的統(tǒng)計(jì)頁(yè)通過(guò)stats socket或web界面找到qcur高、qmax大的實(shí)例和后臺(tái)server。生產(chǎn)上的處理手段一般分三步第一步臨時(shí)調(diào)低對(duì)應(yīng)后端的maxconn或調(diào)高后端的timeout server給后端喘息空間第二步定位后端變慢的原因通常是數(shù)據(jù)庫(kù)慢查詢、緩存穿透第三步在HAProxy上啟用排隊(duì)策略比如限制單IP最大連接數(shù)給慢客戶端單獨(dú)的池子避免正常請(qǐng)求被拖死。4.4 常見(jiàn)問(wèn)題速查表故障現(xiàn)象可能原因排查命令/思路VIP通的但業(yè)務(wù)時(shí)好時(shí)壞ARP表緩存沖突VIP被多臺(tái)機(jī)器響應(yīng)ip neigh、arping 檢查VIP對(duì)應(yīng)MAC是否始終在LVS主節(jié)點(diǎn)LVS轉(zhuǎn)發(fā)但后端總丟棄請(qǐng)求realserver未綁定VIP或未加回程路由ifconfig lo:0、route -n 確認(rèn)VIP綁定和路由Keepalived主備同時(shí)持有VIP組播被防火墻隔離vrid不一致tcpdump抓VRRP報(bào)文(224.0.0.18)檢查防火墻規(guī)則HAProxy健康檢查正常但轉(zhuǎn)發(fā)502后端超時(shí)或隊(duì)列滿看stats頁(yè)面的qcur/scur排查后端日志交換機(jī)斷網(wǎng)后VIP漂移失敗交換機(jī)STP收斂太慢或ARP緩存過(guò)大調(diào)整交換機(jī)端口fastport、恒定性ARP配置連接數(shù)增長(zhǎng)但CPU不高負(fù)載不平衡未配置leastconn檢查backend的balance策略改為leastconn試試上面這個(gè)表是我自己實(shí)際排障記錄改寫的基本覆蓋了新手到中級(jí)運(yùn)維最常遇到的問(wèn)題。排查思路有個(gè)共同點(diǎn)先確認(rèn)VIP在哪再確認(rèn)轉(zhuǎn)發(fā)規(guī)則有沒(méi)有生效最后再往后端追不要一開(kāi)始就在應(yīng)用日志里翻來(lái)翻去。這種分層排查的習(xí)慣比任何腳本都能更快幫你定位問(wèn)題。5. 性能評(píng)估與架構(gòu)演進(jìn)建議5.1 壓測(cè)思路與指標(biāo)預(yù)期整套架構(gòu)落地后必須壓測(cè)拿到真實(shí)數(shù)據(jù)否則你根本不知道它在什么時(shí)候會(huì)崩。壓測(cè)我建議分三層做。第一層只壓LVS用tcpreplay或pktgen生成純TCP包觀察LVS節(jié)點(diǎn)的CPU和丟包率這一層的重點(diǎn)不是QPS而是吞吐bps和ppsLVS在純轉(zhuǎn)發(fā)時(shí)瓶頸通常是物理網(wǎng)卡和內(nèi)核協(xié)議棧而不是軟件本身。第二層壓LVSHAProxy用wrk或ab打HTTP請(qǐng)求觀察HAProxy節(jié)點(diǎn)的CPU、內(nèi)存、連接隊(duì)列重點(diǎn)指標(biāo)是QPS、延遲和錯(cuò)誤率。第三層全鏈路壓到后端Nginx拉上數(shù)據(jù)庫(kù)或緩存一起壓看整個(gè)架構(gòu)的瓶頸到底在哪一層。壓測(cè)過(guò)程中我發(fā)現(xiàn)一個(gè)很有意思的現(xiàn)象很多時(shí)候瓶頸不在LVS也不在HAProxy而是后端Nginx的keepalive連接數(shù)和單個(gè)進(jìn)程的fd上限沒(méi)調(diào)好。用wrk測(cè)試時(shí)并發(fā)一上去后端日志馬上出現(xiàn)too many open files聯(lián)合創(chuàng)始人一晚上都在改ulimit——類似的坑現(xiàn)在如果你提前知道完全可以避免。5.2 流量再大之后從單集群到多活當(dāng)單集群的容量逼近極限或者有跨機(jī)房容災(zāi)需求時(shí)架構(gòu)還得繼續(xù)進(jìn)化。LVSKeepalived雖然能在單個(gè)集群內(nèi)做到秒級(jí)切換但跨機(jī)房就無(wú)能為力了。這時(shí)你會(huì)需要上層DNS、GSLB、云負(fù)載均衡或自建邊界集群來(lái)分流多個(gè)IDC。到了這個(gè)階段LVS和HAProxy仍然在單個(gè)機(jī)房?jī)?nèi)部起到重要作用但全局調(diào)度已經(jīng)不屬于它們的職責(zé)范圍。我在規(guī)模增長(zhǎng)過(guò)程中還發(fā)現(xiàn)LVS的VIP在單一集群里雖然好使但多機(jī)房場(chǎng)景下IP就變成了稀缺資源而且不同運(yùn)維團(tuán)隊(duì)對(duì)LVS的理解不一致也容易造成配置漂移。后期如果條件允許我會(huì)優(yōu)先考慮讓負(fù)載均衡團(tuán)隊(duì)統(tǒng)一維護(hù)一套IaC模板用terraform或ansible把LVS、Keepalived、HAProxy的配置全部代碼化減少人為修改帶來(lái)的不可控風(fēng)險(xiǎn)。這一點(diǎn)越早做越好別等到三十臺(tái)以上的機(jī)器再回頭改。5.3 架構(gòu)演進(jìn)中值得保留的細(xì)節(jié)演進(jìn)歸演進(jìn)有三個(gè)基礎(chǔ)細(xì)節(jié)是我無(wú)論架構(gòu)怎么變都一直保留的一是所有健康檢查都必須走“業(yè)務(wù)探活”絕不能只看進(jìn)程在不在二是所有VIP相關(guān)的ARP和路由變更都必須在變更前先宿主機(jī)演練不能被生產(chǎn)環(huán)境打臉三是壓測(cè)指標(biāo)和監(jiān)控報(bào)警要一直保留原始版本的對(duì)比數(shù)據(jù)方便快速判斷流量模式是否發(fā)生了變化。這些習(xí)慣看似瑣碎但在故障面前它們比任何想象中的“架構(gòu)先進(jìn)”都更能救你命。6. 寫在最后的一點(diǎn)個(gè)人體會(huì)負(fù)載均衡這套東西資料雖然多但真正能在生產(chǎn)里跑得穩(wěn)的組合往往是團(tuán)隊(duì)對(duì)每一層職責(zé)邊界理解最透徹的組合。我自己踩過(guò)不少坑有的坑是因?yàn)榕渲脜?shù)少寫了一行有的坑是因?yàn)榧軜?gòu)順序沒(méi)想清楚有的坑則是被網(wǎng)上各種千篇一律的教程誤導(dǎo)照著抄卻沒(méi)驗(yàn)證。如果你讀完這篇能記住三句話我會(huì)很滿足LVS解決并發(fā)吞吐問(wèn)題HAProxy解決業(yè)務(wù)分發(fā)問(wèn)題Keepalived解決故障高可用問(wèn)題。搞清楚每一層解決什么問(wèn)題選型就不會(huì)偏排障也不會(huì)手忙腳亂。最后再分享一個(gè)小技巧每次做架構(gòu)變更前先在本地用虛擬機(jī)關(guān)閉所有防火墻把LVS的轉(zhuǎn)發(fā)鏈路、Keepalived的VIP漂移、HAProxy的健康檢查全部實(shí)測(cè)一遍再?gòu)?fù)現(xiàn)一次故障切換確認(rèn)無(wú)誤后再上生產(chǎn)——這套流程看上去麻煩但相比線上出一次故障的成本劃算太多了。