負載均衡基本原理與lvs

前言：

　　以前在山西的項目上使用的是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運算。