資料介紹
本質上講,網絡負載平衡是分布式作業調度系統的一種實現。平衡器作為網絡請求分配的控制者,要根據集群節點的當前處理能力,采用集中或分布策略對網絡服務請求進行調配,并且在每個服務請求的生命周期里監控各個節點的有效狀態。一般的說,平衡器對請求的調度具備以下的特征:
網絡服務請求必須是可管理的
請求的分配對用戶是透明的
最好能夠提供異構系統的支持
能夠依據集群節點的資源情況進行動態分配和調整
負載平衡器在集群的各個服務節點中分配工作負載或網絡流量。可以靜態預先設置或根據當前的網絡狀態來決定負載分發到哪個特定的節點,節點在集群內部可以互相連接,但它們必須與平衡器直接或間接相連。
網絡平衡器可以認為是網絡層次上的作業調度系統,大多數網絡負載平衡器能夠在網絡的相應層次上實現單一系統映像,整個集群能夠體現為一個單一的IP地址被用戶訪問,而具體服務的節點對用戶而言是透明的。這里,平衡器可靜態或動態配置,用一種或多種算法決定哪個節點獲得下一個網絡服務請求。
2.網絡平衡原理
在TCP/IP協議中,數據包含有必要的網絡信息,因而在網絡緩存或網絡平衡的具體實現算法里,數據包的信息很重要。但由于數據包是面向分組的(IP)和面向連接的(TCP),且經常被分片,沒有與應用有關的完整信息,特別是和連接會話相關的狀態信息。因此必須從連接的角度看待數據包——從源地址的端口建立到目的地址端口的連接。
平衡考慮的另一個要素就是節點的資源使用狀態。由于負載平衡是這類系統的最終目的,那么及時、準確的把握節點負載狀況,并根據各個節點當前的資源使用狀態動態調整負載平衡的任務分布,是網絡動態負載平衡集群系統考慮的另一關鍵問題。
一般情況下,集群的服務節點可以提供諸如處理器負載,應用系統負載、活躍用戶數、可用的網絡協議緩存以及其他的資源信息。信息通過高效的消息機制傳給平衡器,平衡器監視所有處理節點的狀態,主動決定下個任務傳給誰。平衡器可以是單個設備,也可以使一組平行或樹狀分布的設備。
3.基本的網絡負載平衡算法
平衡算法設計的好壞直接決定了集群在負載均衡上的表現,設計不好的算法,會導致集群的負載失衡。一般的平衡算法主要任務是決定如何選擇下一個集群節點,然后將新的服務請求轉發給它。有些簡單平衡方法可以獨立使用,有些必須和其它簡單或高級方法組合使用。而一個好的負載均衡算法也并不是萬能的,它一般只在某些特殊的應用環境下才能發揮最大效用。因此在考察負載均衡算法的同時,也要注意算法本身的適用面,并在采取集群部署的時候根據集群自身的特點進行綜合考慮,把不同的算法和技術結合起來使用。
3.1 輪轉法:
輪轉算法是所有調度算法中最簡單也最容易實現的一種方法。在一個任務隊列里,隊列的每個成員(節點)都具有相同的地位,輪轉法簡單的在這組成員中順序輪轉選擇。在負載平衡環境中,均衡器將新的請求輪流發給節點隊列中的下一節點,如此連續、周而復始,每個集群的節點都在相等的地位下被輪流選擇。這個算法在DNS域名輪詢中被廣泛使用。
輪轉法的活動是可預知的,每個節點被選擇的機會是1/N,因此很容易計算出節點的負載分布。輪轉法典型的適用于集群中所有節點的處理能力和性能均相同的情況,在實際應用中,一般將它與其他簡單方法聯合使用時比較有效。
3.2 散列法
散列法也叫哈希法(HASH),通過單射不可逆的HASH函數,按照某種規則將網絡請求發往集群節點。哈希法在其他幾類平衡算法不是很有效時會顯示出特別的威力。例如,在前面提到的UDP會話的情況下,由于輪轉法和其他幾類基于連接信息的算法,無法識別出會話的起止標記,會引起應用混亂。
而采取基于數據包源地址的哈希映射可以在一定程度上解決這個問題:將具有相同源地址的數據包發給同一服務器節點,這使得基于高層會話的事務可以以適當的方式運行。相對稱的是,基于目的地址的哈希調度算法可以用在Web Cache集群中,指向同一個目標站點的訪問請求都被負載平衡器發送到同一個Cache服務節點上,以避免頁面缺失而帶來的更新Cache問題。
3.3 最少連接法
在最少連接法中,平衡器紀錄目前所有活躍連接,把下一個新的請求發給當前含有最少連接數的節點。這種算法針對TCP連接進行,但由于不同應用對系統資源的消耗可能差異很大,而連接數無法反映出真實的應用負載,因此在使用重型Web服務器作為集群節點服務時(例如Apache服務器),該算法在平衡負載的效果上要打個折扣。為了減少這個不利的影響,可以對每個節點設置最大的連接數上限(通過閾值設定體現)。
3.4 最低缺失法
在最低缺失法中,平衡器長期紀錄到各節點的請求情況,把下個請求發給歷史上處理請求最少的節點。與最少連接法不同的是,最低缺失記錄過去的連接數而不是當前的連接數。
3.5 最快響應法
平衡器記錄自身到每一個集群節點的網絡響應時間,并將下一個到達的連接請求分配給響應時間最短的節點,這種方法要求使用ICMP包或基于UDP包的專用技術來主動探測各節點。
在大多數基于LAN的集群中,最快響應算法工作的并不是很好,因為LAN中的ICMP包基本上都在10ms內完成回應,體現不出節點之間的差異;如果在 WAN上進行平衡的話,響應時間對于用戶就近選擇服務器而言還是具有現實意義的;而且集群的拓撲越分散這種方法越能體現出效果來。這種方法是高級平衡基于拓撲結構重定向用到的主要方法。
3.6 加權法
加權方法只能與其他方法合用,是它們的一個很好的補充。加權算法根據節點的優先級或當前的負載狀況(即權值)來構成負載平衡的多優先級隊列,隊列中的每個等待處理的連接都具有相同處理等級,這樣在同一個隊列里可以按照前面的輪轉法或者最少連接法進行均衡,而隊列之間按照優先級的先后順序進行均衡處理。在這里權值是基于各節點能力的一個估計值。
4、動態反饋負載均衡
當客戶訪問集群資源時,提交的任務所需的時間和所要消耗的計算資源是千差萬別的,它依賴于很多因素。例如:任務請求的服務類型、當前網絡帶寬的情況、以及當前服務器資源利用的情況等等。一些負載比較重的任務需要進行計算密集的查詢、數據庫訪問、很長響應數據流;而負載比較輕的任務請求往往只需要讀一個小文件或者進行很簡單的計算。
對任務請求處理時間的不同可能會導致處理結點利用率的傾斜(Skew),即處理結點的負載不平衡。有可能存在這樣情況,有些結點已經超負荷運行,而其他結點基本是閑置著。同時,有些結點已經忙不過來,有很長的請求隊列,還不斷地收到新的請求。反過來說,這會導致客戶長時間的等待,而集群整體的服務質量下降。因此,有必要采用一種機制,使得平衡器能夠實時地了解各個結點的負載狀況,并能根據負載的變化做出調整。
具體的做法上采用了基于負反饋機制的動態負載均衡算法,該算法考慮每一個結點的實時負載和響應能力,不斷調整任務分布的比例,來避免有些結點超載時依然收到大量請求,從而提高單一集群的整體吞吐率。
在集群內,負載均衡器上運行服務端監控進程,監控進程負責監視和收集集群內各個結點的負載信息;而每個結點上運行客戶端進程,負責定時向均衡器報告自身的負載狀況。監控進程根據收到的全部結點的負載信息來進行同步操作,既對將要分配的任務按照權值得比例重新進行分布。權值得計算主要根據各個結點的CPU 利用率、可用內存以及磁盤I/O狀況計算出新的權值,若新權值和當前權值的差值大于設定的閥值,監控器采用新的權值對集群范圍內的任務重新進行分布,直到下一次的負載信息同步到來之前。均衡器可以配合動態權值,采用加權輪詢算法來對接受的網絡服務請求進行調度。
4.1 加權輪詢調度
加權輪詢調度(Weighted Round-Robin Scheduling)算法用相應的權值表示結點的處理性能。該算法根據權值的高低順序并按照輪詢的方式將任務請求分配到各結點。權值高的結點比權值低的結點處理更多的任務請求,相同權值的結點處理相同份額的請求。加權輪詢的基本原理可描述為:
假設某集群內有一組結點N = {N0, N1, …, Nn-1},W(Ni)表示結點Ni的權值,
一個指示變量i表示上一次選擇的服務器,T(Ni)表示結點Ni當前所分配的任務量。
∑T(Ni) 表示當前同步周期需要處理的任務總量。
∑W(Ni) 表示結點的權值總和。
則: W(Ni)/ ∑W(Ni)= T(Ni)/ ∑T(Ni)
表示任務的分配是按照各個結點權值占權值總數的比例來進行分配。
4.2 權值計算
當集群的結點初次投入系統中使用時,系統管理員根據結點的硬件配置情況對每個結點都設定一個初始權值DW(Ni)(通常根據結點的硬件配置來定義,硬件配置越高的結點默認值越高),在負載均衡器上也先使用這個權值。然后,隨著結點負載的變化,均衡器對權值進行調整。
動態權值是由結點運行時各方面的參數計算出來的。我們在實驗中選取了最重要幾項,包括:CPU資源,內存資源,當前進程數,響應時間等信息作為計算公式的因子。結合每個結點當前的權值,可以計算出新的權值的大小。動態權值目的是要正確反映結點負載的狀況,以預測結點將來可能的負載變化。對于不同類型的系統應用,各個參數的重要程度也有所不同。典型的Web應用環境下,可用內存資源和響應時間就非常重要;如果用戶以長的數據庫事務為主,則CPU使用率和可用內存就相對重要一些。為了方便在系統運行過程中針對不同的應用對各個參數的比例進行適當調整,我們為每一個參數設定一個常量系數 Ri ,用來來表示各個負載參數的重要程度,其中Σ Ri = 1。因此,任何一個結點Ni的權值公式就可以描述為:
LOAD(Ni)=R1*Lcpu(Ni)+R2*Lmemory(Ni)+R3*Lio(Ni)+R4*Lprocess(Ni)+R5*Lresponse(Ni)
其中Lf(Ni) 表示結點Ni 當前某一項參數的負載值,
上述公式中依次表示為:CPU使用率、內存使用率、
磁盤I/O訪問率、進程總數以及響應時間。
例如,在WEB服務器集群中,我們采用以系數{0.1, 0.4, 0.1, 0.1, 0.3},這里認為服務器的內存和請求響應時間較其他參數重要一些。若當前的系數Ri不能很好地反映應用的負載,系統管理員可以對系數不斷地修正,直到找到貼近當前應用的一組系數。
另外,關于采集權值的周期置,雖然很短的周期可以更確切地反映各個結點的負載,但是很頻繁地采集(如1秒1次或者多次)會給均衡器和結點帶來負擔,也可能增加不必要的網絡負荷。另外,由于采集器是在采集時刻進行負載計算的,經實驗證明,均衡器反映出來各個結點的負載信息會出現劇烈的抖動,均衡器無法準確捕捉結點真實的負載變化趨勢。因此解決這些問題,一方面要適當地調整采集負載信息的周期,一般在5~10秒;另一方面,可以使用移動平均線或者是滑動窗口來避免抖動,使得均衡器收集到的負載信息表現為平滑曲線,這樣在負反饋機制的調整效果上就會比較好。
均衡器的動態權值采集程序周期性地運行,若缺省權值不為零,則查詢該結點的各負載參數,并計算出動態權值LOAD(Ni) 。我們引入以下權值計算公式,結合結點的初始權值和采集的動態權值來計算最終的權值結果。
Wi = A*DW(Ni)+B*(LOAD(Ni)-DW(Ni))1/3
在公式中,如果動態權值恰好等于初始權值,最終權值不變,則說明系統的負載狀況剛好達到理想狀況,等于初始權值DW(Ni)。如果動態權值計算結果高于初始權值,最終權值變高,則說明系統負載很輕,均衡器將會增加分配給該結點的任務比率。如果動態權值低于初始權值,最終權值變低,說明系統開始處于重載狀況,均衡器將會減少對該結點分配的任務。在實際使用中,若發現所有結點的權值都小于他們的DW(Ni),則說明當前個集群處于超載狀態,這時需要加入新的結點到集群中來處理部分負載;反之,若所有結點的權值大大高于DW(Ni),則說明當前系統的負載都比較輕。
5、總結
網絡負載平衡是集群作業調度系統的具體實現。由于其處理的作業單元是TCP/IP協議下的網絡連接,因此可以采用面向網絡連接的集中基本調度算法。考慮集群負載不平衡的可能,采取了動態獲取服務節點的權值并使用負反饋機制調整平衡器對網絡服務請求的分布,以適應服務節點在運行過程中資源的變化。筆者也在 LVS集群系統的基礎上,配合原有的輪詢算法對其進行改進,增加了采集動態權值的程序并實時反饋到負載平衡器的調度系統上。實踐證明,采用動態平衡在集群系統的整體吞吐量方面有所提高,特別是在集群各個節點性能不一,集群提供的網絡服務程序所訪問的資源多樣化的情況下,負反饋機制的效果尤其明顯。在其他類型的集群中,負反饋機制的動態負載平衡也能夠得到很好的應用,只是平衡器所處理的作業單元不同于網絡連接,而具體的負載算法上也將有所不同。
?
網絡服務請求必須是可管理的
請求的分配對用戶是透明的
最好能夠提供異構系統的支持
能夠依據集群節點的資源情況進行動態分配和調整
負載平衡器在集群的各個服務節點中分配工作負載或網絡流量。可以靜態預先設置或根據當前的網絡狀態來決定負載分發到哪個特定的節點,節點在集群內部可以互相連接,但它們必須與平衡器直接或間接相連。
網絡平衡器可以認為是網絡層次上的作業調度系統,大多數網絡負載平衡器能夠在網絡的相應層次上實現單一系統映像,整個集群能夠體現為一個單一的IP地址被用戶訪問,而具體服務的節點對用戶而言是透明的。這里,平衡器可靜態或動態配置,用一種或多種算法決定哪個節點獲得下一個網絡服務請求。
2.網絡平衡原理
在TCP/IP協議中,數據包含有必要的網絡信息,因而在網絡緩存或網絡平衡的具體實現算法里,數據包的信息很重要。但由于數據包是面向分組的(IP)和面向連接的(TCP),且經常被分片,沒有與應用有關的完整信息,特別是和連接會話相關的狀態信息。因此必須從連接的角度看待數據包——從源地址的端口建立到目的地址端口的連接。
平衡考慮的另一個要素就是節點的資源使用狀態。由于負載平衡是這類系統的最終目的,那么及時、準確的把握節點負載狀況,并根據各個節點當前的資源使用狀態動態調整負載平衡的任務分布,是網絡動態負載平衡集群系統考慮的另一關鍵問題。
一般情況下,集群的服務節點可以提供諸如處理器負載,應用系統負載、活躍用戶數、可用的網絡協議緩存以及其他的資源信息。信息通過高效的消息機制傳給平衡器,平衡器監視所有處理節點的狀態,主動決定下個任務傳給誰。平衡器可以是單個設備,也可以使一組平行或樹狀分布的設備。
3.基本的網絡負載平衡算法
平衡算法設計的好壞直接決定了集群在負載均衡上的表現,設計不好的算法,會導致集群的負載失衡。一般的平衡算法主要任務是決定如何選擇下一個集群節點,然后將新的服務請求轉發給它。有些簡單平衡方法可以獨立使用,有些必須和其它簡單或高級方法組合使用。而一個好的負載均衡算法也并不是萬能的,它一般只在某些特殊的應用環境下才能發揮最大效用。因此在考察負載均衡算法的同時,也要注意算法本身的適用面,并在采取集群部署的時候根據集群自身的特點進行綜合考慮,把不同的算法和技術結合起來使用。
3.1 輪轉法:
輪轉算法是所有調度算法中最簡單也最容易實現的一種方法。在一個任務隊列里,隊列的每個成員(節點)都具有相同的地位,輪轉法簡單的在這組成員中順序輪轉選擇。在負載平衡環境中,均衡器將新的請求輪流發給節點隊列中的下一節點,如此連續、周而復始,每個集群的節點都在相等的地位下被輪流選擇。這個算法在DNS域名輪詢中被廣泛使用。
輪轉法的活動是可預知的,每個節點被選擇的機會是1/N,因此很容易計算出節點的負載分布。輪轉法典型的適用于集群中所有節點的處理能力和性能均相同的情況,在實際應用中,一般將它與其他簡單方法聯合使用時比較有效。
3.2 散列法
散列法也叫哈希法(HASH),通過單射不可逆的HASH函數,按照某種規則將網絡請求發往集群節點。哈希法在其他幾類平衡算法不是很有效時會顯示出特別的威力。例如,在前面提到的UDP會話的情況下,由于輪轉法和其他幾類基于連接信息的算法,無法識別出會話的起止標記,會引起應用混亂。
而采取基于數據包源地址的哈希映射可以在一定程度上解決這個問題:將具有相同源地址的數據包發給同一服務器節點,這使得基于高層會話的事務可以以適當的方式運行。相對稱的是,基于目的地址的哈希調度算法可以用在Web Cache集群中,指向同一個目標站點的訪問請求都被負載平衡器發送到同一個Cache服務節點上,以避免頁面缺失而帶來的更新Cache問題。
3.3 最少連接法
在最少連接法中,平衡器紀錄目前所有活躍連接,把下一個新的請求發給當前含有最少連接數的節點。這種算法針對TCP連接進行,但由于不同應用對系統資源的消耗可能差異很大,而連接數無法反映出真實的應用負載,因此在使用重型Web服務器作為集群節點服務時(例如Apache服務器),該算法在平衡負載的效果上要打個折扣。為了減少這個不利的影響,可以對每個節點設置最大的連接數上限(通過閾值設定體現)。
3.4 最低缺失法
在最低缺失法中,平衡器長期紀錄到各節點的請求情況,把下個請求發給歷史上處理請求最少的節點。與最少連接法不同的是,最低缺失記錄過去的連接數而不是當前的連接數。
3.5 最快響應法
平衡器記錄自身到每一個集群節點的網絡響應時間,并將下一個到達的連接請求分配給響應時間最短的節點,這種方法要求使用ICMP包或基于UDP包的專用技術來主動探測各節點。
在大多數基于LAN的集群中,最快響應算法工作的并不是很好,因為LAN中的ICMP包基本上都在10ms內完成回應,體現不出節點之間的差異;如果在 WAN上進行平衡的話,響應時間對于用戶就近選擇服務器而言還是具有現實意義的;而且集群的拓撲越分散這種方法越能體現出效果來。這種方法是高級平衡基于拓撲結構重定向用到的主要方法。
3.6 加權法
加權方法只能與其他方法合用,是它們的一個很好的補充。加權算法根據節點的優先級或當前的負載狀況(即權值)來構成負載平衡的多優先級隊列,隊列中的每個等待處理的連接都具有相同處理等級,這樣在同一個隊列里可以按照前面的輪轉法或者最少連接法進行均衡,而隊列之間按照優先級的先后順序進行均衡處理。在這里權值是基于各節點能力的一個估計值。
4、動態反饋負載均衡
當客戶訪問集群資源時,提交的任務所需的時間和所要消耗的計算資源是千差萬別的,它依賴于很多因素。例如:任務請求的服務類型、當前網絡帶寬的情況、以及當前服務器資源利用的情況等等。一些負載比較重的任務需要進行計算密集的查詢、數據庫訪問、很長響應數據流;而負載比較輕的任務請求往往只需要讀一個小文件或者進行很簡單的計算。
對任務請求處理時間的不同可能會導致處理結點利用率的傾斜(Skew),即處理結點的負載不平衡。有可能存在這樣情況,有些結點已經超負荷運行,而其他結點基本是閑置著。同時,有些結點已經忙不過來,有很長的請求隊列,還不斷地收到新的請求。反過來說,這會導致客戶長時間的等待,而集群整體的服務質量下降。因此,有必要采用一種機制,使得平衡器能夠實時地了解各個結點的負載狀況,并能根據負載的變化做出調整。
具體的做法上采用了基于負反饋機制的動態負載均衡算法,該算法考慮每一個結點的實時負載和響應能力,不斷調整任務分布的比例,來避免有些結點超載時依然收到大量請求,從而提高單一集群的整體吞吐率。
在集群內,負載均衡器上運行服務端監控進程,監控進程負責監視和收集集群內各個結點的負載信息;而每個結點上運行客戶端進程,負責定時向均衡器報告自身的負載狀況。監控進程根據收到的全部結點的負載信息來進行同步操作,既對將要分配的任務按照權值得比例重新進行分布。權值得計算主要根據各個結點的CPU 利用率、可用內存以及磁盤I/O狀況計算出新的權值,若新權值和當前權值的差值大于設定的閥值,監控器采用新的權值對集群范圍內的任務重新進行分布,直到下一次的負載信息同步到來之前。均衡器可以配合動態權值,采用加權輪詢算法來對接受的網絡服務請求進行調度。
4.1 加權輪詢調度
加權輪詢調度(Weighted Round-Robin Scheduling)算法用相應的權值表示結點的處理性能。該算法根據權值的高低順序并按照輪詢的方式將任務請求分配到各結點。權值高的結點比權值低的結點處理更多的任務請求,相同權值的結點處理相同份額的請求。加權輪詢的基本原理可描述為:
假設某集群內有一組結點N = {N0, N1, …, Nn-1},W(Ni)表示結點Ni的權值,
一個指示變量i表示上一次選擇的服務器,T(Ni)表示結點Ni當前所分配的任務量。
∑T(Ni) 表示當前同步周期需要處理的任務總量。
∑W(Ni) 表示結點的權值總和。
則: W(Ni)/ ∑W(Ni)= T(Ni)/ ∑T(Ni)
表示任務的分配是按照各個結點權值占權值總數的比例來進行分配。
4.2 權值計算
當集群的結點初次投入系統中使用時,系統管理員根據結點的硬件配置情況對每個結點都設定一個初始權值DW(Ni)(通常根據結點的硬件配置來定義,硬件配置越高的結點默認值越高),在負載均衡器上也先使用這個權值。然后,隨著結點負載的變化,均衡器對權值進行調整。
動態權值是由結點運行時各方面的參數計算出來的。我們在實驗中選取了最重要幾項,包括:CPU資源,內存資源,當前進程數,響應時間等信息作為計算公式的因子。結合每個結點當前的權值,可以計算出新的權值的大小。動態權值目的是要正確反映結點負載的狀況,以預測結點將來可能的負載變化。對于不同類型的系統應用,各個參數的重要程度也有所不同。典型的Web應用環境下,可用內存資源和響應時間就非常重要;如果用戶以長的數據庫事務為主,則CPU使用率和可用內存就相對重要一些。為了方便在系統運行過程中針對不同的應用對各個參數的比例進行適當調整,我們為每一個參數設定一個常量系數 Ri ,用來來表示各個負載參數的重要程度,其中Σ Ri = 1。因此,任何一個結點Ni的權值公式就可以描述為:
LOAD(Ni)=R1*Lcpu(Ni)+R2*Lmemory(Ni)+R3*Lio(Ni)+R4*Lprocess(Ni)+R5*Lresponse(Ni)
其中Lf(Ni) 表示結點Ni 當前某一項參數的負載值,
上述公式中依次表示為:CPU使用率、內存使用率、
磁盤I/O訪問率、進程總數以及響應時間。
例如,在WEB服務器集群中,我們采用以系數{0.1, 0.4, 0.1, 0.1, 0.3},這里認為服務器的內存和請求響應時間較其他參數重要一些。若當前的系數Ri不能很好地反映應用的負載,系統管理員可以對系數不斷地修正,直到找到貼近當前應用的一組系數。
另外,關于采集權值的周期置,雖然很短的周期可以更確切地反映各個結點的負載,但是很頻繁地采集(如1秒1次或者多次)會給均衡器和結點帶來負擔,也可能增加不必要的網絡負荷。另外,由于采集器是在采集時刻進行負載計算的,經實驗證明,均衡器反映出來各個結點的負載信息會出現劇烈的抖動,均衡器無法準確捕捉結點真實的負載變化趨勢。因此解決這些問題,一方面要適當地調整采集負載信息的周期,一般在5~10秒;另一方面,可以使用移動平均線或者是滑動窗口來避免抖動,使得均衡器收集到的負載信息表現為平滑曲線,這樣在負反饋機制的調整效果上就會比較好。
均衡器的動態權值采集程序周期性地運行,若缺省權值不為零,則查詢該結點的各負載參數,并計算出動態權值LOAD(Ni) 。我們引入以下權值計算公式,結合結點的初始權值和采集的動態權值來計算最終的權值結果。
Wi = A*DW(Ni)+B*(LOAD(Ni)-DW(Ni))1/3
在公式中,如果動態權值恰好等于初始權值,最終權值不變,則說明系統的負載狀況剛好達到理想狀況,等于初始權值DW(Ni)。如果動態權值計算結果高于初始權值,最終權值變高,則說明系統負載很輕,均衡器將會增加分配給該結點的任務比率。如果動態權值低于初始權值,最終權值變低,說明系統開始處于重載狀況,均衡器將會減少對該結點分配的任務。在實際使用中,若發現所有結點的權值都小于他們的DW(Ni),則說明當前個集群處于超載狀態,這時需要加入新的結點到集群中來處理部分負載;反之,若所有結點的權值大大高于DW(Ni),則說明當前系統的負載都比較輕。
5、總結
網絡負載平衡是集群作業調度系統的具體實現。由于其處理的作業單元是TCP/IP協議下的網絡連接,因此可以采用面向網絡連接的集中基本調度算法。考慮集群負載不平衡的可能,采取了動態獲取服務節點的權值并使用負反饋機制調整平衡器對網絡服務請求的分布,以適應服務節點在運行過程中資源的變化。筆者也在 LVS集群系統的基礎上,配合原有的輪詢算法對其進行改進,增加了采集動態權值的程序并實時反饋到負載平衡器的調度系統上。實踐證明,采用動態平衡在集群系統的整體吞吐量方面有所提高,特別是在集群各個節點性能不一,集群提供的網絡服務程序所訪問的資源多樣化的情況下,負反饋機制的效果尤其明顯。在其他類型的集群中,負反饋機制的動態負載平衡也能夠得到很好的應用,只是平衡器所處理的作業單元不同于網絡連接,而具體的負載算法上也將有所不同。
?
下載該資料的人也在下載
下載該資料的人還在閱讀
更多 >
- 負載平衡監控系統設計源碼分享 3次下載
- Apache2+tomcat5.5集群及Apache負載均衡配置實例
- 一種快速計算動態網絡相似性的方法 4次下載
- 使用C51單片機和Proteus仿真設計負載平衡監控系統的應用實例資料說明 4次下載
- 使用改進權重的D-S證據理論的動態負載平衡算法概述 14次下載
- 負載平衡云存儲算法 0次下載
- 基于攻擊事件的動態網絡風險評估框架 0次下載
- 一種面向負載平衡的主動復制技術
- PKUAS中負載平衡機制的設計與實現 21次下載
- MPI并行程序設計的負載平衡實現方法
- 動態網絡響應的研究
- 動態網頁設計教程,下載 0次下載
- 基于JXTA的FTP服務器集群負載平衡策略
- 基于流水線負載平衡模型的并行爬蟲研究
- 區分任務類型的資源負載平衡算法——TDSA
- 動態追溯方法:徹底革新軟件測試 259次閱讀
- 搭建Keepalived+Lvs+Nginx高可用集群負載均衡 2544次閱讀
- 靜態分析和動態分析的區別 5438次閱讀
- 如何通過級聯LTC4370電路輕松對3個或4個電源進行負載平衡 1468次閱讀
- 網絡延遲及故障分析方法指南匯總! 6038次閱讀
- 在Kubernetes集群發生網絡異常時如何排查 4553次閱讀
- 如何平衡內部部署集群和云計算服務 793次閱讀
- 電源負載的連接方法 1.3w次閱讀
- 改變負載電流的方法有哪些 8448次閱讀
- 多體動力學平衡狀態分析方法介紹 4114次閱讀
- Cloud RAN和移動邊緣計算,二者形成分歧 915次閱讀
- 一文解構PyTorch:深入了解PyTorch內部機制 3879次閱讀
- 動態平衡原理分析(智能平衡車的工作原理) 8557次閱讀
- 用實例深入闡述雙端口分析和回歸比分析 6039次閱讀
- 多PV節點的不平衡配電網潮流故障分析方法 1301次閱讀
下載排行
本周
- 1TC358743XBG評估板參考手冊
- 1.36 MB | 330次下載 | 免費
- 2開關電源基礎知識
- 5.73 MB | 6次下載 | 免費
- 3100W短波放大電路圖
- 0.05 MB | 4次下載 | 3 積分
- 4嵌入式linux-聊天程序設計
- 0.60 MB | 3次下載 | 免費
- 5基于FPGA的光纖通信系統的設計與實現
- 0.61 MB | 2次下載 | 免費
- 6基于FPGA的C8051F單片機開發板設計
- 0.70 MB | 2次下載 | 免費
- 751單片機窗簾控制器仿真程序
- 1.93 MB | 2次下載 | 免費
- 8基于51單片機的RGB調色燈程序仿真
- 0.86 MB | 2次下載 | 免費
本月
- 1OrCAD10.5下載OrCAD10.5中文版軟件
- 0.00 MB | 234315次下載 | 免費
- 2555集成電路應用800例(新編版)
- 0.00 MB | 33564次下載 | 免費
- 3接口電路圖大全
- 未知 | 30323次下載 | 免費
- 4開關電源設計實例指南
- 未知 | 21548次下載 | 免費
- 5電氣工程師手冊免費下載(新編第二版pdf電子書)
- 0.00 MB | 15349次下載 | 免費
- 6數字電路基礎pdf(下載)
- 未知 | 13750次下載 | 免費
- 7電子制作實例集錦 下載
- 未知 | 8113次下載 | 免費
- 8《LED驅動電路設計》 溫德爾著
- 0.00 MB | 6653次下載 | 免費
總榜
- 1matlab軟件下載入口
- 未知 | 935054次下載 | 免費
- 2protel99se軟件下載(可英文版轉中文版)
- 78.1 MB | 537796次下載 | 免費
- 3MATLAB 7.1 下載 (含軟件介紹)
- 未知 | 420026次下載 | 免費
- 4OrCAD10.5下載OrCAD10.5中文版軟件
- 0.00 MB | 234315次下載 | 免費
- 5Altium DXP2002下載入口
- 未知 | 233046次下載 | 免費
- 6電路仿真軟件multisim 10.0免費下載
- 340992 | 191185次下載 | 免費
- 7十天學會AVR單片機與C語言視頻教程 下載
- 158M | 183278次下載 | 免費
- 8proe5.0野火版下載(中文版免費下載)
- 未知 | 138040次下載 | 免費
評論
查看更多