主頁(yè) > 知識(shí)庫(kù) > 深入理解Linux負(fù)載均衡LVS

深入理解Linux負(fù)載均衡LVS

熱門標(biāo)簽:百度競(jìng)價(jià)點(diǎn)擊價(jià)格的計(jì)算公式 硅谷的囚徒呼叫中心 檢查注冊(cè)表項(xiàng) 使用U盤(pán)裝系統(tǒng) 美圖手機(jī) 智能手機(jī) 網(wǎng)站建設(shè) 阿里云

一、LVS負(fù)載均衡

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

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

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

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

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

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

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

如圖:

LVS的各個(gè)層次的詳細(xì)介紹:

3.1、Load Balancer層

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

3.2、Server Arrary層

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

3.3、Shared Storage層

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

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

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

(2)PREROUTING 鏈?zhǔn)紫葧?huì)接受到用戶請(qǐng)求,判斷目標(biāo)IP確實(shí)是本地IP,將數(shù)據(jù)包發(fā)往 INPUT 鏈

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

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

五、LVS的工作原理

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

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

(1)DS:Director Server  指的是前端負(fù)載均衡器節(jié)點(diǎn)。

(2)RS:Real Server  后端真實(shí)的工作服務(wù)器。

(3)VIP:向外部直接面向用戶請(qǐng)求,作為用戶請(qǐng)求的目標(biāo)的ip地址。

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

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

(6)CIP:Client IP    訪問(wèn)客戶端的IP地址。

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

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

VS/NAT是一種最簡(jiǎn)單的方式,所有的RealServer只需要將自己的網(wǎng)關(guān)指向Director即可??蛻舳丝梢允侨我獠僮飨到y(tǒng),但此方式下,一個(gè)Director能夠帶動(dòng)的RealServer比較有限。在VS/NAT的方式下,Director也可以兼為一臺(tái)RealServer。VS/NAT的體系結(jié)構(gòu)如圖所示。

八、NAT 模式工作原理

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

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

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

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

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

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

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

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

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

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

9.1、DR 模式工作原理圖

(1)首先用戶用CIP請(qǐng)求VIP。

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

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

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

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

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

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

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

配置DR的三種方式:

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

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

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

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

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

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

4-7:保留未使用。

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

arp_announce:定義將自己地址向外通告的通告級(jí)別:

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

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

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

9.2、DR模式的特性

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

十、Tunnel 模式

10.1、Tunnel 模式工作原理

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

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

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

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

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

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

10.2、Tunnel模式的特性

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

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

固定調(diào)度算法:rr,wrr,dh,sh

動(dòng)態(tài)調(diào)度算法:wlc,lc,lblc,lblcr

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

動(dòng)態(tài)調(diào)度算法:調(diào)度器會(huì)去判斷后端服務(wù)器的繁忙程度,然后依據(jù)調(diào)度算法動(dòng)態(tài)得派發(fā)請(qǐng)求。

11.1、rr:輪詢(round robin)

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

11.2、wrr:加權(quán)輪詢(weight round robin)

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

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

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

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

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

11.5、lc:最少連接數(shù)(least-connection)

這個(gè)算法會(huì)根據(jù)后端 RS 的連接數(shù)來(lái)決定把請(qǐng)求分發(fā)給誰(shuí),比如 RS1 連接數(shù)比 RS2 連接數(shù)少,那么請(qǐng)求就優(yōu)先發(fā)給 RS1。這里問(wèn)題是無(wú)法做到會(huì)話保持,即session共享。

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

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

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

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

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

標(biāo)簽:懷化 湖北 黃山 山南 賀州 通遼 湘潭 煙臺(tái)

巨人網(wǎng)絡(luò)通訊聲明:本文標(biāo)題《深入理解Linux負(fù)載均衡LVS》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題,煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們,我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無(wú)關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266