負載均衡集群是Load Balance 集群的縮寫(xiě),翻譯成中文就是負載均衡集群。常用的負載均衡開(kāi)源軟件有Nginx、LVS、Haproxy,商業(yè)的硬件負載均衡設備有F5、Netscale等。
LB集群的架構和原理很簡(jiǎn)單,就是當用戶(hù)的請求過(guò)來(lái)時(shí),會(huì )直接分發(fā)到Director Server上,然后它把用戶(hù)的請求根據設置好的調度算法,智能均衡的分發(fā)后端真正服務(wù)器(real server)上。為了避免不同機器上用戶(hù)請求的數據不一樣,需要用到了共享存儲,這樣保證所有用戶(hù)請求的數據是一樣的。
這是由章文嵩博士發(fā)起的一個(gè)開(kāi)源項目,官網(wǎng):現在LVS已經(jīng)是 Linux 內核標準的一部分。使用 LVS 可以達到的技術(shù)目標是:通過(guò) LVS 達到的負載均衡技術(shù)和 Linux 操作系統實(shí)現一個(gè)高性能高可用的 Linux 服務(wù)集群,它具有良好的可靠性、可擴展性和可操作性。從而以廉價(jià)的成本實(shí)現最優(yōu)的性能。
LVS集群采用IP負載均衡技術(shù)和基于內容請求分發(fā)技術(shù)。調度器具有很好的吞吐率,將請求均衡地轉移到不同的服務(wù)器上執行,且調度器自動(dòng)屏蔽掉服 務(wù)器的故障,從而將一組服務(wù)器構成一個(gè)高性能的、高可用的虛擬服務(wù)器。整個(gè)服務(wù)器集群的結構對客戶(hù)是透明的,而且無(wú)需修改客戶(hù)端和服務(wù)器端的程序。
負載均衡的原理很簡(jiǎn)單,就是當客戶(hù)端發(fā)起請求時(shí),請求直接發(fā)給Director Server(調度器),這時(shí)會(huì )根據設定的調度算法,將請求按照算法的規定智能的分發(fā)到真正的后臺服務(wù)器。以達到將壓力均攤。但是我們知道,http的連接時(shí)無(wú)狀態(tài)的,假設這樣一個(gè)場(chǎng)景,我登錄某寶買(mǎi)東西,當我看上某款商品時(shí),我將它加入購物車(chē),但是我刷新了一下頁(yè)面,這時(shí)由于負載均衡的原因,調度器又選了新的一臺服務(wù)器為我提供服務(wù),我剛才的購物車(chē)內容全都不見(jiàn)了,這樣就會(huì )有十分差的用戶(hù)體驗。所以就還需要一個(gè)存儲共享,這樣就保證了用戶(hù)請求的數據是一樣的。所以L(fǎng)VS負載均衡分為三層架構(也就是LVS負載均衡主要組成部分):
如圖:
LVS的各個(gè)層次的詳細介紹:
位于整個(gè)集群系統的最前端,有一臺或者多臺負載調度器(Director Server)組成,LVS模塊就是安裝在Director Server上,而Director的主要作用類(lèi)似于一個(gè)路由器,它含有完成LVS功能所設定的路由表,通過(guò)這些路由表把用戶(hù)的請求分發(fā)給Server Array層的應用服務(wù)器(Real Server)上。同時(shí),在Director Server上還要安裝隊Real Server服務(wù)的監控模塊Ldirectord,此模塊用于檢測各個(gè)Real Server服務(wù)的健康狀況。在Real Server不可用時(shí)把它從 LVS 路由表中剔除,恢復時(shí)重新加入。
由一組實(shí)際運行應用服務(wù)的機器組成,Real Server可以是WEB 服務(wù)器、MALL服務(wù)器、FTP服務(wù)器、DNS服務(wù)器、等等,每個(gè)Real Server 之間通過(guò)高速的LAN或分布在各地的WAN相連接,在實(shí)際的應用中,Director Server也可以同時(shí)兼任Real Server的角色。
是為所有Real Server提供共享存儲空間和內容一致性的存儲區域,在物理上,一般有磁盤(pán)陣列設備組成,為了提供內容的一致性,一般可以通過(guò)NFS網(wǎng)絡(luò )文件系統共享數據,但是NFS在繁忙的業(yè)務(wù)系統中,性能并不是很好,此時(shí)可以采用集群文件系統,列如Red hat的GFS文件系統等等。一個(gè)公司得有一個(gè)后臺賬目吧,這才能協(xié)調。不然客戶(hù)把錢(qián)付給了A,而換B接待客戶(hù),因為沒(méi)有相同的賬目。B說(shuō)客戶(hù)沒(méi)付錢(qián),那這樣就不是客戶(hù)體驗度的問(wèn)題了。
(1)當用戶(hù)負載均衡調度器(Director Server)發(fā)起請求,調度器將請求發(fā)往至內核空間
(2)PREROUTING 鏈首先會(huì )接受到用戶(hù)請求,判斷目標IP確實(shí)是本地IP,將數據包發(fā)往 INPUT 鏈
(3)IPVS 是工作在 INPUT 鏈上的,當用戶(hù)請求到達INPUT時(shí),IPVS 會(huì )將用戶(hù)請求和自己定義好的集群服務(wù)進(jìn)行比對,如果用戶(hù)請求的就是集群服務(wù),那么此時(shí) IPVS 會(huì )強行修改數據包里的目標IP地址和端口,并將新的數據包發(fā)往 POSTROUTING 鏈
(4)POSTROUTING 鏈將收到數據包后發(fā)現目標IP地址剛好是自己的后端服務(wù)器,那么此時(shí)通過(guò)選路,將數據包最終發(fā)送給后端的服務(wù)器
LVS 的工作模式分為4中分別是 NAT,DR,TUN,FULL-NAT。其中做個(gè)比較,由于工作原理的關(guān)系的,NAT的配置最為簡(jiǎn)單,但是NAT對調度器的壓力太大了,導致其效率最低,DR和TUN的工作原理差不多,但是DR中,所有主機必須處于同一個(gè)物理環(huán)境中,而在TUN中,所有主機可以分布在不同的位置,服務(wù)器一個(gè)在紐約,一個(gè)在深圳。最多應用的是FULL-NAT。
(1)DS:Director Server 指的是前端負載均衡器節點(diǎn)。
(2)RS:Real Server 后端真實(shí)的工作服務(wù)器。
(3)VIP:向外部直接面向用戶(hù)請求,作為用戶(hù)請求的目標的ip地址。
(4)DIP:Director Server IP 主要用于和內部服務(wù)器通訊的ip地址。
(5)RIP:Real Server IP 后端服務(wù)器的ip地址。
(6)CIP:Client IP 訪(fǎng)問(wèn)客戶(hù)端的IP地址。
這個(gè)是通過(guò)網(wǎng)絡(luò )地址轉換的方法來(lái)實(shí)現調度的。首先調度器(LB)接收到客戶(hù)的請求數據包時(shí)(請求的目的IP為VIP),根據調度算法決定將請求發(fā)送給哪個(gè)后端的真實(shí)服務(wù)器(RS)。然后調度就把客戶(hù)端發(fā)送的請求數據包的目標IP地址及端口改成后端真實(shí)服務(wù)器的IP地址(RIP),這樣真實(shí)服務(wù)器(RS)就能夠接收到客戶(hù)的請求數據包了。真實(shí)服務(wù)器響應完請求后,查看默認路由(NAT模式下我們需要把RS的默認路由設置為L(cháng)B服務(wù)器。)把響應后的數據包發(fā)送給LB,LB再接收到響應包后,把包的源地址改成虛擬地址(VIP)然后發(fā)送回給客戶(hù)端。
VS/NAT是一種最簡(jiǎn)單的方式,所有的RealServer只需要將自己的網(wǎng)關(guān)指向Director即可??蛻?hù)端可以是任意操作系統,但此方式下,一個(gè)Director能夠帶動(dòng)的RealServer比較有限。在VS/NAT的方式下,Director也可以兼為一臺RealServer。VS/NAT的體系結構如圖所示。
(1)當用戶(hù)請求到達Director Server,此時(shí)的請求數據報文會(huì )先到內核空間的PREROUTING鏈。此時(shí)報文的源IP為 CIP,目標IP為 VIP。
(2)PREROUTING檢查發(fā)現數據包的目標IP 是本機,將數據包發(fā)送至INPUT鏈。
(3)IPVS比對數據包請求的服務(wù)是否為集群服務(wù),若是,修改數據包的目標IP地址為后端服務(wù)器IP,然后將數據包發(fā)送至POSTROUTING鏈。此時(shí)報文的源IP為 CIP,目標IP為RIP。
(4)POSTROUTING鏈通過(guò)選路,將數據包發(fā)送給Real Server。
(5)Real Server對比發(fā)現目標為自己的IP,開(kāi)始構建響應報文發(fā)回給Director Server。此時(shí)報文的源IP為 RIP,目標IP為 CIP。
(6)Director Server在響應客戶(hù)端前,此時(shí)會(huì )將源IP地址修改為自己的VIP地址,然后響應給客戶(hù)端。此時(shí)報文的源IP為 VIP,目標IP為CIP。
DR模式也就是用直接路由技術(shù)實(shí)現虛擬服務(wù)器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣,但它的報文轉發(fā)方法又有不同,VS/DR通過(guò)改寫(xiě)請求報文的MAC地址,將請求發(fā)送到Real Server,而Real Server將響應直接返回給客戶(hù),免去了VS/TUN中的IP隧道開(kāi)銷(xiāo)。這種方式是三種負載調度機制中性能最高最好的,但是必須要求Director Server與Real Server都有一塊網(wǎng)卡連在同一物理網(wǎng)段上。
Director和RealServer必需在物理上有一個(gè)網(wǎng)卡通過(guò)不間斷的局域網(wǎng)相連。 RealServer上綁定的VIP配置在各自Non-ARP的網(wǎng)絡(luò )設備上(如lo或tunl),Director的VIP地址對外可見(jiàn),而RealServer的VIP對外是不可見(jiàn)的。RealServer的地址即可以是內部地址,也可以是真實(shí)地址。
DR模式是通過(guò)改寫(xiě)請求報文的目標MAC地址,將請求發(fā)給真實(shí)服務(wù)器的,而真實(shí)服務(wù)器響應后的處理結果直接返回給客戶(hù)端用戶(hù)。同TUN模式一樣,DR模式可以極大的提高集群系統的伸縮性。而且DR模式?jīng)]有IP隧道的開(kāi)銷(xiāo),對集群中的真實(shí)服務(wù)器也沒(méi)有必要必須支持IP隧道協(xié)議的要求。但是要求調度器LB與真實(shí)服務(wù)器RS都有一塊網(wǎng)卡連接到同一物理網(wǎng)段上,必須在同一個(gè)局域網(wǎng)環(huán)境。
(1)首先用戶(hù)用CIP請求VIP。
(2)根據上圖可以看到,不管是Director Server 還是Real Server 上都需要配置相同的VIP,那么當用戶(hù)請求到達我們的集群網(wǎng)絡(luò )的前端路由器的時(shí)候,請求數據包的源地址為CIP,目標地址為VIP;此時(shí)路由器還會(huì )發(fā)廣播問(wèn)誰(shuí)是VIP,那么我們集群中所有的節點(diǎn)都配置有VIP,此時(shí)誰(shuí)先響應路由器那么路由器就會(huì )將用戶(hù)請求發(fā)給誰(shuí),這樣一來(lái)我們的集群系統是不是沒(méi)有意義了,那我們可以在網(wǎng)關(guān)路由器上配置靜態(tài)路由指定VIP就是Director Server,或者使用一種機制不讓Real Server 接受來(lái)自網(wǎng)絡(luò )中的ARP 地址解析請求,這樣一來(lái)用戶(hù)的請求包都會(huì )經(jīng)過(guò)Director Server。
(3)當用戶(hù)請求到達Director Server,此時(shí)請求的數據報文會(huì )先到內核空間的PREROUTING鏈,此時(shí)報文的源IP為CIP,目標IP為VIP。
(4)PREROUTING檢查發(fā)現數據包的目標IP為本機,將數據包發(fā)送至INPUT鏈。
(5)IPVS對比數據包請求的服務(wù)是否為集群服務(wù),若是,將請求報文中的源MAC地址修改DIP的MAC地址,將目標MAC地址修改為RIP的MAC地址,然后將數據包發(fā)至POSTROUTING鏈,此時(shí)的源IP和目標IP均未修改,僅修改了源MAC地址為DIP的MAC地址,目標MAC地址為RIP的MAC地址。
(6)由于DS和RS在同一個(gè)網(wǎng)絡(luò )中,所以是通過(guò)二層來(lái)傳輸,POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址,那么此時(shí)數據包將會(huì )發(fā)至Real Server。
(7)RS發(fā)現請求報文的MAC地址是自己的MAC地址,就接收報文。處理完成之后,將相應報文通過(guò)lo接口傳送給eth0網(wǎng)卡然后向外發(fā)出。此時(shí)的源IP地址為VIP,目標IP為CIP。
(8)響應報文最終送達至客戶(hù)端。
配置DR的三種方式:
arp_ignore:定義接收到ARP請求時(shí)的響應級別
0:只要本地設置的有相應的地址,就給予響應。(默認)
1:僅回應目標IP地址是本地的入網(wǎng)地址的arp請求。
2:僅回應目標IP地址是本地的入網(wǎng)地址,而且源IP和目標IP在同一個(gè)子網(wǎng)的arp請求。
3:不回應網(wǎng)絡(luò )界面的arp請求,而只對設置的唯一和連接地址做出回應。
4-7:保留未使用。
8:不回應所有的arp請求。
arp_announce:定義將自己地址向外通告的通告級別:
0:將本地任何接口上的任何地址向外通告。
1:視圖僅向目標網(wǎng)絡(luò )通告與其網(wǎng)絡(luò )匹配的地址。
2:僅向與本地接口上地址匹配的網(wǎng)絡(luò )進(jìn)行通告。
(1)當用戶(hù)請求到達Director Server,此時(shí)請求的數據報文會(huì )先拿到內核空間的PREROUTING鏈,此時(shí)報文的源IP為CIP,目標IP為VIP。
(2)PREROUTING檢查發(fā)現數據包的目標IP是本機,將數據包發(fā)送至INPUT鏈。
(3)IPVS對比數據包請求的服務(wù)是否為集群服務(wù),若是,在請求報文的首部再次封裝一層IP報文,封裝源IP為DIP,目標IP為RIP。然后發(fā)至POSTROUTING鏈,此時(shí)源IP為DIP,目標IP為RIP。
(4)POSTROUTING鏈根據最新封裝的IP報文,將數據包發(fā)送至RS(因為在外層多封裝了一層IP首部,所以可以理解為 此時(shí)通過(guò)隧道傳輸)。此時(shí)源IP為DIP,目標IP為RIP。
(5)RS接收到報文后發(fā)現是自己的IP地址,就將報文接收下來(lái),拆除掉最外層的IP后,會(huì )發(fā)現里面還有一層IP首部,而且目標是自己的lo接口VIP,那么此時(shí)RS開(kāi)始處理請求,處理完成之后,通過(guò)lo接口發(fā)送給eth0網(wǎng)卡,然后向外傳遞。此時(shí)源IP為VIP,目標IP為CIP。
(6)響應報文最終送達至客戶(hù)端。
固定調度算法:rr,wrr,dh,sh
動(dòng)態(tài)調度算法:wlc,lc,lblc,lblcr
固定調度算法:即調度器不會(huì )去判斷后端服務(wù)器的繁忙與否,一如既往得將請求派發(fā)下去。
動(dòng)態(tài)調度算法:調度器會(huì )去判斷后端服務(wù)器的繁忙程度,然后依據調度算法動(dòng)態(tài)得派發(fā)請求。
這種算法是最簡(jiǎn)單的,就是按依次循環(huán)的方式將請求調度到不同的服務(wù)器上,該算法最大的特點(diǎn)就是簡(jiǎn)單。輪詢(xún)算法假設所有的服務(wù)器處理請求的能力都是一樣的,調度器會(huì )將所有的請求平均分配給每個(gè)真實(shí)服務(wù)器,不管后端 RS 配置和處理能力,非常均衡地分發(fā)下去。這個(gè)調度的缺點(diǎn)是,不管后端服務(wù)器的繁忙程度是怎樣的,調度器都會(huì )講請求依次發(fā)下去。如果A服務(wù)器上的請求很快請求完了,而B(niǎo)服務(wù)器的請求一直持續著(zhù),將會(huì )導致B服務(wù)器一直很忙,而A很閑,這樣便沒(méi)起到均衡的左右。
這種算法比 rr 的算法多了一個(gè)權重的概念,可以給 RS 設置權重,權重越高,那么分發(fā)的請求數越多,權重的取值范圍 0 – 100。主要是對rr算法的一種優(yōu)化和補充, LVS 會(huì )考慮每臺服務(wù)器的性能,并給每臺服務(wù)器添加要給權值,如果服務(wù)器A的權值為1,服務(wù)器B的權值為2,則調度到服務(wù)器B的請求會(huì )是服務(wù)器A的2倍。權值越高的服務(wù)器,處理的請求越多。
簡(jiǎn)單的說(shuō),即將同一類(lèi)型的請求分配給同一個(gè)后端服務(wù)器,例如將以 .jgp、.jpg等結尾的請求轉發(fā)到同一個(gè)節點(diǎn)。這種算法其實(shí)不是為了真正意義的負載均衡,而是為了資源的分類(lèi)管理。這種調度算法主要應用在使用了緩存節點(diǎn)的系統中,提高緩存的命中率。
即將來(lái)自同一個(gè)ip的請求發(fā)給后端的同一個(gè)服務(wù)器,如果后端服務(wù)器工作正常沒(méi)有超負荷的話(huà)。這可以解決session共享的問(wèn)題,但是這里有個(gè)問(wèn)題,很多企業(yè)、社區、學(xué)校都是共用的一個(gè)IP,這將導致請求分配的不均衡。
這個(gè)算法會(huì )根據后端 RS 的連接數來(lái)決定把請求分發(fā)給誰(shuí),比如 RS1 連接數比 RS2 連接數少,那么請求就優(yōu)先發(fā)給 RS1。這里問(wèn)題是無(wú)法做到會(huì )話(huà)保持,即session共享。
這個(gè)比最少連接數多了一個(gè)加權的概念,即在最少連接數的基礎上加一個(gè)權重值,當連接數相近,權重值越大,越優(yōu)先被分派請求。
將來(lái)自同一目的地址的請求分配給同一臺RS如果這臺服務(wù)器尚未滿(mǎn)負荷,否則分配給連接數最小的RS,并以它為下一次分配的首先考慮。
以上就是深入理解Linux負載均衡LVS的詳細內容,更多關(guān)于Linux 負載均衡 LVS的資料請關(guān)注腳本之家其它相關(guān)文章!
免責聲明:本站發(fā)布的內容(圖片、視頻和文字)以原創(chuàng )、來(lái)自本網(wǎng)站內容采集于網(wǎng)絡(luò )互聯(lián)網(wǎng)轉載等其它媒體和分享為主,內容觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng),如侵犯了原作者的版權,請告知一經(jīng)查實(shí),將立刻刪除涉嫌侵權內容,聯(lián)系我們QQ:712375056,同時(shí)歡迎投稿傳遞力量。
Copyright ? 2009-2022 56dr.com. All Rights Reserved. 特網(wǎng)科技 特網(wǎng)云 版權所有 特網(wǎng)科技 粵ICP備16109289號
域名注冊服務(wù)機構:阿里云計算有限公司(萬(wàn)網(wǎng)) 域名服務(wù)機構:煙臺帝思普網(wǎng)絡(luò )科技有限公司(DNSPod) CDN服務(wù):阿里云計算有限公司 百度云 中國互聯(lián)網(wǎng)舉報中心 增值電信業(yè)務(wù)經(jīng)營(yíng)許可證B2
建議您使用Chrome、Firefox、Edge、IE10及以上版本和360等主流瀏覽器瀏覽本網(wǎng)站