負(fù)載均衡是衡量初中級(jí)以上運(yùn)維技術(shù)水平的重要標(biāo)尺!

負(fù)載均衡是普通運(yùn)維人員很難有機(jī)會(huì)接觸和系統(tǒng)學(xué)習(xí)的知識(shí)!

1. 負(fù)載均衡轉(zhuǎn)發(fā)數(shù)重要嗎?

keepalived + lvs 的組合，執(zhí)行ipvsadm ，輸出的數(shù)據(jù)顯示了每個(gè)后端服務(wù)器連接的數(shù)量，一些服務(wù)器的值高些，而一些卻低一些。一些人糾結(jié)：怎么a服務(wù)器活躍數(shù)是90，而b服務(wù)器才55?

負(fù)載均衡的均衡是相對(duì)的，當(dāng)訪問(wèn)量很小的時(shí)候，這個(gè)差異會(huì)明顯一些。一旦上量，差別就會(huì)縮小。比如活躍數(shù)都是數(shù)千個(gè)，一些機(jī)器多幾十或者少幾百，你不會(huì)覺(jué)得有什么不妥。

負(fù)載均衡的主要目標(biāo)是高可用，只要負(fù)載均衡、監(jiān)控檢查、失敗切換三個(gè)功能正常，并且從用戶的角度出發(fā)，訪問(wèn)應(yīng)用(比如網(wǎng)站)一切正常，才是重點(diǎn)，多幾個(gè)負(fù)載量，少幾個(gè)負(fù)載量無(wú)關(guān)緊要。

2. 哪種負(fù)載均衡工具更好?

lvs + keepalived、haproxy+nginx、nginx + keepalived幾種組合，keepalived倒是一致之選，而其它幾個(gè)工具，選誰(shuí)更好呢?

看場(chǎng)景吧，緩存類(lèi)的應(yīng)用，如squid適合lvs;其它情形可根據(jù)自己的使用習(xí)慣來(lái)選擇。

現(xiàn)在一般的web服務(wù)，棄用apache而選nginx居多，如果負(fù)載均衡再部署一個(gè)nginx，變成keepalived + nginx + nginx 的形式，個(gè)人感覺(jué)有點(diǎn)別扭，更愿意選擇haproxy。

3. vip不漂移怎么辦?

很多時(shí)候可能是輸入的時(shí)候不小心，犯了低級(jí)的錯(cuò)誤。比如keepalived里邊，主備兩系統(tǒng)的router_id不一致、或者virtual_router_id不一致。

這類(lèi)錯(cuò)誤比較難以排查，在書(shū)寫(xiě)的時(shí)候，一定要仔細(xì)。

另外一個(gè)情況可能是，在同一個(gè)局域網(wǎng)內(nèi)，有多個(gè)負(fù)載均衡集群存在，集群之間的router_id 、virtual_router_id 要注意分別，保持唯一性。

4. 完成負(fù)載均衡的***實(shí)踐?

經(jīng)常在網(wǎng)上有人求助，按文檔部署的集群不能正常的工作。通過(guò)溝通，發(fā)現(xiàn)工作方式往往不正確。

那么正確、高效的方式是什么呢(有些人稱(chēng)***實(shí)踐)?請(qǐng)往下看：

• 檢查后端真實(shí)服務(wù)是否正常。
• 綁定負(fù)載均衡器的本地ip(不要綁vip)，測(cè)試訪問(wèn)是否正常。
• 綁定vip進(jìn)行訪問(wèn)，檢查訪問(wèn)是否正常。

5. 什么情況下需要負(fù)載均衡?

有人說(shuō)我沒(méi)那么大的訪問(wèn)量，用負(fù)載均衡有點(diǎn)浪費(fèi)。負(fù)載均衡是實(shí)現(xiàn)高可用的手段之一，不是以流量大小為出發(fā)點(diǎn)的。

如果你的公司或者機(jī)構(gòu)，主要收入來(lái)自與網(wǎng)絡(luò)的話，發(fā)生故障造成服務(wù)不可訪問(wèn)，造成的損失是否可以忍受，考慮好這個(gè)，再做決策。

還有人說(shuō)，我用了阿里云、騰訊云，彈性計(jì)算、高可用，買(mǎi)個(gè)高配的云主機(jī)，要什么負(fù)載均衡!建議多了解一下，這些云服務(wù)商有專(zhuān)門(mén)的負(fù)載均衡，要花錢(qián)的，用不著的話，它推這個(gè)有啥意義?

6. 開(kāi)源軟件不穩(wěn)定嗎?

這是商業(yè)解決供應(yīng)商的說(shuō)辭，他們的市場(chǎng)做得比較成功，以至于一些技術(shù)人員，一旦提及開(kāi)源解決方案，***反應(yīng)就是：開(kāi)源的穩(wěn)定么?性能上得去么?

前幾天有個(gè)系統(tǒng)集成商也只要質(zhì)疑，我回答他：“你拿一個(gè)商業(yè)軟件，我找一個(gè)對(duì)應(yīng)的開(kāi)源軟件比比如何?”

7. 公有云上的負(fù)載均衡?

大部分公有云不提供havip支持，因此在技術(shù)上不太容易實(shí)現(xiàn)負(fù)載均衡。

從產(chǎn)品設(shè)計(jì)上考慮，用戶自己部署負(fù)載均衡，會(huì)與云服務(wù)商推出的服務(wù)產(chǎn)生沖突。

從其不斷推出的產(chǎn)品線來(lái)看，恨不得把所有的服務(wù)都囊括進(jìn)去，讓用戶從此依賴(lài)服務(wù)商，財(cái)源滾滾。

8. 如何快速排查負(fù)載均衡故障?

步驟如下：

• 確定問(wèn)題是部分還是全部?是網(wǎng)絡(luò)問(wèn)題還是系統(tǒng)問(wèn)題?
• 檢查后端服務(wù)是否正常。因?yàn)楹蠖瞬攀钦鎸?shí)提供服務(wù)的場(chǎng)所，是整個(gè)負(fù)載均衡存在的根基(就算負(fù)載均衡體系暫時(shí)崩潰了，只要后端服務(wù)正常，可臨時(shí)采取措施，把用戶請(qǐng)求直接暴露給用戶，可最快速度恢復(fù)業(yè)務(wù))。在實(shí)際的工作中，大部分的故障集中在后端服務(wù)器，比如大名鼎鼎的502。
• 排查負(fù)載均衡是否正常。一般情況下，負(fù)載均衡服務(wù)器基本不安裝其它服務(wù)(一機(jī)多用者慎重)，因此，除了硬盤(pán)被日志塞滿產(chǎn)生故障外，另外一個(gè)可能就是硬件損壞。本人管理的系統(tǒng)，運(yùn)行時(shí)間最長(zhǎng)的負(fù)載均衡服務(wù)器，有超過(guò)八年沒(méi)趴窩的。

9. 有負(fù)載均衡就完事無(wú)憂了么?

部署了負(fù)載均衡，后端服務(wù)器可以部分失效、負(fù)載均衡器本身也可以有一個(gè)失效?？雌饋?lái)很讓人放心，就算發(fā)生故障，也暫時(shí)能頂一陣。是不是慢吞吞地地心情好了，想起來(lái)了再去做故障恢復(fù)?

***不要這樣干，有故障發(fā)生，發(fā)現(xiàn)以后，盡可能快的把故障修復(fù)并再次加入集群，不玩心跳。

10. 負(fù)載均衡能承載多大的并發(fā)?

這與后端服務(wù)關(guān)系密切，后端程序、邏輯性能***，承載的并發(fā)數(shù)就大;反之就小，無(wú)確切的數(shù)據(jù)支撐。

上線前，有可能對(duì)系統(tǒng)做壓力測(cè)試，但這種測(cè)試大部分是一致性測(cè)試(至少是同一個(gè)訪問(wèn)源)，與真實(shí)的用戶訪問(wèn)還是存在很大差異。

真實(shí)的用戶訪問(wèn)，來(lái)源不同，訪問(wèn)的對(duì)象不同，比如有的用戶網(wǎng)絡(luò)環(huán)境差，訪問(wèn)速度慢，完成一次連接的時(shí)間長(zhǎng)，占有資源的釋放時(shí)間就要久一些。這種測(cè)試可做大概的參考，評(píng)估時(shí)應(yīng)該預(yù)留余量。