目錄
- 一、LVS負載均衡
- 二、負載均衡LVS基本介紹
- 三、LVS的體系架構(gòu)
- 3.1、Load Balancer層
- 3.2、Server Arrary層
- 3.3、Shared Storage層
- 四、LVS的實現(xiàn)原理
- 五、LVS的工作原理
- 六、LVS相關(guān)術(shù)語
- 七、NAT 模式-網(wǎng)絡(luò)地址轉(zhuǎn)換
- 八、NAT 模式工作原理
- 九、DR 模式-直接路由模式
- 9.1、DR 模式工作原理圖
- 9.2、DR模式的特性
- 十、Tunnel 模式
- 10.1、Tunnel 模式工作原理
- 10.2、Tunnel模式的特性
- 十一、LVS 的調(diào)度算法
- 11.1、rr:輪詢(round robin)
- 11.2、wrr:加權(quán)輪詢(weight round robin)
- 11.3、dh:目標地址散列調(diào)度算法 (destination hash)
- 11.4、sh:源地址散列調(diào)度算法(source hash)
- 11.5、lc:最少連接數(shù)(least-connection)
- 11.6、wlc:加權(quán)最少連接數(shù)(weight least-connection)
- 11.7、lblc:基于局部性的最少連接調(diào)度算法(locality-based least-connection)
一、LVS負載均衡
負載均衡集群是Load Balance 集群的縮寫,翻譯成中文就是負載均衡集群。常用的負載均衡開源軟件有Nginx、LVS、Haproxy,商業(yè)的硬件負載均衡設(shè)備有F5、Netscale等。
二、負載均衡LVS基本介紹
LB集群的架構(gòu)和原理很簡單,就是當用戶的請求過來時,會直接分發(fā)到Director Server上,然后它把用戶的請求根據(jù)設(shè)置好的調(diào)度算法,智能均衡的分發(fā)后端真正服務(wù)器(real server)上。為了避免不同機器上用戶請求的數(shù)據(jù)不一樣,需要用到了共享存儲,這樣保證所有用戶請求的數(shù)據(jù)是一樣的。
這是由章文嵩博士發(fā)起的一個開源項目,官網(wǎng):http://www.linuxvirtualserver.org現(xiàn)在LVS已經(jīng)是 Linux 內(nèi)核標準的一部分。使用 LVS 可以達到的技術(shù)目標是:通過 LVS 達到的負載均衡技術(shù)和 Linux 操作系統(tǒng)實現(xiàn)一個高性能高可用的 Linux 服務(wù)集群,它具有良好的可靠性、可擴展性和可操作性。從而以廉價的成本實現(xiàn)最優(yōu)的性能。
LVS集群采用IP負載均衡技術(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ā)起請求時,請求直接發(fā)給Director Server(調(diào)度器),這時會根據(jù)設(shè)定的調(diào)度算法,將請求按照算法的規(guī)定智能的分發(fā)到真正的后臺服務(wù)器。以達到將壓力均攤。但是我們知道,http的連接時無狀態(tài)的,假設(shè)這樣一個場景,我登錄某寶買東西,當我看上某款商品時,我將它加入購物車,但是我刷新了一下頁面,這時由于負載均衡的原因,調(diào)度器又選了新的一臺服務(wù)器為我提供服務(wù),我剛才的購物車內(nèi)容全都不見了,這樣就會有十分差的用戶體驗。所以就還需要一個存儲共享,這樣就保證了用戶請求的數(shù)據(jù)是一樣的。所以LVS負載均衡分為三層架構(gòu)(也就是LVS負載均衡主要組成部分):
如圖:
LVS的各個層次的詳細介紹:
3.1、Load Balancer層
位于整個集群系統(tǒng)的最前端,有一臺或者多臺負載調(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ù)的機器組成,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)當用戶負載均衡調(diào)度器(Director Server)發(fā)起請求,調(diào)度器將請求發(fā)往至內(nèi)核空間
(2)PREROUTING 鏈首先會接受到用戶請求,判斷目標IP確實是本地IP,將數(shù)據(jù)包發(fā)往 INPUT 鏈
(3)IPVS 是工作在 INPUT 鏈上的,當用戶請求到達INPUT時,IPVS 會將用戶請求和自己定義好的集群服務(wù)進行比對,如果用戶請求的就是集群服務(wù),那么此時 IPVS 會強行修改數(shù)據(jù)包里的目標IP地址和端口,并將新的數(shù)據(jù)包發(fā)往 POSTROUTING 鏈
(4)POSTROUTING 鏈將收到數(shù)據(jù)包后發(fā)現(xiàn)目標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中,所有主機必須處于同一個物理環(huán)境中,而在TUN中,所有主機可以分布在不同的位置,服務(wù)器一個在紐約,一個在深圳。最多應(yīng)用的是FULL-NAT。
六、LVS相關(guān)術(shù)語
(1)DS:Director Server 指的是前端負載均衡器節(jié)點。
(2)RS:Real Server 后端真實的工作服務(wù)器。
(3)VIP:向外部直接面向用戶請求,作為用戶請求的目標的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ù)包的目標IP地址及端口改成后端真實服務(wù)器的IP地址(RIP),這樣真實服務(wù)器(RS)就能夠接收到客戶的請求數(shù)據(jù)包了。真實服務(wù)器響應(yīng)完請求后,查看默認路由(NAT模式下我們需要把RS的默認路由設(shè)置為LB服務(wù)器。)把響應(yīng)后的數(shù)據(jù)包發(fā)送給LB,LB再接收到響應(yīng)包后,把包的源地址改成虛擬地址(VIP)然后發(fā)送回給客戶端。
VS/NAT是一種最簡單的方式,所有的RealServer只需要將自己的網(wǎng)關(guān)指向Director即可??蛻舳丝梢允侨我獠僮飨到y(tǒng),但此方式下,一個Director能夠帶動的RealServer比較有限。在VS/NAT的方式下,Director也可以兼為一臺RealServer。VS/NAT的體系結(jié)構(gòu)如圖所示。
八、NAT 模式工作原理
(1)當用戶請求到達Director Server,此時的請求數(shù)據(jù)報文會先到內(nèi)核空間的PREROUTING鏈。此時報文的源IP為 CIP,目標IP為 VIP。
(2)PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標IP 是本機,將數(shù)據(jù)包發(fā)送至INPUT鏈。
(3)IPVS比對數(shù)據(jù)包請求的服務(wù)是否為集群服務(wù),若是,修改數(shù)據(jù)包的目標IP地址為后端服務(wù)器IP,然后將數(shù)據(jù)包發(fā)送至POSTROUTING鏈。此時報文的源IP為 CIP,目標IP為RIP。
(4)POSTROUTING鏈通過選路,將數(shù)據(jù)包發(fā)送給Real Server。
(5)Real Server對比發(fā)現(xiàn)目標為自己的IP,開始構(gòu)建響應(yīng)報文發(fā)回給Director Server。此時報文的源IP為 RIP,目標IP為 CIP。
(6)Director Server在響應(yīng)客戶端前,此時會將源IP地址修改為自己的VIP地址,然后響應(yīng)給客戶端。此時報文的源IP為 VIP,目標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隧道開銷。這種方式是三種負載調(diào)度機制中性能最高最好的,但是必須要求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模式是通過改寫請求報文的目標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,那么當用戶請求到達我們的集群網(wǎng)絡(luò)的前端路由器的時候,請求數(shù)據(jù)包的源地址為CIP,目標地址為VIP;此時路由器還會發(fā)廣播問誰是VIP,那么我們集群中所有的節(jié)點都配置有VIP,此時誰先響應(yīng)路由器那么路由器就會將用戶請求發(fā)給誰,這樣一來我們的集群系統(tǒng)是不是沒有意義了,那我們可以在網(wǎng)關(guān)路由器上配置靜態(tài)路由指定VIP就是Director Server,或者使用一種機制不讓Real Server 接受來自網(wǎng)絡(luò)中的ARP 地址解析請求,這樣一來用戶的請求包都會經(jīng)過Director Server。
(3)當用戶請求到達Director Server,此時請求的數(shù)據(jù)報文會先到內(nèi)核空間的PREROUTING鏈,此時報文的源IP為CIP,目標IP為VIP。
(4)PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標IP為本機,將數(shù)據(jù)包發(fā)送至INPUT鏈。
(5)IPVS對比數(shù)據(jù)包請求的服務(wù)是否為集群服務(wù),若是,將請求報文中的源MAC地址修改DIP的MAC地址,將目標MAC地址修改為RIP的MAC地址,然后將數(shù)據(jù)包發(fā)至POSTROUTING鏈,此時的源IP和目標IP均未修改,僅修改了源MAC地址為DIP的MAC地址,目標MAC地址為RIP的MAC地址。
(6)由于DS和RS在同一個網(wǎng)絡(luò)中,所以是通過二層來傳輸,POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址,那么此時數(shù)據(jù)包將會發(fā)至Real Server。
(7)RS發(fā)現(xiàn)請求報文的MAC地址是自己的MAC地址,就接收報文。處理完成之后,將相應(yīng)報文通過lo接口傳送給eth0網(wǎng)卡然后向外發(fā)出。此時的源IP地址為VIP,目標IP為CIP。
(8)響應(yīng)報文最終送達至客戶端。
配置DR的三種方式:
- 第一種:在路由器上明顯說明vip對應(yīng)的地址一定是Director上的MAC,只要綁定,以后再跟vip通信也不用再請求了,這個綁定是靜態(tài)的,所以它也不會失效,也不會再次發(fā)起請求,但是有個前提,我們的路由設(shè)備必須有操作權(quán)限才能夠綁定MAC地址,萬一這個路由器是運營商操作的,我們沒法操作怎么辦?第一種方式固然很簡單,但未必可行。
- 第二種:在個別主機上(列如:紅帽)它們引進的有一種程序arptables,它有點類似iptables,它肯定是基于arp或者MAC做訪問控制的,很顯然我們只需要在每一個Real Server上定義arptables規(guī)則,如果用戶arp廣播請求的目標地址是本機的vip則不予響應(yīng),或者說響應(yīng)的報文不讓出去,很顯然(gateway)是接收不到的,也就是director響應(yīng)的報文才能到達gateway,這個也行。第二種方式我們可以基于arptables。
- 第三種:在相對較新的版本中新增了兩個內(nèi)核參數(shù)(kernelparameter),第一個是arp_ignore定義接受到ARP請求時的響應(yīng)級別;第二個是arp_announce定義將自己地址向外通告時的通告級別。[提示:很顯然我們現(xiàn)在的系統(tǒng)一般在內(nèi)核中都是支持這些參數(shù)的,我們用參數(shù)的方式進行調(diào)整更具有樸實性,它還不依賴額外的條件,像arptables,也不依賴外在路由配置的設(shè)置,反而通常我們使用的是第三種配置方式
arp_ignore:定義接收到ARP請求時的響應(yīng)級別
0:只要本地設(shè)置的有相應(yīng)的地址,就給予響應(yīng)。(默認)
1:僅回應(yīng)目標IP地址是本地的入網(wǎng)地址的arp請求。
2:僅回應(yīng)目標IP地址是本地的入網(wǎng)地址,而且源IP和目標IP在同一個子網(wǎng)的arp請求。
3:不回應(yīng)網(wǎng)絡(luò)界面的arp請求,而只對設(shè)置的唯一和連接地址做出回應(yīng)。
4-7:保留未使用。
8:不回應(yīng)所有的arp請求。
arp_announce:定義將自己地址向外通告的通告級別:
0:將本地任何接口上的任何地址向外通告。
1:視圖僅向目標網(wǎng)絡(luò)通告與其網(wǎng)絡(luò)匹配的地址。
2:僅向與本地接口上地址匹配的網(wǎng)絡(luò)進行通告。
9.2、DR模式的特性
- 保證前端路由將目標地址為VIP報文統(tǒng)統(tǒng)發(fā)給Director Server,而不是RS。
- Director和RS的VIP為同一個VIP。
- RS可以使用私有地址,也可以是公網(wǎng)地址,如果使用公網(wǎng)地址,此時可以通過互聯(lián)網(wǎng)對RIP進行直接訪問。
- 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必須在同一機房。
十、Tunnel 模式
10.1、Tunnel 模式工作原理
(1)當用戶請求到達Director Server,此時請求的數(shù)據(jù)報文會先拿到內(nèi)核空間的PREROUTING鏈,此時報文的源IP為CIP,目標IP為VIP。
(2)PREROUTING檢查發(fā)現(xiàn)數(shù)據(jù)包的目標IP是本機,將數(shù)據(jù)包發(fā)送至INPUT鏈。
(3)IPVS對比數(shù)據(jù)包請求的服務(wù)是否為集群服務(wù),若是,在請求報文的首部再次封裝一層IP報文,封裝源IP為DIP,目標IP為RIP。然后發(fā)至POSTROUTING鏈,此時源IP為DIP,目標IP為RIP。
(4)POSTROUTING鏈根據(jù)最新封裝的IP報文,將數(shù)據(jù)包發(fā)送至RS(因為在外層多封裝了一層IP首部,所以可以理解為 此時通過隧道傳輸)。此時源IP為DIP,目標IP為RIP。
(5)RS接收到報文后發(fā)現(xiàn)是自己的IP地址,就將報文接收下來,拆除掉最外層的IP后,會發(fā)現(xiàn)里面還有一層IP首部,而且目標是自己的lo接口VIP,那么此時RS開始處理請求,處理完成之后,通過lo接口發(fā)送給eth0網(wǎng)卡,然后向外傳遞。此時源IP為VIP,目標IP為CIP。
(6)響應(yīng)報文最終送達至客戶端。
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)化和補充, 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:目標地址散列調(diào)度算法 (destination hash)
簡單的說,即將同一類型的請求分配給同一個后端服務(wù)器,例如將以 .jgp、.jpg等結(jié)尾的請求轉(zhuǎn)發(fā)到同一個節(jié)點。這種算法其實不是為了真正意義的負載均衡,而是為了資源的分類管理。這種調(diào)度算法主要應(yīng)用在使用了緩存節(jié)點的系統(tǒng)中,提高緩存的命中率。
11.4、sh:源地址散列調(diào)度算法(source hash)
即將來自同一個ip的請求發(fā)給后端的同一個服務(wù)器,如果后端服務(wù)器工作正常沒有超負荷的話。這可以解決session共享的問題,但是這里有個問題,很多企業(yè)、社區(qū)、學校都是共用的一個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)重值,當連接數(shù)相近,權(quán)重值越大,越優(yōu)先被分派請求。
11.7、lblc:基于局部性的最少連接調(diào)度算法(locality-based least-connection)
將來自同一目的地址的請求分配給同一臺RS如果這臺服務(wù)器尚未滿負荷,否則分配給連接數(shù)最小的RS,并以它為下一次分配的首先考慮。
以上就是深入理解Linux負載均衡LVS的詳細內(nèi)容,更多關(guān)于Linux 負載均衡 LVS的資料請關(guān)注腳本之家其它相關(guān)文章!