一、LVS負(fù)載均衡

負(fù)載均衡集群是Load Balance 集群的縮寫，翻譯成中文就是負(fù)載均衡集群。常用的負(fù)載均衡開源軟件有Nginx、LVS、Haproxy，商業(yè)的硬件負(fù)載均衡設(shè)備有F5、Netscale等。

二、負(fù)載均衡LVS基本介紹

LB集群的架構(gòu)和原理很簡單，就是當(dāng)用戶的請求過來時，會直接分發(fā)到Director Server上，然后它把用戶的請求根據(jù)設(shè)置好的調(diào)度算法，智能均衡的分發(fā)后端真正服務(wù)器（real server）上。為了避免不同機(jī)器上用戶請求的數(shù)據(jù)不一樣，需要用到了共享存儲，這樣保證所有用戶請求的數(shù)據(jù)是一樣的。

這是由章文嵩博士發(fā)起的一個開源項目，官網(wǎng)：http://www.linuxvirtualserver.org現(xiàn)在LVS已經(jīng)是 Linux 內(nèi)核標(biāo)準(zhǔn)的一部分。使用 LVS 可以達(dá)到的技術(shù)目標(biāo)是：通過 LVS 達(dá)到的負(fù)載均衡技術(shù)和 Linux 操作系統(tǒng)實現(xiàn)一個高性能高可用的 Linux 服務(wù)集群，它具有良好的可靠性、可擴(kuò)展性和可操作性。從而以廉價的成本實現(xiàn)最優(yōu)的性能。 

LVS集群采用IP負(fù)載均衡技術(shù)和基于內(nèi)容請求分發(fā)技術(shù)。調(diào)度器具有很好的吞吐率，將請求均衡地轉(zhuǎn)移到不同的服務(wù)器上執(zhí)行，且調(diào)度器自動屏蔽掉服 務(wù)器的故障，從而將一組服務(wù)器構(gòu)成一個高性能的、高可用的虛擬服務(wù)器。整個服務(wù)器集群的結(jié)構(gòu)對客戶是透明的，而且無需修改客戶端和服務(wù)器端的程序。

三、LVS的體系架構(gòu)

負(fù)載均衡的原理很簡單，就是當(dāng)客戶端發(fā)起請求時，請求直接發(fā)給Director Server（調(diào)度器），這時會根據(jù)設(shè)定的調(diào)度算法，將請求按照算法的規(guī)定智能的分發(fā)到真正的后臺服務(wù)器。以達(dá)到將壓力均攤。但是我們知道，http的連接時無狀態(tài)的，假設(shè)這樣一個場景，我登錄某寶買東西，當(dāng)我看上某款商品時，我將它加入購物車，但是我刷新了一下頁面，這時由于負(fù)載均衡的原因，調(diào)度器又選了新的一臺服務(wù)器為我提供服務(wù)，我剛才的購物車內(nèi)容全都不見了，這樣就會有十分差的用戶體驗。所以就還需要一個存儲共享，這樣就保證了用戶請求的數(shù)據(jù)是一樣的。所以LVS負(fù)載均衡分為三層架構(gòu)(也就是LVS負(fù)載均衡主要組成部分)：

如圖：

LVS的各個層次的詳細(xì)介紹：

3.1、Load Balancer層

位于整個集群系統(tǒng)的最前端，有一臺或者多臺負(fù)載調(diào)度器（Director Server）組成，LVS模塊就是安裝在Director Server上，而Director的主要作用類似于一個路由器，它含有完成LVS功能所設(shè)定的路由表，通過這些路由表把用戶的請求分發(fā)給Server Array層的應(yīng)用服務(wù)器（Real Server）上。同時，在Director Server上還要安裝隊Real Server服務(wù)的監(jiān)控模塊Ldirectord，此模塊用于檢測各個Real Server服務(wù)的健康狀況。在Real Server不可用時把它從 LVS 路由表中剔除，恢復(fù)時重新加入。

3.2、Server Arrary層

由一組實際運行應(yīng)用服務(wù)的機(jī)器組成，Real Server可以是WEB 服務(wù)器、MALL服務(wù)器、FTP服務(wù)器、DNS服務(wù)器、等等，每個Real Server 之間通過高速的LAN或分布在各地的WAN相連接，在實際的應(yīng)用中，Director Server也可以同時兼任Real Server的角色。

3.3、Shared Storage層

是為所有Real Server提供共享存儲空間和內(nèi)容一致性的存儲區(qū)域，在物理上，一般有磁盤陣列設(shè)備組成，為了提供內(nèi)容的一致性，一般可以通過NFS網(wǎng)絡(luò)文件系統(tǒng)共享數(shù)據(jù)，但是NFS在繁忙的業(yè)務(wù)系統(tǒng)中，性能并不是很好，此時可以采用集群文件系統(tǒng)，列如Red hat的GFS文件系統(tǒng)等等。一個公司得有一個后臺賬目吧，這才能協(xié)調(diào)。不然客戶把錢付給了A，而換B接待客戶，因為沒有相同的賬目。B說客戶沒付錢，那這樣就不是客戶體驗度的問題了。

四、LVS的實現(xiàn)原理

（1）當(dāng)用戶負(fù)載均衡調(diào)度器（Director Server）發(fā)起請求，調(diào)度器將請求發(fā)往至內(nèi)核空間

（2）PREROUTING 鏈?zhǔn)紫葧邮艿接脩粽埱螅袛嗄繕?biāo)IP確實是本地IP，將數(shù)據(jù)包發(fā)往 INPUT 鏈

（3）IPVS 是工作在 INPUT 鏈上的，當(dāng)用戶請求到達(dá)INPUT時，IPVS 會將用戶請求和自己定義好的集群服務(wù)進(jìn)行比對，如果用戶請求的就是集群服務(wù)，那么此時 IPVS 會強(qiáng)行修改數(shù)據(jù)包里的目標(biāo)IP地址和端口，并將新的數(shù)據(jù)包發(fā)往 POSTROUTING 鏈

（4）POSTROUTING 鏈將收到數(shù)據(jù)包后發(fā)現(xiàn)目標(biāo)IP地址剛好是自己的后端服務(wù)器，那么此時通過選路，將數(shù)據(jù)包最終發(fā)送給后端的服務(wù)器

五、LVS的工作原理

LVS 的工作模式分為4中分別是 NAT，DR，TUN，F(xiàn)ULL-NAT。其中做個比較，由于工作原理的關(guān)系的，NAT的配置最為簡單，但是NAT對調(diào)度器的壓力太大了，導(dǎo)致其效率最低，DR和TUN的工作原理差不多，但是DR中，所有主機(jī)必須處于同一個物理環(huán)境中，而在TUN中，所有主機(jī)可以分布在不同的位置，服務(wù)器一個在紐約，一個在深圳。最多應(yīng)用的是FULL-NAT。

六、LVS相關(guān)術(shù)語

（1）DS：Director Server　　指的是前端負(fù)載均衡器節(jié)點。

（2）RS：Real Server　　后端真實的工作服務(wù)器。

（3）VIP：向外部直接面向用戶請求，作為用戶請求的目標(biāo)的ip地址。

（4）DIP：Director Server IP　　主要用于和內(nèi)部服務(wù)器通訊的ip地址。

（5）RIP：Real Server IP　　后端服務(wù)器的ip地址。

（6）CIP：Client IP　　　　訪問客戶端的IP地址。

七、NAT 模式-網(wǎng)絡(luò)地址轉(zhuǎn)換

這個是通過網(wǎng)絡(luò)地址轉(zhuǎn)換的方法來實現(xiàn)調(diào)度的。首先調(diào)度器(LB)接收到客戶的請求數(shù)據(jù)包時（請求的目的IP為VIP），根據(jù)調(diào)度算法決定將請求發(fā)送給哪個后端的真實服務(wù)器（RS）。然后調(diào)度就把客戶端發(fā)送的請求數(shù)據(jù)包的目標(biāo)IP地址及端口改成后端真實服務(wù)器的IP地址（RIP）,這樣真實服務(wù)器（RS）就能夠接收到客戶的請求數(shù)據(jù)包了。真實服務(wù)器響應(yīng)完請求后，查看默認(rèn)路由（NAT模式下我們需要把RS的默認(rèn)路由設(shè)置為LB服務(wù)器。）把響應(yīng)后的數(shù)據(jù)包發(fā)送給LB,LB再接收到響應(yīng)包后，把包的源地址改成虛擬地址（VIP）然后發(fā)送回給客戶端。

VS/NAT是一種最簡單的方式，所有的RealServer只需要將自己的網(wǎng)關(guān)指向Director即可。客戶端可以是任意操作系統(tǒng)，但此方式下，一個Director能夠帶動的RealServer比較有限。在VS/NAT的方式下，Director也可以兼為一臺RealServer。VS/NAT的體系結(jié)構(gòu)如圖所示。

八、NAT 模式工作原理

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

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

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

（4）POSTROUTING鏈通過選路，將數(shù)據(jù)包發(fā)送給Real Server。

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

（6）Director Server在響應(yīng)客戶端前，此時會將源IP地址修改為自己的VIP地址，然后響應(yīng)給客戶端。此時報文的源IP為 VIP，目標(biāo)IP為CIP。

九、DR 模式-直接路由模式

DR模式也就是用直接路由技術(shù)實現(xiàn)虛擬服務(wù)器。它的連接調(diào)度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉(zhuǎn)發(fā)方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發(fā)送到Real Server，而Real Server將響應(yīng)直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負(fù)載調(diào)度機(jī)制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網(wǎng)卡連在同一物理網(wǎng)段上。

Director和RealServer必需在物理上有一個網(wǎng)卡通過不間斷的局域網(wǎng)相連。 RealServer上綁定的VIP配置在各自Non-ARP的網(wǎng)絡(luò)設(shè)備上(如lo或tunl),Director的VIP地址對外可見，而RealServer的VIP對外是不可見的。RealServer的地址即可以是內(nèi)部地址，也可以是真實地址。

DR模式是通過改寫請求報文的目標(biāo)MAC地址，將請求發(fā)給真實服務(wù)器的，而真實服務(wù)器響應(yīng)后的處理結(jié)果直接返回給客戶端用戶。同TUN模式一樣，DR模式可以極大的提高集群系統(tǒng)的伸縮性。而且DR模式?jīng)]有IP隧道的開銷，對集群中的真實服務(wù)器也沒有必要必須支持IP隧道協(xié)議的要求。但是要求調(diào)度器LB與真實服務(wù)器RS都有一塊網(wǎng)卡連接到同一物理網(wǎng)段上，必須在同一個局域網(wǎng)環(huán)境。

9.1、DR 模式工作原理圖

（1）首先用戶用CIP請求VIP。

（2）根據(jù)上圖可以看到，不管是Director Server 還是Real Server 上都需要配置相同的VIP，那么當(dāng)用戶請求到達(dá)我們的集群網(wǎng)絡(luò)的前端路由器的時候，請求數(shù)據(jù)包的源地址為CIP，目標(biāo)地址為VIP；此時路由器還會發(fā)廣播問誰是VIP，那么我們集群中所有的節(jié)點都配置有VIP，此時誰先響應(yīng)路由器那么路由器就會將用戶請求發(fā)給誰，這樣一來我們的集群系統(tǒng)是不是沒有意義了，那我們可以在網(wǎng)關(guān)路由器上配置靜態(tài)路由指定VIP就是Director Server，或者使用一種機(jī)制不讓Real Server 接受來自網(wǎng)絡(luò)中的ARP 地址解析請求，這樣一來用戶的請求包都會經(jīng)過Director Server。

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

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

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

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

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

（8）響應(yīng)報文最終送達(dá)至客戶端。

配置DR的三種方式：

• 第一種：在路由器上明顯說明vip對應(yīng)的地址一定是Director上的MAC，只要綁定，以后再跟vip通信也不用再請求了，這個綁定是靜態(tài)的，所以它也不會失效，也不會再次發(fā)起請求，但是有個前提，我們的路由設(shè)備必須有操作權(quán)限才能夠綁定MAC地址，萬一這個路由器是運營商操作的，我們沒法操作怎么辦？第一種方式固然很簡單，但未必可行。
• 第二種：在個別主機(jī)上（列如：紅帽）它們引進(jìn)的有一種程序arptables，它有點類似iptables，它肯定是基于arp或者M(jìn)AC做訪問控制的，很顯然我們只需要在每一個Real Server上定義arptables規(guī)則，如果用戶arp廣播請求的目標(biāo)地址是本機(jī)的vip則不予響應(yīng)，或者說響應(yīng)的報文不讓出去，很顯然（gateway）是接收不到的，也就是director響應(yīng)的報文才能到達(dá)gateway，這個也行。第二種方式我們可以基于arptables。
• 第三種：在相對較新的版本中新增了兩個內(nèi)核參數(shù)（kernelparameter），第一個是arp_ignore定義接受到ARP請求時的響應(yīng)級別；第二個是arp_announce定義將自己地址向外通告時的通告級別。[提示：很顯然我們現(xiàn)在的系統(tǒng)一般在內(nèi)核中都是支持這些參數(shù)的，我們用參數(shù)的方式進(jìn)行調(diào)整更具有樸實性，它還不依賴額外的條件，像arptables，也不依賴外在路由配置的設(shè)置，反而通常我們使用的是第三種配置方式

arp_ignore:定義接收到ARP請求時的響應(yīng)級別

0：只要本地設(shè)置的有相應(yīng)的地址，就給予響應(yīng)。（默認(rèn)）

1：僅回應(yīng)目標(biāo)IP地址是本地的入網(wǎng)地址的arp請求。

2：僅回應(yīng)目標(biāo)IP地址是本地的入網(wǎng)地址，而且源IP和目標(biāo)IP在同一個子網(wǎng)的arp請求。

3：不回應(yīng)網(wǎng)絡(luò)界面的arp請求，而只對設(shè)置的唯一和連接地址做出回應(yīng)。

4-7：保留未使用。

8：不回應(yīng)所有的arp請求。

arp_announce：定義將自己地址向外通告的通告級別：

0：將本地任何接口上的任何地址向外通告。

1：視圖僅向目標(biāo)網(wǎng)絡(luò)通告與其網(wǎng)絡(luò)匹配的地址。

2：僅向與本地接口上地址匹配的網(wǎng)絡(luò)進(jìn)行通告。

9.2、DR模式的特性

• 保證前端路由將目標(biāo)地址為VIP報文統(tǒng)統(tǒng)發(fā)給Director Server，而不是RS。
• Director和RS的VIP為同一個VIP。
• RS可以使用私有地址，也可以是公網(wǎng)地址，如果使用公網(wǎng)地址，此時可以通過互聯(lián)網(wǎng)對RIP進(jìn)行直接訪問。
• RS跟Director Server必須在同一個物理網(wǎng)絡(luò)中。
• 所有的請求報文經(jīng)由Director Server，但響應(yīng)報文必須不能經(jīng)過Director Server。
• 不支持地址轉(zhuǎn)換，也不支持端口轉(zhuǎn)換。
• RS 可以是大多數(shù)常見的操作系統(tǒng)。
• RS 的網(wǎng)關(guān)絕不允許指向DIP（因為我們不允許它經(jīng)過Director）
• RS上的lo接口配置VIP的ip地址
• DR模式是市面上用得最廣的。
• 缺陷：RS和DS必須在同一機(jī)房。

十、Tunnel 模式

10.1、Tunnel 模式工作原理

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

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

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

（4）POSTROUTING鏈根據(jù)最新封裝的IP報文，將數(shù)據(jù)包發(fā)送至RS（因為在外層多封裝了一層IP首部，所以可以理解為 此時通過隧道傳輸）。此時源IP為DIP，目標(biāo)IP為RIP。

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

（6）響應(yīng)報文最終送達(dá)至客戶端。

10.2、Tunnel模式的特性

• RIP、VIP、DIP全是公網(wǎng)地址。
• RS的網(wǎng)關(guān)不會也不可能指向DIP。
• 所有的請求報文經(jīng)由Director Server，但響應(yīng)報文必須不能經(jīng)過Director Server。
• 不支持端口映射。
• RS的系統(tǒng)必須支持隧道。

十一、LVS 的調(diào)度算法

固定調(diào)度算法：rr，wrr，dh，sh

動態(tài)調(diào)度算法：wlc，lc，lblc，lblcr

固定調(diào)度算法：即調(diào)度器不會去判斷后端服務(wù)器的繁忙與否，一如既往得將請求派發(fā)下去。

動態(tài)調(diào)度算法：調(diào)度器會去判斷后端服務(wù)器的繁忙程度，然后依據(jù)調(diào)度算法動態(tài)得派發(fā)請求。

11.1、rr：輪詢（round robin）

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

11.2、wrr：加權(quán)輪詢（weight round robin）

這種算法比 rr 的算法多了一個權(quán)重的概念，可以給 RS 設(shè)置權(quán)重，權(quán)重越高，那么分發(fā)的請求數(shù)越多，權(quán)重的取值范圍 0 – 100。主要是對rr算法的一種優(yōu)化和補(bǔ)充， LVS 會考慮每臺服務(wù)器的性能，并給每臺服務(wù)器添加要給權(quán)值，如果服務(wù)器A的權(quán)值為1，服務(wù)器B的權(quán)值為2，則調(diào)度到服務(wù)器B的請求會是服務(wù)器A的2倍。權(quán)值越高的服務(wù)器，處理的請求越多。

11.3、dh：目標(biāo)地址散列調(diào)度算法 （destination hash）

簡單的說，即將同一類型的請求分配給同一個后端服務(wù)器，例如將以 .jgp、.jpg等結(jié)尾的請求轉(zhuǎn)發(fā)到同一個節(jié)點。這種算法其實不是為了真正意義的負(fù)載均衡，而是為了資源的分類管理。這種調(diào)度算法主要應(yīng)用在使用了緩存節(jié)點的系統(tǒng)中，提高緩存的命中率。

11.4、sh：源地址散列調(diào)度算法（source hash）

即將來自同一個ip的請求發(fā)給后端的同一個服務(wù)器，如果后端服務(wù)器工作正常沒有超負(fù)荷的話。這可以解決session共享的問題，但是這里有個問題，很多企業(yè)、社區(qū)、學(xué)校都是共用的一個IP，這將導(dǎo)致請求分配的不均衡。

11.5、lc：最少連接數(shù)（least-connection）

這個算法會根據(jù)后端 RS 的連接數(shù)來決定把請求分發(fā)給誰，比如 RS1 連接數(shù)比 RS2 連接數(shù)少，那么請求就優(yōu)先發(fā)給 RS1。這里問題是無法做到會話保持，即session共享。

11.6、wlc：加權(quán)最少連接數(shù)（weight least-connection）

這個比最少連接數(shù)多了一個加權(quán)的概念，即在最少連接數(shù)的基礎(chǔ)上加一個權(quán)重值，當(dāng)連接數(shù)相近，權(quán)重值越大，越優(yōu)先被分派請求。

11.7、lblc：基于局部性的最少連接調(diào)度算法（locality-based least-connection）

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

以上就是深入理解Linux負(fù)載均衡LVS的詳細(xì)內(nèi)容，更多關(guān)于Linux 負(fù)載均衡 LVS的資料請關(guān)注腳本之家其它相關(guān)文章！