LVS調度算法

三種LVS負載均衡模式

LVS負載均衡模式---1.NAT模式

NAT用法原本是由於網絡IP地址不足而把內部保留IP地址經過映射轉換成公網地址的一種上網方式(原地址NAT)?若是把NAT的過程稍微變化,就能夠成爲負載均衡的一種方式?原理其實就是把從客戶端發來的IP包的IP頭目的地址在DR上換成其中一臺REALSERVER的IP地址併發至此REALSERVER,而REALSERVER則在處理完成後把數據通過DR主機發回給客戶端,DR在這個時候再把數據包的原IP地址改成DR接口上的IP地址便可?期間,不管是進來的流量,仍是出去的流量,都必須通過DR?

LVS負載均衡模式---2.IP隧道模式

隧道模式則相似於×××的方式,使用網絡分層的原理,在從客戶端發來的數據包的基礎上,封裝一個新的IP頭標記(不完整的IP頭,只有目的IP部)發給REALSERVER,REALSERVER收到後,先把DR發過來的數據包的頭給解開,還原其數據包原樣,處理後,直接返回給客戶端,而不須要再通過DR?須要注意的是,因爲REALSERVER須要對DR發過來的數據包進行還原,也就是說必須支持IPTUNNEL協議?因此,在REALSERVER的內核中,必須編譯支持IPTUNNEL這個選項?IPTUNNEL也在Net working options裏面?

LVS負載均衡模式---3.直接路由模式

直接路由模式比較特別,很難說和什麼方面類似,前2種模式基本上都是工做在網絡層上(三層),而直接路由模式則應該是工做在數據鏈路層上(二層)?其原理爲,DR和REALSERVER都使用同一個IP對外服務?但只有DR對ARP請求進行響應,全部REALSERVER對自己這個IP的ARP請求保持靜默?也就是說,網關會把對這個服務IP的請求所有定向給DR,而DR收到數據包後根據調度算法,找出對應的REALSERVER,把目的MAC地址改成REALSERVER的MAC併發給這臺REALSERVER?這時REALSERVER收到這個數據包,則等於直接從客戶端收到這個數據包無異,處理後直接返回給客戶端?因爲DR要對二層包頭進行改換,因此DR和REALSERVER之間必須在一個廣播域,也能夠簡單的理解爲在同一臺交換機上?

LVS負載均衡的八種調度算法：

1.輪叫調度(Round-RobinScheduling) rr
**
調度器經過"輪叫"調度算法將外部請求按順序輪流分配到集羣中的真實服務器上,它均等地對待每一臺服務器,而無論服務器上實際的鏈接數和系統負載?

2.加權輪叫調度(WeightedRound-RobinScheduling) wrr

調度器經過"加權輪叫"調度算法根據真實服務器的不一樣處理能力來調度訪問請求?這樣能夠保證處理能力強的服務器處理更多的訪問流量?調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值?

3.最小鏈接調度(Least-ConnectionScheduling) lc

調度器經過"最少鏈接"調度算法動態地將網絡請求調度到已創建的連接數最少的服務器上?若是集羣系統的真實服務器具備相近的系統性能,採用"最小鏈接"調度算法能夠較好地均衡負載?

4.加權最小鏈接調度(WeightedLeast-ConnectionScheduling) wlc

在集羣系統中的服務器性能差別較大的狀況下,調度器採用"加權最少連接"調度算法優化負載均衡性能,具備較高權值的服務器將承受較大比例的活動鏈接負載?調度器能夠自動問詢真實服務器的負載狀況,並動態地調整其權值

5.基於局部性的最少連接(Locality-BasedLeastConnectionsScheduling) lblc

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

6.帶複製的基於局部性最少連接(Locality-BasedLeastConnectionswithReplicationScheduling) lblcr

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

7.目標地址散列調度(DestinationHashingScheduling) dh

目標地址散列"調度算法根據請求的目標IP地址,做爲散列鍵(HashKey)從靜態分配的散列表找出對應的服務器,若該服務器是可用的且未超載,將請求發送到該服務器,不然返回空

8.源地址散列調度(SourceHashingScheduling) sh

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

二.LVS的基本工做原理

1. 當用戶向負載均衡調度器（Director Server）發起請求，調度器將請求發往至內核空間
2. PREROUTING鏈首先會接收到用戶請求，判斷目標IP肯定是本機IP，將數據包發往INPUT鏈
3. IPVS是工做在INPUT鏈上的，當用戶請求到達INPUT時，IPVS會將用戶請求和本身已定義好的集羣服務進行比對，若是用戶請求的就是定義的集羣服務，那麼此時IPVS會強行修改數據包裏的目標IP地址及端口，並將新的數據包發往POSTROUTING鏈
4. POSTROUTING連接收數據包後發現目標IP地址恰好是本身的後端服務器，那麼此時經過選路，將數據包最終發送給後端的服務器

三. LVS/NAT的原理

(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP
(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c). IPVS比對數據包請求的服務是否爲集羣服務，如果，修改數據包的目標IP地址爲後端服務器IP，而後將數據包發至POSTROUTING鏈。 此時報文的源IP爲CIP，目標IP爲RIP
(d). POSTROUTING鏈經過選路，將數據包發送給Real Server
(e). Real Server比對發現目標爲本身的IP，開始構建響應報文發回給Director Server。 此時報文的源IP爲RIP，目標IP爲CIP
(f). Director Server在響應客戶端前，此時會將源IP地址修改成本身的VIP地址，而後響應給客戶端。 此時報文的源IP爲VIP，目標IP爲CIP

四. LVS/DR的原理

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP
(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈
(c) IPVS比對數據包請求的服務是否爲集羣服務，如果，將請求報文中的源MAC地址修改成DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，而後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址爲DIP的MAC地址，目標MAC地址爲RIP的MAC地址
(d) 因爲DS和RS在同一個網絡中，因此是經過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址，那麼此時數據包將會發至Real Server。
(e) RS發現請求報文的MAC地址是本身的MAC地址，就接收此報文。處理完成以後，將響應報文經過lo接口傳送給eth0網卡而後向外發出。 此時的源IP地址爲VIP，目標IP爲CIP
(f) 響應報文最終送達至客戶端

五. LVS/Tun的原理
(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP爲CIP，目標IP爲VIP 。(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈(c) IPVS比對數據包請求的服務是否爲集羣服務，如果，在請求報文的首部再次封裝一層IP報文，封裝源IP爲爲DIP，目標IP爲RIP。而後發至POSTROUTING鏈。 此時源IP爲DIP，目標IP爲RIP(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（由於在外層封裝多了一層IP首部，因此能夠理解爲此時經過隧道傳輸）。 此時源IP爲DIP，目標IP爲RIP(e) RS接收到報文後發現是本身的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裏面還有一層IP首部，並且目標是本身的lo接口VIP，那麼此時RS開始處理此請求，處理完成以後，經過lo接口送給eth0網卡，而後向外傳遞。 此時的源IP地址爲VIP，目標IP爲CIP(f) 響應報文最終送達至客戶端