負載平衡系統對於想要提供大規模服務的系統來說,常常是很重要的一件事,因為有些情況下,我們無法憑藉著單一的計算資源來滿足系統對於計算資源的需求。所以,我們必須倚賴分散式的架構,透過串連多個計算資源來提高系統的整體能力。

為了讓對系統資源的運用,不會因為過度集中在少數的計算資源個體(例如實體的伺服器)上,而讓系統的表現無法發揮得更淋漓盡致(像是讓少數硬體伺服器的CPU過度忙碌,其他少數伺服器的CPU卻處於閒置),這時,就會需要運用到負載平衡系統來協助。

不只是考量伺服器端負載,也要涵蓋到網路連線速度與頻寬
何謂負載?

它有可能是CPU的利用率、伺服器上的行程個數、也有可能是網路頻寬的使用量、檔案系統上的檔案個數、佔用的檔案空間、等等。對於不同的應用來說,負載的定義也有可能不同,甚至可能是一個綜合多種因子的指標。

乍聽之下,負載平衡系統的目標,像是要平衡系統中不同計算資源上的負載。平衡是個大方向,因為過度使用特定資源勢必使其成為瓶頸,但是這不意謂著,負載平衡系統的目標就是讓每個資源的負載都一樣,因為我們在分派計算工作至不同的計算資源上時,除了希望平衡負載之外,同時還會有一些其他的目標。

舉例來說,你使用多個應用程式伺服器,來處理來自客戶端的工作請求,而你的應用程式伺服器散佈在全世界各地。之所以將應用程式伺服器分散到全世界各地的目的,不單只是因為想要透過多伺服器串連起來的計算能力來得到更多的計算能力,而同時也兼具考量因為客戶端的工作請求可能來自於世界各地,因為和伺服器之間的網路連線距離,也會影響到和客戶端之間的通訊速度,進而影響回應予客戶端的速度。

因此,在分配工作請求的同時,除了考慮到目前各伺服器的實際負載之外,我們同時也必須考慮工作請求的來源地,和各伺服器之間的連線速度及可用頻寬。

因此,在提供客戶端夠好的品質,以及提高系統使用率的目標上,負載平衡系統時常必須要拿捏出一個平衡點出來。

從CDN看負載平衡
相信大家對於「內容傳遞網路(Content Delivery Network,CDN)」都不陌生,在許多應用時常都會使用到。CDN的原始想法就是將供客戶端存取的內容,分散到不同地點去,一方面不會受限在單一資料中心的總體頻寬,另一方面,也可以視客戶端和可用資料中心的距離、該資料中心的可用頻寬及相關負載,來決定究竟要將客戶端的請求,分配到那一個資料中心去。

現今有很多視訊分享的網站,都採用CDN的方式,來將視訊內容傳遞給客戶端的應用程式。這有很大的原因是因為現今的視訊檔案內容都有一定的大小,若是全世界的使用者都連往同一資料中心,對單一資料中心而言,必須提供的頻寬就要十分巨大。但若能導到不同地點的不同資料中心去,建置多個頻寬較小的資料中心,會比較容易。

同時,因為網路連線的特性關係,還可以進一步考慮到各區資料中心的實際負載,以及使用者和各區資料中心的連線速度及品質,來動態的決定究竟要將使用者分配到那一個資料中心去存取內容,以便提供最佳的連線速度及品質。

像是在臺灣的使用者,就被分派到臺灣的資料中心去存取,而在美東的使用者,就被分派到美東的資料中心。如此一來,其作用一方面是平衡負載,另一方面便是盡可能地最佳化系統對使用者所提供的品質。

因此,它並不完全只考慮連線的距離,同時它也考慮到負載。例如對視訊檔案的資料中心而言,對外的頻寬使用情況就是重要的負載參數。對於一個即將分派的新的客戶端請求,雖然連線距離是一個主要的考量,但是若是(網路距離上)最近的資料中心負載過高,耗去了太多的頻寬,便有可能將其分派到較遠的資料中心去。

因為負載也會影響到連線品質,若是將該請求分派至最近的資料中心去,但因為它的頻寬所剩無幾,反而造成此客戶端無法獲得夠好的連線品質,連帶影響到原有的客戶端。所以說,與其說它是考慮負載平衡的系統,不如說它是個把負載平衡考慮進來的分派系統。

從工作分派的角度來實施負載平衡

因為有了分派系統,所以除了可以動態依據負載或其他的考量因素,來決定究竟如何分派之外,也因為有了動態分派的能力,所以也可以進一步地偵測計算資源的存廢與否,來將工作分派到存活的計算資源上。

因此,當分散式的架構中有部份的計算資源因故毀損時,整個系統不致於無法對特定的客戶端提供服務。

當有此類的情事發生時,系統不會全毀,系統只會在能力上退化,因為可用的系統資源變少了。或許提供的服務品質變得較不好,但不致於完全無法提供服務。如此一來,便可以提供更高的可用性(Availability)。

但從容忍錯誤的觀點來看,即使可以透過分派系統收集其他資源的可用與否資訊,進而決定如何分派,使得客戶端總是能在分派的同時被分派到可用的資料上,但是集中化的分派系統本身卻成了單點錯誤的所在。這也就是說,倘若損毀的部份是分派系統的話,那麼整個系統都無法正常運作了。

當然,你也可以設計出一個分散式的分派系統來降低這個風險,或是採用一些其他的技巧。

例如,像著名的網路電話軟體Skype,它是一個基於P2P架構的系統,其前身為KaZaA。無論是KaZaA或是Skype,都倚賴所謂Super Peer的節點,因為有很多的重要活動,都會需要最末端的客戶端,即Peer連向Super Peer來完成。那麼Peer要如何得知有那些Super Peer可供連接呢?一開始免不了要連往一個集中化的伺服器去取得。但是幾乎每個P2P架構都會盡可能的去集中化,其中的原因是若此集中化的伺服器損毀後,整個系統就無法運作了。而Skype會從集中的伺服器下載一份初始的Super Peer清單,這份清單基本上就是集中化分派系統的決策結果,它會依據Peer的位置,來回傳適合該Peer連線的Super Peer。

若初次連線時,此集中化的伺服器恰好掛點,那麼對於此Peer而言,就真的無法運作下去。但若在初次連線、取得第一份Super Peer的清單後才發生了伺服器損毀的情況,Skype便有辦法在集中化的分派系統損毀時,繼續運作下去。

因為每個Peer都會在本地端,記住一份Super Peer的清單,甚至從它所連接的Super Peer,再去取得不在此清單上的Super Peer資訊,因此,即使集中的伺服器短暫地無法運作,也會因為本地端仍有一份Super Peer清單,而不致於完全不知道目前有那些Super Peer,可供連線。

從負載平衡系統到工作分派系統,需要考慮的因素變多了,但對於採分散式架構的系統來說,都是相當重要的組成。

而且,若你想在你的系統中採用分散式架構,上述這樣的議題就會是很重要的。

作者簡介


Advertisement

更多 iThome相關內容