負載均衡是衡量初中級以上運維技術水平的重要標尺！
負載均衡是普通運維人員很難有機會接觸和系統學習的知識！
keepalived + lvs 的組合，執行ipvsadm ，輸出的數據顯示了每個後端伺服器連接的數量，一些伺服器的值高些，而一些卻低一些。一些人糾結：怎麼a伺服器活躍數是90，而b伺服器才55？
負載均衡的均衡是相對的，當訪問量很小的時候，這個差異會明顯一些。一旦上量，差別就會縮小。比如活躍數都是數千個，一些機器多幾十或者少幾百，你不會覺得有什麼不妥。
負載均衡的主要目標是高可用，只要負載均衡、監控檢查、失敗切換三個功能正常，並且從用戶的角度出發，訪問應用（比如網站）一切正常，才是重點，多幾個負載量，少幾個負載量無關緊要。
lvs + keepalived、haproxy+nginx、nginx + keepalived幾種組合，keepalived倒是一致之選，而其它幾個工具，選誰更好呢？
看場景吧，緩存類的應用，如squid適合lvs；其它情形可根據自己的使用習慣來選擇。
現在一般的web服務，棄用apache而選nginx居多，如果負載均衡再部署一個nginx，變成keepalived + nginx + nginx 的形式，個人感覺有點彆扭，更願意選擇haproxy。
很多時候可能是輸入的時候不小心，犯了低級的錯誤。比如keepalived裡邊，主備兩系統的router_id不一致、或者virtual_router_id不一致。
這類錯誤比較難以排查，在書寫的時候，一定要仔細。
另外一個情況可能是，在同一個區域網內，有多個負載均衡集群存在，集群之間的router_id 、virtual_router_id 要注意分別，保持唯一性。
經常在網上有人求助，按文檔部署的集群不能正常的工作。通過溝通，發現工作方式往往不正確。
那么正確、高效的方式是什麼呢（有些人稱最佳實踐）？請往下看：
檢查後端真實服務是否正常。
綁定負載均衡器的本地ip（不要綁vip），測試訪問是否正常。
綁定vip進行訪問，檢查訪問是否正常。
有人說我沒那麼大的訪問量，用負載均衡有點浪費。負載均衡是實現高可用的手段之一，不是以流量大小為出發點的。
如果你的公司或者機構，主要收入來自與網絡的話，發生故障造成服務不可訪問，造成的損失是否可以忍受，考慮好這個，再做決策。
還有人說，我用了阿里雲、騰訊雲，彈性計算、高可用，買個高配的雲主機，要什麼負載均衡！建議多了解一下，這些雲服務商有專門的負載均衡，要花錢的，用不著的話，它推這個有啥意義？
這是商業解決供應商的說辭，他們的市場做得比較成功，以至於一些技術人員，一旦提及開源解決方案，第一反應就是：開源的穩定麼？性能上得去麼？
前幾天有個系統集成商也只要質疑，我回答他：「你拿一個商業軟體，我找一個對應的開源軟體比比如何？」
大部分公有雲不提供havip支持，因此在技術上不太容易實現負載均衡。
從產品設計上考慮，用戶自己部署負載均衡，會與雲服務商推出的服務產生衝突。
從其不斷推出的產品線來看，恨不得把所有的服務都囊括進去，讓用戶從此依賴服務商，財源滾滾。
步驟如下：
A.確定問題是部分還是全部？是網絡問題還是系統問題？
B.檢查後端服務是否正常。因為後端才是真實提供服務的場所，是整個負載均衡存在的根基（就算負載均衡體系暫時崩潰了，只要後端服務正常，可臨時採取措施，把用戶請求直接暴露給用戶，可最快速度恢復業務）。在實際的工作中，大部分的故障集中在後端伺服器，比如大名鼎鼎的502。
C.排查負載均衡是否正常。一般情況下，負載均衡伺服器基本不安裝其它服務（一機多用者慎重），因此，除了硬碟被日誌塞滿產生故障外，另外一個可能就是硬體損壞。本人管理的系統，運行時間最長的負載均衡伺服器，有超過八年沒趴窩的。
部署了負載均衡，後端伺服器可以部分失效、負載均衡器本身也可以有一個失效。看起來很讓人放心，就算發生故障，也暫時能頂一陣。是不是慢吞吞地地心情好了，想起來了再去做故障恢復？
最好不要這樣幹，有故障發生，發現以後，儘可能快的把故障修復並再次加入集群，不玩心跳。
這與後端服務關係密切，後端程序、邏輯性能極佳，承載的並發數就大；反之就小，無確切的數據支撐。
上線前，有可能對系統做壓力測試，但這種測試大部分是一致性測試（至少是同一個訪問源），與真實的用戶訪問還是存在很大差異。
真實的用戶訪問，來源不同，訪問的對象不同，比如有的用戶網絡環境差，訪問速度慢，完成一次連接的時間長，佔有資源的釋放時間就要久一些。這種測試可做大概的參考，評估時應該預留餘量。
本文來源
作者：sery 來源：51CTO
出於傳播網絡知識之目的，轉載該文章，如需刪除，請私信。
微信號｜Networking_MG
關注公眾號
加入「網絡工程師」交流群