負(fù)載均衡：LVS 負(fù)載調(diào)度原理

這篇具有很好參考價(jià)值的文章主要介紹了負(fù)載均衡：LVS 負(fù)載調(diào)度原理。希望對大家有所幫助。如果存在錯(cuò)誤或未考慮完全的地方，請大家不吝賜教，您也可以點(diǎn)擊"舉報(bào)違法"按鈕提交疑問。

LVS 官方中文站點(diǎn)參考資料：

http://www.linuxvirtualserver.org/zh/index.html

LVS 二層負(fù)載均衡機(jī)制

只有LVS實(shí)現(xiàn)了二層負(fù)載均衡
通過LVS的DR模式來實(shí)現(xiàn)的

負(fù)載均衡：LVS 負(fù)載調(diào)度原理,Linux系統(tǒng)運(yùn)維,負(fù)載均衡,lvs,運(yùn)維,云計(jì)算

數(shù)據(jù)包走向原理說明：

客戶端請求數(shù)據(jù)包報(bào)文源地址和目標(biāo)地址：CIP、VIP
負(fù)載均衡將客戶端請求數(shù)據(jù)包報(bào)文的源 MAC 地址改為自己 DIP 的 MAC 地址，目前 MAC 地址改為 RIP 的 MAC 地址，并將這個(gè)數(shù)據(jù)包發(fā)送給后端服務(wù)器

后端服務(wù)器和負(fù)載均衡服務(wù)器只能在一個(gè)局域網(wǎng)內(nèi)，不能跨 VLAN
后端服務(wù)器直接獲取的是客戶端的源IP地址
后端服務(wù)器發(fā)現(xiàn)請求的數(shù)據(jù)包報(bào)文中的目標(biāo)地址的 MAC 是自己，就接收了這個(gè)數(shù)據(jù)包，由于數(shù)據(jù)包的 MAC 地址被修改，因此后端服務(wù)器需要在 lo 網(wǎng)口綁定 VIP，處理完報(bào)文后，將響應(yīng)報(bào)文通過 lo 接口送給eth0網(wǎng)卡直接發(fā)給客戶端，因?yàn)閿?shù)據(jù)包由后端直接返回給客戶端，所以后端服務(wù)器必須綁定公網(wǎng) IP 地址

LVS 三層負(fù)載均衡機(jī)制

只有LVS實(shí)現(xiàn)了三層負(fù)載均衡
是通過LVS的【IP-TUN】模式完成的

負(fù)載均衡：LVS 負(fù)載調(diào)度原理,Linux系統(tǒng)運(yùn)維,負(fù)載均衡,lvs,運(yùn)維,云計(jì)算

數(shù)據(jù)包走向原理說明：

客戶端請求數(shù)據(jù)包報(bào)文源地址和目標(biāo)地址：CIP、VIP
負(fù)載均衡將客戶都請求的數(shù)據(jù)包報(bào)文首部再封裝一層 IP 報(bào)文，將源地址改為 DIP，目標(biāo)地址改為 RIP，并將這個(gè)數(shù)據(jù)包發(fā)送給后端服務(wù)器，這個(gè)模式是可以跨 VLAN 的，三層負(fù)載會導(dǎo)致在后端服務(wù)器中不能直接獲取到客戶端的源 IP 地址
后端服務(wù)器接收到報(bào)文請求后，首先拆開第一層封裝，然后發(fā)現(xiàn)里面還有一層 IP 首部的目標(biāo)地址，是自己 lo 接口上的 VIP 地址，所以會處理請求報(bào)文，并將響應(yīng)報(bào)文通過 lo 接口發(fā)送給 eth0 網(wǎng)卡直接發(fā)送給客戶端

LVS 四層負(fù)載均衡機(jī)制

負(fù)載均衡：LVS 負(fù)載調(diào)度原理,Linux系統(tǒng)運(yùn)維,負(fù)載均衡,lvs,運(yùn)維,云計(jì)算

LVS通過【NAT】模式實(shí)現(xiàn)的

數(shù)據(jù)包走向原理說明：

客戶端請求數(shù)據(jù)包報(bào)文源地址和目標(biāo)地址：CIP、VIP
負(fù)載均衡將客戶端請求數(shù)據(jù)包中的報(bào)文的目標(biāo)地址改成 RIP 地址，并將數(shù)據(jù)包發(fā)給后端服務(wù)器，同樣要求所有的后端服務(wù)器和負(fù)載均衡服務(wù)器只能在一個(gè) VLAN 中
報(bào)文送到后端服務(wù)器后，目標(biāo)服務(wù)器就會響應(yīng)請求，并將響應(yīng)數(shù)據(jù)包返回給負(fù)載均衡服務(wù)器
負(fù)載均衡將響應(yīng)數(shù)據(jù)包的源地址 IP 改成 VIP 地址后發(fā)送給客戶端
負(fù)載均衡服務(wù)器會存在性能瓶頸

LVS 調(diào)度算法

IPVS 在內(nèi)核中的負(fù)載均衡調(diào)度是以連接為粒度的。在 HTTP 協(xié)議（非持久）中，每個(gè)對象從 WEB 服務(wù)器上獲取都需要建立一個(gè) TCP 連接，同一用戶的不同請求會被調(diào)度到不同的服務(wù)器上，所以這種細(xì)粒度的調(diào)度在一定程度上可以避免單個(gè)用戶訪問的突發(fā)性引起服務(wù)器間的負(fù)載不平衡。

在內(nèi)核中的連接調(diào)度算法上，IPVS 已實(shí)現(xiàn)了以下八種調(diào)度算法

輪叫調(diào)度（RR）

輪叫調(diào)度（Round Robin Scheduling）算法就是以輪叫的方式依次將請求調(diào)度不同的服務(wù)器，即每次調(diào)度執(zhí)行i = (i + 1) mod n，并選出第i臺服務(wù)器。算法的優(yōu)點(diǎn)是其簡潔性，它無需記錄當(dāng)前所有連接的狀態(tài)，所以它是一種無狀態(tài)調(diào)度。

適合后端服務(wù)器組處理性能一致（配置相同）
請求間隙較大時(shí)，容易導(dǎo)致分配不均衡

加權(quán)輪叫調(diào)度（WRR）

加權(quán)輪叫調(diào)度（Weighted Round-Robin Scheduling）算法可以解決服務(wù)器間性能不一的情況，它用相應(yīng)的權(quán)值表示服務(wù)器的處理性能，服務(wù)器的缺省權(quán)值為1。假設(shè)服務(wù)器A的權(quán)值為1，B的權(quán)值為2，則表示服務(wù)器B的處理性能是A的兩倍。加權(quán)輪叫調(diào)度算法是按權(quán)值的高低和輪叫方式分配請求到各服務(wù)器。權(quán)值高的服務(wù)器先收到的連接，權(quán)值高的服務(wù)器比權(quán)值低的服務(wù)器處理更多的連接，相同權(quán)值的服務(wù)器處理相同數(shù)目的連接數(shù)。

有三個(gè)服務(wù)器A、B和C分別有權(quán)值4、3和2，則在一個(gè)調(diào)度周期內(nèi)(mod sum(W(Si)))調(diào)度序列為AABABCABC。加權(quán)輪叫調(diào)度算法還是比較簡單和高效
請求間隙較大時(shí)，容易導(dǎo)致分配不均衡

最小連接調(diào)度（LC）

最小連接調(diào)度（Least-Connection Scheduling）算法是把新的連接請求分配到當(dāng)前連接數(shù)最小的服務(wù)器。最小連接調(diào)度是一種動態(tài)調(diào)度算法，它通過服務(wù)器當(dāng)前所活躍的連接數(shù)來估計(jì)服務(wù)器的負(fù)載情況。調(diào)度器需要記錄各個(gè)服務(wù)器已建立連接的數(shù)目，當(dāng)一個(gè)請求被調(diào)度到某臺服務(wù)器，其連接數(shù)加1；當(dāng)連接中止或超時(shí)，其連接數(shù)減一。

在系統(tǒng)實(shí)現(xiàn)時(shí)，我們也引入當(dāng)服務(wù)器的權(quán)值為零時(shí)，表示該服務(wù)器不可用而不被調(diào)度
當(dāng)各個(gè)服務(wù)器有相同的處理性能時(shí)，最小連接調(diào)度算法能把負(fù)載變化大的請求分布平滑到各個(gè)服務(wù)器上，所有處理時(shí)間比較長的請求不可能被發(fā)送到同一臺服務(wù)器上。但是，當(dāng)各個(gè)服務(wù)器的處理能力不同時(shí)，該算法并不理想，因?yàn)門CP連接處理請求后會進(jìn)入TIME_WAIT狀態(tài)，TCP的TIME_WAIT一般為2分鐘，此時(shí)連接還占用服務(wù)器的資源，所以會出現(xiàn)這樣情形，性能高的服務(wù)器已處理所收到的連接，連接處于TIME_WAIT狀態(tài)，而性能低的服務(wù)器已經(jīng)忙于處理所收到的連接，還不斷地收到新的連接請求

加權(quán)最小連接調(diào)度（WLC）

加權(quán)最小連接調(diào)度（Weighted Least-Connection Scheduling）算法是最小連接調(diào)度的超集，各個(gè)服務(wù)器用相應(yīng)的權(quán)值表示其處理性能。服務(wù)器的缺省權(quán)值為1，系統(tǒng)管理員可以動態(tài)地設(shè)置服務(wù)器的權(quán) 值。加權(quán)最小連接調(diào)度在調(diào)度新連接時(shí)盡可能使服務(wù)器的已建立連接數(shù)和其權(quán)值成比例。

基于局部性的最少鏈接調(diào)度（LBLC）

基于局部性的最少鏈接調(diào)度（Locality-Based Least Connections Scheduling，以下簡稱為LBLC）算法是針對請求報(bào)文的目標(biāo)IP地址的負(fù)載均衡調(diào)度，目前主要用于Cache集群系統(tǒng)，因?yàn)樵贑ache集群中客戶請求報(bào)文的目標(biāo)IP地址是變化的。這里假設(shè)任何后端服務(wù)器都可以處理任一請求，算法的設(shè)計(jì)目標(biāo)是在服務(wù)器的負(fù)載基本平衡情況下，將相同目標(biāo)IP地址的請求調(diào)度到同一臺服務(wù)器，來提高各臺服務(wù)器的訪問局部性和主存Cache命中率，從而整個(gè)集群系統(tǒng)的處理能力。

LBLC調(diào)度算法先根據(jù)請求的目標(biāo)IP地址找出該目標(biāo)IP地址最近使用的服務(wù)器，若該服務(wù)器是可用的且沒有超載，將請求發(fā)送到該服務(wù)器；若服務(wù)器不存在，或者該服務(wù)器超載且有服務(wù)器處于其一半的工作負(fù)載，則用“最少鏈接”的原則選出一個(gè)可用的服務(wù)器，將請求發(fā)送到該服務(wù)器

帶復(fù)制的基于局部性最少鏈接調(diào)度（LBLCR）

帶復(fù)制的基于局部性最少鏈接調(diào)度（Locality-Based Least Connections with Replication Scheduling，以下簡稱為LBLCR）算法也是針對目標(biāo)IP地址的負(fù)載均衡，目前主要用于Cache集群系統(tǒng)。它與LBLC算法的不同之處是它要維護(hù)從一個(gè)目標(biāo)IP地址到一組服務(wù)器的映射，而LBLC算法維護(hù)從一個(gè)目標(biāo)IP地址到一臺服務(wù)器的映射。對于一個(gè)“熱門”站點(diǎn)的服務(wù)請求，一臺Cache 服務(wù)器可能會忙不過來處理這些請求。這時(shí)，LBLC調(diào)度算法會從所有的Cache服務(wù)器中按“最小連接”原則選出一臺Cache服務(wù)器，映射該“熱門”站點(diǎn)到這臺Cache服務(wù)器，很快這臺Cache服務(wù)器也會超載，就會重復(fù)上述過程選出新的Cache服務(wù)器。這樣，可能會導(dǎo)致該“熱門”站點(diǎn)的映像會出現(xiàn) 在所有的Cache服務(wù)器上，降低了Cache服務(wù)器的使用效率。LBLCR調(diào)度算法將“熱門”站點(diǎn)映射到一組Cache服務(wù)器（服務(wù)器集合），當(dāng)該“熱門”站點(diǎn)的請求負(fù)載增加時(shí)，會增加集合里的Cache服務(wù)器，來處理不斷增長的負(fù)載；當(dāng)該“熱門”站點(diǎn)的請求負(fù)載降低時(shí)，會減少集合里的Cache服務(wù)器數(shù)目。這樣，該“熱門”站點(diǎn)的映像不太可能出現(xiàn)在所有的Cache服務(wù)器上，從而提供Cache集群系統(tǒng)的使用效率。

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

目標(biāo)地址散列調(diào)度（DH）

目標(biāo)地址散列調(diào)度（Destination Hashing Scheduling）算法也是針對目標(biāo)IP地址的負(fù)載均衡，但它是一種靜態(tài)映射算法，通過一個(gè)散列（Hash）函數(shù)將一個(gè)目標(biāo)IP地址映射到一臺服務(wù)器。

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

源地址散列調(diào)度（SH）

源地址散列調(diào)度（Source Hashing Scheduling）算法正好與目標(biāo)地址散列調(diào)度算法相反，它根據(jù)請求的源IP地址，作為散列鍵（Hash Key）從靜態(tài)分配的散列表找出對應(yīng)的服務(wù)器，若該服務(wù)器是可用的且未超載，將請求發(fā)送到該服務(wù)器，否則返回空。它采用的散列函數(shù)與目標(biāo)地址散列調(diào)度算法的相同。文章來源地址http://www.zghlxwxcb.cn/news/detail-718754.html