linux系統構架 - LB集羣之LVS介紹

LB 集羣是 load balance 集羣的簡寫，翻譯成中文就是負載均衡集羣。經常使用的負載均衡開源軟件有 nginx、lvs、keepalived ，商業的硬件負載設備 F五、Netscale。

LB 集羣的架構以下圖，原理也很簡答，就是當用戶的請求過來時，會直接發到分發器（Director Server）上，而後它把用戶的請求根據預先設置好的算法，智能均衡地分發到後端的真正服務器（real server）上。若是不一樣的機器，可能用戶請求到的數據不同，爲了不這樣的狀況發生，因此用到了共享存儲，這樣保證全部用戶請求的數據是同樣的。

LVS 是一個實現負載均衡集羣的開源軟件項目，LVS 架構從邏輯上可分爲調度層(Director)、server 集羣層(Real server)和共享存儲。LVS 從實現上分爲下面三種模式。

LVS的基本工做過程

（1）NAT（調度器將請求的目標 ip 即 vip 地址改成 Real server 的 ip, 返回的數據包也通過調度器，調度器再把源地址修改成 vip）。

NAT模式-網絡地址轉換

Virtualserver via Network address translation(VS/NAT)

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

原理圖簡述：

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地址和端口進行轉換。即用戶請求的端口和真實服務器的端口能夠不一致。

 

（2）TUN （調度器將請求來的數據包封裝加密經過 ip 隧道轉發到後端的 real server 上，而 real server 會直接把數據返回給客戶端，而再也不通過調度器）。

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地址。

 

（3）DR（調度器將請求來的數據包的目標 mac 地址改成 real server 的 mac 地址，返回的時候也不通過調度器，直接返回給客戶端）。

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相同的端口提供服務。

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

 

 

出現的幾個 IP 概念，須要解釋一下，其中 DIP(driector ip)爲分發器的 IP，NAT 模式下它必須爲公網 IP，要對外服務。VIP(virtual ip)爲虛擬 IP，用在 TUN 和 DR 模式中，須要同時配置在分發器和後端真實服務器上。RIP(Real IP)爲後端真實服務器的 IP，在 TUN 和DR 模式中，RIP 爲公網 IP。

參考資料 http://www.it165.net/admin/html/201401/2248.html

 

LVS調度算法

要想把用戶的請求調度給後端的 RS，是須要通過調度算法來實現的，那麼關於 LVS 的調度算法，都有哪些？
（1）輪叫調度(Round Robin)(簡稱 rr)，這種算法是最簡單的，無論後端 RS 配置和處理能力，很是均衡地分發下去。
（2）加權輪叫(Weighted Round Robin)(簡稱 wrr)，比上面的算法多了一個權重的概念，能夠給 RS 設置權重，權重越高，那麼分發的請求數越多，權重取值範圍 0-100。
（3）最少連接(least connection)(LC)，這個算法會根據後端 RS 的鏈接數來決定把請求分發給誰，好比 RS1 鏈接數比 RS2 鏈接數少，那麼請求就優先發給 RS1。
（4）加權最少連接(Weighted Least Connections)(WLC) ，比第三個算法多了一個權重的概念。

 

 

 

 

 

 

 

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