王茹 劉銳 呂歡歡

摘要：隨著企業(yè)科研生產(chǎn)的信息化不斷發(fā)展，軟硬件需求不斷增加，如何提高設備利用率，控制作業(yè)進程在不同的服務器上合理分配，變成一個亟待解決的問題。文章通過在實際生產(chǎn)系統(tǒng)中的應用測試，比較分析靜態(tài)負載均衡、動態(tài)負載均衡——最少連接數(shù)、動態(tài)負載均衡——動態(tài)反饋等算法在企業(yè)集群中的實用性，進而提出一套基于Linux專業(yè)應用軟件的可伸縮、高可用的服務器集群動態(tài)反饋機制算法。

關鍵詞：負載均衡;集群;動態(tài)反饋;作業(yè)調(diào)度;LVS

中圖分類號：TN929.52? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）11-0033-03

1 引言

隨著企業(yè)科研生產(chǎn)的信息化不斷發(fā)展，應用軟件數(shù)量增多，硬件設備使用量加大，網(wǎng)絡系統(tǒng)不斷延伸，設備忙閑不均的狀況日益突出。如何提高設備利用率，控制作業(yè)進程在不同的服務器上合理分配，變成一個亟待解決的問題。本文擬通過對某款專業(yè)軟件在單臺服務器上的壓力測試，來直觀地反映負載不均對設備使用率以及用戶體驗的影響，繼而探索企業(yè)集群系統(tǒng)網(wǎng)絡動態(tài)負載均衡算法。

2 專業(yè)應用軟件壓力測試

以某款科研人員常用的專業(yè)軟件E為例，對單臺服務器進行壓力測試。通過向該服務器，同時提交大小相同的一個作業(yè)、兩個作業(yè)以及多個作業(yè)，觀察作業(yè)計算過程中的CPU和內(nèi)存使用情況，并記錄整個作業(yè)的cpu-time（計算時間） 和elapsed-time（經(jīng)歷時間） ，以反映不同的負載情況對生產(chǎn)效率和用戶體驗的影響。

實驗中用到的測試機器硬件配置為8核英特爾Xeon e5-2643處理器，主頻3.30GHz，內(nèi)存32G。實驗中使用的作業(yè)A，數(shù)據(jù)體的大小為1.4M，計算結(jié)果為406M，計算時占用單臺機器的8個CPU核。作業(yè)A來自科研生產(chǎn)實際使用數(shù)據(jù)，它的數(shù)據(jù)大小和計算使用的核數(shù)都是較為普遍的狀況，有很好的參考價值。

圖1分別為提交單個作業(yè)前后，測試服務器的系統(tǒng)狀態(tài)。作業(yè)開始計算后，cpu的使用率迅速攀升至99%以上，并且維持在99%左右，而內(nèi)存的占用率較小，僅使用0.9%左右。

從作業(yè)的日志文件中可以看出（圖2） ，整個作業(yè)的cpu-time為705.35秒（約11分鐘） ，elapsed-time為713.42秒（約12分鐘） 。計算時間和經(jīng)歷時間都在可接受的范圍內(nèi)。

類似地，將兩個相同的作業(yè)A同時提交給服務器，盡管CPU的使用率仍然在99%左右，每個作業(yè)分配到原有的cpu資源只有原來的一半，內(nèi)存使用率相比之前稍高（如圖3） 。而從作業(yè)的日志分析來看，每個作業(yè)都存在著搶奪CPU資源不成功而處于資源的詢問與等待狀態(tài)（如圖4） 。

分別查看兩個作業(yè)的日志文件（圖5） ，兩個作業(yè)的cpu-time分別為4111.06秒（約68分鐘） 和4660.06秒（約78分鐘） ，作業(yè)的elapsed time分別為8105.27秒（約135分鐘） 和8643.46秒（約144分鐘） 。與之前提交單個作業(yè)相比，用戶的等待時間超過12倍。這樣的計算效率，甚至不如將提交的作業(yè)進行排隊，然后依次發(fā)往服務器進行計算。

可想而知，如果作業(yè)更復雜、提交作業(yè)的用戶數(shù)繼續(xù)增多，等待時間將被無限延長，計算時間和經(jīng)歷時間都是不可被接受的。

而這僅是單臺服務器的壓力測試情況，如果放在整個科研生產(chǎn)環(huán)境中，大量服務器，大量的科研人員使用，用戶不知道哪臺服務器被占用，哪臺空閑。只能憑著使用習慣進行作業(yè)提交，這就會造成負載失衡，可能有的機器超負荷運轉(zhuǎn)，而有的機器卻在空閑狀態(tài)，硬件資源無法得到充分的利用。

因此，將服務器構(gòu)造成集群，研究對它的負載均衡算法，對內(nèi)協(xié)調(diào)資源，對外統(tǒng)一提供服務。可以最大化地利用現(xiàn)有的計算資源，為提高科研生產(chǎn)的工作效率做貢獻。

3 服務器集群的負載均衡

負載均衡集群的成敗關鍵在于算法，好的算法可以科學地衡量各個服務器的負載輕重，動態(tài)地平衡整個系統(tǒng)的作業(yè)分配，使得整個系統(tǒng)高質(zhì)高效地完成各類服務請求。負載均衡問題實際上是映射問題，一邊是將要被執(zhí)行的任務，另一邊是負載集群的服務器節(jié)點，每個任務都對應著與它相聯(lián)系的服務器，這種聯(lián)系就是分發(fā)策略。根據(jù)分發(fā)策略，可以在任務和服務器之間建立了一對一或一對多的聯(lián)系（如圖6） 。

靜態(tài)負載均衡是根據(jù)事先確定好的分配策略來進行分發(fā)，不使用集群中實時的負載狀態(tài)來決定作業(yè)分配。而科研生產(chǎn)實際應用中，作業(yè)的性質(zhì)、體量大小、當前服務器狀態(tài)是隨時變化的。因此，通過實時監(jiān)測整個系統(tǒng)的負載狀態(tài)，來進行任務分配，是最貼合應用實際的方法。通過事先預設算法的評價體系，動態(tài)計算系統(tǒng)中對應的每一臺服務器的負載值，衡量哪一臺在當前狀態(tài)下最適合被用來處理任務，從而平滑整個系統(tǒng)的負擔，輸出高效的服務。以此為出發(fā)點，考慮以下動態(tài)負載均衡算法：

（1） 最少連接數(shù)

這種算法是，調(diào)度服務器事先制作作業(yè)統(tǒng)計表，統(tǒng)計該系統(tǒng)中每一臺可以提供服務的設備的作業(yè)連接數(shù)。每當新來一個作業(yè)請求，就對照查找到應用連接數(shù)最少的服務器，并將這個作業(yè)分配給它。此時在調(diào)度服務器的作業(yè)統(tǒng)計表中，為該服務器的作業(yè)數(shù)加1[1]。待該作業(yè)計算完成，不再占用資源時，再次更新作業(yè)統(tǒng)計表，該服務器的作業(yè)數(shù)減1。

該算法適合作業(yè)計算量差距不大且服務器配置接近的應用系統(tǒng)。而實際應用中，應用軟件每次提交的作業(yè)數(shù)據(jù)體量大小不一，設備由于購買批次、種類的不同，處理能力也不盡相同。這就造成可能某一臺服務器目前分配的作業(yè)數(shù)量較少，但是數(shù)據(jù)體量大，系統(tǒng)占用資源多，而調(diào)度服務器只根據(jù)作業(yè)數(shù)來判斷，還是不停地為該臺服務器分配任務，最終導致響應和處理時間被不斷延長。

（2） 動態(tài)反饋負載均衡算法

通過對最少連接數(shù)算法的應用實踐，發(fā)現(xiàn)存在即使服務器負載過重，甚至出現(xiàn)超載情況時，仍有作業(yè)分配的情況?？紤]讓調(diào)度服務器收集集群系統(tǒng)中各設備的實時負載信息以及應答速率，動態(tài)地平衡整個集群系統(tǒng)各服務器之間的作業(yè)處理分配，以提高整個系統(tǒng)的運行效率[2]。

如圖7負載均衡調(diào)度器動態(tài)地收集各服務的內(nèi)存使用率、CPU使用率、作業(yè)數(shù)等負載信息，全面監(jiān)控整個集群系統(tǒng)的負載狀態(tài)。監(jiān)控程序通過動態(tài)反饋負載均衡算法，計算一個在該體系下負載值最低的服務器，并將該作業(yè)請求送達該選中的服務器。每隔一段時間，集群中每一個節(jié)點的負載狀況都會發(fā)生變化。因此，我們需要在每隔一個時間段內(nèi)就重新監(jiān)控負載狀態(tài)，并更新調(diào)度器中記錄的信息，以保證任務分配的準確性[3]。

4 企業(yè)集群動態(tài)反饋負載均衡方法研究

在企業(yè)的科研生產(chǎn)環(huán)境中，不同的軟件在運行時資源占用情況不同。對CPU、內(nèi)存、顯卡以及I/O讀寫、網(wǎng)絡性能需求的側(cè)重點各有不同。科研硬件設備來自不同的廠商，不同的生產(chǎn)年份，以及不同的配置。應用環(huán)境復雜、應用場景多、應用需求各不相同。并且由于各種服務器、工作站的處理能力不同，不同的用戶進行作業(yè)的復雜程度、時間長度也各不相同。通過實驗與應用實踐，在企業(yè)的生產(chǎn)環(huán)境中，使用動態(tài)反饋負載均衡算法，對整個集群系統(tǒng)進行作業(yè)調(diào)度是最合適的方法。

在動態(tài)反饋的算法中，每一次調(diào)度器輪詢?nèi)ゲ檎腋鞴?jié)點的CPU、內(nèi)存、I/O、訪問量等信息，都需要額外使用系統(tǒng)資源，尤其當系統(tǒng)節(jié)點較多時，這些開銷是不可忽視的。因此，不可能一旦有作業(yè)請求，就立刻做一遍資源監(jiān)控。只能按照事先約定好的時間周期，來進行定時的負載查詢。而對于負載查詢周期的設定，也需要根據(jù)應用環(huán)境反復實驗、仔細測量，不能為了降低系統(tǒng)開銷，就延長周期，這樣會導致調(diào)度器信息滯后，而將大量的作業(yè)分配給本已超載的服務器。參考文獻[4]的對這方面的實際測算，將集群負載的查詢間隔設置為1-11s/次是最合適的。為提高調(diào)度器收集信息的效率，可以為每臺服務器配置相應的進程，協(xié)助調(diào)度器收集負載信息。如果調(diào)度器與協(xié)助進程通訊無回應，則調(diào)度器標記該設備不可達，從服務器序列中刪除該臺設備，以防誤分配。待該設備的協(xié)助進程重新與調(diào)度器建立連接，再更新相應的服務器記錄，保證服務器的狀態(tài)始終可達[5]。通過協(xié)助進程反饋的負載信息，調(diào)度器更新記錄，并在每一次作業(yè)送達之時，根據(jù)預設算法，計算出最合適的服務器去完成任務。在進行負載均衡計算時，服務節(jié)點存在異構(gòu)的情況，因此不僅要考慮節(jié)點的負載量，而且也必須要考慮到節(jié)點的處理能力。這樣可以自然地讓性能更強、配置更優(yōu)的設備完成更多的作業(yè)請求，保證資源的物盡其用。

因此，我們將集群中某時刻某臺服務器的處理能力記為S，它主要從這幾個指標考慮：CPU、內(nèi)存、進程數(shù)、I/O速率、網(wǎng)絡能力等，我們分別標記為C、M、P、D、N。根據(jù)應用需要，這些指標可以部分或全部納入計算。同時，我們還可以引入?yún)?shù)k（權(quán)值） ，來標識每一項指標對某一類作業(yè)的決定因素大小。由此，形成當前該服務器對該類作業(yè)的處理能力計算函數(shù)：

比如，對于本文用來做單臺服務器壓力測試的專業(yè)軟件E來說，我們可以這樣調(diào)整參數(shù)k，k={0.35，0.1，0.3，0.15，0.1}，用以強調(diào)節(jié)點的CPU處理能力和最大進程數(shù)對該項服務的重要性。如果經(jīng)實際測試，參數(shù)k的值不能恰當?shù)胤从硲脤Y源的比重需要，應用系統(tǒng)運維人員或業(yè)務人員可以對其不斷修正，直到找到貼近實際情況最優(yōu)的一組解。

類似地，在動態(tài)反饋算法中，我們需要用利用每一個時間周期監(jiān)控的負載信息作為依據(jù)，來計算設備的綜合負載情況，供選擇實際執(zhí)行任務服務器的最優(yōu)解。我們將從調(diào)度服務器和集群實際服務器中獲得的指標，來分別計算，作為負載選擇的信息支持。以服務器上的進程連接數(shù)為例，來說明如何計算服務器的負載估值。計算進程數(shù)占用率是單位時間中，服務器處理的新任務占整個所計算周期中平均任務數(shù)的比。假設在時間T1和T2時，某臺服務器上的連接數(shù)分別為P1和P2。那么在T2-T1的時間內(nèi)，集群中的服務器Si新收到的任務數(shù)為Pi2-Pi1。因此，根據(jù)所取時間間隔數(shù)需要，我們就可以得到n個在T2-T1時間內(nèi)，Si收到的新進程數(shù)Pi2-Pi1，新進程數(shù)占用率可以計算為：

INPUTi=Pi2-Pi1i=1n（Pi2-Pi1）n

除了進程數(shù)的多少，集群中各服務器的CPU使用情況、內(nèi)存使用情況、I/O速率、網(wǎng)絡帶寬能力等，都是該設備負載信息在某一方面的體現(xiàn)，我們分別標記為C、M、D、N，來計算不同的因子對綜合負載情況的影響。類似地，我們還可以引入?yún)?shù)r（權(quán)值） [3]，來標識每一項指標對某一類作業(yè)的決定因素大小。其中[r（ri=1）] ，不同類型的服務器和應用，可根據(jù)需要調(diào)整每一項權(quán)值的系數(shù)大小。因此，某臺服務器的綜合負載L[6]，可以以如下函數(shù)計算得出：

同理，對于本文用來做單臺服務器壓力測試的專業(yè)軟件E，可將參數(shù)設置為r={0.35，0.1，0.3，0.15，0.1}。如果經(jīng)實際測試，參數(shù)r的值不能恰當?shù)胤从硲脤Y源的比重需要，應用系統(tǒng)運維人員或業(yè)務人員可以對其不斷修正，直到找到貼近實際情況，最優(yōu)的一組解。

在實際運行的集群系統(tǒng)中，根據(jù)當前計算出的節(jié)點負載情況排序，選擇負載最輕的服務器來承擔相應的作業(yè)任務。也可以以事先劃分資源池的方式，根據(jù)不同應用的實際需要（如：CPU需求型、內(nèi)存需求型等） ，形成特定用途的集群。每當有作業(yè)請求提交時，先將其分配到資源池，再根據(jù)負載均衡算法計算出最優(yōu)的實際服務器，進而提交作業(yè)任務。

5 結(jié)論

本文結(jié)合企業(yè)現(xiàn)有集群系統(tǒng)的應用現(xiàn)狀，以某款常用應用軟件E為例，對單臺服務器進行壓力測試，當作業(yè)量提高一倍或多倍時，生產(chǎn)效率超倍數(shù)地大幅降低，用戶的等待時長超倍數(shù)增長。因此，本文通過在實際生產(chǎn)系統(tǒng)中的應用測試，比較分析靜態(tài)負載均衡、動態(tài)負載均衡——最少連接數(shù)、動態(tài)負載均衡——動態(tài)反饋等算法在企業(yè)集群中的實用性，進而提出一套基于Linux專業(yè)應用軟件的可伸縮、高可用的服務器集群動態(tài)反饋機制算法。

參考文獻：

[1] 王中丹.完全計算機自動化—批處理程序自動執(zhí)行系統(tǒng)[J].電大理工，2008（4）：39-40.

[2] 周光友，郭慶平，劉鵬，等.一種視頻服務器集群的動態(tài)反饋調(diào)度算法[J].小型微型計算機系統(tǒng)，2009，30（3）：555-559.

[3] 陶勝，倪曉軍，嚴獻科.基于負載增量動態(tài)反饋的動漫渲染機制研究[J].電腦與信息技術，2016，24（6）：4-6.

[4] 陳亮，王加陽.基于粗糙集的負載均衡算法研究[J].計算機工程與科學，2010，32（1）：101-104.

[5] 何濤，李戰(zhàn)懷，劉文潔.均衡負載實時反饋算法的實現(xiàn)[J].微處理機，2009，30（2）：78-81.

[6] 張文昌，夏學知.基于剩余計算能力的動態(tài)負載均衡系統(tǒng)[J].計算機與數(shù)字工程，2010，38（9）：135-139.

收稿日期：2021-12-27

作者簡介：王茹（1988—） ，女，山西絳縣人，中級職稱，研究方向為計算機應用技術;劉銳（1987—） ，山東壽光人，中級工程師，碩士，研究方向為計算機應用技術;呂歡歡（1987—） ，女，廣西玉林人，中級工程師，碩士，研究方向為海洋工程。