LVS系列教程05-負載調(diào)度

目錄

前言

之前我們主要講述了LVS集群中實現(xiàn)的三種 IP 負載均衡技術(shù)，它們主要解決系統(tǒng)的可伸縮性和透明性問題，如何通過負載調(diào)度器將請求高效地分發(fā)到不同的服務(wù)器執(zhí)行，使得由多臺獨立計算機組成的集群系統(tǒng)成為一臺虛擬服務(wù)器；客戶端應(yīng)用程序與集群系統(tǒng)交互時，就像與一臺高性能的服務(wù)器交互一樣。

下來我們將主要講述在負載調(diào)度器上的負載調(diào)度策略和算法，如何將請求流調(diào)度到各臺服務(wù)器，使得各臺服務(wù)器盡可能地保持負載均衡。

• 描述 IP 負載均衡軟件 IPVS 在內(nèi)核中所實現(xiàn)的各種連接調(diào)度算法
• 描述一個動態(tài)反饋負載均衡算法(Dynamic-feedback load balancing)，它結(jié)合內(nèi)核中的加權(quán)連接調(diào)度算法，根據(jù)動態(tài)反饋回來的負載信息來調(diào)整服務(wù)器的權(quán)值，來進一步避免服務(wù)器間的負載不平衡。

在下面描述中，我們稱客戶的socket和服務(wù)器的socket之間的數(shù)據(jù)通訊為連接，無論它們是使用TCP還是UDP協(xié)議。對于UDP數(shù)據(jù)報文的調(diào)度，IPVS調(diào)度器也會為之建立調(diào)度記錄并設(shè)置超時值(如 5 分鐘)；在設(shè)定的時間內(nèi)，來自同一地址(IP 地址和端口)的UDP數(shù)據(jù)包會被調(diào)度到同一臺服務(wù)器。

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

一、內(nèi)核中的連接調(diào)度算法

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

• 輪叫調(diào)度（Round-Robin Scheduling）
• 加權(quán)輪叫調(diào)度（Weighted Round-Robin Scheduling）
• 最小連接調(diào)度（Least-Connection Scheduling）
• 加權(quán)最小連接調(diào)度（Weighted Least-Connection Scheduling）
• 基于局部性的最少鏈接（Locality-Based Least Connections Scheduling）
• 帶復(fù)制的基于局部性最少鏈接（Locality-Based Least Connections with Replication Scheduling）
• 目標地址散列調(diào)度（Destination Hashing Scheduling）
• 源地址散列調(diào)度（Source Hashing Scheduling）
• 最短預(yù)期延時調(diào)度（Shortest Expected Delay Scheduling）
• 不排隊調(diào)度（Never Queue Scheduling）

二、動態(tài)反饋負載均衡算法

動態(tài)反饋負載均衡算法考慮服務(wù)器的實時負載和響應(yīng)情況，不斷調(diào)整服務(wù)器間處理請求的比例，來避免有些服務(wù)器超載時依然收到大量請求，從而提高整個系統(tǒng)的吞吐率。下圖顯示了該算法的工作環(huán)境，在負載調(diào)度器上運行Monitor Daemon進程，Monitor Daemon來監(jiān)視和收集各個服務(wù)器的負載信息。Monitor Daemon可根據(jù)多個負載信息算出一個綜合負載值。Monitor Daemon將各個服務(wù)器的綜合負載值和當前權(quán)值算出一組新的權(quán)值，若新權(quán)值和當前權(quán)值的差值大于設(shè)定的閥值，Monitor Daemon將該服務(wù)器的權(quán)值設(shè)置到內(nèi)核中的IPVS調(diào)度中，而在內(nèi)核中連接調(diào)度一般采用加權(quán)輪叫調(diào)度算法或者加權(quán)最小連接調(diào)度算法。

2.1 連接調(diào)度

當客戶通過TCP連接訪問網(wǎng)絡(luò)訪問時，服務(wù)所需的時間和所要消耗的計算資源是千差萬別的，它依賴于很多因素。例如，它依賴于請求的服務(wù)類型、當前網(wǎng)絡(luò)帶寬的情況、以及當前服務(wù)器資源利用的情況。一些負載比較重的請求需要進行計算密集的查詢、數(shù)據(jù)庫訪問、很長響應(yīng)數(shù)據(jù)流；而負載比較輕的請求往往只需要讀一個HTML頁面或者進行很簡單的計算。

請求處理時間的千差萬別可能會導(dǎo)致服務(wù)器利用的傾斜(Skew)，即服務(wù)器間的負載不平衡。例如，有一個 WEB 頁面有 A、B、C 和 D 文件，其中 D 是大圖像文件，瀏覽器需要建立四個連接來取這些文件。當多個用戶通過瀏覽器同時訪問該頁面時，最極端的情況是所有 D 文件的請求被發(fā)到同一臺服務(wù)器。所以說，有可能存在這樣情況，有些服務(wù)器已經(jīng)超負荷運行，而其他服務(wù)器基本是閑置著。同時，有些服務(wù)器已經(jīng)忙不過來，有很長的請求隊列，還不斷地收到新的請求。反過來說，這會導(dǎo)致客戶長時間的等待，覺得系統(tǒng)的服務(wù)質(zhì)量差。

簡單連接調(diào)度

簡單連接調(diào)度可能會使得服務(wù)器傾斜的發(fā)生。在上面的例子中，若采用輪叫調(diào)度算法，且集群中正好有四臺服務(wù)器，必有一臺服務(wù)器總是收到 D 文件的請求。這種調(diào)度策略會導(dǎo)致整個系統(tǒng)資源的低利用率，因為有些資源被用盡導(dǎo)致客戶的長時間等待，而其他資源空閑著。

實際 TCP/IP 流量的特征

文獻說明網(wǎng)絡(luò)流量是呈波浪型發(fā)生的，在一段較長時間的小流量后，會有一段大流量的訪問，然后是小流量，這樣跟波浪一樣周期性地發(fā)生。文獻揭示在WAN和LAN上網(wǎng)絡(luò)流量存在自相似的特征，在WEB訪問流也存在自相似性。這就需要一個動態(tài)反饋機制，利用服務(wù)器組的狀態(tài)來應(yīng)對訪問流的自相似性。

2.3 動態(tài)反饋負載均衡機制

TCP/IP流量的特征通俗地說是有許多短事務(wù)和一些長事務(wù)組成，而長事務(wù)的工作量在整個工作量占有較高的比例。所以，我們要設(shè)計一種負載均衡算法，來避免長事務(wù)的請求總被分配到一些機器上，而是盡可能將帶有毛刺(Burst)的分布分割成相對較均勻的分布。

我們提出基于動態(tài)反饋負載均衡機制，來控制新連接的分配，從而控制各個服務(wù)器的負載。例如，在IPVS調(diào)度器的內(nèi)核中使用加權(quán)輪叫調(diào)度算法來調(diào)度新的請求連接；在負載調(diào)度器的用戶空間中運行Monitor Daemon。Monitor Daemon定時地監(jiān)視和收集各個服務(wù)器的負載信息，根據(jù)多個負載信息算出一個綜合負載值。Monitor Daemon將各個服務(wù)器的綜合負載值和當前權(quán)值算出一組新的權(quán)值。當綜合負載值表示服務(wù)器比較忙時，新算出的權(quán)值會比其當前權(quán)值要小，這樣新分配到該服務(wù)器的請求數(shù)就會少一些。當綜合負載值表示服務(wù)器處于低利用率時，新算出的權(quán)值會比其當前權(quán)值要大，來增加新分配到該服務(wù)器的請求數(shù)。若新權(quán)值和當前權(quán)值的差值大于設(shè)定的閥值，Monitor Daemon將該服務(wù)器的權(quán)值設(shè)置到內(nèi)核中的 IPVS 調(diào)度中。過了一定的時間間隔(如 2 秒鐘)，Monitor Daemon再查詢各個服務(wù)器的情況，并相應(yīng)調(diào)整服務(wù)器的權(quán)值；這樣周期性地進行?？梢哉f，這是一個負反饋機制，使得服務(wù)器保持較好的利用率。

在加權(quán)輪叫調(diào)度算法中，當服務(wù)器的權(quán)值為零，已建立的連接會繼續(xù)得到該服務(wù)器的服務(wù)，而新的連接不會分配到該服務(wù)器。系統(tǒng)管理員可以將一臺服務(wù)器的權(quán)值設(shè)置為零，使得該服務(wù)器安靜下來，當已有的連接都結(jié)束后，他可以將該服務(wù)器切出，對其進行維護。維護工作對系統(tǒng)都是不可少的，比如硬件升級和軟件更新等，零權(quán)值使得服務(wù)器安靜的功能很主要。所以，在動態(tài)反饋負載均衡機制中我們要保證該功能，當服務(wù)器的權(quán)值為零時，我們不對服務(wù)器的權(quán)值進行調(diào)整。

2.4 綜合負載

在計算綜合負載時，我們主要使用兩大類負載信息：輸入指標和服務(wù)器指標。輸入指標是在調(diào)度器上收集到的，而服務(wù)器指標是在服務(wù)器上的各種負載信息。我們用綜合負載來反映服務(wù)器當前的比較確切負載情況，對于不同的應(yīng)用，會有不同的負載情況，這里我們引入各個負載信息的系數(shù)，來表示各個負載信息在綜合負載中輕重。系統(tǒng)管理員根據(jù)不同應(yīng)用的需求，調(diào)整各個負載信息的系數(shù)。另外，系統(tǒng)管理員設(shè)置收集負載信息的時間間隔。

輸入指標主要是在單位時間內(nèi)服務(wù)器收到新連接數(shù)與平均連接數(shù)的比例，它是在調(diào)度器上收集到的，所以這個指標是對服務(wù)器負載情況的一個估計值。在調(diào)度器上有各個服務(wù)器收到連接數(shù)的計數(shù)器，對于服務(wù)器 Si，可以得到分別在時間T1和T2時的計數(shù)器值Ci1和Ci2，計算出在時間間隔T2-T1內(nèi)服務(wù)器 Si 收到新連接數(shù)Ni = Ci2 - Ci1。這樣，得到一組服務(wù)器在時間間隔T2-T1內(nèi)服務(wù)器Si收到新連接數(shù){Ni}，服務(wù)器Si的輸入指標INPUTi為其新連接數(shù)與n臺服務(wù)器收到平均連接數(shù)的比值，其公式為

服務(wù)器指標主要記錄服務(wù)器各種負載信息，如服務(wù)器當前CPU負載LOADi、服務(wù)器當前磁盤使用情況Di、當前內(nèi)存利用情況Mi和當前進程數(shù)目 Pi。有兩種方法可以獲得這些信息；一是在所有的服務(wù)器上運行著SNMP(Simple Network Management Protocol)服務(wù)進程，而在調(diào)度器上的Monitor Daemon通過SNMP向各個服務(wù)器查詢獲得這些信息；二是在服務(wù)器上實現(xiàn)和運行收集信息的Agent，由Agent定時地向Monitor Daemon報告負載信息。若服務(wù)器在設(shè)定的時間間隔內(nèi)沒有響應(yīng)，Monitor Daemon認為服務(wù)器是不可達的，將服務(wù)器在調(diào)度器中的權(quán)值設(shè)置為零，不會有新的連接再被分配到該服務(wù)器；若在下一次服務(wù)器有響應(yīng)，再對服務(wù)器的權(quán)值進行調(diào)整。再對這些數(shù)據(jù)進行處理，使其落在[0, ∞)的區(qū)間內(nèi)，1 表示負載正好，大于 1 表示服務(wù)器超載，小于 1 表示服務(wù)器處于低負載狀態(tài)。獲得調(diào)整后的數(shù)據(jù)有DISKi、MEMORYi和 PROCESSi。

另一個重要的服務(wù)器指標是服務(wù)器所提供服務(wù)的響應(yīng)時間，它能比較好地反映服務(wù)器上請求等待隊列的長度和請求的處理時間。調(diào)度器上的Monitor Daemon作為客戶訪問服務(wù)器所提供的服務(wù)，測得其響應(yīng)時間。例如，測試從WEB服務(wù)器取一個HTML頁面的響應(yīng)延時，Monitor Daemon只要發(fā)送一個“GET /”請求到每個服務(wù)器，然后記錄響應(yīng)時間。若服務(wù)器在設(shè)定的時間間隔內(nèi)沒有響應(yīng)，Monitor Daemon認為服務(wù)器是不可達的，將服務(wù)器在調(diào)度器中的權(quán)值設(shè)置為零。同樣，我們對響應(yīng)時間進行如上調(diào)整，得到RESPONSEi。

這里，我們引入一組可以動態(tài)調(diào)整的系數(shù) Ri 來表示各個負載參數(shù)的重要程度，其中ΣRi = 1。綜合負載可以通過以下公式計算出：

例如，在 WEB 服務(wù)器集群中，我們采用以下系數(shù){0.1, 0.3, 0.1, 0.1, 0.1, 0.3}，認為服務(wù)器的CPU負載和請求響應(yīng)時間較其他參數(shù)重要一些。若當前的系數(shù) Ri 不能很好地反映應(yīng)用的負載，系統(tǒng)管理員可以對系數(shù)不斷地修正，直到找到貼近當前應(yīng)用的一組系數(shù)。

另外，關(guān)于查詢時間間隔的設(shè)置，雖然很短的間隔可以更確切地反映各個服務(wù)器的負載，但是很頻繁地查詢（如 1 秒鐘幾次）會給調(diào)度器和服務(wù)器帶來一定的負載，如頻繁執(zhí)行的Monitor Daemon在調(diào)度器會有一定的開銷，同樣頻繁地查詢服務(wù)器指標會服務(wù)器帶來一定的開銷。所以，這里要有個折衷(Tradeoff)，我們一般建議將時間間隔設(shè)置在 5 到 20 秒之間。

2.5 權(quán)值計算

當服務(wù)器投入集群系統(tǒng)中使用時，系統(tǒng)管理員對服務(wù)器都設(shè)定一個初始權(quán)值DEFAULT_WEIGHTi，在內(nèi)核的 IPVS 調(diào)度中也先使用這個權(quán)值。然后，隨著服務(wù)器負載的變化，對權(quán)值進行調(diào)整。為了避免權(quán)值變成一個很大的值，我們對權(quán)值的范圍作一個限制[DEFAULT_WEIGHTi, SCALE*DEFAULT_WEIGHTi]，SCALE是可以調(diào)整的，它的缺省值為 10。

Monitor Daemon周期性地運行，若DEFAULT_WEIGHTi不為零，則查詢該服務(wù)器的各負載參數(shù)，并計算出綜合負載值A(chǔ)GGREGATE_LOADi。我們引入以下權(quán)值計算公式，根據(jù)服務(wù)器的綜合負載值調(diào)整其權(quán)值。

在公式中，0.95是我們想要達到的系統(tǒng)利用率，A 是一個可調(diào)整的系數(shù)（缺省值為 5）。當綜合負載值為0.95時，服務(wù)器權(quán)值不變；當綜合負載值大于0.95時，權(quán)值變?。划斁C合負載值小于0.95時，權(quán)值變大。若新權(quán)值大于SCALEDEFAULT_WEIGHTi，我們將新權(quán)值設(shè)為 SCALEDEFAULT_WEIGHTi。若新權(quán)值與當前權(quán)值的差異超過設(shè)定的閥值，則將新權(quán)值設(shè)置到內(nèi)核中的IPVS調(diào)度參數(shù)中，否則避免打斷 IPVS調(diào)度的開銷。我們可以看出這是一個負反饋公式，會使得權(quán)值調(diào)整到一個穩(wěn)定點，如系統(tǒng)達到理想利用率時，權(quán)值是不變的。

在實際使用中，若發(fā)現(xiàn)所有服務(wù)器的權(quán)值都小于他們的DEFAULT_WEIGHT，則說明整個服務(wù)器集群處于超載狀態(tài)，這時需要加入新的服務(wù)器結(jié)點到集群中來處理部分負載；反之，若所有服務(wù)器的權(quán)值都接近于SCALE*DEFAULT_WEIGHT，則說明當前系統(tǒng)的負載都比較輕。

文章作者: Escape 

鏈接: https://escapelife.github.io/posts/dfa2286f.html

關(guān)注「開源Linux」加星標，提升IT技能