一.LVS介紹

Linux?虛擬服務(wù)器(Linux Virtual Servers,LVS)?使用負(fù)載均衡技術(shù)將多臺(tái)服務(wù)器組成一個(gè)虛擬服務(wù)器。它為適應(yīng)快速增長的網(wǎng)絡(luò)訪問需求提供了一個(gè)負(fù)載能力易于擴(kuò)展，而價(jià)格低廉的解決方案。

LVS (Linux?Virtual Server)其實(shí)是一種集群(Cluster)技術(shù)，采用IP負(fù)載均衡技術(shù)（LVS?的?IP?負(fù)載均衡技術(shù)是通過?IPVS?模塊來實(shí)現(xiàn)的，linux內(nèi)核2.6版本以上是默認(rèn)安裝IPVS的）和基于內(nèi)容請求分發(fā)技術(shù)。調(diào)度器具有很好的吞吐率，將請求均衡地轉(zhuǎn)移到不同的服務(wù)器上執(zhí)行，且調(diào)度器自動(dòng)屏蔽掉服務(wù)器的故障，從而將一組服務(wù)器構(gòu)成一個(gè)高性能的、高可用的虛擬服務(wù)器。整個(gè)服務(wù)器集群的結(jié)構(gòu)對客戶是透明的，而且無需修改客戶端和服務(wù)器端的程序。

LVS負(fù)載均衡調(diào)度技術(shù)是在LINUX內(nèi)核中實(shí)現(xiàn)的，因此被稱之為LINUX虛擬服務(wù)器。我們使用該軟件配置LVS時(shí)候，不能直接配置內(nèi)核中的IPVS，而需要使用IPVS的管理工具ipvsadm進(jìn)行管理，當(dāng)然我們也可以通過keepalived軟件直接管理IPVS及負(fù)載均衡器的高可用，并不是通過ipvsadm來管理ipvs。

二.LVS集群結(jié)構(gòu)

（官網(wǎng)文件位置http://www.linuxvirtualserver.org/zh/lvs2.html）

LVS由前端的負(fù)載均衡器(Load Balancer，LB)和后端的真實(shí)服務(wù)器(Real Server，RS)群組成。RS間可通過局域網(wǎng)或廣域網(wǎng)連接。LVS的這種結(jié)構(gòu)對用戶是透明的，用戶只能看見一臺(tái)作為LB的虛擬服務(wù)器(Virtual Server)，而看不到提供服務(wù)的RS群。當(dāng)用戶的請求發(fā)往虛擬服務(wù)器，LB根據(jù)設(shè)定的包轉(zhuǎn)發(fā)策略和負(fù)載均衡調(diào)度算法將用戶請求轉(zhuǎn)發(fā)給RS。RS再將用戶請求結(jié)果返回給用戶。

LVS集群的體系結(jié)構(gòu)

一般來說，LVS集群采用三層結(jié)構(gòu)，其體系結(jié)構(gòu)如圖1所示，三層主要組成部分為：

負(fù)載調(diào)度器（load balancer），它是整個(gè)集群對外面的前端機(jī)，負(fù)責(zé)將客戶的請求發(fā)送到一組服務(wù)器上執(zhí)行，而客戶認(rèn)為服務(wù)是來自一個(gè)IP地址（我們可稱之為虛擬IP地址）上的。

服務(wù)器池（server pool），是一組真正執(zhí)行客戶請求的服務(wù)器，執(zhí)行的服務(wù)有WEB、MAIL、FTP和DNS等。

共享存儲(chǔ)（shared storage），它為服務(wù)器池提供一個(gè)共享的存儲(chǔ)區(qū)，這樣很容易使得服務(wù)器池?fù)碛邢嗤膬?nèi)容，提供相同的服務(wù)如mysql，網(wǎng)絡(luò)文件系統(tǒng)或者分布式文件系統(tǒng)。

lvs可伸展的架構(gòu)模型：可伸縮Web服務(wù)，可伸縮媒體服務(wù)，可伸縮Cache服務(wù)

三.LVS的工作模式：

LVS?的?IP?負(fù)載均衡技術(shù)是通過?IPVS?模塊來實(shí)現(xiàn)的，IPVS?是?LVS集群系統(tǒng)的核心軟件，它的主要作用是：安裝在 DS（Director Server-lvs部署的服務(wù)器）上，同時(shí)在?DS（Director Server）上虛擬出一個(gè)?IP?地址，用戶必須通過這個(gè)虛擬的?IP?地址訪問服務(wù)器。這個(gè)虛擬?IP?一般稱為?LVS?的VIP，即?Virtual IP。訪問的請求首先經(jīng)過?VIP?到達(dá)負(fù)載調(diào)度器，然后由負(fù)載調(diào)度器從??RS（Real Server）列表中選取一個(gè)服務(wù)節(jié)點(diǎn)響應(yīng)用戶的請求。?

LVS的工作模式

四.LVS三種工作模式：

客戶端的ip地址定義為CIP，真實(shí)服務(wù)器的IP定義為RIP,lvs上的真實(shí)ip定義為：DIP，lvs上的虛擬ip定義為VIP

1.NAT模式-----網(wǎng)絡(luò)地址轉(zhuǎn)換(ip的轉(zhuǎn)換)

1）NAT模式下ip報(bào)文改變圖

NAT模式

2）NAT模式數(shù)據(jù)包走向說明：

a). 當(dāng)用戶請求到達(dá)Director Server，此時(shí)請求的數(shù)據(jù)報(bào)文會(huì)先到內(nèi)核空間的PREROUTING鏈。 此時(shí)報(bào)文的源IP為CIP，目標(biāo)IP為VIP

b). PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標(biāo)IP是本機(jī)，將數(shù)據(jù)包送至INPUT鏈

c). IPVS比對數(shù)據(jù)包請求的服務(wù)是否為集群服務(wù)，若是，修改數(shù)據(jù)包的目標(biāo)IP地址為后端服務(wù)器IP，然后將數(shù)據(jù)包發(fā)至POSTROUTING鏈。 此時(shí)報(bào)文的源IP為CIP，目標(biāo)IP為RIP

d). POSTROUTING鏈通過選路，將數(shù)據(jù)包發(fā)送給Real Server

e). Real Server比對發(fā)現(xiàn)目標(biāo)為自己的IP，開始構(gòu)建響應(yīng)報(bào)文發(fā)回給Director Server。 此時(shí)報(bào)文的源IP為RIP，目標(biāo)IP為CIP

f). Director Server在響應(yīng)客戶端前，此時(shí)會(huì)將源IP地址修改為自己的VIP地址，然后響應(yīng)給客戶端。 此時(shí)報(bào)文的源IP為VIP，目標(biāo)IP為CIP。

3）NAT模式的特點(diǎn)：

a）RS應(yīng)該使用私有地址，RS的網(wǎng)關(guān)必須指向DIP，否則報(bào)文無法送達(dá)客戶端，DIP和RIP必須在同一個(gè)網(wǎng)段內(nèi)

b）NAT?模式支持對?IP?地址和端口進(jìn)行轉(zhuǎn)換。即用戶請求的端口和真實(shí)服務(wù)器的端口可以不一致

4）NAT模式優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：集群中的RS可以使用任何支持TCP/IP操作系統(tǒng)，只有負(fù)載均衡器需要一個(gè)合法的IP地址

缺點(diǎn)：擴(kuò)展性有限，一般要求最多之能?10-20?臺(tái)節(jié)點(diǎn)。當(dāng)服務(wù)器節(jié)點(diǎn)增長過多時(shí),負(fù)載均衡器將成為整個(gè)系統(tǒng)的瓶頸，因?yàn)樗械恼埱蟀蛻?yīng)答包的流向都經(jīng)過負(fù)載均衡器。當(dāng)服務(wù)器節(jié)點(diǎn)過多時(shí)，大量的數(shù)據(jù)包都交匯在負(fù)載均衡器那，速度就會(huì)變慢！

2.DR模式--------->MAC地址的轉(zhuǎn)換

1）DR模式下ip報(bào)文轉(zhuǎn)換圖：

DR模式

2）DR模式數(shù)據(jù)包走向說明：

a)?當(dāng)用戶請求到達(dá)Director Server，此時(shí)請求的數(shù)據(jù)報(bào)文會(huì)先到內(nèi)核空間的PREROUTING鏈。 此時(shí)報(bào)文的源IP為CIP，目標(biāo)IP為VIP

b)?PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標(biāo)IP是本機(jī)，將數(shù)據(jù)包送至INPUT鏈

c)?IPVS比對數(shù)據(jù)包請求的服務(wù)是否為集群服務(wù)，若是，將請求報(bào)文中的源MAC地址修改為DIP的MAC地址，將目標(biāo)MAC地址修改RIP的MAC地址，然后將數(shù)據(jù)包發(fā)至POSTROUTING鏈。 此時(shí)的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標(biāo)MAC地址為RIP的MAC地址

d)?由于DS和RS在同一個(gè)網(wǎng)絡(luò)中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標(biāo)MAC地址為RIP的MAC地址，那么此時(shí)數(shù)據(jù)包將會(huì)發(fā)至Real Server。

e)?RS發(fā)現(xiàn)請求報(bào)文的MAC地址是自己的MAC地址，就接收此報(bào)文。處理完成之后，將響應(yīng)報(bào)文通過lo接口傳送給eth0網(wǎng)卡然后向外發(fā)出。 此時(shí)的源IP地址為VIP，目標(biāo)IP為CIP

f)?響應(yīng)報(bào)文最終送達(dá)至客戶端

3）DR模式的特點(diǎn)：

a）請求的報(bào)文經(jīng)過DS，而?RS?響應(yīng)處理后的報(bào)文無需經(jīng)過調(diào)度器DS ，因此并發(fā)訪問量大時(shí)使用效率很高（和?NAT?模式比）。RS的網(wǎng)關(guān)絕不允許指向DIP(因?yàn)槲覀儾辉试S他經(jīng)過director)

b）由于?DR?模式的調(diào)度器僅做?MAC?地址的改寫，所以不支持端口映射，端口必須一致

c）RS?主機(jī)需要綁定?VIP?地址在?LO?接口（掩碼32?位）上，并且需要配置?ARP?抑制

d）因?yàn)?DR?模式是通過?MAC?地址改寫機(jī)制實(shí)現(xiàn)轉(zhuǎn)發(fā)，因此所有?RS?節(jié)點(diǎn)和DS 只能在一個(gè)局域網(wǎng)里面

3.TUN模型

在原有的IP報(bào)文外再次封裝多一層IP首部，內(nèi)部IP首部(源地址為CIP，目標(biāo)IIP為VIP)，外層IP首部(源地址為DIP，目標(biāo)IP為RIP)

1） TUN模式下的ip報(bào)文轉(zhuǎn)換圖：

TUN模式

2)TUN模式數(shù)據(jù)包走向：

(a)?當(dāng)用戶請求到達(dá)Director Server，此時(shí)請求的數(shù)據(jù)報(bào)文會(huì)先到內(nèi)核空間的PREROUTING鏈。 此時(shí)報(bào)文的源IP為CIP，目標(biāo)IP為VIP 。

(b)?PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標(biāo)IP是本機(jī)，將數(shù)據(jù)包送至INPUT鏈

(c)?IPVS比對數(shù)據(jù)包請求的服務(wù)是否為集群服務(wù)，若是，在請求報(bào)文的首部再次封裝一層IP報(bào)文，封裝源IP為為DIP，目標(biāo)IP為RIP。然后發(fā)至POSTROUTING鏈。 此時(shí)源IP為DIP，目標(biāo)IP為RIP

(d)?POSTROUTING鏈根據(jù)最新封裝的IP報(bào)文，將數(shù)據(jù)包發(fā)至RS（因?yàn)樵谕鈱臃庋b多了一層IP首部，所以可以理解為此時(shí)通過隧道傳輸）。 此時(shí)源IP為DIP，目標(biāo)IP為RIP

(e)?RS接收到報(bào)文后發(fā)現(xiàn)是自己的IP地址，就將報(bào)文接收下來，拆除掉最外層的IP后，會(huì)發(fā)現(xiàn)里面還有一層IP首部，而且目標(biāo)是自己的lo接口VIP，那么此時(shí)RS開始處理此請求，處理完成之后，通過lo接口送給eth0網(wǎng)卡，然后向外傳遞。 此時(shí)的源IP地址為VIP，目標(biāo)IP為CIP

(f)?響應(yīng)報(bào)文最終送達(dá)至客戶端

3）TUN模式的特點(diǎn)：

a）TUNNEL?模式必須在所有的?realserver?機(jī)器上面綁定?VIP?的?IP?地址

b）TUNNEL?模式的?vip ------>realserver?的包通信通過?TUNNEL?模式，不管是內(nèi)網(wǎng)和外網(wǎng)都能通信，所以不需要?lvs vip?跟?realserver?在同一個(gè)網(wǎng)段內(nèi)

c）TUNNEL?模式?realserver?會(huì)把?packet?直接發(fā)給?client?不會(huì)給?lvs?了

d)TUNNEL?模式走的隧道模式，所以運(yùn)維起來比較難，所以一般不用。

4)TUN模式的優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：負(fù)載均衡器只負(fù)責(zé)將請求包分發(fā)給后端節(jié)點(diǎn)服務(wù)器，而RS將應(yīng)答包直接發(fā)給用戶。所以，減少了負(fù)載均衡器的大量數(shù)據(jù)流動(dòng)，負(fù)載均衡器不再是系統(tǒng)的瓶頸，就能處理很巨大的請求量，這種方式，一臺(tái)負(fù)載均衡器能夠?yàn)楹芏郣S進(jìn)行分發(fā)。而且跑在公網(wǎng)上就能進(jìn)行不同地域的分發(fā)

缺點(diǎn)：隧道模式的RS節(jié)點(diǎn)需要合法IP，這種方式需要所有的服務(wù)器支持”IP Tunneling”(IP Encapsulation)協(xié)議，服務(wù)器可能只局限在部分Linux系統(tǒng)上

4.FULLNAT模式

無論是?DR?還是?NAT?模式，不可避免的都有一個(gè)問題：LVS?和?RS?必須在同一個(gè)?VLAN?下，否則?LVS?無法作為?RS?的網(wǎng)關(guān)。

這引發(fā)的兩個(gè)問題是：

a、同一個(gè)?VLAN?的限制導(dǎo)致運(yùn)維不方便，跨?VLAN?的?RS?無法接入。

b、LVS?的水平擴(kuò)展受到制約。當(dāng)?RS?水平擴(kuò)容時(shí)，總有一天其上的單點(diǎn)?LVS?會(huì)成為瓶頸

1）FULL-NAT模式數(shù)據(jù)包走向圖：

FULLNAT模式數(shù)據(jù)包走向圖

2）FULL-NAT模式數(shù)據(jù)包走向說明：

a）在包從?LVS?轉(zhuǎn)到?RS?的過程中，源地址從客戶端?IP?被替換成了?LVS?的內(nèi)網(wǎng)?IP，目的地址轉(zhuǎn)換成RS的IP

b）當(dāng)?RS?處理完接受到的包，返回時(shí)，會(huì)將這個(gè)包返回給?LVS?的內(nèi)網(wǎng)?IP

c ) LVS?收到包后，在?NAT?模式修改源地址的基礎(chǔ)上，再把?RS?發(fā)來的包中的目標(biāo)地址從?LVS?內(nèi)網(wǎng)?IP?改為客戶端的?IP

3）Full-NAT?主要的思想是把網(wǎng)關(guān)和其下機(jī)器的通信，改為了普通的網(wǎng)絡(luò)通信，從而解決了跨?VLAN?的問題。采用這種方式，LVS?和?RS?的部署在?VLAN?上將不再有任何限制，大大提高了運(yùn)維部署的便利性

4)Full-NAT優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)：FULL NAT?模式也不需要?LBIP?和?realserver ip?在同一個(gè)網(wǎng)段。保證?RS?回包一定能夠回到?LVS。

五.LVS負(fù)載均衡調(diào)度算法

Lvs的調(diào)度算法決定了如何在集群節(jié)點(diǎn)之間分布工作負(fù)荷。當(dāng)lvs收到來自客戶端訪問VIP的上的集群服務(wù)的入站請求時(shí)，lvs必須決定哪個(gè)集群節(jié)點(diǎn)應(yīng)該處理請求。

1.靜態(tài)算法：只根據(jù)算法進(jìn)行調(diào)度而不考慮后端服務(wù)器的實(shí)際連接情況和負(fù)載情況

1）rr? ?輪詢調(diào)度算法

均等的將外部請求按順序輪流分配到集群中的真實(shí)服務(wù)器上

2）WRR? 加權(quán)輪詢調(diào)度算法

根據(jù)一定的權(quán)重將外部請求分配到集群中的真實(shí)服務(wù)器上，可以保證處理能力強(qiáng)的服務(wù)器處理更多的訪問流量

3）SH? ?基于源地址hash調(diào)度算法

根據(jù)請求的源IP地址，作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應(yīng)的服務(wù)器，若該服務(wù)器是可用的且未超載，將請求發(fā)送到該服務(wù)器，否則返回空?

4）DH???基于目的地址hash調(diào)度算法

根據(jù)請求的目標(biāo)IP地址，作為散列鍵(HashKey)從靜態(tài)分配的散列表找出對應(yīng)的服務(wù)器，若該服務(wù)器是可用的且未超載，將請求發(fā)送到該服務(wù)器，否則返回空。

2.動(dòng)態(tài)算法：前端的調(diào)度器會(huì)根據(jù)后端真實(shí)服務(wù)器的實(shí)際連接情況來分配請求，RS的負(fù)載狀態(tài)通常由活動(dòng)鏈接(active),非活動(dòng)鏈接(inactive)和權(quán)重來計(jì)算

1)LC 最少連接

動(dòng)態(tài)地將網(wǎng)絡(luò)請求調(diào)度到已建立的鏈接數(shù)最少的服務(wù)器上

2）WLC 加權(quán)最少連接

在集群系統(tǒng)中的服務(wù)器性能差異較大的情況下，調(diào)度器采用“加權(quán)最少鏈接”調(diào)度算法優(yōu)化負(fù)載均衡性能，具有較高權(quán)值的服務(wù)器將承受較大比例的活動(dòng)連接負(fù)載。

3）LBLC：基于局部型最少連接

根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址最近使用的服務(wù)器，若該服務(wù)器是可用的且沒有超載，將請求發(fā)送到該服務(wù)器;若服務(wù)器不存在，或者該服務(wù)器超載且有服務(wù)器處于一半的工作負(fù)載，則用“最少鏈接”的原則選出一個(gè)可用的服務(wù)器，將請求發(fā)送到該服務(wù)器。主要用于Cache集群系統(tǒng)。

4）LBLCR?帶復(fù)制的基于局部性最少連接

目前主要用于Cache集群系統(tǒng)?該算法根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址對應(yīng)的服務(wù)器組，按”最小連接”原則從服務(wù)器組中選出一臺(tái)服務(wù)器，若服務(wù)器沒有超載，將請求發(fā)送到該服務(wù)器；若服務(wù)器超載，則按“最小連接”原則從這個(gè)集群中選出一臺(tái)服務(wù)器，將該服務(wù)器加入到服務(wù)器組中，將請求發(fā)送到該服務(wù)器?同時(shí)，當(dāng)該服務(wù)器組有一段時(shí)間沒有被修改，將最忙的服務(wù)器從服務(wù)器組中刪除，以降低復(fù)制的程度。

LBLCR與LBLC算法的不同之處是它要維護(hù)從一個(gè)目標(biāo)IP地址到一組服務(wù)器的映射，而LBLC算法維護(hù)從一個(gè)目標(biāo)IP地址到一臺(tái)服務(wù)器的映射?

5）SED??最短延遲調(diào)度

在WLC基礎(chǔ)上改進(jìn)，Overhead =?（ACTIVE+1）*256/加權(quán)，不再考慮非活動(dòng)狀態(tài)，把當(dāng)前處于活動(dòng)狀態(tài)的數(shù)目+1來實(shí)現(xiàn)，數(shù)目最小的，接受下次請求，+1的目的是為了考慮加權(quán)的時(shí)候，非活動(dòng)連接過多缺陷：當(dāng)權(quán)限過大的時(shí)候，會(huì)倒置空閑服務(wù)器一直處于無連接狀態(tài)。

6）NQ?永不排隊(duì)/最少隊(duì)列調(diào)度

無需隊(duì)列。如果有臺(tái) RS的連接數(shù)＝0就直接分配過去，不需要再進(jìn)行sed（最短延遲調(diào)度）運(yùn)算，保證不會(huì)有一個(gè)主機(jī)很空間。在SED基礎(chǔ)上無論+幾，第二次一定給下一個(gè)，保證不會(huì)有一個(gè)主機(jī)不會(huì)很空閑著，不考慮非活動(dòng)連接，才用NQ，SED要考慮活動(dòng)狀態(tài)連接，對于DNS的UDP不需要考慮非活動(dòng)連接，而httpd的處于保持狀態(tài)的服務(wù)就需要考慮非活動(dòng)連接給服務(wù)器的壓力

4.生產(chǎn)環(huán)境中的調(diào)度算法的選擇

1）一般的網(wǎng)絡(luò)服務(wù)，如?www，mail，mysql?等常用的?LVS?調(diào)度算法為：

基本輪詢調(diào)度?rr

加權(quán)最小連接調(diào)度?wlc

加權(quán)輪詢調(diào)度?wrr

2）基于局部性的最小連接?lblc?和帶復(fù)制的給予局部性最小連接?lblcr?主要適用于?web cache?和?DB cache?，一般不這么用。

3、源地址散列調(diào)度?SH?和目標(biāo)地址散列調(diào)度?DH?可以結(jié)合使用在防火墻集群中，可以保證整個(gè)系統(tǒng)的出入口唯一。

實(shí)際適用中這些算法的適用范圍很多，工作中最好參考內(nèi)核中的連接調(diào)度算法的實(shí)現(xiàn)原理，然后根據(jù)具體的業(yè)務(wù)需求合理的選型。

rr，wrr，wlc是常用的。