負載均衡是衡量初中級以上運維技術水平的重要標尺!

負載均衡是普通運維人員很難有機會接觸和系統(tǒng)學習的知識!

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

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

負載均衡的均衡是相對的，當訪問量很小的時候，這個差異會明顯一些。一旦上量，差別就會縮小。比如活躍數(shù)都是數(shù)千個，一些機器多幾十或者少幾百，你不會覺得有什么不妥。

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

2. 哪種負載均衡工具更好?

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

看場景吧，緩存類的應用，如squid適合lvs;其它情形可根據(jù)自己的使用習慣來選擇。

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

3. vip不漂移怎么辦?

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

這類錯誤比較難以排查，在書寫的時候，一定要仔細。

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

4. 完成負載均衡的***實踐?

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

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

• 檢查后端真實服務是否正常。
• 綁定負載均衡器的本地ip(不要綁vip)，測試訪問是否正常。
• 綁定vip進行訪問，檢查訪問是否正常。

5. 什么情況下需要負載均衡?

有人說我沒那么大的訪問量，用負載均衡有點浪費。負載均衡是實現(xiàn)高可用的手段之一，不是以流量大小為出發(fā)點的。

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

還有人說，我用了阿里云、騰訊云，彈性計算、高可用，買個高配的云主機，要什么負載均衡!建議多了解一下，這些云服務商有專門的負載均衡，要花錢的，用不著的話，它推這個有啥意義?

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

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

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

7. 公有云上的負載均衡?

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

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

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

8. 如何快速排查負載均衡故障?

步驟如下：

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

9. 有負載均衡就完事無憂了么?

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

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

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

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

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

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