LVS簡介

Internet的快速增長使多媒體網絡服務器面對的訪問數量快速增加，服務器需要具備提供大量并發訪問服務的能力，因此對于大負載的服務器來講，CPU、I/O處理能力很快會成為瓶頸。由于單臺服務器的性能總是有限的，簡單的提高硬件性能并不能真正解決這個問題。為此，必須采用多服務器和負載均衡技術才能滿足大量并發訪問的需要。Linux 虛擬服務器(Linux Virtual Servers,LVS) 使用負載均衡技術將多臺服務器組成一個虛擬服務器。它為適應快速增長的網絡訪問需求提供了一個負載能力易于擴展，而價格低廉的解決方案。

LVS結構與工作原理

一：LVS的結構

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

二：LVS內核模型

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

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

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

4.如果數據包里面的目的地址及端口在規則里面，那么這條數據報文將被修改目的地址為事先定義好的后端服務器，并送往POSTROUTING鏈。

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

三：LVS的包轉發模型

1.NAT模型：

①.客戶端將請求發往前端的負載均衡器，請求報文源地址是CIP(客戶端IP),后面統稱為CIP)，目標地址為VIP(負載均衡器前端地址，后面統稱為VIP)。

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

③.報文送到Real Server后，由于報文的目標地址是自己，所以會響應該請求，并將響應報文返還給LVS。

④.然后lvs將此報文的源地址修改為本機并發送給客戶端。注意：在NAT模式中，Real Server的網關必須指向LVS，否則報文無法送達客戶端。

2.DR模型：

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

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

③.RS發現請求報文中的目的MAC是自己，就會將次報文接收下來，處理完請求報文后，將響應報文通過lo接口送給eth0網卡直接發送給客戶端。注意：需要設置lo接口的VIP不能響應本地網絡內的arp請求。

3.TUN模型：

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

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

③.RS收到請求報文后，會首先拆開第一層封裝,然后發現里面還有一層IP首部的目標地址是自己lo接口上的VIP，所以會處理次請求報文，并將響應報文通過lo接口送給eth0網卡直接發送給客戶端。注意：需要設置lo接口的VIP不能在共網上出現。

四.LVS的調度算法

LVS的調度算法分為靜態與動態兩類。

1.靜態算法（4種）：只根據算法進行調度 而不考慮后端服務器的實際連接情況和負載情況

①.RR：輪叫調度（Round Robin）

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

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

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

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

2.動態算法（6種）：前端的調度器會根據后端真實服務器的實際連接情況來分配請求

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

②.WLC：加權最少連接(默認采用的就是這種)（Weighted Least Connections）
　 在集群系統中的服務器性能差異較大的情況下，調度器采用“加權最少鏈接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載?調度器可以自動問詢真實服務器的負載情況,并動態地調整其權值。

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

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

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

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