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地址對應的服務器 組，按」最小鏈接」原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按「最小鏈接」原則從這個集羣中選出一臺 服務器，將該服務器加入到服務器組中，將請求發送到該服務器｡同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以下降複製的程 度。