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