一、LVS是什麽？

二、IPVS的工作原理

三、為什麽要使用LVS？

四、LVS集群的專用術語

五、LVS集群的類型

六、LVS調度方法（LVS Scheduler）

一、LVS是什麽？

LVS（Linux Virtual Server，Linux虛擬服務器）是由章文嵩開發的一款開源軟件（遵循GPL協議）。LVS工作在layer 4，又稱為四層路由/四層交換，能夠根據請求報文的目標IP地址和目標PORT將其調度轉發至後端的某臺服務器上，調度轉發是根據調度算法來進行的。

LVS由兩部分組成，分別是工作在內核空間的ipvs框架和工作在用戶空間的ipvsadm命令。ipvsadm是工作在用戶空間的命令行工具，用於管理集群服務及集群服務上的Real Server（RS），而ipvs則是工作於內核上的netfilter的INPUT鉤子上的程序，其功能是根據用戶定義的集群實現對請求報文的轉發。

LVS支持基於TCP、UDP、SCTP、AH、EST、AH_EST等協議進行調度。

二、IPVS的工作原理

上面提到，ipvs工作於內核空間中，而ipvsadm則是用戶定義集群的接口，並將用戶定義的策略送往ipvs，因此真正使策略生效的是工作在netfilter的INPUT鉤子上的ipvs程序。以下主要介紹ipvs的工作原理，其原理圖如下。

當前端調度器（Director）接收到發往本主機的請求時，首先進入PREROUTING鏈，經查看路由表發現，該請求的目標IP地址是本主機，因此將請求報文送往INPUT鏈，經過查看請求報文的目標端口發現，請求的是集群服務的端口，因此IPVS就會根據調度方法和集群類型，強行將請求報文發往FORWARD鏈上，而後經過POSTROUTING，再送往基於調度算法挑選出的某一臺後端RS。

三、為什麽要使用LVS？

LVS是負載均衡能力最強的一款軟件，對於選擇LVS作為負載均衡的原因總結如下。

1、相比於Nginx、Haproxy等負載均衡器，LVS支持較大的並發量。Nginx、Haproxy是工作在七層的負載均衡器，因此需要監聽在一個端口上，同時對於每一個客戶端都需要打開一個套接字文件來接受請求數據，當在應用層分析完數據時，有需要扮演成客戶端角色向後端的服務器主機發送請求報文，不僅需要打開大量套接字文件，還需要有多個隨機端口可以使用，而端口數最多只有65535個，並且其中有一部分端口是不能使用的。因此，工作在七層的負載均衡軟件（如Nginx、Haproxy等）的最大並發數受限於能夠打開的套接字文件數（內核需要打開很多的文件描述符來維護）以及能使用的隨機端口數。對於LVS而言，因此它工作在四層，所以不需要監聽在某個端口以響應客戶端請求，因此不需要打開套接字接受和發送數據，同時也不需要使用端口，所有功能均在ipvs中實現，因此LVS的性能更高，支持的並發量更大。據統計，LVS的最大並發量可以達到400~500w。

2、LVS是一款開源且免費的軟件，結合Linux使用可以大大降低企業的應用成本。

3、LVS具有可伸縮性。當一臺服務器負載壓力增長時，系統可以在不降低服務質量的情況下通過擴展來滿足需求。

4、LVS具有高可靠性。這在國內很多大型的、關鍵性的Web站點實踐中得到印證。

四、LVS集群的專用術語

VS：Virtual Server，虛擬服務器，又稱調度器（Director）、分發器（Dispatcher）和負載均衡器（Balancer）。

RS：Real Server，真實服務器，即在調度器後端提供服務的服務器主機。

CIP：Clint IP，客戶端的IP地址。

VIP：Virtual IP，調度器（Director）面向客戶端提供服務的IP地址。

DIP：Director IP，調度器（Director）用於與後端真實服務器（RS）通信的IP地址。

RIP：Real server IP，調度器（Director）後端的真實服務器（RS）的IP地址。

五、LVS集群的類型

用戶請求到達前端的負載調度器後，根據調度器如何將請求報文發送到各個提供服務的Real Server（RS）節點，以及各Real Server（RS）節點如何返回數據給用戶，可以將LVS集群類型分為LVS-NAT、LVS-DR、LVS-TUN和LVS-FullNat四種。其中，LVS-NAT、LVS-DR和LVS-TUN是LVS的標準類型，而LVS-FullNat則為非LVS的標準類型，是根據淘寶的需要而改進的一種集群類型。以下分別介紹這四種集群類型。

1、LVS-NAT

NAT即Network Address Translation，也即是通過網絡地址轉換技術來實現虛擬服務器。在NAT方式中，當用戶請求報文到達時，調度器通過將請求報文中的目標地址和目標端口修改為挑選出的某RS的RIP和PORT以實現轉發。因此，LVS-NAT相當於多目標的NAT。RS得到數據後即開始處理請求，當RS將響應數據返回給用戶時，需要再次經過調度器並由調度器將響應報文的源地址和源端口修改為調度器的VIP和相應的PORT，然後把數據發送給用戶，完成整個負載調度的過程。

LVS-NAT模型的特性：

（1）DIP和RIP必須在同一IP網絡中（因為響應報文要經由Director轉發），且應該使用私有地址；各個RS的網關要指向DIP（保證響應報文經由VS）。

（2）請求報文和響應報文都經由Director轉發，因此在較高負載下（用戶請求越來越多時），Director易成為系統性能瓶頸。

（3）因為請求報文和響應報文都經由Director，因此支持端口映射。

（4）VS必須是Linux，RS可以是任意OS。

註意：因為LVS-NAT是多目標的NAT，因此需要打開連接追蹤模板來追蹤連接，最大並發數取決於連接追蹤模板能夠記錄的連接數量，而鏈接追蹤模板能夠記錄的連接數量則取決於用於記錄連接追蹤的內存空間大小。

2、LVS-TUN

TUN即Tunneling，也就是通過IP隧道技術實現虛擬服務器。在TUN方式中，當用戶請求報文到達時，調度器不修改請求報文的IP首部（源IP為CIP，目標IP為VIP），而是在原IP首部之外再封裝一個IP首部（源IP為DIP，目標IP為挑選出的RS的RIP）。而這個RS將直接響應用戶的請求，不會再經由Director轉發，因此調度器只處理用戶的報文請求，從而大大提高了集群系統的吞吐量。LVS-TUN這種集群類型的另外一個特點是對RS的地域位置沒有要求，一般和Director不再同一網段中（也可以在同一網段），即各個RS可以分別分布在不同的地域位置。

LVS-TUN模型的特性：

（1）RIP、VIP和DIP全得是公網地址。

（2）RS的網關不能指向也不可能指向DIP。

（3）請求報文經由Director轉發，但響應報文將由RS直接發往CIP。

（4）因為響應報文不經由Director轉發，因此不支持端口映射。

（5）RS的OS必須支持隧道功能。

問題1：使用LVS-TUN這種方式時，因為需要再添加IP首部，如果再封裝一個IP首部後超過MTU怎麽辦？

回答：需要做分片處理。

問題：為什麽DIP必須為公網地址？

回答：因為封裝IP隧道（外IP首部）時，源IP為DIP，目標IP為RIP，這個具有兩個IP首部的報文在出口時經由路由器但不可能進行NAT，否則報文的兩個IP首部都可能會被拆掉，導致RS接受不到請求報文。

3、LVS-DR

DR即Direct Routing，也就是通過直接路由實現虛擬服務器。在DR方式中，當用戶請求報文到達負載調度器時，調度器通過為請求報文重新封裝一個MAC首部進行轉發，重新封裝後的報文中的源MAC是DIP所在接口的MAC地址，目標MAC是挑選出的某RS的RIP所在的接口的MAC地址，而請求報文的IP首部不會發生變化（源IP是CIP，目標IP是VIP）。而RS將響應直接返回給用戶，可以免去LVS-TUN中的IP隧道開銷。因此在LVS-NAT、LVS-TUN和LVS-DR這三種最常用的調度方式中，LVS-DR這種調度方式是性能最好的。在LVS-DR這種方式中，各個RS上都必須配有VIP，以便在響應用戶請求時，用VIP作為源IP來封裝報文的IP首部。

LVS-DR模型的特性：

（1）必須確保前端路由器將目標IP為VIP的請求報文發往Director。

解決方案：
1、在路由器上靜態綁定VIP和Director的MAC地址。當這種方式有兩點缺陷：
    （1）必須有前端路由器的控制權。
    （2）當構建高可用LVS負載均衡集群時，調度器的VIP所在接口的MAC地址可能會發生改變。
2、禁止RS響應VIP的ARP請求，禁止RS的VIP進行通告。
    （a）通過arptables命令設定。
    （b）修改RS的內核參數（arp_ignore, arp_announce），並把VIP綁定在lo的接口的別名上。

（2）RS的RIP可以使用私網地址，也可以使用公網地址。

（3）RS跟Director必須在同一物理網絡中。否則，如果RS跟Director之間只要多了一個路由器則MAC地址就改變了，無法確保按照Director的調度將請求報文轉發給挑選出的某RS。

（4）RS的網關必須不能指向DIP。

（5）請求報文必須由Director調度，但響應報文必須不能經由Director轉發。

（6）因為響應報文必須不能經由Director轉發，因此不支持端口映射。

（7）RS可以使用大多數OS。

4、LVS-FullNat

FullNat即完全網絡地址轉換，也即是通過完全網絡地址轉換技術來實現虛擬服務器的。在FullNat方式中，當用戶請求報文到達時，調度器通過同時修改請求報文的源IP地址（CIP --> DIP）和目標IP地址（VIP --> RIP）進行轉發。響應報文則相反。使用這種方式，可以構建一個更為復雜的內部網絡，可以經過路由器轉發請求報文，但又不至於像LVS-TUN一樣需要在原來的IP首部之外再封裝一個IP首部，從而可能造成巨型幀（有可能會超過MTU）。

FullNat模型的特性：

（1）VIP是公網地址，DIP和RIP是私網地址，且通常不在同一網絡中，但需要經由路由器互通。

（2）RS收到的請求報文源IP為DIP，因此響應報文將直接響應給DIP。也就是請求報文和響應報文都經由Director。

（3）因為請求報文和響應報文都經由Director，所以支持端口映射。

（4）RS可以使用大多數的OS。

六、LVS調度方法（LVS Scheduler）

LVS的調度方法有多種，根據其調度時是否考慮後端主機的當前負載，可分為靜態方法和動態方法兩類。靜態方法有RR、WRR、SH和DH，動態方法有LC、WLC、SED、NQ、LBLC和LBLCR。

6.1 靜態方法

靜態方法就是僅根據算法本身進行調度的算法。靜態方法有RR、WRR、SH和DH這四種。接下來分別介紹每一種靜態方法。

(1) RR

全稱 ==> Round Robin，輪詢/輪調/輪叫。

特點 ==> 調度器將用戶請求分別輪詢轉發給各臺RS。

缺陷 ==> 沒有考慮到各RS的負載能力可能不同。

(2) WRR

全稱 ==> Weighted RR，加權輪詢。

特點 ==> 調度器將用戶請求分別按照各RS的（事先設定好的）權重，輪詢轉發給各臺RS，也就是給一定權重的RS分配與其權重匹配的用戶請求報文數量。

優點 ==> 考慮了各RS的負載能力可能不同（通過權重值設定），彌補了RR算法的缺陷。

(3) SH

全稱 ==> Source Hashing，源地址哈希。

特點 ==> 根據請求報文的源地址與此前挑選出的RS綁定起來，即實現將同一個IP的請求發往同一個RS，這是會話保持的一種方式。哈希的是源地址。SH算法是通過在內存中維護一個哈希表以實現綁定效果的。

適用場景 ==> 在電商站點中可能會用到SH算法。

(4) DH

全稱 ==> Destination Hashing，目標地址哈希。

特點 ==> 根據請求報文的目標地址與某臺RS綁定起來，即實現將目標地址為同一個地址的請求報文發往同一個RS。哈希的目標地址。DH算法是通過在內存中維護一個哈希表以實現綁定效果的。

適用場景 ==> 通常用在正向Web代理（緩存）服務器中，負載均衡內網用戶對外部服務器的請求。調度器可根據客戶端訪問的目標地址將請求報文找到對應的緩存服務器，可以提高緩存命中率。

6.2 動態方法

動態方法就是根據算法僅各RS當前的負載狀態進行調度的算法。各RS當前的負載值用“Overhead”進行表示。動態方法有LC、WLC、SED、NQ、LBLC和LBLCR等。在介紹動態方法之前，需要了解連接種類。連接分為活動連接（Active）和非活動連接（Inactive）兩種，如下。

① 活動連接（Active）：指的是服務器正在等待客戶端發送請求的連接、服務器正在處理請求的連接或者服務器正在響應客戶端請求的連接。每個活動連接消耗的資源比非活動連接多得多，相當於256個非活動連接。

② 非活動連接（Inactive）：指的是處於空閑狀態的連接，即在連接上沒有傳輸數據。

接下來分別介紹每一種動態方法。

(1) LC

全稱 ==> Least Connections，最少連接。

公式 ==> Overhead=Active*256+Inactive

特點 ==> 調度器將用戶請求發往連接數最少（Overhead最少）的RS。

缺陷 ==> 沒有考慮到各RS負載能力可能不同。

(2) WLC

全稱 ==> Weighted LC，加權最少連接。

公式 ==> Overhead=(Active*256+Inactive)/weight

說明 ==> WLC是最通用的、默認的調度方法。

特點 ==> 調度器將用戶請求發往加權連接數最少（Overhead最少）的RS。

優點 ==> 既考慮了各RS的連接數，又考慮了各RS的負載能力，彌補了LC算法的缺陷。

缺陷 ==> 剛開始所有RS都沒有負載的情況下，Overhead都為0，因此在各RS的Overhead值都相等的情況下，調度器只能通過輪詢的方法來調度轉發，所以調度器可能會把第一個用戶請求發往處理能力較低的RS。

(3) SED

全稱 ==> Shortest Expections Delay，最小期望延遲。

公式 ==> Overhead=(Active+1)*256/weight

特點 ==> 不考慮非活動連接數，初始時活動連接數為1，調度器將用戶請求發往加權連接數最少（Overhead最少）的RS。

優點 ==> 剛開始各RS零負載的情況下，Overhead不為0，調度器仍然會先把請求轉發到負載能力（處理能力）較強的RS上，彌補了WLC算法的缺陷。

缺陷 ==> 在並發量不是很大時，有可能調度器會把所有的請求都發往負載能力較強的RS，導致負載能力較弱的RS一直處於空閑狀態。而且SED算法不考慮非活動連接數，可能不適應於某些場景（非活動連接對性能影響較大時）。

(4) NQ

全稱 ==> Never Queue，不排隊。

特點 ==> 是RR算法和SED算法的結合，是SED算法的優化。在各RS零負載的情況下，調度器先將用戶請求分別輪詢轉發給每一臺RS（不管其負載能力/處理能力的高低），確保每一臺RS都處理一定數量的請求，然後再按照SED算法進行調度。

優點 ==> 保證了各RS都處理一定數量的用戶請求，因此繼承了SED算法的優點，彌補了SED算法的缺陷。

缺陷 ==> 與SED一樣不考慮非活動連接數，可能不適應於某些場景（非活動連接對性能影響較大時）。

(5) LBLC

全稱 ==> Locality-Based LC，基於本地的LC算法。

特點 ==> 是動態的DH算法。與DH一樣，其應用場景通常為正向Web代理（緩存）服務器，但相比於DH算法而言，LBLC是通過犧牲緩存的命中率來提高負載均衡的效果的。

優點 ==> 相比較於DH算法，經由調度器轉發後能使用戶請求報文更加負載均衡在多臺緩存服務器上。

缺陷 ==> 雖然使用戶請求更加負載均衡在多臺緩存服務器上，但犧牲了緩存服務器的命中率。

(6) LBLCR

全稱 ==> LBLC with Replcation，帶復制功能的LBLC。

特點 & 優點 ==> 是改進版的LBLC算法，既考慮了負載均衡，又考慮了緩存的命中率。如果用戶請求報文被調度到沒有對應緩存資源的緩存服務器（正向代理）上時，則該緩存服務器可以直接到已有該緩存資源的緩存服務器上請求並獲取資源，而不是到原始服務器上去請求。只有當所有緩存服務器上都沒有該緩存資源時，才到原始服務器上去請求。

本文出自 “Tab” 博客，請務必保留此出處http://xuweitao.blog.51cto.com/11761672/1952110

LVS負載均衡集群