一、什么是LVS

        LVS是Linux Virtual Server的簡寫，意即Linux虛擬服務器，是一個虛擬的服務器集群系統。本項目在1998年5月由章文嵩博士成立，是中國國內最早出現的自由軟件項目之一。

        LVS集群采用IP負載均衡技術和基于內容請求分發技術。調度器具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序。

        為此，在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。

二、LVS的結構

    LVS由前端的負載均衡器(Load Balancer，LB)和后端的真實服務器(Real Server，RS)群組成。RS間可通過局域網或廣域網連接。LVS的這種結構對用戶是透明的，用戶只能看見一臺作為LB的虛擬服務器(Virtual Server)，而看不到提供服務的RS群。當用戶的請求發往虛擬服務器，LB根據設定的包轉發策略和負載均衡調度算法將用戶請求轉發給RS。RS再將用戶請求結果返回給用戶。

  負載均衡器一般存在單點故障，所以我們需要在LB節點上做HA。 實現的方法有：heartbeat,keepalived

三、LVS的內核模型

        LVS由前端的負載均衡器(Load Balancer，LB)和后端的真實服務器(Real Server，RS)群組成。RS間可通過局域網或廣域網連接。LVS的這種結構對用戶是透明的，用戶只能看見一臺作為LB的虛擬服務器(Virtual Server)，而看不到提供服務的RS群。當用戶的請求發往虛擬服務器，LB根據設定的包轉發策略和負載均衡調度算法將用戶請求轉發給RS。RS再將用戶請求結果返回給用戶。

如上圖所示，客戶請求報文的走向路徑

1：當客戶端的請求到達負載均衡器的內核空間時，首先會到達PREROUTING鏈

2：當內核發現請求數據包的目的地址是本機時，會將數據包送往INPUT鏈

3：LVS由用戶空間的ipvsadm和內核空間的IPVS組成，ipvsadm用來定義規則，ipvs利用ipvsadm定義的規則工作，I
PVS工作在INPUT鏈上， 當數據包到達INPUT鏈時，首先會被IPVS檢查，如果數據包里面的目標地址及端口沒有在規則里面，
那么這條數據將被放行至用戶空間。

4：如果數據包里面的目標地址及端口在規則里面，那么這條數據報文的目標地址為將被修改為事先定義的后端服務器地址，

并送往POSTROUTING鏈。

5:最后經由POSTROUTING鏈發往后端服務器

四、LVS集群的類型

Ⅰ：LVS-NAT 模型：多目標的DNAT,通過將請求報文中的目標地址和目標端口修改為挑選出的某RS的RIP和PORT實現轉發；

NAT模型的特點：

(1)RIP和DIP必須在同一IP網段，且應該使用私有地址，RS的網關必須要指向DIP（保證響應報文必須經由VS）

    (2)請求報文和響應報文都經由Director轉發，較高負載下，Director易于成為系統性能瓶頸。

    (3)支持端口映射；

    (4)VS必須是Linux，RS可以是任意OS;

如上圖所示，客戶端報文請求和響應報文走向路徑；

1：客戶端client將請求發往前段的負責均衡器，請求報文源IP是CIP(客戶端IP)，目標IP為VIP（負載均衡器前端地址）

2：負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它就將請求報文的目標IP改為后端服務器的RIP地址并將報文根據算法發送出去。

3：報文送達Real Server后，由于報文的目標IP是自己，所以會響應請求，并講響應報文返還給LVS。

4：然后LVS將此報文的源IP修改為本機并發送給客戶端。

優點：集群中的物理服務器可以使用任何支持TCP/IP操作系統，只有負載均衡器需要一個合法的IP地址。

缺點：擴展性有限。當服務器節點（普通PC服務器）增長過多時,負載均衡器將成為整個系統的瓶頸，因為所有的請求包和應答包的流向都經過負載均衡器。當服務器節點過多時，大量的數據包都交匯在負載均衡器那，速度就會變慢！

Ⅱ：LVS-DR模型

1：客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP，目標地址為VIP。

2：負載均衡器收到報文后，發現請求的是在規則里面存在的地址，那么它將客戶端請求報文的源MAC地址改為自己DIP的MAC地址，目標MAC改為RIP的MAC地址，并將此包發送給RS

3：RS發現請求報文中的目標MAC是自己，就會將此次報文接收下來，處理完請求報文后，將響應報文通過lo:1接口送給eth0網卡直接發送給客戶端

優點：和TUN（隧道模式）一樣，負載均衡器也只是分發請求，應答包通過單獨的路由方法返回給客戶端。與VS-TUN相比，VS-DR這種實現方式不需要隧道結構，因此可以使用大多數操作系統做為物理服務器。

缺點：（不能說缺點，只能說是不足）要求負載均衡器的網卡必須與物理網卡在一個物理段上。

Ⅲ：LVS-TUN模型

1：客戶端將請求發往前端的負載均衡器，請求報文源地址為CIP,目標地址為VIP

2：負載均衡器收到報文后，發現請求是規則里面存在的地址，那么它將在客戶端請求報文的首部再封裝一層IP報文，將源地址改為DIP,目標地址改為RIP，并將此包發送給RS

3：RS收到請求包文后，首先會拆開第一層封裝，然后發現里面還有一層IP首部的目標地址是自己的lo:1接口上的VIP ,所以會處理此請求報文，并將響應報文通過lo:1接口送給eth0網卡直接送給客戶端；

優點：負載均衡器只負責將請求包分發給后端節點服務器，而RS將應答包直接發給用戶。所以，減少了負載均衡器的大量數據流動，負載均衡器不再是系統的瓶頸，就能處理很巨大的請求量，這種方式，一臺負載均衡器能夠為很多RS進行分發。而且跑在公網上就能進行不同地域的分發。

缺點：隧道模式的RS節點需要合法IP，這種方式需要所有的服務器支持”IP Tunneling”(IP Encapsulation)協議，服務器可能只局限在部分Linux系統上。

Ⅳ：LVS-FULLNAT模型：通過同時修改請求報文的源IP地址(CIP–>DIP)和目標IP地址(VIP–>RIP)進行轉發；

特點：

(1)VIP是公網地址，RIP和DIP是私網地址，且通常不在同一網絡中，但需要經由路由器互通；

(2)RS收到的請求報文源IP為DIP，因此響應報文將直接響應給DIP;

(3)請求和響應報文都經由Director

(4)支持端口映射； 

五：LVS集群調度算法

    根據其調度時是否考慮后端主機的當前負載，可分為靜態和動態方法兩類

靜態方法：只根據算法進行調度，而不考慮后端主機的實際連接情況和負載情況

(1) RR : Round Robin,  輪詢/輪叫/輪調

  調度器通過”輪叫”調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載

(2) WRR：Weight RR, 加權輪詢

  調度器通過“加權輪叫”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況,并動態地調整其權值。

(3) DH: Destination Hashing, 目標地址哈希，一般應用在正向web代理(緩存), 負載均能內網用戶對外部服務器的請求；

  根據請求的目標IP地址，作為散列鍵(HashKey)從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。

(4) SH：Source Hash, 源地址哈希

   源地址散列”調度算法根據請求的源IP地址，作為散列鍵(HashKey)從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空

動態方法：根據算法及各RS當前的負載狀態進行調度

(1).LC：最少鏈接（Least Connections）

　 調度器通過”最少連接”調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用”最小連接”調度算法可以較好地均衡負載。

(2).WLC：加權最少連接(默認采用的就是這種)（Weighted Least Connections）

　 在集群系統中的服務器性能差異較大的情況下，調度器采用“加權最少鏈接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載?調度器可以自動問詢真實服務器的負載情況,并動態地調整其權值。

(3).SED：最短延遲調度（Shortest Expected Delay ）

　 在WLC基礎上改進，Overhead = （ACTIVE+1）*256/加權，不再考慮非活動狀態，把當前處于活動狀態的數目+1來實現，數目最小的，接受下次請求，+1的目的是為了考慮加權的時候，非活動連接過多缺陷：當權限過大的時候，會倒置空閑服務器一直處于無連接狀態。

(4).NQ永不排隊/最少隊列調度（Never Queue Scheduling NQ）

　 無需隊列。如果有臺 realserver的連接數＝0就直接分配過去，不需要再進行sed運算，保證不會有一個主機很空間。在SED基礎上無論+幾，第二次一定給下一個，保證不會有一個主機不會很空閑著，不考慮非活動連接，才用NQ，SED要考慮活動狀態連接，對于DNS的UDP不需要考慮非活動連接，而httpd的處于保持狀態的服務就需要考慮非活動連接給服務器的壓力。

(5).LBLC：基于局部性的最少鏈接（locality-Based Least Connections）

　 基于局部性的最少鏈接”調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統?該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器;若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用“最少鏈接”的原則選出一個可用的服務器，將請求發送到該服務器?

(6). LBLCR：帶復制的基于局部性最少連接（Locality-Based Least Connections with Replication）

　 帶復制的基于局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統?它與LBLC算法的不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射?該算法根據請求的目標IP地址找出該目標IP地址對應的服務器組，按”最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按“最小連接”原則從這個集群中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器?同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程度。