前言：

　　之前在山西的專案上使用的是lvs下的NAT模式，但另外兩個模式並沒有涉及，今天系統的整理下關於負載均衡的相關理論與lvs各模式的相關優點與不足，知其然與所以然，而後能針對性的應用：

基本介紹

1.1 負載均衡的由來

在業務初期，我們一般會先使用單臺伺服器對外提供服務。隨著業務流量越來越大，單臺伺服器無論如何優化，無論採用多好的硬體，總會有效能天花板，當單伺服器的效能無法滿足業務需求時，就需要把多臺伺服器組成集群系統提高整體的處理效能。不過我們要使用統一的入口方式對外提供服務，所以需要一個流量排程器通過均衡的演算法，將使用者大量的請求均衡地分發到後端叢集不同的伺服器上。這就是我們後邊要說的 負載均衡。

1.2 負載均衡的優點

提高了服務的整體效能

提高了服務的擴充套件性

提高了服務的高可用性

1.3 負載均衡的型別

廣義上的負載均衡器大概可以分為 3 類，包括：DNS 方式實現負載均衡、硬體負載均衡、軟體負載均衡。

1.3.1 DNS負載均衡

DNS 實現負載均衡是最基礎簡單的方式。一個域名通過 DNS 解析到多個 IP，每個 IP 對應不同的伺服器例項，這樣就完成了流量的排程，雖然沒有使用常規的負載均衡器，但也的確完成了簡單負載均衡的功能。

 

 

 

通過 DNS 實現負載均衡的方式的優點：

實現簡單，成本低，無需自己開發或維護負載均衡裝置，

通過 DNS 實現負載均衡的方式的缺點：

伺服器故障切換延遲大

伺服器升級不方便。我們知道 DNS 與使用者之間是層層的快取，即便是在故障發生時及時通過 DNS 修改或摘除故障伺服器，但中間由於經過運營商的 DNS 快取，且快取很有可能不遵循 TTL 規則，導致 DNS 生效時間變得非常緩慢，有時候一天後還會有些許的請求流量。

流量排程不均衡，粒度太粗

DNS 排程的均衡性，受地區運營商 LocalDNS 返回 IP 列表的策略有關係，有的運營商並不會輪詢返回多個不同的 IP 地址。另外，某個運營商 LocalDNS 背後服務了多少使用者，這也會構成流量排程不均的重要因素。

流量分配策略比較簡單，支援的演算法較少。DNS 一般只支援 RR 的輪詢方式，流量分配策略比較簡單，不支援權重、Hash 等排程演算法。

DNS 支援的 IP 列表有限制

我們知道 DNS 使用 UDP 報文進行資訊傳遞，每個 UDP 報文大小受鏈路的 MTU 限制，所以報文中儲存的 IP 地址數量也是非常有限的，阿里 DNS 系統針對同一個域名支援配置 10 個不同的 IP 地址。

注：實際上生產環境中很少使用這種方式來實現負載均衡，畢竟缺點很明顯。文中之所以描述 DNS 負載均衡方式，是為了能夠更清楚地解釋負載均衡的概念。一些大公司一般也會利用 DNS 來實現地理級別的負載均衡，實現就近訪問，提高訪問速度，這種方式一般是入口流量的基礎負載均衡，下層會有更專業的負載均衡裝置實現的負載架構。

1.3.2 硬體負載均衡

硬體負載均衡是通過專門的硬體裝置來實現負載均衡功能，類似於交換機、路由器，是一個負載均衡專用的網路裝置。目前業界典型的硬體負載均衡裝置有兩款：F5 和 A10。這類裝置效能強勁、功能強大，但價格非常昂貴，一般只有 “土豪” 公司才會使用此類裝置，普通業務量級的公司一般負擔不起，二是業務量沒那麼大，用這些裝置也是浪費。

硬體負載均衡的優點：

功能強大：全面支援各層級的負載均衡，支援全面的負載均衡演算法。

效能強大：效能遠超常見的軟體負載均衡器。

穩定性高：商用硬體負載均衡，經過了良好的嚴格測試，經過大規模使用，穩定性高。

安全防護：除了具備負載均衡外，還具備防火牆、防 DDoS 攻擊等安全功能，貌似還支援 SNAT 功能。

硬體負載均衡的缺點：

價格昂貴，就是貴。

擴充套件性差，無法進行擴充套件和定製。

除錯和維護比較麻煩，需要專業人員。

1.3.3 軟體負載均衡

軟體負載均衡，可以在普通的伺服器上執行負載均衡軟體，實現負載均衡功能。目前常見的有 Nginx、HAproxy、LVS，瞭解到很多大公司使用的 LVS 都是定製版的，做過很多效能方面的優化，比開源版本效能會高出很多，

目前較為熟悉的負載均衡軟體是 LVS，且大部分中小型公司使用開源的 LVS 足夠滿足業務需求；

軟體負載均衡的優點：

簡單：無論是部署還是維護都比較簡單。

便宜：買個 Linux 伺服器，裝上軟體即可。

靈活：4 層和 7 層負載均衡可以根據業務進行選擇；也可以根據業務特點，比較方便進行擴充套件和定製功能。

第2章 基礎原理

2.1 Netfilter基本原理

LVS 是基於 Linux 核心中 netfilter 框架實現的負載均衡系統，所以要學習 LVS 之前必須要先簡單瞭解 netfilter 基本工作原理。netfilter 其實很複雜也很重要，平時我們說的 Linux 防火牆就是 netfilter，不過我們平時操作的都是 iptables，iptables 只是使用者空間編寫和傳遞規則的工具而已，真正工作的是 netfilter。通過下圖可以簡單瞭解下 netfilter 的工作機制：

 

 

 

netfilter 是核心態的 Linux 防火牆機制，作為一個通用、抽象的框架，提供了一整套的 hook 函式管理機制，提供諸如資料包過濾、網路地址轉換、基於協議型別的連線跟蹤的功能。

 

通俗點講，就是 netfilter 提供一種機制，可以在資料包流經過程中，根據規則設定若干個關卡（hook 函式）來執行相關的操作。netfilter 總共設定了 5 個點，包括：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING

PREROUTING ：剛剛進入網路層，還未進行路由查詢的包，通過此處

INPUT ：通過路由查詢，確定發往本機的包，通過此處

FORWARD ：經路由查詢後，要轉發的包，在POST_ROUTING之前

OUTPUT ：從本機程序剛發出的包，通過此處

POSTROUTING ：進入網路層已經經過路由查詢，確定轉發，將要離開本裝置的包，通過此處

資料包大致流經路徑：

當一個數據包進入網絡卡，經過鏈路層之後進入網路層就會到達 PREROUTING，接著根據目標 IP 地址進行路由查詢，如果目標 IP 是本機，資料包繼續傳遞到 INPUT 上，經過協議棧後根據埠將資料送到相應的應用程式；應用程式處理請求後將響應資料包傳送到 OUTPUT 上，最終通過 POSTROUTING 後傳送出網絡卡。如果目標 IP 不是本機，而且伺服器開啟了 forward 引數，就會將資料包遞送給 FORWARD 上，最後通過 POSTROUTING 後傳送出網絡卡。

第3章 Lvs負載均衡

Lvs是軟體負載均衡，LVS 是基於 netfilter 框架，主要工作於 INPUT 鏈上，在 INPUT 上註冊 ip_vs_in HOOK 函式，進行 IPVS 主流程，大概原理如圖所示：

 

 

 

當用戶訪問網站時，使用者資料通過層層網路，最後通過交換機進入 LVS 伺服器網絡卡，並進入核心網路層。進入 PREROUTING 後經過路由查詢，確定訪問的目的 VIP 是本機 IP 地址，所以資料包進入到 INPUT 鏈上，IPVS 是工作在 INPUT 鏈上，會根據訪問的 vip+port 判斷請求是否 IPVS 服務，如果是則呼叫註冊的 IPVS HOOK 函式，進行 IPVS 相關主流程，強行修改資料包的相關資料，並將資料包發往 POSTROUTING 鏈上。POSTROUTING 上收到資料包後，根據目標 IP 地址（後端伺服器），通過路由選路，將資料包最終發往後端的伺服器上。

3.1 基本簡介

LVS（Linux Virtual Server）即Linux虛擬伺服器，是由章文嵩博士主導的開源負載均衡專案，目前LVS已經被整合到Linux核心模組中。該專案在Linux核心中實現了基於IP的資料請求負載均衡排程方案；

3.2 工作模式

開源 LVS 版本有 3 種工作模式，每種模式工作原理截然不同，說各種模式都有自己的優缺點，分別適合不同的應用場景，不過最終本質的功能都是能實現均衡的流量排程和良好的擴充套件性。主要包括以下三種模式

DR 模式

NAT 模式

Tunnel 模式

相關術語介紹

CIP：Client IP，表示的是客戶端 IP 地址。

VIP：Virtual IP，表示負載均衡對外提供訪問的 IP 地址，一般負載均衡 IP 都會通過 Virtual IP 實現高可用。

RIP：RealServer IP，表示負載均衡後端的真實伺服器 IP 地址。

DIP：Director IP，表示負載均衡與後端伺服器通訊的 IP 地址。

CMAC：客戶端的 MAC 地址，準確的應該是 LVS 連線的路由器的 MAC 地址。

VMAC：負載均衡 LVS 的 VIP 對應的 MAC 地址。

DMAC：負載均衡 LVS 的 DIP 對應的 MAC 地址。

RMAC：後端真實伺服器的 RIP 地址對應的 MAC 地址。

3.2.1 DR模式

 

 

 

其實 DR 是最常用的工作模式，因為它的強大的效能。下邊以一次請求和響應資料流的過程來描述 DR 模式的具體原理：

第一步：

當客戶端請求網站主頁，經過 DNS 解析到 IP 後，向網站伺服器傳送請求資料，資料包經過層層網路到達網站負載均衡 LVS 伺服器，到達 LVS 網絡卡時的資料包：源 IP 是客戶端 IP 地址 CIP，目的 IP 是新浪對外的伺服器 IP 地址，也就是 VIP；此時源 MAC 地址是 CMAC，其實是 LVS 連線的路由器的 MAC 地址（為了容易理解記為 CMAC），目標 MAC 地址是 VIP 對應的 MAC，記為 VMAC。

第二步：

資料包到達網絡卡後，經過鏈路層到達 PREROUTING 位置（剛進入網路層），查詢路由發現目的 IP 是 LVS 的 VIP，就會遞送到 INPUT 鏈上，此時資料包 MAC、IP、Port 都沒有修改。

第三步：

資料包到達 INPUT 鏈，INPUT 是 LVS 主要工作的位置。此時 LVS 會根據目的 IP 和 Port 來確認是否是 LVS 定義的服務，如果是定義過的 VIP 服務，就會根據配置的 Service 資訊，從 RealServer 中選擇一個作為後端伺服器 RS1，然後以 RS1 作為目標查詢 Out 方向的路由，確定下一跳資訊以及資料包要通過哪個網絡卡發出。最後將資料包通過 INET_HOOK 到 OUTPUT 鏈上（Out 方向剛進入網路層）。

第四步：

資料包通過 POSTROUTING 鏈後，從網路層轉到鏈路層，將目的 MAC 地址修改為 RealServer 伺服器 MAC 地址，記為 RMAC；而源 MAC 地址修改為 LVS 與 RS 同網段的 selfIP 對應的 MAC 地址，記為 DMAC。此時，資料包通過交換機轉發給了 RealServer 伺服器

第五步：

請求資料包到達 RealServer 伺服器後，鏈路層檢查目的 MAC 是自己網絡卡地址。到了網路層，查詢路由，目的 IP 是 VIP（lo 上配置了 VIP），判定是本地主機的資料包，經過協議棧後拷貝至應用程式（比如這裡是 nginx 伺服器），nginx 響應請求後，產生響應資料包。以目的 VIP 為 dst 查詢 Out 路由，確定下一跳資訊和傳送網絡卡裝置資訊，傳送資料包。此時資料包源、目的 IP 分別是 VIP、CIP，而源 MAC 地址是 RS1 的 RMAC，目的 MAC 是下一跳（路由器）的 MAC 地址，記為 CMAC（為了容易理解，記為 CMAC）。然後資料包通過 RS 相連的路由器轉發給真正客戶端。

DR模式的優缺點：

DR 模式的優點

a. 響應資料不經過 lvs，效能高

b. 對資料包修改小，資訊儲存完整（攜帶客戶端源 IP）

DR 模式的缺點

a. lvs 與 rs 必須在同一個物理網路（不支援跨機房）

b. rs 上必須配置 lo 和其它核心引數

c. 不支援埠對映

DR 模式的使用場景

如果對效能要求非常高，可以首選 DR 模式，而且可以透傳客戶端源 IP 地址

3.2.2  NAT模式

 

 

 

第一步：

使用者請求資料包經過層層網路，到達 lvs 網絡卡，此時資料包源 IP 是 CIP，目的 IP 是 VIP。

經過網絡卡進入網路層 prerouting 位置，根據目的 IP 查詢路由，確認是本機 IP，將資料包轉發到 INPUT 上，此時源、目的 IP 都未發生變化。

第二步：

到達 lvs 後，通過目的 IP 和目的 port 查詢是否為 IPVS 服務。若是 IPVS 服務，則會選擇一個 RS 作為後端伺服器，將資料包目的 IP 修改為 RIP，並以 RIP 為目的 IP 查詢路由資訊，確定下一跳和出口資訊，將資料包轉發至 output 上。

第三步：

修改後的資料包經過 postrouting 和鏈路層處理後，到達 RS 伺服器，此時的資料包源 IP 是 CIP，目的 IP 是 RIP。

第四步：

到達 RS 伺服器的資料包經過鏈路層和網路層檢查後，被送往使用者空間 nginx 程式。nginx 程式處理完畢，傳送響應資料包，由於 RS 上預設閘道器配置為 lvs 裝置 IP，所以 nginx 伺服器會將資料包轉發至下一跳，也就是 lvs 伺服器。此時資料包源 IP 是 RIP，目的 IP 是 CIP。

第五步：

lvs 伺服器收到 RS 響應資料包後，根據路由查詢，發現目的 IP 不是本機 IP，且 lvs 伺服器開啟了轉發模式，所以將資料包轉發給 forward 鏈，此時資料包未作修改。

第六步：

lvs 收到響應資料包後，根據目的 IP 和目的 port 查詢服務和連線表，將源 IP 改為 VIP，通過路由查詢，確定下一跳和出口資訊，將資料包傳送至閘道器，經過複雜的網路到達使用者客戶端，最終完成了一次請求和響應的互動。

NAT模式的優缺點：

NAT 模式優點

a. 能夠支援 windows 作業系統

b. 支援埠對映。如果 rs 埠與 vport 不一致，lvs 除了修改目的 IP，也會修改 dport 以支援埠對映。

NAT 模式缺點

a. 後端 RS 需要配置閘道器

b. 雙向流量對 lvs 負載壓力比較大

NAT 模式的使用場景

如果你是 windows 系統，使用 lvs 的話，則必須選擇 NAT 模式了。

3.2.3  Tunnel模式

 

 

 

第一步：

使用者請求資料包經過多層網路，到達 lvs 網絡卡，此時資料包源 IP 是 cip，目的 ip 是 vip。

第二步：

經過網絡卡進入網路層 prerouting 位置，根據目的 ip 查詢路由，確認是本機 ip，將資料包轉發到 input 鏈上，到達 lvs，此時源、目的 ip 都未發生變化。

第三步：

到達 lvs 後，通過目的 ip 和目的 port 查詢是否為 IPVS 服務。若是 IPVS 服務，則會選擇一個 rs 作為後端伺服器，以 rip 為目的 ip 查詢路由資訊，確定下一跳、dev 等資訊，然後 IP 頭部前邊額外增加了一個 IP 頭（以 dip 為源，rip 為目的 ip），將資料包轉發至 output 上。

第四步：

資料包根據路由資訊經最終經過 lvs 網絡卡，傳送至路由器閘道器，通過網路到達後端伺服器。

第五步：

後端伺服器收到資料包後，ipip 模組將 Tunnel 頭部解除安裝，正常看到的源 ip 是 cip，目的 ip 是 vip，由於在 tunl0 上配置 vip，路由查詢後判定為本機 ip，送往應用程式。應用程式 nginx 正常響應資料後以 vip 為源 ip，cip 為目的 ip 資料包傳送出網絡卡，最終到達客戶端。

Tunnel 模式的優點

a. 單臂模式，對 lvs 負載壓力小

b. 對資料包修改較小，資訊儲存完整

c. 可跨機房（不過在國內實現有難度）

Tunnel 模式的缺點

a. 需要在後端伺服器安裝配置 ipip 模組

b. 需要在後端伺服器 tunl0 配置 vip

c. 隧道頭部的加入可能導致分片，影響伺服器效能

d. 隧道頭部 IP 地址固定，後端伺服器網絡卡 hash 可能不均

e. 不支援埠對映

Tunnel 模式的使用場景

理論上，如果對轉發效能要求較高，且有跨機房需求，Tunnel 可能是較好的選擇。

3.3 排程演算法

3.3.1 輪詢排程

輪詢排程（Round Robin 簡稱'RR'）演算法就是按依次迴圈的方式將請求排程到不同的伺服器上，該演算法最大的特點就是實現簡單。輪詢演算法假設所有的伺服器處理請求的能力都一樣的，排程器會將所有的請求平均分配給每個真實伺服器。

3.3.2 加權輪詢排程

加權輪詢（Weight Round Robin 簡稱'WRR'）演算法主要是對輪詢演算法的一種優化與補充，LVS會考慮每臺伺服器的效能，並給每臺伺服器新增一個權值，如果伺服器A的權值為1，伺服器B的權值為2，則排程器排程到伺服器B的請求會是伺服器A的兩倍。權值越高的伺服器，處理的請求越多。

3.3.3 最小連線排程

最小連線排程（Least Connections 簡稱'LC'）演算法是把新的連線請求分配到當前連線數最小的伺服器。最小連線排程是一種動態的排程演算法，它通過伺服器當前活躍的連線數來估計伺服器的情況。排程器需要記錄各個伺服器已建立連線的數目，當一個請求被排程到某臺伺服器，其連線數加1；當連線中斷或者超時，其連線數減1。

（集群系統的真實伺服器具有相近的系統性能，採用最小連線排程演算法可以比較好地均衡負載。)

3.3.4 加權最小連線排程

加權最少連線（Weight Least Connections 簡稱'WLC'）演算法是最小連線排程的超集，各個伺服器相應的權值表示其處理效能。伺服器的預設權值為1，系統管理員可以動態地設定伺服器的權值。加權最小連線排程在排程新連線時儘可能使伺服器的已建立連線數和其權值成比例。排程器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

3.3.5 基於區域性的最少連線

基於區域性的最少連線排程（Locality-Based Least Connections 簡稱'LBLC'）演算法是針對請求報文的目標IP地址的負載均衡排程，目前主要用於Cache集群系統，因為在Cache叢集客戶請求報文的目標IP地址是變化的。這裡假設任何後端伺服器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求排程到同一臺伺服器，來提高各臺伺服器的訪問區域性性和Cache命中率，從而提升整個集群系統的處理能力。LBLC排程演算法先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則使用'最少連線'的原則選出一個可用的伺服器，將請求傳送到伺服器。

3.3.6 帶複製的基於區域性性的最少連線

帶複製的基於區域性性的最少連線（Locality-Based Least Connections with Replication  簡稱'LBLCR'）演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統，它與LBLC演算法不同之處是它要維護從一個目標IP地址到一組伺服器的對映，而LBLC演算法維護從一個目標IP地址到一臺伺服器的對映。按'最小連線'原則從該伺服器組中選出一一臺伺服器，若伺服器沒有超載，將請求傳送到該伺服器；若伺服器超載，則按'最小連線'原則從整個叢集中選出一臺伺服器，將該伺服器加入到這個伺服器組中，將請求傳送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度。

 

3.3.7 目標地址雜湊排程

目標地址雜湊排程（Destination Hashing 簡稱'DH'）演算法先根據請求的目標IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。

3.3.8 源地址雜湊排程U

源地址雜湊排程（Source Hashing  簡稱'SH'）演算法先根據請求的源IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。它採用的雜湊函式與目標地址雜湊排程演算法的相同，它的演算法流程與目標地址雜湊排程演算法的基本相似。

3.3.9 最短的期望的延遲

最短的期望的延遲排程（Shortest Expected Delay 簡稱'SED'）演算法基於WLC演算法。舉個例子吧，ABC三臺伺服器的權重分別為1、2、3 。那麼如果使用WLC演算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED演算法後會進行一個運算

A：（1+1）/1=2   B：（1+2）/2=3/2   C：（1+3）/3=4/3   就把請求交給得出運算結果最小的伺服器。

3.3.10 最少佇列排程

 

最少佇列排程（Never Queue 簡稱'NQ'）演算法，無需佇列。如果有realserver的連線數等於0就直接分配過去，不需要在進行SED運算。

第1章 基本介紹

1.1 負載均衡的由來

在業務初期，我們一般會先使用單臺伺服器對外提供服務。隨著業務流量越來越大，單臺伺服器無論如何優化，無論採用多好的硬體，總會有效能天花板，當單伺服器的效能無法滿足業務需求時，就需要把多臺伺服器組成集群系統提高整體的處理效能。不過我們要使用統一的入口方式對外提供服務，所以需要一個流量排程器通過均衡的演算法，將使用者大量的請求均衡地分發到後端叢集不同的伺服器上。這就是我們後邊要說的 負載均衡。

1.2 負載均衡的優點

提高了服務的整體效能

提高了服務的擴充套件性

提高了服務的高可用性

1.3 負載均衡的型別

廣義上的負載均衡器大概可以分為 3 類，包括：DNS 方式實現負載均衡、硬體負載均衡、軟體負載均衡。

1.3.1 DNS負載均衡

DNS 實現負載均衡是最基礎簡單的方式。一個域名通過 DNS 解析到多個 IP，每個 IP 對應不同的伺服器例項，這樣就完成了流量的排程，雖然沒有使用常規的負載均衡器，但也的確完成了簡單負載均衡的功能。

 

通過 DNS 實現負載均衡的方式的優點：

實現簡單，成本低，無需自己開發或維護負載均衡裝置，

通過 DNS 實現負載均衡的方式的缺點：

伺服器故障切換延遲大

伺服器升級不方便。我們知道 DNS 與使用者之間是層層的快取，即便是在故障發生時及時通過 DNS 修改或摘除故障伺服器，但中間由於經過運營商的 DNS 快取，且快取很有可能不遵循 TTL 規則，導致 DNS 生效時間變得非常緩慢，有時候一天後還會有些許的請求流量。

流量排程不均衡，粒度太粗

DNS 排程的均衡性，受地區運營商 LocalDNS 返回 IP 列表的策略有關係，有的運營商並不會輪詢返回多個不同的 IP 地址。另外，某個運營商 LocalDNS 背後服務了多少使用者，這也會構成流量排程不均的重要因素。

流量分配策略比較簡單，支援的演算法較少。DNS 一般只支援 RR 的輪詢方式，流量分配策略比較簡單，不支援權重、Hash 等排程演算法。

DNS 支援的 IP 列表有限制

我們知道 DNS 使用 UDP 報文進行資訊傳遞，每個 UDP 報文大小受鏈路的 MTU 限制，所以報文中儲存的 IP 地址數量也是非常有限的，阿里 DNS 系統針對同一個域名支援配置 10 個不同的 IP 地址。

注：實際上生產環境中很少使用這種方式來實現負載均衡，畢竟缺點很明顯。文中之所以描述 DNS 負載均衡方式，是為了能夠更清楚地解釋負載均衡的概念。一些大公司一般也會利用 DNS 來實現地理級別的負載均衡，實現就近訪問，提高訪問速度，這種方式一般是入口流量的基礎負載均衡，下層會有更專業的負載均衡裝置實現的負載架構。

1.3.2 硬體負載均衡

硬體負載均衡是通過專門的硬體裝置來實現負載均衡功能，類似於交換機、路由器，是一個負載均衡專用的網路裝置。目前業界典型的硬體負載均衡裝置有兩款：F5 和 A10。這類裝置效能強勁、功能強大，但價格非常昂貴，一般只有 “土豪” 公司才會使用此類裝置，普通業務量級的公司一般負擔不起，二是業務量沒那麼大，用這些裝置也是浪費。

硬體負載均衡的優點：

功能強大：全面支援各層級的負載均衡，支援全面的負載均衡演算法。

效能強大：效能遠超常見的軟體負載均衡器。

穩定性高：商用硬體負載均衡，經過了良好的嚴格測試，經過大規模使用，穩定性高。

安全防護：除了具備負載均衡外，還具備防火牆、防 DDoS 攻擊等安全功能，貌似還支援 SNAT 功能。

硬體負載均衡的缺點：

價格昂貴，就是貴。

擴充套件性差，無法進行擴充套件和定製。

除錯和維護比較麻煩，需要專業人員。

1.3.3 軟體負載均衡

軟體負載均衡，可以在普通的伺服器上執行負載均衡軟體，實現負載均衡功能。目前常見的有 Nginx、HAproxy、LVS，瞭解到很多大公司使用的 LVS 都是定製版的，做過很多效能方面的優化，比開源版本效能會高出很多，

目前較為熟悉的負載均衡軟體是 LVS，且大部分中小型公司使用開源的 LVS 足夠滿足業務需求；

軟體負載均衡的優點：

簡單：無論是部署還是維護都比較簡單。

便宜：買個 Linux 伺服器，裝上軟體即可。

靈活：4 層和 7 層負載均衡可以根據業務進行選擇；也可以根據業務特點，比較方便進行擴充套件和定製功能。

第2章 基礎原理

2.1 Netfilter基本原理

LVS 是基於 Linux 核心中 netfilter 框架實現的負載均衡系統，所以要學習 LVS 之前必須要先簡單瞭解 netfilter 基本工作原理。netfilter 其實很複雜也很重要，平時我們說的 Linux 防火牆就是 netfilter，不過我們平時操作的都是 iptables，iptables 只是使用者空間編寫和傳遞規則的工具而已，真正工作的是 netfilter。通過下圖可以簡單瞭解下 netfilter 的工作機制：

 

netfilter 是核心態的 Linux 防火牆機制，作為一個通用、抽象的框架，提供了一整套的 hook 函式管理機制，提供諸如資料包過濾、網路地址轉換、基於協議型別的連線跟蹤的功能。

 

通俗點講，就是 netfilter 提供一種機制，可以在資料包流經過程中，根據規則設定若干個關卡（hook 函式）來執行相關的操作。netfilter 總共設定了 5 個點，包括：PREROUTING、INPUT、FORWARD、OUTPUT、POSTROUTING

PREROUTING ：剛剛進入網路層，還未進行路由查詢的包，通過此處

INPUT ：通過路由查詢，確定發往本機的包，通過此處

FORWARD ：經路由查詢後，要轉發的包，在POST_ROUTING之前

OUTPUT ：從本機程序剛發出的包，通過此處

POSTROUTING ：進入網路層已經經過路由查詢，確定轉發，將要離開本裝置的包，通過此處

資料包大致流經路徑：

當一個數據包進入網絡卡，經過鏈路層之後進入網路層就會到達 PREROUTING，接著根據目標 IP 地址進行路由查詢，如果目標 IP 是本機，資料包繼續傳遞到 INPUT 上，經過協議棧後根據埠將資料送到相應的應用程式；應用程式處理請求後將響應資料包傳送到 OUTPUT 上，最終通過 POSTROUTING 後傳送出網絡卡。如果目標 IP 不是本機，而且伺服器開啟了 forward 引數，就會將資料包遞送給 FORWARD 上，最後通過 POSTROUTING 後傳送出網絡卡。

第3章 Lvs負載均衡

Lvs是軟體負載均衡，LVS 是基於 netfilter 框架，主要工作於 INPUT 鏈上，在 INPUT 上註冊 ip_vs_in HOOK 函式，進行 IPVS 主流程，大概原理如圖所示：

 

當用戶訪問網站時，使用者資料通過層層網路，最後通過交換機進入 LVS 伺服器網絡卡，並進入核心網路層。進入 PREROUTING 後經過路由查詢，確定訪問的目的 VIP 是本機 IP 地址，所以資料包進入到 INPUT 鏈上，IPVS 是工作在 INPUT 鏈上，會根據訪問的 vip+port 判斷請求是否 IPVS 服務，如果是則呼叫註冊的 IPVS HOOK 函式，進行 IPVS 相關主流程，強行修改資料包的相關資料，並將資料包發往 POSTROUTING 鏈上。POSTROUTING 上收到資料包後，根據目標 IP 地址（後端伺服器），通過路由選路，將資料包最終發往後端的伺服器上。

3.1 基本簡介

LVS（Linux Virtual Server）即Linux虛擬伺服器，是由章文嵩博士主導的開源負載均衡專案，目前LVS已經被整合到Linux核心模組中。該專案在Linux核心中實現了基於IP的資料請求負載均衡排程方案；

3.2 工作模式

開源 LVS 版本有 3 種工作模式，每種模式工作原理截然不同，說各種模式都有自己的優缺點，分別適合不同的應用場景，不過最終本質的功能都是能實現均衡的流量排程和良好的擴充套件性。主要包括以下三種模式

DR 模式

NAT 模式

Tunnel 模式

相關術語介紹

CIP：Client IP，表示的是客戶端 IP 地址。

VIP：Virtual IP，表示負載均衡對外提供訪問的 IP 地址，一般負載均衡 IP 都會通過 Virtual IP 實現高可用。

RIP：RealServer IP，表示負載均衡後端的真實伺服器 IP 地址。

DIP：Director IP，表示負載均衡與後端伺服器通訊的 IP 地址。

CMAC：客戶端的 MAC 地址，準確的應該是 LVS 連線的路由器的 MAC 地址。

VMAC：負載均衡 LVS 的 VIP 對應的 MAC 地址。

DMAC：負載均衡 LVS 的 DIP 對應的 MAC 地址。

RMAC：後端真實伺服器的 RIP 地址對應的 MAC 地址。

3.2.1 DR模式

 

其實 DR 是最常用的工作模式，因為它的強大的效能。下邊以一次請求和響應資料流的過程來描述 DR 模式的具體原理：

第一步：

當客戶端請求網站主頁，經過 DNS 解析到 IP 後，向網站伺服器傳送請求資料，資料包經過層層網路到達網站負載均衡 LVS 伺服器，到達 LVS 網絡卡時的資料包：源 IP 是客戶端 IP 地址 CIP，目的 IP 是新浪對外的伺服器 IP 地址，也就是 VIP；此時源 MAC 地址是 CMAC，其實是 LVS 連線的路由器的 MAC 地址（為了容易理解記為 CMAC），目標 MAC 地址是 VIP 對應的 MAC，記為 VMAC。

第二步：

資料包到達網絡卡後，經過鏈路層到達 PREROUTING 位置（剛進入網路層），查詢路由發現目的 IP 是 LVS 的 VIP，就會遞送到 INPUT 鏈上，此時資料包 MAC、IP、Port 都沒有修改。

第三步：

資料包到達 INPUT 鏈，INPUT 是 LVS 主要工作的位置。此時 LVS 會根據目的 IP 和 Port 來確認是否是 LVS 定義的服務，如果是定義過的 VIP 服務，就會根據配置的 Service 資訊，從 RealServer 中選擇一個作為後端伺服器 RS1，然後以 RS1 作為目標查詢 Out 方向的路由，確定下一跳資訊以及資料包要通過哪個網絡卡發出。最後將資料包通過 INET_HOOK 到 OUTPUT 鏈上（Out 方向剛進入網路層）。

第四步：

資料包通過 POSTROUTING 鏈後，從網路層轉到鏈路層，將目的 MAC 地址修改為 RealServer 伺服器 MAC 地址，記為 RMAC；而源 MAC 地址修改為 LVS 與 RS 同網段的 selfIP 對應的 MAC 地址，記為 DMAC。此時，資料包通過交換機轉發給了 RealServer 伺服器

第五步：

請求資料包到達 RealServer 伺服器後，鏈路層檢查目的 MAC 是自己網絡卡地址。到了網路層，查詢路由，目的 IP 是 VIP（lo 上配置了 VIP），判定是本地主機的資料包，經過協議棧後拷貝至應用程式（比如這裡是 nginx 伺服器），nginx 響應請求後，產生響應資料包。以目的 VIP 為 dst 查詢 Out 路由，確定下一跳資訊和傳送網絡卡裝置資訊，傳送資料包。此時資料包源、目的 IP 分別是 VIP、CIP，而源 MAC 地址是 RS1 的 RMAC，目的 MAC 是下一跳（路由器）的 MAC 地址，記為 CMAC（為了容易理解，記為 CMAC）。然後資料包通過 RS 相連的路由器轉發給真正客戶端。

DR模式的優缺點：

DR 模式的優點

a. 響應資料不經過 lvs，效能高

b. 對資料包修改小，資訊儲存完整（攜帶客戶端源 IP）

DR 模式的缺點

a. lvs 與 rs 必須在同一個物理網路（不支援跨機房）

b. rs 上必須配置 lo 和其它核心引數

c. 不支援埠對映

DR 模式的使用場景

如果對效能要求非常高，可以首選 DR 模式，而且可以透傳客戶端源 IP 地址

3.2.2  NAT模式

 

第一步：

使用者請求資料包經過層層網路，到達 lvs 網絡卡，此時資料包源 IP 是 CIP，目的 IP 是 VIP。

經過網絡卡進入網路層 prerouting 位置，根據目的 IP 查詢路由，確認是本機 IP，將資料包轉發到 INPUT 上，此時源、目的 IP 都未發生變化。

第二步：

到達 lvs 後，通過目的 IP 和目的 port 查詢是否為 IPVS 服務。若是 IPVS 服務，則會選擇一個 RS 作為後端伺服器，將資料包目的 IP 修改為 RIP，並以 RIP 為目的 IP 查詢路由資訊，確定下一跳和出口資訊，將資料包轉發至 output 上。

第三步：

修改後的資料包經過 postrouting 和鏈路層處理後，到達 RS 伺服器，此時的資料包源 IP 是 CIP，目的 IP 是 RIP。

第四步：

到達 RS 伺服器的資料包經過鏈路層和網路層檢查後，被送往使用者空間 nginx 程式。nginx 程式處理完畢，傳送響應資料包，由於 RS 上預設閘道器配置為 lvs 裝置 IP，所以 nginx 伺服器會將資料包轉發至下一跳，也就是 lvs 伺服器。此時資料包源 IP 是 RIP，目的 IP 是 CIP。

第五步：

lvs 伺服器收到 RS 響應資料包後，根據路由查詢，發現目的 IP 不是本機 IP，且 lvs 伺服器開啟了轉發模式，所以將資料包轉發給 forward 鏈，此時資料包未作修改。

第六步：

lvs 收到響應資料包後，根據目的 IP 和目的 port 查詢服務和連線表，將源 IP 改為 VIP，通過路由查詢，確定下一跳和出口資訊，將資料包傳送至閘道器，經過複雜的網路到達使用者客戶端，最終完成了一次請求和響應的互動。

NAT模式的優缺點：

NAT 模式優點

a. 能夠支援 windows 作業系統

b. 支援埠對映。如果 rs 埠與 vport 不一致，lvs 除了修改目的 IP，也會修改 dport 以支援埠對映。

NAT 模式缺點

a. 後端 RS 需要配置閘道器

b. 雙向流量對 lvs 負載壓力比較大

NAT 模式的使用場景

如果你是 windows 系統，使用 lvs 的話，則必須選擇 NAT 模式了。

3.2.3  Tunnel模式

 

第一步：

使用者請求資料包經過多層網路，到達 lvs 網絡卡，此時資料包源 IP 是 cip，目的 ip 是 vip。

第二步：

經過網絡卡進入網路層 prerouting 位置，根據目的 ip 查詢路由，確認是本機 ip，將資料包轉發到 input 鏈上，到達 lvs，此時源、目的 ip 都未發生變化。

第三步：

到達 lvs 後，通過目的 ip 和目的 port 查詢是否為 IPVS 服務。若是 IPVS 服務，則會選擇一個 rs 作為後端伺服器，以 rip 為目的 ip 查詢路由資訊，確定下一跳、dev 等資訊，然後 IP 頭部前邊額外增加了一個 IP 頭（以 dip 為源，rip 為目的 ip），將資料包轉發至 output 上。

第四步：

資料包根據路由資訊經最終經過 lvs 網絡卡，傳送至路由器閘道器，通過網路到達後端伺服器。

第五步：

後端伺服器收到資料包後，ipip 模組將 Tunnel 頭部解除安裝，正常看到的源 ip 是 cip，目的 ip 是 vip，由於在 tunl0 上配置 vip，路由查詢後判定為本機 ip，送往應用程式。應用程式 nginx 正常響應資料後以 vip 為源 ip，cip 為目的 ip 資料包傳送出網絡卡，最終到達客戶端。

Tunnel 模式的優點

a. 單臂模式，對 lvs 負載壓力小

b. 對資料包修改較小，資訊儲存完整

c. 可跨機房（不過在國內實現有難度）

Tunnel 模式的缺點

a. 需要在後端伺服器安裝配置 ipip 模組

b. 需要在後端伺服器 tunl0 配置 vip

c. 隧道頭部的加入可能導致分片，影響伺服器效能

d. 隧道頭部 IP 地址固定，後端伺服器網絡卡 hash 可能不均

e. 不支援埠對映

Tunnel 模式的使用場景

理論上，如果對轉發效能要求較高，且有跨機房需求，Tunnel 可能是較好的選擇。

3.3 排程演算法

3.3.1 輪詢排程

輪詢排程（Round Robin 簡稱'RR'）演算法就是按依次迴圈的方式將請求排程到不同的伺服器上，該演算法最大的特點就是實現簡單。輪詢演算法假設所有的伺服器處理請求的能力都一樣的，排程器會將所有的請求平均分配給每個真實伺服器。

3.3.2 加權輪詢排程

加權輪詢（Weight Round Robin 簡稱'WRR'）演算法主要是對輪詢演算法的一種優化與補充，LVS會考慮每臺伺服器的效能，並給每臺伺服器新增一個權值，如果伺服器A的權值為1，伺服器B的權值為2，則排程器排程到伺服器B的請求會是伺服器A的兩倍。權值越高的伺服器，處理的請求越多。

3.3.3 最小連線排程

最小連線排程（Least Connections 簡稱'LC'）演算法是把新的連線請求分配到當前連線數最小的伺服器。最小連線排程是一種動態的排程演算法，它通過伺服器當前活躍的連線數來估計伺服器的情況。排程器需要記錄各個伺服器已建立連線的數目，當一個請求被排程到某臺伺服器，其連線數加1；當連線中斷或者超時，其連線數減1。

（集群系統的真實伺服器具有相近的系統性能，採用最小連線排程演算法可以比較好地均衡負載。)

3.3.4 加權最小連線排程

加權最少連線（Weight Least Connections 簡稱'WLC'）演算法是最小連線排程的超集，各個伺服器相應的權值表示其處理效能。伺服器的預設權值為1，系統管理員可以動態地設定伺服器的權值。加權最小連線排程在排程新連線時儘可能使伺服器的已建立連線數和其權值成比例。排程器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

3.3.5 基於區域性的最少連線

基於區域性的最少連線排程（Locality-Based Least Connections 簡稱'LBLC'）演算法是針對請求報文的目標IP地址的負載均衡排程，目前主要用於Cache集群系統，因為在Cache叢集客戶請求報文的目標IP地址是變化的。這裡假設任何後端伺服器都可以處理任一請求，演算法的設計目標是在伺服器的負載基本平衡情況下，將相同目標IP地址的請求排程到同一臺伺服器，來提高各臺伺服器的訪問區域性性和Cache命中率，從而提升整個集群系統的處理能力。LBLC排程演算法先根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則使用'最少連線'的原則選出一個可用的伺服器，將請求傳送到伺服器。

3.3.6 帶複製的基於區域性性的最少連線

帶複製的基於區域性性的最少連線（Locality-Based Least Connections with Replication  簡稱'LBLCR'）演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統，它與LBLC演算法不同之處是它要維護從一個目標IP地址到一組伺服器的對映，而LBLC演算法維護從一個目標IP地址到一臺伺服器的對映。按'最小連線'原則從該伺服器組中選出一一臺伺服器，若伺服器沒有超載，將請求傳送到該伺服器；若伺服器超載，則按'最小連線'原則從整個叢集中選出一臺伺服器，將該伺服器加入到這個伺服器組中，將請求傳送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度。

 

3.3.7 目標地址雜湊排程

目標地址雜湊排程（Destination Hashing 簡稱'DH'）演算法先根據請求的目標IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。

3.3.8 源地址雜湊排程U

源地址雜湊排程（Source Hashing  簡稱'SH'）演算法先根據請求的源IP地址，作為雜湊鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且並未超載，將請求傳送到該伺服器，否則返回空。它採用的雜湊函式與目標地址雜湊排程演算法的相同，它的演算法流程與目標地址雜湊排程演算法的基本相似。

3.3.9 最短的期望的延遲

最短的期望的延遲排程（Shortest Expected Delay 簡稱'SED'）演算法基於WLC演算法。舉個例子吧，ABC三臺伺服器的權重分別為1、2、3 。那麼如果使用WLC演算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED演算法後會進行一個運算

A：（1+1）/1=2   B：（1+2）/2=3/2   C：（1+3）/3=4/3   就把請求交給得出運算結果最小的伺服器。

3.3.10 最少佇列排程

最少佇列排程（Never Queue 簡稱'NQ'）演算法，無需佇列。如果有realserver的連線數等於0就直接分配過去，不需要在進行SED運算。