應用負載均衡之LVS(一)：基本概念和三種模式

本文目錄：1. LVS簡介2. LVS-ipvs三種模式的工作原理　2.1 VS/NAT模式　2.2 VS/TUN模式　2.3 VS/DR模式　2.4 lvs-ipvs的三種模式比較3. VS/TUN和VS/DR模式中的ARP問題4. LVS負載均衡的調度演算法網站架構中，負載均衡技術是實現網站架構 ...

本文目錄：
1. LVS簡介
2. LVS-ipvs三種模式的工作原理
　2.1 VS/NAT模式
　2.2 VS/TUN模式
　2.3 VS/DR模式
　2.4 lvs-ipvs的三種模式比較
3. VS/TUN和VS/DR模式中的ARP問題
4. LVS負載均衡的調度演算法

網站架構中，負載均衡技術是實現網站架構伸縮性的主要手段之一。所謂"伸縮性"，是指可以不斷向集群中添加新的伺服器來提升性能、緩解不斷增加的併發用戶訪問壓力。通俗地講，就是一頭牛拉不動時，就用兩頭、三頭、更多頭牛來拉。

負載均衡有好幾種方式：http URL重定向、DNS的A記錄負載均衡、反向代理負載均衡、IP負載均衡和鏈路層負載。本文所述為LVS，它的VS/NAT和VS/TUN模式是IP負載均衡的優秀代表，而它的VS/DR模式則是鏈路層負載均衡的優秀代表。

1.LVS簡介

LVS中文官方手冊：http://www.linuxvirtualserver.org/zh/index.html。這個手冊對於瞭解lvs的背景知識很有幫助。

LVS英文官方手冊：http://www.linuxvirtualserver.org/Documents.html。這個手冊比較全面，對於瞭解和學習lvs的原理、配置很有幫助。

LVS是章文嵩開發的一個國產開源負載均衡軟體。LVS最初是他在大學期間的玩具，隨著後來使用的用戶越來越多，LVS也越來越完善，最終集成到了Linux的內核中。有不少開源牛人都為LVS開發過輔助工具和輔助組件，最出名的就是Alexandre為LVS編寫的Keepalived，它最初專門用於監控LVS，後來加入了通過VRRP實現高可用的功能。

LVS的全稱是Linux virtual server，即Linux虛擬伺服器。之所以是虛擬伺服器，是因為LVS自身是個負載均衡器(director)，不直接處理請求，而是將請求轉發至位於它後端真正的伺服器realserver上。

LVS是四層(傳輸層tcp/udp)、七層(應用層)的負載均衡工具，只不過大眾一般都使用它的四層負載均衡功能ipvs，而七層的內容分發負載工具ktcpvs(kernel tcp virtual server)不怎麼完善，使用的人並不多。

ipvs是集成在內核中的框架，可以通過用戶空間的程式ipvsadm工具來管理，該工具可以定義一些規則來管理內核中的ipvs。就像iptables和netfilter的關係一樣。

2.LVS-ipvs三種模式的工作原理

首先要解釋的是LVS相關的幾種IP：

VIP:virtual IP，LVS伺服器上接收外網數據包的網卡IP地址。
DIP:director IP，LVS伺服器上轉發數據包到realserver的網卡IP地址。
RIP:realserver(常簡稱為RS)上接收Director轉發數據包的IP，即提供服務的伺服器IP。
CIP:客戶端的IP。

LVS的三種工作模式：通過網路地址轉換(NAT)將一組伺服器構成一個高性能的、高可用的虛擬伺服器，是VS/NAT技術。在分析VS/NAT的缺點和網路服務的非對稱性的基礎上，提出了通過IP隧道實現虛擬伺服器的方法VS/TUN（Virtual Server via IP Tunneling），和通過直接路由實現虛擬伺服器的方法VS/DR（Virtual Server via Direct Routing），它們可以極大地提高系統的伸縮性。

2.1 VS/NAT模式

客戶端發送的請求到達Director後，Director根據負載均衡演算法改寫目標地址為後端某個RIP(web伺服器池中主機之一)並轉發給該後端主機，就像NAT一樣。當後端主機處理完請求後，後端主機將響應數據交給Director，並由director改寫源地址為VIP後傳輸給客戶端。大多數商品化的IP負載均衡硬體都是使用此方法，如Cisco的LocalDirector、F5的Big/IP。

這種模式下：

RIP和DIP一般處於同一私有網段中。但並非必須，只要它們能通信即可。
各RealServer的網關指向DIP，這樣能保證將響應數據交給Director。
VS/NAT模式的最大缺點是Director負責所有進出數據：不僅處理客戶端發起的請求，還負責將響應傳輸給客戶端。而響應數據一般比請求數據大得多，調度器Director容易出現瓶頸。
這種模式配置起來最簡單。

2.2 VS/TUN模式

採用NAT技術時，由於請求和響應報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。為瞭解決這個問題，調度器把請求報文通過IP隧道轉發至真實伺服器，而真實伺服器將響應直接返回給客戶，所以調度器只處理請求報文。由於一般網路服務響應報文比請求報文大許多，採用VS/TUN技術後，調度器得到極大的解放，集群系統的最大吞吐量可以提高10倍。

VS/TUN模式的工作原理：

(1)IP隧道技術又稱為IP封裝技術，它可以將帶有源和目標IP地址的數據報文使用新的源和目標IP進行第二次封裝，這樣這個報文就可以發送到一個指定的目標主機上；
(2)VS/TUN模式下，調度器和後端伺服器組之間使用IP隧道技術。當客戶端發送的請求(CIP-->VIP)被director接收後，director修改該報文，加上IP隧道兩端的IP地址作為新的源和目標地址，並將請求轉發給後端被選中的一個目標；
(3)當後端伺服器接收到報文後，首先解封報文得到原有的CIP-->VIP，該後端伺服器發現自身的tun介面上配置了VIP，因此接受該數據包。
(4)當請求處理完成後，結果將不會重新交給director，而是直接返回給客戶端；在後端伺服器返回給客戶端數據包時，由於使用的是普通網卡介面，根據一般的路由條目，源IP地址將是該網卡介面上的地址，例如是RIP。因此，要讓響應數據包的源IP為VIP，必須添加一條特殊的路由條目，明確指定該路由的源地址是VIP。

採用VS/TUN模式時的基本屬性和要求：

RealServer的RIP和director的DIP不用處於同一物理網路中，且RIP必須可以和公網通信。也就是說集群節點可以跨互聯網實現。
realserver的tun介面上需要配置VIP地址，以便接收director轉發過來的數據包，以及作為響應報文的源IP。
director給realserver時需要藉助隧道，隧道外層的IP頭部的源IP是DIP，目標IP是RIP。而realsever響應給客戶端的IP頭部是根據隧道內層的IP頭分析得到的，源IP是VIP，目標IP是CIP。這樣客戶端就無法區分這個VIP到底是director的還是伺服器組中的。
需要添加一條特殊的路由條目，使得後端伺服器返迴響應給客戶端時的源IP為VIP。
director只處理入站請求，響應請求由realserver完成。

一般來說，VS/TUN模式會用來負載調度緩存伺服器組，這些緩存伺服器一般放置在不同網路環境，可以就近返回數據給客戶端。在請求對象不能在Cache伺服器本地命中的情況下，Cache伺服器要向源伺服器發請求，將結果取回，最後將結果返回給客戶。

2.3 VS/DR模式

VS/TUN模式下，調度器對數據包的處理是使用IP隧道技術進行二次封裝。VS/DR模式和VS/TUN模式很類似，只不過調度器對數據包的處理是改寫數據幀的目標MAC地址，通過鏈路層來負載均衡。

VS/DR通過改寫請求報文的目標MAC地址，將請求發送到真實伺服器，而真實伺服器將響應直接返回給客戶。同VS/TUN技術一樣，VS/DR技術可極大地提高集群系統的伸縮性。這種方法沒有IP隧道的開銷，對集群中的真實伺服器也沒有必須支持IP隧道協議的要求，但是要求調度器與真實伺服器都有一塊網卡連在同一物理網段上，以便使用MAC地址通信轉發數據包。

VS/DR模式的工作原理：

(1)客戶端發送的請求被director接收後，director根據負載均衡演算法，改寫數據幀的目標MAC地址為後端某RS的MAC地址，並將該數據包轉發給該RS(實際上是往整個區域網發送，但只有該MAC地址的RS才不會丟棄)。
(2)RS接收到數據包後，發現數據包的目標IP地址為VIP，而RS本身已經將VIP配置在了某個介面上，因此RS會接收下這個數據包併進行處理。
(3)處理完畢後，RS直接將響應報文響應給客戶端。在返回給客戶端的時候，由於實用的是普通網卡介面，根據一般的路由條目，源IP地址將是該網卡介面上的地址，例如RIP。因此，要讓響應數據包的源IP為VIP，需要添加一條特殊的路由條目，明確指定該路由的源地址為VIP。

也就是說，客戶端請求發送到LB上，源和目標IP為CIP:VIP，LB上有VIP和DIP，重新改寫MAC地址後通過DIP發送給某個realserver，如RS1，此時源和目標IP還是CIP:VIP，但是目標MAC地址改寫為RIP1所在網卡的MAC地址"RS1_MAC"，RS1發現自身有VIP地址，所以收下此數據報文(所以在RS上必須配置VIP)。返回時，RS1根據路由表直接返回給客戶端，此時，源和目標IP是VIP:CIP。

採用VS/DR模式時的基本屬性和要求：

RealServer的RIP和director的DIP必須處於同一網段中，以便使用MAC地址進行通信。
realserver上必須配置VIP地址，以便接收director轉發過來的數據包，以及作為響應報文的源IP。
realsever響應給客戶端的數據包的源和目標IP為VIP-->CIP。
需要添加一條特殊的路由條目，使得後端伺服器返迴響應給客戶端時的源IP為VIP。
director只處理入站請求，響應請求由realserver完成。

2.4 lvs-ipvs的三種模式比較

三種模式的比較如圖所示：

在性能上，VS/DR和VS/TUN遠高於VS/NAT，因為調度器只處於從客戶到伺服器的半連接中，按照半連接的TCP有限狀態機進行狀態遷移，極大程度上減輕了調度器的壓力。VS/DR性能又稍高於VS/TUN，因為少了隧道的開銷。但是，VS/DR和VS/TUN的主要區別是VS/TUN可以跨網路實現後端伺服器負載均衡(也可以區域網內)，而VS/DR只能和director在區域網內進行負載均衡。

3.VS/TUN和VS/DR模式中的ARP問題

在【【VS/TUN和VS/DR的arp問題】】中非常詳細地分析了ARP、arp_ignore和arp_announce相關原理和設置方法。此處簡單說明為何需要設置arp抑制以及設置arp抑制的方法。

當一個目標IP地址為VIP的數據包進入Director前端的路由器時，路由器會向區域網內發送ARP廣播，以找出VIP地址的MAC地址在哪台主機上。

Director和各RS都配置了VIP。當路由器發送ARP廣播後，Director和RS都會收到這個廣播包，且都認為這個廣播包找的就是自己，於是都回應給路由器，這樣路由器上的ARP緩存表中的條目VIP<-->vip_MAC就不斷被覆蓋直到最後一個回應。這樣一來，路由器將把客戶端的數據包發送給最後一個回應的主機，這台主機的VIP可能是Director上的，也可能是某個RS上的。在一定時間內，路由器收到目標IP為VIP的數據包都會發送給該主機。但路由器會定時發送ARP廣播包，這樣一來ARP緩存表中的VIP對應的MAC地址可能會換成另一臺主機。

因此，必須要保證路由器只保存Director上VIP對應的MAC地址，即只允許Director才對路由器的ARP廣播進行回應。也就是說，所有RS上的VIP必須隱藏起來。

一般通過將Real Server上的VIP設置在lo介面的別名介面上(如lo:0)，並設置arp_ignore=1和arp_announce=2的方式來隱藏RS上的VIP。至於VIP為何要設置在lo介面上以及為何要這樣設置這兩個arp參數，請參看【【VS/TUN和VS/DR的arp問題】】，內容非常詳細。

echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/all/arp_announce

或者

sysctl -w net.ipv4.conf.all.arp_ignore=1
sysctl -w net.ipv4.conf.all.arp_announce=2

或者將arp參數設置到內核參數配置文件中以讓其永久生效。

echo "net.ipv4.conf.all.arp_ignore=1" >>/etc/sysctl.conf
echo "net.ipv4.conf.all.arp_announce=2" >>/etc/sysctl.conf
sysctl -p

在網上幾乎所有文章還設置了lo介面上的arp參數：

echo 1 >/proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 >/proc/sys/net/ipv4/conf/lo/arp_announce

但這沒有任何意義，因為從lo介面不受arp參數的影響。

應該在配置VIP之前就設置arp參數，以防止配置VIP後、設置arp抑制之前被外界主機發現。

4.LVS負載均衡的調度演算法

LVS的調度演算法，詳細內容見官方手冊：http://www.linuxvirtualserver.org/zh/lvs4.html 。

IPVS在內核中的負載均衡調度是以連接為粒度的。在HTTP協議（非持久）中，每次從WEB伺服器上獲取資源都需要建立一個TCP連接，同一用戶的不同請求會被調度到不同的伺服器上，所以這種細粒度的調度在一定程度上可以避免單個用戶訪問的突發性引起伺服器間的負載不平衡。

LVS分為兩種調度方式：靜態調度和動態反饋調度。

靜態調度方式是指不管RS的繁忙程度，根據調度演算法計算後輪到誰就調度誰。例如兩台realserver，一開始雙方都在處理500個連接，下一個請求到來前，server1只斷開了10個，而server2斷開了490個，但是此時輪到了server1，就會調度server1而不管繁忙的程度。

動態調度方式是指根據RS的繁忙程度反饋，計算出下一個連接應該調度誰(動態反饋負載均衡演算法考慮伺服器的實時負載和響應情況，不斷調整伺服器間處理請求的比例，來避免有些伺服器超載時依然收到大量請求，從而提高整個系統的吞吐率)。

在內核中的連接調度演算法上，IPVS已實現了以下八種調度演算法：預設的演算法為wlc。

靜態調度：
- 輪叫調度（Round-Robin Scheduling,rr）
- 加權輪叫調度（Weighted Round-Robin Scheduling,wrr），按照權重比例作為輪詢標準
- 目標地址散列調度（Destination Hashing Scheduling,dh），目標地址哈希，對於同一目標IP的請求總是發往同一伺服器
- 源地址散列調度（Source Hashing Scheduling,sh），源地址哈希，在一定時間內，只要是來自同一個客戶端的請求，就發送至同一個realserver
動態反饋調度：
- 最小連接調度（Least-Connection Scheduling,lc），調度器需要記錄各個伺服器已建立連接的數目，當一個請求被調度到某伺服器，其連接數加1；當連接中止或超時，其連接數減1。當各個伺服器的處理能力不同時，該演算法不理想。
- 加權最小連接調度（Weighted Least-Connection Scheduling,wlc）
- 基於本地的最少連接（Locality-Based Least Connections Scheduling,lblc），目前該演算法主要用於cache集群系統。
- 帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication Scheduling,lblcr），目前主要用於Cache集群系統。