LVS原理詳解

LVS項目介紹
 LVS原理詳解以及部署

一、LVS 簡介

linux virtual server 簡稱 LVS，是章文嵩博士1998年發起的一個開源項目(官網)。

Internet的快速增長使多媒體網絡服務器面對的訪問數量快速增加，服務器需要具備提供大量併發訪問服務的能力，因此對於大負載的服務器來講， CPU、I/O處理能力很快會成爲瓶頸。由於單臺服務器的性能總是有限的，簡單的提高硬件性能並不能真正解決這個問題。爲此，必須採用多服務器和負載均衡技術才能滿足大量併發訪問的需要。

針對高可伸縮、高可用網絡服務的需求，我們給出了基於IP負載均衡技術和基於內容請求分發技術的負載平衡調度解決方法，並在Linux內核中實現了這些方法，將一組服務器構成一個實現可伸縮的、高可用網絡服務的虛擬服務器。

Linux 虛擬服務器(Linux Virtual Servers,LVS) 使用負載均衡技術將多臺服務器組成一個虛擬服務器。它爲適應快速增長的網絡訪問需求提供了一個負載能力易於擴展，而價格低廉的解決方案。

虛擬服務器的體系結構如下圖所示，一組服務器通過高速的局域網或者地理分佈的廣域網相互連接，在它們的前端有一個負載調度器（Load Balancer）。負載調度器能無縫地將網絡請求調度到真實服務器上，從而使得服務器集羣的結構對客戶是透明的，客戶訪問集羣系統提供的網絡服務就像訪問一臺高性能、高可用的服務器一樣。客戶程序不受服務器集羣的影響不需作任何修改。系統的伸縮性通過在服務機羣中透明地加入和刪除一個節點來達到，通過檢測節點或服務進程故障和正確地重置系統達到高可用性。由於我們的負載調度技術是在Linux內核中實現的，我們稱之爲Linux虛擬服務器（Linux Virtual Server）。

lvs已經集成到linux 2.6版本以上的內核中。lvs的負載能力特別強，優化空間特別大。lvs的變種DPVS據說是lvs性能的幾倍，由愛奇藝開發，並廣泛用於愛奇藝IDC。其他負載均衡服務器還有nginx，haproxy，F5，Netscale。

二、LVS 基本原理

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

三、LVS組成

LVS 由2部分程序組成，包括 ipvs 和 ipvsadm。

IPVS(ip virtual server)：一段代碼工作在內核空間，叫IPVS，是真正生效實現調度的代碼。IPVS的總體結構主要由IP包處理、負載均衡算法、系統配置與管理三個模塊及虛擬服務器與真實服務器鏈表組成。
ipvsadm：另外一段是工作在用戶空間，叫ipvsadm，即IPVS管理器，負責爲ipvs內核框架編寫規則，定義誰是集羣服務，而誰是後端真實的服務器(Real Server)。

四、LVS技術術語

DS：Director Server。指的是前端負載均衡器節點。
RS：Real Server。後端真實的工作服務器。
VIP：Virtual IP，向外部直接面向用戶請求，作爲用戶請求的目標的IP地址。
DIP：Director Server IP，主要用於和內部主機通訊的IP地址。
RIP：Real Server IP，後端服務器的IP地址。
CIP：Client IP，訪問客戶端的IP地址。

五、LVS工作模式和原理

5.1、NAT模式

通過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給後端的真實服務器；真實服務器的響應報文通過調度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。

VS/NAT的體系結構

5.1.1、NAT模式工作原理

(1) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。此時報文的源IP爲CIP，目標IP爲VIP。
(2) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈。
(3) IPVS比對數據包請求的服務是否爲集羣服務，若是，修改數據包的目標IP地址爲後端服務器IP，然後將數據包發至POSTROUTING鏈。此時報文的源IP爲CIP，目標IP爲RIP。
(4) POSTROUTING鏈通過選路，將數據包發送給Real Server
(5) Real Server比對發現目標爲自己的IP，開始構建響應報文發回給Director Server。此時報文的源IP爲RIP，目標IP爲CIP。
(6) Director Server在響應客戶端前，此時會將源IP地址修改爲自己的VIP地址，然後響應給客戶端。此時報文的源IP爲VIP，目標IP爲CIP。

5.1.2、NAT特性

RIP最好是內網IP
RS的網關必須指向DIP。
DIP和RIP必須在同一個網段內。
請求和迴應的報文都必須經過director，director容易成爲瓶頸。
NAT支持端口轉發。

5.2、Tunnel模式

在VS/NAT 的集羣系統中，請求和響應的數據報文都需要通過負載調度器，當真實服務器的數目在10臺和20臺之間時，負載調度器將成爲整個集羣系統的新瓶頸。大多數 Internet服務都有這樣的特點：請求報文較短而響應報文往往包含大量的數據。如果能將請求和響應分開處理，即在負載調度器中只負責調度請求而響應直接返回給客戶，將極大地提高整個集羣系統的吞吐量。

IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標爲一個IP地址的數據報文能被封裝和轉發到另一個IP地址。IP隧道技術亦稱爲IP封裝技術（IP encapsulation）。IP隧道主要用於移動主機和虛擬私有網絡（Virtual Private Network），在其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。

我們利用IP隧道技術將請求報文封裝轉發給後端服務器，響應報文能從後端服務器直接返回給客戶。但在這裏，後端服務器有一組而非一個，所以我們不可能靜態地建立一一對應的隧道，而是動態地選擇一臺服務器，將請求報文封裝和轉發給選出的服務器。這樣，我們可以利用IP隧道的原理將一組服務器上的網絡服務組成在一個IP地址上的虛擬網絡服務。 VS/TUN的體系結構如下圖所示，各個服務器將VIP地址配置在自己的IP隧道設備上。

VS/TUN的體系結構

5.2.1、Tunnel模式工作原理

當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。此時報文的源IP爲CIP，目標IP爲VIP 。
PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈。
IPVS比對數據包請求的服務是否爲集羣服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP爲爲DIP，目標IP爲RIP。然後發至POSTROUTING鏈。此時源IP爲DIP，目標IP爲RIP。
POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因爲在外層封裝多了一層IP首部，所以可以理解爲此時通過隧道傳輸）。此時源IP爲DIP，目標IP爲RIP。
RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裏面還有一層IP首部，而且目標是自己的lo接口VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo接口送給eth0網卡，然後向外傳遞。此時的源IP地址爲VIP，目標IP爲CIP
響應報文最終送達至客戶端

在這裏需要指出，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址肯定也爲VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認爲得到正常的服務，而不會知道究竟是哪一臺服務器處理的。

5.2.2、Tunnel模式特性

RIP、VIP、DIP全是公網地址。
RS的網關不會也不可能指向DIP
所有的請求報文經由Director Server，但響應報文必須不能進過Director Server
不支持端口映射
RS的系統必須支持隧道

5.3、DR模式

跟VS/TUN 方法相同，VS/DR利用大多數Internet服務的非對稱特點，負載調度器中只負責調度請求，而服務器直接將響應返回給客戶，可以極大地提高整個集羣系統的吞吐量。該方法與IBM的NetDispatcher產品中使用的方法類似（其中服務器上的IP地址配置方法是相似的），但IBM的 NetDispatcher是非常昂貴的商品化產品，我們也不知道它內部所使用的機制，其中有些是IBM的專利。

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

VIP地址爲調度器和服務器組共享，調度器配置的VIP地址是對外可見的，用於接收虛擬服務的請求報文；所有的服務器把VIP地址配置在各自的Non-ARP網絡設備上，它對外面是不可見的，只是用於處理目標地址爲VIP的網絡請求

5.3.1、DR模式工作原理

(1) 首先用戶用CIP請求VIP。
(2) 根據上圖可以看到,不管是Director Server還是Real Server上都需要配置相同的VIP,那麼當用戶請求到達我們的集羣網絡的前端路由器的時候,請求數據包的源地址爲CIP目標地址爲VIP,此時路由器會發廣播問誰是VIP,那麼我們集羣中所有的節點都配置有VIP,此時誰先響應路由器那麼路由器就會將用戶請求發給誰,這樣一來我們的集羣系統是不是沒有意義了,那我們可以在網關路由器上配置靜態路由指定VIP就是Director Server,或者使用一種機制不讓Real Server 接收來自網絡中的ARP地址解析請求,這樣一來用戶的請求數據包都會經過Director Servrer。
(3) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。此時報文的源IP爲CIP，目標IP爲VIP。
(4) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈。
(5) IPVS比對數據包請求的服務是否爲集羣服務，若是，將請求報文中的源MAC地址修改爲DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然後將數據包發至POSTROUTING鏈。此時的源IP和目的IP均未修改，僅修改了源MAC地址爲DIP的MAC地址，目標MAC地址爲RIP的MAC地址
(6) 由於DS和RS在同一個網絡中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址爲RIP的MAC地址，那麼此時數據包將會發至Real Server。
(7) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之後，將響應報文通過lo接口傳送給eth0網卡然後向外發出。此時的源IP地址爲VIP，目標IP爲CIP
(8) 響應報文最終送達至客戶端。

VS/DR的工作流程

在VS/DR中，根據缺省的TCP/IP協議棧處理，請求報文的目標地址爲VIP，響應報文的源地址肯定也爲VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認爲得到正常的服務，而不會知道是哪一臺服務器處理的。

5.3.2、配置DR有三種方式：

第一種方式：

在路由器上明顯說明vip對應的地址一定是Director上的MAC，只要綁定，以後再跟vip通信也不用再請求了，這個綁定是靜態的，所以它也不會失效，也不會再次發起請求，但是有個前提，我們的路由設備必須有操作權限能夠綁定MAC地址，萬一這個路由器是運行商操作的，我們沒法操作怎麼辦？第一種方式固然很簡便，但未必可行。

第二種方式：

在給別主機上（例如：紅帽）它們引進的有一種程序arptables,它有點類似於iptables,它肯定是基於arp或基於MAC做訪問控制的，很顯然我們只需要在每一個real server上定義arptables規則，如果用戶arp廣播請求的目標地址是本機的vip則不予相應，或者說相應的報文不讓出去，很顯然網關（gateway）是接受不到的，也就是director相應的報文才能到達gateway，這個也行。第二種方式我們可以基於arptables。

第三種方式：

在相對較新的版本中新增了兩個內核參數(kernelparameter)，第一個是arp_ignore定義接受到ARP請求時的相應級別;第二個是arp_announce定義將自己地址向外通告時的通告級別。

提示：很顯然我們現在的系統一般在內核中都是支持這些參數的，我們用參數的方式進行調整更具有樸實性，它還不依賴於額外的條件，像arptables,也不依賴外在路由配置的設置，反而通常我們使用的是第三種配置

arp_ignore:定義接受到ARP請求時的相應級別
0：  只要本地配置的有相應地址，就給予響應。（默認）
1：  僅迴應目標IP地址是本地的入網地址的arp請求。
2：  僅迴應目標IP地址是本地的入網地址，而且源IP和目標IP在同一個子網的arp請   求。
3：  不迴應該網絡界面的arp請求，而只對設置的唯一和連接地址做出迴應
4-7：保留未使用
8：  不迴應所有的arp請求。

arp_announce：定義將自己地址向外通告是的通告級別;
0:   將本地任何接口上的任何地址向外通告
1：  試圖僅向目標網絡通告與其網絡匹配的地址
2：  僅向與本地接口上地址匹配的網絡進行通告

5.3.3、DR特性

特點1：保證前端路由將目標地址爲VIP報文統統發給Director Server，而不是RS。
Director和RS的VIP爲同一個VIP。
RS可以使用私有地址；也可以是公網地址，如果使用公網地址，此時可以通過互聯網對RIP進行直接訪問。
RS跟Director Server必須在同一個物理網絡中。
所有的請求報文經由Director Server，但響應報文必須不能進過Director Server。
不支持地址轉換，也不支持端口映射
RS可以是大多數常見的操作系統
RS的網關絕不允許指向DIP(因爲我們不允許他經過director)
RS上的lo接口配置VIP的IP地址
DR模式是市面上用得最廣的。
缺陷：RS和DS必須在同一機房中

補充：特點1的解決方法：

在前端路由器做靜態地址路由綁定，將對於VIP的地址僅路由到Director Server。存在問題：用戶未必有路由操作權限，因爲有可能是運營商提供的，所以這個方法未必實用。
arptables：在arp的層次上實現在ARP解析時做防火牆規則，過濾RS響應ARP請求。這是由iptables提供的。
修改RS上內核參數（arp_ignore和arp_announce）將RS上的VIP配置在lo接口的別名上，並限制其不能響應對VIP地址解析請求。

六、LVS的調度算法

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

固定調度算法：即調度器不會去判斷後端服務器的繁忙與否，一如既往得將請求派發下去。

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

動態調度算法：調度器會去判斷後端服務器的繁忙程度，然後依據調度算法動態得派發請求。

6.1、rr：輪詢（round robin）

這種算法是最簡單的，就是按依次循環的方式將請求調度到不同的服務器上，該算法最大的特點就是簡單。輪詢算法假設所有的服務器處理請求的能力都是一樣的，調度器會將所有的請求平均分配給每個真實服務器，不管後端 RS 配置和處理能力，非常均衡地分發下去。這個調度的缺點是，不管後端服務器的繁忙程度是怎樣的，調度器都會講請求依次發下去。如果A服務器上的請求很快請求完了，而B服務器的請求一直持續着，將會導致B服務器一直很忙，而A很閒，這樣便沒起到均衡的左右。

6.2、wrr：加權輪詢（weight round robin）

這種算法比 rr 的算法多了一個權重的概念，可以給 RS 設置權重，權重越高，那麼分發的請求數越多，權重的取值範圍 0 – 100。主要是對rr算法的一種優化和補充， LVS 會考慮每臺服務器的性能，並給每臺服務器添加要給權值，如果服務器A的權值爲1，服務器B的權值爲2，則調度到服務器B的請求會是服務器A的2倍。權值越高的服務器，處理的請求越多。

6.3、dh：目標地址散列調度算法（destination hash）

簡單的說，即將同一類型的請求分配給同一個後端服務器，例如將以 .jgp、.png等結尾的請求轉發到同一個節點。這種算法其實不是爲了真正意義的負載均衡，而是爲了資源的分類管理。這種調度算法主要應用在使用了緩存節點的系統中，提高緩存的命中率。

6.4、sh：源地址散列調度算法（source hash）

即將來自同一個ip的請求發給後端的同一個服務器，如果後端服務器工作正常沒有超負荷的話。這可以解決session共享的問題，但是這裏有個問題，很多企業、社區、學校都是共用的一個IP，這將導致請求分配的不均衡。

6.5、lc：最少連接數（least-connection）

這個算法會根據後端 RS 的連接數來決定把請求分發給誰，比如 RS1 連接數比 RS2 連接數少，那麼請求就優先發給 RS1。這裏問題是無法做到會話保持，即session共享。

6.6、wlc：加權最少連接數（weight least-connection）

這個比最少連接數多了一個加權的概念，即在最少連接數的基礎上加一個權重值，當連接數相近，權重值越大，越優先被分派請求。

6.7、lblc：基於局部性的最少連接調度算法（locality-based least-connection）

將來自同一目的地址的請求分配給同一臺RS如果這臺服務器尚未滿負荷，否則分配給連接數最小的RS，並以它爲下一次分配的首先考慮。

6.8、lblcr：基於地址的帶重複最小連接數調度 (Locality-Based Least-Connection with Replication)

這個用得少，可以略過。

七、LVS集羣的特點

LVS集羣的特點可以歸結如下：

7.1、功能

有實現三種IP負載均衡技術和八種連接調度算法的IPVS軟件。在IPVS內部實現上，採用了高效的Hash函數和垃圾回收機制，能正確處理所調度報文相關的ICMP消息（有些商品化的系統反而不能）。虛擬服務的設置數目沒有限制，每個虛擬服務有自己的服務器集。它支持持久的虛擬服務（如HTTP Cookie和HTTPS等需要該功能的支持），並提供詳盡的統計數據，如連接的處理速率和報文的流量等。針對大規模拒絕服務（Deny of Service）攻擊，實現了三種防衛策略。
有基於內容請求分發的應用層交換軟件KTCPVS，它也是在Linux內核中實現。有相關的集羣管理軟件對資源進行監測，能及時將故障屏蔽，實現系統的高可用性。主、從調度器能週期性地進行狀態同步，從而實現更高的可用性。

7.2、適用性

後端服務器可運行任何支持TCP/IP的操作系統，包括Linux，各種Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows NT/2000等。

負載調度器能夠支持絕大多數的TCP和UDP協議：

協議	內容
TCP	HTTP，FTP，PROXY，SMTP，POP3，IMAP4，DNS，LDAP，HTTPS，SSMTP等
UDP	DNS，NTP，ICP，視頻、音頻流播放協議等

無需對客戶機和服務器作任何修改，可適用大多數Internet服務。

7.3、性能

LVS服務器集羣系統具有良好的伸縮性，可支持幾百萬個併發連接。配置100M網卡，採用VS/TUN或VS/DR調度技術，集羣系統的吞吐量可高達1Gbits/s；如配置千兆網卡，則系統的最大吞吐量可接近10Gbits/s。

7.4、可靠性

LVS服務器集羣軟件已經在很多大型的、關鍵性的站點得到很好的應用，所以它的可靠性在真實應用得到很好的證實。有很多調度器運行一年多，未作一次重啓動。

7.5、軟件許可證

LVS集羣軟件是按GPL（GNU Public License）許可證發行的自由軟件，這意味着你可以得到軟件的源代碼，有權對其進行修改，但必須保證你的修改也是以GPL方式發行。