LVS原理詳解（3種工做模式及8種調度算法）

2017年1月12日, 星期四

---

LVS原理詳解（3種工做模式及8種調度算法）

 

LVS原理詳解及部署之二：LVS原理詳解（3種工做方式8種調度算法）

做者：woshiliwentong  發佈日期：2014-01-06 09:31:20

1、集羣簡介

什麼是集羣

計算機集羣簡稱集羣是一種計算機系統，它經過一組鬆散集成的計算機軟件和/或硬件鏈接起來高度緊密地協做完成計算工做。在某種意義上，他們能夠被看做是一臺計算機。集羣系統中的單個計算機一般稱爲節點，一般經過局域網鏈接，但也有其它的可能鏈接方式。集羣計算機一般用來改進單個計算機的計算速度和/或可靠性。通常狀況下集羣計算機比單個計算機，好比工做站或超級計算機性能價格比要高得多。

集羣就是一組獨立的計算機，經過網絡鏈接組合成一個組合來共同完一個任務

LVS在企業架構中的位置：

以上的架構只是衆多企業裏面的一種而已。綠色的線就是用戶訪問請求的數據流向。用戶-->LVS負載均衡服務器--->apahce服務器--->mysql服務器&memcache服務器&共享存儲服務器。而且咱們的mysql、共享存儲也可以使用LVS再進行負載均衡。

---------------小結-------------------------

集羣：就是一組相互獨立的計算機，經過高速的網絡組成一個計算機系統，每一個集羣節點都是運行其本身進程的一個獨立服務器。對網絡用戶來說，網站後端就是一個單一的系統，協同起來向用戶提供系統資源，系統服務。

-------------------------------------------

 

爲何要使用集羣

 

集羣的特色

1）高性能performance。一些須要很強的運算處理能力好比天氣預報，核試驗等。這就不是幾臺計算機可以搞定的。這須要上千臺一塊兒來完成這個工做的。

2）價格有效性

一般一套系統集羣架構，只須要幾臺或數十臺服務器主機便可，與動則上百王的專用超級計算機具備更高的性價比。

3）可伸縮性

當服務器負載壓力增加的時候，系統可以擴展來知足需求，且不下降服務質量。

4）高可用性

儘管部分硬件和軟件發生故障，整個系統的服務必須是7*24小時運行的。

集羣的優點

1）透明性

若是一部分服務器宕機了業務不受影響，通常耦合度沒有那麼高，依賴關係沒有那麼高。好比NFS服務器宕機了其餘就掛載不了了，這樣依賴性太強。

2）高性能

訪問量增長，可以輕鬆擴展。

3）可管理性

整個系統可能在物理上很大，但很容易管理。

4）可編程性

在集羣系統上，容易開發應用程序，門戶網站會要求這個。

 

集羣分類及不一樣分類的特色

計算機集羣架構按照功能和結構通常分紅如下幾類：

1）負載均衡集羣（Loadbalancingclusters）簡稱LBC

2）高可用性集羣（High-availabilityclusters）簡稱HAC

3）高性能計算集羣（High-perfomanceclusters）簡稱HPC

4）網格計算（Gridcomputing）

網絡上面通常認爲是有三個，負載均衡和高可用集羣式咱們互聯網行業經常使用的集羣架構。

（1）負載均衡集羣

負載均衡集羣爲企業提供了更爲實用，性價比更高的系統架構解決方案。負載均衡集羣把不少客戶集中訪問的請求負載壓力可能儘量平均的分攤到計算機集羣中處理。客戶請求負載一般包括應用程度處理負載和網絡流量負載。這樣的系統很是適合向使用同一組應用程序爲大量用戶提供服務。每一個節點均可以承擔必定的訪問請求負載壓力，而且能夠實現訪問請求在各節點之間動態分配，以實現負載均衡。

負載均衡運行時，通常經過一個或多個前端負載均衡器將客戶訪問請求分發到後端一組服務器上，從而達到整個系統的高性能和高可用性。這樣計算機集羣有時也被稱爲服務器羣。通常高可用性集羣和負載均衡集羣會使用相似的技術，或同時具備高可用性與負載均衡的特色。

 

負載均衡集羣的做用

1）分擔訪問流量（負載均衡）

2）保持業務的連續性（高可用）

（2）高可用性集羣

通常是指當集羣中的任意一個節點失效的狀況下，節點上的全部任務自動轉移到其餘正常的節點上，而且此過程不影響整個集羣的運行，不影響業務的提供。

相似是集羣中運行着兩個或兩個以上的同樣的節點，當某個主節點出現故障的時候，那麼其餘做爲從 節點的節點就會接替主節點上面的任務。從節點能夠接管主節點的資源（IP地址，架構身份等），此時用戶不會發現提供服務的對象從主節點轉移到從節點。

高可用性集羣的做用：當一個機器宕機另外一臺進行接管。比較經常使用的高可用集羣開源軟件有：keepalive，heardbeat。

（3）高性能計算集羣

高性能計算集羣採用將計算任務分配到集羣的不一樣計算節點兒提升計算能力，於是主要應用在科學計算領域。比較流行的HPC採用Linux操做系統和其它一些免費軟件來完成並行運算。這一集羣配置一般被稱爲Beowulf集羣。這類集羣一般運行特定的程序以發揮HPCcluster的並行能力。這類程序通常應用特定的運行庫, 好比專爲科學計算設計的MPI庫。

HPC集羣特別適合於在計算中各計算節點之間發生大量數據通信的計算做業，好比一個節點的中間結果或影響到其它節點計算結果的狀況。

經常使用集羣軟硬件

 

經常使用開源集羣軟件有：lvs，keepalived，haproxy，nginx，apache，heartbeat

經常使用商業集羣硬件有：F5,Netscaler，Radware，A10等

 

2、LVS負載均衡集羣介紹

負載均衡集羣的做用：提供一種廉價、有效、透明的方法，來擴展網絡設備和服務器的負載帶寬、增長吞吐量，增強網絡數據處理能力、提升網絡的靈活性和可用性。

1）把單臺計算機沒法承受的大規模的併發訪問或數據流量分擔到多臺節點設備上分別處理，減小用戶等待響應的時間，提高用戶體驗。

2）單個重負載的運算分擔到多臺節點設備上作並行處理，每一個節點設備處理結束後，將結果彙總，返回給用戶，系統處理能力獲得大幅度提升。

3）7*24小時的服務保證，任意一個或多個設備節點設備宕機，不能影響到業務。在負載均衡集羣中，全部計算機節點都應該提供相同的服務，集羣負載均衡獲取全部對該服務的如站請求。

 

LVS介紹

LVS是linux virtual server的簡寫linux虛擬服務器，是一個虛擬的服務器集羣系統，能夠再unix/linux平臺下實現負載均衡集羣功能。該項目在1998年5月由章文嵩博士組織成立。

 

如下是LVS官網提供的4篇文章：（很是詳細，我以爲有興趣仍是看官方文檔比較正宗吧！！）

http://www.linuxvirtualserver.org/zh/lvs1.html

http://www.linuxvirtualserver.org/zh/lvs2.html

http://www.linuxvirtualserver.org/zh/lvs3.html

http://www.linuxvirtualserver.org/zh/lvs4.html

IPVS發展史

早在2.2內核時，IPVS就已經之內核補丁的形式出現。

從2.4.23版本開始ipvs軟件就是合併到linux內核的經常使用版本的內核補丁的集合。

從2.4.24之後IPVS已經成爲linux官方標準內核的一部分

從上圖能夠看出lpvs是工做在內核層，咱們不可以直接操做ipvs，vs負載均衡調度技術是在linux內核中實現的。所以，被稱之爲linux虛擬服務器。咱們使用該軟件配置lvs的時候，不能直接配置內核中的ipvs，而須要使用ipvs的管理工具ipvsadm進行管理。經過keepalived也能夠管理LVS。

LVS體系結構與工做原理簡單描述

LVS集羣負載均衡器接受服務的全部入展客戶端的請求，而後根據調度算法決定哪一個集羣節點來處理回覆客戶端的請求。

LVS虛擬服務器的體系以下圖所示，一組服務器經過高速的局域網或者地理分佈的廣域網相互鏈接，在這組服務器以前有一個負載調度器（load balance）。負載調度器負責將客戶的請求調度到真實服務器上。這樣這組服務器集羣的結構對用戶來講就是透明的。客戶訪問集羣系統就如只是訪問一臺高性能，高可用的服務器同樣。客戶程序不受服務器集羣的影響，不作任何修改。

就好比說：咱們去飯店吃飯點菜，客戶只要跟服務員點菜就行。並不須要知道具體他們是怎麼分配工做的，因此他們內部對於咱們來講是透明的。此時這個服務員就會按照必定的規則把他手上的活，分配到其餘人員上去。這個服務員就是負載均衡器（LB）然後面這些真正作事的就是服務器集羣。

底下是官網提供的結構圖：

LVS的基本工做過程

客戶請發送向負載均衡服務器發送請求。負載均衡器接受客戶的請求，而後先是根據LVS的調度算法（8種）來決定要將這個請求發送給哪一個節點服務器。而後依據本身的工做模式（3種）來看應該如何把這些客戶的請求如何發送給節點服務器，節點服務器又應該如何來把響應數據包發回給客戶端。

恩，那這樣咱們就只要接下來搞懂LVS的3中工做模式，8種調度算法就能夠了。

 

LVS的三種工做模式：

 

1）VS/NAT模式（Network address translation）

2）VS/TUN模式（tunneling）

3）DR模式（Direct routing）

 

 

一、NAT模式-網絡地址轉換

Virtualserver via Network address translation(VS/NAT)

這個是經過網絡地址轉換的方法來實現調度的。首先調度器(LB)接收到客戶的請求數據包時（請求的目的IP爲VIP），根據調度算法決定將請求發送給哪一個後端的真實服務器（RS）。而後調度就把客戶端發送的請求數據包的目標IP地址及端口改爲後端真實服務器的IP地址（RIP）,這樣真實服務器（RS）就可以接收到客戶的請求數據包了。真實服務器響應完請求後，查看默認路由（NAT模式下咱們須要把RS的默認路由設置爲LB服務器。）把響應後的數據包發送給LB,LB再接收到響應包後，把包的源地址改爲虛擬地址（VIP）而後發送回給客戶端。

調度過程IP包詳細圖：

原理圖簡述：

1)客戶端請求數據，目標IP爲VIP

2)請求數據到達LB服務器，LB根據調度算法將目的地址修改成RIP地址及對應端口（此RIP地址是根據調度算法得出的。）並在鏈接HASH表中記錄下這個鏈接。

3)數據包從LB服務器到達RS服務器webserver，而後webserver進行響應。Webserver的網關必須是LB，而後將數據返回給LB服務器。

4)收到RS的返回後的數據，根據鏈接HASH表修改源地址VIP&目標地址CIP，及對應端口80.而後數據就從LB出發到達客戶端。

5)客戶端收到的就只能看到VIP\DIP信息。

 

NAT模式優缺點：

一、NAT技術將請求的報文和響應的報文都須要經過LB進行地址改寫，所以網站訪問量比較大的時候LB負載均衡調度器有比較大的瓶頸，通常要求最多之能10-20臺節點

二、只須要在LB上配置一個公網IP地址就能夠了。

三、每臺內部的節點服務器的網關地址必須是調度器LB的內網地址。

四、NAT模式支持對IP地址和端口進行轉換。即用戶請求的端口和真實服務器的端口能夠不一致。

 

 

二、TUN模式

virtual server via ip tunneling模式:採用NAT模式時，因爲請求和響應的報文必須經過調度器地址重寫，當客戶請求愈來愈多時，調度器處理能力將成爲瓶頸。爲了解決這個問題，調度器把請求的報文經過IP隧道轉發到真實的服務器。真實的服務器將響應處理後的數據直接返回給客戶端。這樣調度器就只處理請求入站報文，因爲通常網絡服務應答數據比請求報文大不少，採用VS/TUN模式後，集羣系統的最大吞吐量能夠提升10倍。

VS/TUN的工做流程圖以下所示，它和NAT模式不一樣的是，它在LB和RS之間的傳輸不用改寫IP地址。而是把客戶請求包封裝在一個IP tunnel裏面，而後發送給RS節點服務器，節點服務器接收到以後解開IP tunnel後，進行響應處理。而且直接把包經過本身的外網地址發送給客戶不用通過LB服務器。

Tunnel原理流程圖:

 

原理圖過程簡述：

1）客戶請求數據包，目標地址VIP發送到LB上。

2）LB接收到客戶請求包，進行IP Tunnel封裝。即在原有的包頭加上IP Tunnel的包頭。而後發送出去。

3）RS節點服務器根據IP Tunnel包頭信息（此時就又一種邏輯上的隱形隧道，只有LB和RS之間懂）收到請求包，而後解開IP Tunnel包頭信息，獲得客戶的請求包並進行響應處理。

4）響應處理完畢以後，RS服務器使用本身的出公網的線路，將這個響應數據包發送給客戶端。源IP地址仍是VIP地址。（RS節點服務器須要在本地迴環接口配置VIP，後續會講）

三、DR模式（直接路由模式）

Virtual server via direct routing (vs/dr)

DR模式是經過改寫請求報文的目標MAC地址，將請求發給真實服務器的，而真實服務器響應後的處理結果直接返回給客戶端用戶。同TUN模式同樣，DR模式能夠極大的提升集羣系統的伸縮性。並且DR模式沒有IP隧道的開銷，對集羣中的真實服務器也沒有必要必須支持IP隧道協議的要求。可是要求調度器LB與真實服務器RS都有一塊網卡鏈接到同一物理網段上，必須在同一個局域網環境。

DR模式是互聯網使用比較多的一種模式。

DR模式原理圖：

DR模式原理過程簡述：

VS/DR模式的工做流程圖如上圖所示，它的鏈接調度和管理與NAT和TUN中的同樣，它的報文轉發方法和前兩種不一樣。DR模式將報文直接路由給目標真實服務器。在DR模式中，調度器根據各個真實服務器的負載狀況，鏈接數多少等，動態地選擇一臺服務器，不修改目標IP地址和目標端口，也不封裝IP報文，而是將請求報文的數據幀的目標MAC地址改成真實服務器的MAC地址。而後再將修改的數據幀在服務器組的局域網上發送。由於數據幀的MAC地址是真實服務器的MAC地址，而且又在同一個局域網。那麼根據局域網的通信原理，真實復位是必定可以收到由LB發出的數據包。真實服務器接收到請求數據包的時候，解開IP包頭查看到的目標IP是VIP。（此時只有本身的IP符合目標IP纔會接收進來，因此咱們須要在本地的迴環藉口上面配置VIP。另：因爲網絡接口都會進行ARP廣播響應，但集羣的其餘機器都有這個VIP的lo接口，都響應就會衝突。因此咱們須要把真實服務器的lo接口的ARP響應關閉掉。）而後真實服務器作成請求響應，以後根據本身的路由信息將這個響應數據包發送回給客戶，而且源IP地址仍是VIP。

DR模式小結：

一、經過在調度器LB上修改數據包的目的MAC地址實現轉發。注意源地址仍然是CIP，目的地址仍然是VIP地址。

二、請求的報文通過調度器，而RS響應處理後的報文無需通過調度器LB，所以併發訪問量大時使用效率很高（和NAT模式比）

三、由於DR模式是經過MAC地址改寫機制實現轉發，所以全部RS節點和調度器LB只能在一個局域網裏面

四、RS主機須要綁定VIP地址在LO接口上，而且須要配置ARP抑制。

五、RS節點的默認網關不須要配置成LB，而是直接配置爲上級路由的網關，能讓RS直接出網就能夠。

六、因爲DR模式的調度器僅作MAC地址的改寫，因此調度器LB就不能改寫目標端口，那麼RS服務器就得使用和VIP相同的端口提供服務。

官方三種負載均衡技術比較總結表：

工做模式	VS/NAT	VS/TUN	VS/DR
Real server （節點服務器）	Config dr gw	Tunneling	Non-arp device/tie vip
Server Network	Private	LAN/WAN	LAN
Server number （節點數量）	Low 10-20	High 100	High 100
Real server gateway	Load balance	Own router	Own router
優勢	地址和端口轉換	Wan環境加密數據	性能最高
缺點	效率低	須要隧道支持	不能跨域LAN

LVS調度算法

最好參考此文章：http://www.linuxvirtualserver.org/zh/lvs4.html

Lvs的調度算法決定了如何在集羣節點之間分佈工做負荷。當director調度器收到來自客戶端訪問VIP的上的集羣服務的入站請求時，director調度器必須決定哪一個集羣節點應該處理請求。Director調度器用的調度方法基本分爲兩類：

固定調度算法：rr，wrr，dh，sh

動態調度算法：wlc，lc，lblc，lblcr

 

算法	說明
rr	輪詢算法，它將請求依次分配給不一樣的rs節點，也就是RS節點中均攤分配。這種算法簡單，但只適合於RS節點處理性能差很少的狀況
wrr	加權輪訓調度，它將依據不一樣RS的權值分配任務。權值較高的RS將優先得到任務，而且分配到的鏈接數將比權值低的RS更多。相同權值的RS獲得相同數目的鏈接數。
Wlc	加權最小鏈接數調度，假設各臺RS的全職依次爲Wi，當前tcp鏈接數依次爲Ti，依次去Ti/Wi爲最小的RS做爲下一個分配的RS
Dh	目的地址哈希調度（destination hashing）以目的地址爲關鍵字查找一個靜態hash表來得到須要的RS
SH	源地址哈希調度（source hashing）以源地址爲關鍵字查找一個靜態hash表來得到須要的RS
Lc	最小鏈接數調度（least-connection）,IPVS表存儲了全部活動的鏈接。LB會比較將鏈接請求發送到當前鏈接最少的RS.
Lblc	基於地址的最小鏈接數調度（locality-based least-connection）：未來自同一個目的地址的請求分配給同一臺RS，此時這臺服務器是還沒有滿負荷的。不然就將這個請求分配給鏈接數最小的RS，並以它做爲下一次分配的首先考慮。

LVS調度算法的生產環境選型：

一、通常的網絡服務，如http，mail，mysql等經常使用的LVS調度算法爲：

a.基本輪詢調度rr

b.加權最小鏈接調度wlc

c.加權輪詢調度wrc

二、基於局部性的最小鏈接lblc和帶複製的給予局部性最小鏈接lblcr主要適用於web cache和DB cache

三、源地址散列調度SH和目標地址散列調度DH能夠結合使用在防火牆集羣中，能夠保證整個系統的出入口惟一。

實際適用中這些算法的適用範圍不少，工做中最好參考內核中的鏈接調度算法的實現原理，而後根據具體的業務需求合理的選型。

來源： http://www.it165.net/admin/html/201401/2248.html

null