宋 昕，宋歡歡

（1.河南省地方稅務(wù)局培訓(xùn)中心 學(xué)員科，河南 開封 475000；2.北京郵電大學(xué) 網(wǎng)絡(luò)技術(shù)研究院，北京 100876）

作為分布式計算和服務(wù)計算領(lǐng)域的主要服務(wù)提供技術(shù)，云計算為用戶提供了共享基礎(chǔ)設(shè)施，應(yīng)用開發(fā)平臺以及商業(yè)應(yīng)用的環(huán)境。對應(yīng)于云計算提供的不同共享環(huán)境，一些著名的云計算框架被提出來，比如以IaaS（Infrastructure as a Service）形式出現(xiàn)的Amazon公司的EC2（彈性云計算）和以PaaS（Platform as a Service）形式出現(xiàn)的Google公司的GAE（谷歌應(yīng)用開發(fā)引擎）[1-2]。

作為通用的要求，提供web服務(wù)的平臺應(yīng)該提供一系列的特性，比如資源管理，流量控制和負(fù)載控制等。在傳統(tǒng)的提供web服務(wù)專用資源的情況下，應(yīng)用開發(fā)者能夠通過許多策略管理他們的資源平臺并且實(shí)現(xiàn)負(fù)載均衡，比如基于DNS的和基于轉(zhuǎn)發(fā)器的策略。然而，在云環(huán)境下，所有這些問題都必須由云平臺自身解決。一方面，來自不同開發(fā)者的大量不同的應(yīng)用共享后臺服務(wù)器池的CPU，內(nèi)存和帶寬等資源；另一方面，對不同應(yīng)用承諾的不同QoS必須實(shí)施保障。因此，在云環(huán)境下構(gòu)建web服務(wù)最大的挑戰(zhàn)是如何在為不同應(yīng)用提供不同QoS保障的同時，實(shí)施流量控制和負(fù)載均衡控制。

在之前的工作中研究了開源的PasS形式的云環(huán)境平臺：TANSO（云環(huán)境下基于組件的分布式服務(wù)平臺）[3]。TANSO通過一系列的組件提供了平臺用于管理大規(guī)模web應(yīng)用的接口[4]。 在 TANSO的組件層，Routing TCI（TANSO component instance）負(fù)責(zé)應(yīng)用請求的轉(zhuǎn)發(fā)，流量控制和負(fù)載均衡。作為Routing TCI的實(shí)現(xiàn)，DRS被提出來。

下面將介紹關(guān)于流量控制和負(fù)載均衡的的相關(guān)工作。

1 相關(guān)工作

在web集群中的負(fù)載均衡策略已經(jīng)被研究的很多[5]。通常情況下現(xiàn)有的負(fù)載均衡策略可以被分為兩類：集中式的和分布式的策略。基于DNS的策略和集中式的基于轉(zhuǎn)發(fā)器的策略是常見的集中式負(fù)載均衡策略。在文獻(xiàn)[6]中，基于DNS的負(fù)載均衡控制策略被詳細(xì)的介紹。引用文獻(xiàn)[7]提出了一種基于位置信息的轉(zhuǎn)發(fā)器負(fù)責(zé)均衡策略（LARD），通過使用一個集中式的請求分發(fā)器，LARD將應(yīng)用請求轉(zhuǎn)發(fā)到后臺服務(wù)器時，不但考慮后臺服務(wù)器的負(fù)責(zé)狀況，同時考慮后臺服務(wù)器的內(nèi)存擊中率。但是，LARD集中式的分發(fā)器承擔(dān)非常大的負(fù)荷，限制了整個系統(tǒng)的吞吐量?？紤]到集中式分發(fā)策略的單點(diǎn)故障和性能瓶頸，分布式的轉(zhuǎn)發(fā)器策略被提出來[8]。在分布式轉(zhuǎn)發(fā)器策略的設(shè)計中，許多轉(zhuǎn)發(fā)器被組織成結(jié)構(gòu)化的或者非結(jié)構(gòu)化的形式去轉(zhuǎn)發(fā)應(yīng)用請求，轉(zhuǎn)發(fā)器間通過廣播機(jī)制進(jìn)行通信協(xié)調(diào)。

但是，目前存在的負(fù)責(zé)均衡策略不能在云環(huán)境下很好的適用。在云環(huán)境中面臨著成千上萬不同的應(yīng)用請求，不同的請求之間共享后臺服務(wù)器資源。在這種情況下，基于DNS的負(fù)責(zé)均衡策略不能簡單的將后臺服務(wù)器的IP地址映射成邏輯的主機(jī)名或者應(yīng)用標(biāo)識。同時，現(xiàn)有的基于轉(zhuǎn)發(fā)器策略的的負(fù)責(zé)均衡策略不適用于轉(zhuǎn)發(fā)大量不同應(yīng)用的請求，這些應(yīng)用共享后臺服務(wù)資源，同時具有不同的QoS優(yōu)先級。更重要的是，現(xiàn)有的策略忽略了對不同應(yīng)用的流量控制。在文獻(xiàn)[9]中，一個分布式的流量控制策略被提出來，通過對全局請求速率和局部請求速率的統(tǒng)計，采用一種隨機(jī)丟棄的策略對某一種特定的應(yīng)用進(jìn)行流量控制。DRS提供了一個分布式轉(zhuǎn)發(fā)策略，它提供了一些機(jī)制用于解決在云環(huán)境下上述提到的問題，同時考慮到流量控制和負(fù)載均衡控制。

2 DRS的設(shè)計與實(shí)現(xiàn)

在TANSO的設(shè)計框架中，存在許多的前端轉(zhuǎn)發(fā)路由節(jié)點(diǎn)，如圖1所示，它們之間有組織的或者無組織的通過協(xié)調(diào)來實(shí)現(xiàn)轉(zhuǎn)發(fā)應(yīng)用請求，流量控制和負(fù)載均衡控制。相比傳統(tǒng)web集群環(huán)境中的集中式轉(zhuǎn)發(fā)器，實(shí)現(xiàn)分布式轉(zhuǎn)發(fā)器需要解決以下問題。

1）需要提出一個有效的路由擴(kuò)散算法用于在多個路由節(jié)點(diǎn)上更新應(yīng)用路由信息。

2）為了實(shí)現(xiàn)對某種應(yīng)用的流量控制，多個路由節(jié)點(diǎn)之間必須相互協(xié)調(diào)保證在一段時間間隔內(nèi)的總流量速率。

3）相比集中式的轉(zhuǎn)發(fā)器，每個路由節(jié)點(diǎn)對后臺服務(wù)器狀態(tài)都有一個視圖，需要一種策略去同步不同轉(zhuǎn)發(fā)器之間的后臺服務(wù)器狀態(tài)。

圖1 TANSO平臺基本框架Fig.1 The basic framework of TANSO platform

3 分布式流量控制器

在集中式的流量控制器上，通過不斷統(tǒng)計經(jīng)過該流量器的流量，判斷其是否超過流量上限決定丟棄或轉(zhuǎn)發(fā)。在TANSO路由子系統(tǒng)的設(shè)計中，每個TANSO節(jié)點(diǎn)上都存在一個路由TCI，它維護(hù)了一個全局的路由表，任何對云平臺服務(wù)的訪問都會經(jīng)過路由TCI?，F(xiàn)在需要協(xié)調(diào)在物理拓?fù)渖咸幱诰钟蚓W(wǎng)的多個流量控制節(jié)點(diǎn)來呈現(xiàn)出集中式流量控制器功能，通過使用分布式的隊(duì)列機(jī)制來限制不同應(yīng)用的流量控制。

在進(jìn)行流量控制時，是針對每個應(yīng)用進(jìn)行考慮，并為每個應(yīng)用維持一個隊(duì)列，統(tǒng)計每個應(yīng)用請求的速率，因此，對于出隊(duì)列的每類請求，保存一個統(tǒng)計表，統(tǒng)計每種應(yīng)用的本地流量。表格的形式非常簡單，實(shí)現(xiàn)上是Java中的HashMap，哈希的鍵是每種應(yīng)用的應(yīng)用ID，哈希值是該應(yīng)用在一個時間間隔內(nèi)的請求數(shù)量。每個應(yīng)用請求的命運(yùn)（轉(zhuǎn)發(fā)或丟棄）不能僅由本地的控制器決定，必須通過計算該應(yīng)用流經(jīng)所有流量控制器的總統(tǒng)計值來決定。

在實(shí)現(xiàn)上，使用單位時間內(nèi)應(yīng)用請求（HTTP請求）的個數(shù)來計算流量，每個流量控制器維護(hù)著局部流量并收集全局流量值。對于每個流量控制器，決定轉(zhuǎn)發(fā)/丟棄出隊(duì)的應(yīng)用請求時，需要經(jīng)過以下處理過程。

1）計算一定時間間隔s內(nèi)這種請求的本地流量。

2）從其他流量控制器收集此種應(yīng)用的流量，計算s間段內(nèi)的全局流量。

3）根據(jù)收集全局流量，通過全局流量控制算法決定該請求的轉(zhuǎn)發(fā)或丟棄。

所有的流量控制器被組織成分布式的架構(gòu)，每個控制器獨(dú)通過和其他控制器通信決定通過本地請求的命運(yùn)，最簡單的通信方式廣播網(wǎng)[9]。通過廣播的方式雖然速度很快，但同時也是非常消耗帶寬（O（N2））。

作為替代，采用基于pub/sub的通信子系統(tǒng)用于節(jié)點(diǎn)之間的通信。在使用pub/sub通信子系統(tǒng)時，選取一個不參與路由的TANSO節(jié)點(diǎn)（比如一些資源管理節(jié)點(diǎn)），增加一個簡單PS Master組件（PSM TCI），該插件的功能非常簡單，可以作為一個獨(dú)立的線程獨(dú)立運(yùn)行。PSM TCI的存在是為了給在基于pub/sub模型中實(shí)現(xiàn)“統(tǒng)計/反饋”需求提供輔助，上述提到的局部流量的統(tǒng)計和全局流量的計算可以看成一個 “統(tǒng)計/反饋”的過程，如圖2、3和4所示的3個階段。

圖2 初始化訂閱信息Fig.2 The initialization of sub

如圖4所示，在每一時段的初始階段，每一個流量控制器節(jié)點(diǎn)訂閱全局某一應(yīng)用的請求流量，PS Master則訂閱所有流量控制器的局部流量。

圖5是在每一時段末，所有流量控制器發(fā)布某一應(yīng)用的局部請求流量，相應(yīng)的PS Master將會收到所有流量控制器的流量統(tǒng)計值，據(jù)此計算全局流量。第一二階段是“統(tǒng)計”階段。

圖3 發(fā)布局部流量信息Fig.3 Pub local traffic infomation

圖4 反饋全局瀏覽信息Fig.4 Feedback of global information

第三階段如圖4所示，PS Master計算完全局請求流量以后，發(fā)布全局流量，根據(jù)第一階段的訂閱，所有流量控制器便會收到全局流量統(tǒng)計值，并以此進(jìn)行流量控制算法。這個階段是“反饋”階段。

基于pub/sub通信子系統(tǒng)，采用“統(tǒng)計/反饋”這種形式進(jìn)行局部流量信息和全局流量信息的統(tǒng)計，極大地減少了消息通信量，流程更加清晰。在第三階段末，每一個流量控制器采取一定的請求轉(zhuǎn)發(fā)/丟棄策略，對出隊(duì)列的請求進(jìn)行處理。

4 負(fù)載均衡策略

在傳統(tǒng)的web集群應(yīng)用中，web服務(wù)提供者將服務(wù)部署在自己的數(shù)據(jù)中心或者托管在別的數(shù)據(jù)中心，但是自己負(fù)責(zé)服務(wù)負(fù)載均衡實(shí)施。圖5描述了一種簡單的負(fù)載均衡框架。

圖5 常用的負(fù)載均衡框架Fig.5 Common load equilibrium frame

用戶的請求首先經(jīng)過DNS進(jìn)行初步路由，之后經(jīng)過4層或者7層的轉(zhuǎn)發(fā)器網(wǎng)絡(luò)設(shè)備（軟件模塊）再次進(jìn)行負(fù)載選擇。在進(jìn)行路由或者負(fù)載選擇時，可以采用輪詢或者隨機(jī)的靜態(tài)負(fù)載均衡算法。通常在DNS處采用簡單的靜態(tài)算法，在Dispatcher可以采用動態(tài)或者靜態(tài)算法。

在圖5的場景中，后臺的服務(wù)器池是web服務(wù)提供商自己或托管的數(shù)據(jù)中心，內(nèi)部部署的應(yīng)用獨(dú)享這些服務(wù)器。在Dispatcher使用隨機(jī)的負(fù)載均衡算法時，可以根據(jù)服務(wù)器初始處理能力不同，按一定比例隨機(jī)提交請求。比如服務(wù)器A和B的處理能力分別為M和W，那么可以簡單的將M/（M+W）的請求量提交給服務(wù)器A，W/（M+W）的請求流量提交給B。在使用輪轉(zhuǎn)策略時，可以將服務(wù)器從1～N編號，針對每一個到來的請求，按服務(wù)器編號遞增模N的順序提交給服務(wù)器。在Dispatcher處采用動態(tài)負(fù)載均衡算法時，比如采用最少鏈接算法，可以動態(tài)監(jiān)控每個服務(wù)器鏈接狀態(tài)，并反饋給Dispatcher模塊，以選擇狀態(tài)最優(yōu)的服務(wù)器提交請求。

考慮到集中式轉(zhuǎn)發(fā)器的單點(diǎn)故障和性能問題，TANSO根據(jù)平臺自身的特點(diǎn)，采用分布式的轉(zhuǎn)發(fā)器實(shí)施負(fù)載均衡。一方面這是性能的需求；另一方面，TANSO平臺的分布式路由子系統(tǒng)為構(gòu)建分布式轉(zhuǎn)發(fā)器實(shí)施分布式負(fù)載均衡策略提供了基礎(chǔ)環(huán)境。在實(shí)現(xiàn)上，通過在路由系統(tǒng)中增加Dispatcher的功能，實(shí)施負(fù)載均衡策略。圖6描述TANSO平臺的負(fù)載均衡框架。

圖6 TANSO分布式負(fù)載均衡框架Fig.6 Distributed load balance frame of TANSO

根據(jù)圖6中描述的負(fù)載均衡框架，首要解決以下問題：

1）存在多個前端的Dispatcher，需要同步、協(xié)調(diào)他們對后臺服務(wù)器的狀態(tài)信息。如果采用傳統(tǒng)web集群環(huán)境中的動態(tài)監(jiān)聽獲取服務(wù)器狀態(tài)，每個Dispatcher都需要周期性的監(jiān)聽服務(wù)器的狀態(tài)，一方面造成了大量的通信量；另一方面，由于每個Dispatcher都是基于服務(wù)器狀態(tài)進(jìn)行選擇提交請求，就有可能造成因某一個服務(wù)器狀態(tài)空載高而所有的請求都被提交過去，造成“瞬間過載”的情況。

2）區(qū)別于傳統(tǒng)集群環(huán)境的應(yīng)用獨(dú)享后臺服務(wù)器，TANSO中的應(yīng)用共享服務(wù)器資源，如何處理不同應(yīng)用對服務(wù)器負(fù)載的影響是另外一個問題。

服務(wù)器狀態(tài)更新和應(yīng)用請求的轉(zhuǎn)發(fā)是一個異步的過程，能夠大大減少應(yīng)用請求的響應(yīng)時間。在實(shí)現(xiàn)上，TANSO引入了一個Monitor節(jié)點(diǎn)，用于獲取服務(wù)器狀態(tài)信息，并反饋給分布的Dispatcher。這樣做將傳統(tǒng)中的Dispatcher從既監(jiān)聽服務(wù)器狀態(tài)又負(fù)載轉(zhuǎn)發(fā)應(yīng)用請求中分離出來，讓Dispatcher僅僅去轉(zhuǎn)發(fā)應(yīng)用請求。同時，Monitor可以統(tǒng)一的獲取服務(wù)器的狀態(tài)，保證Dispatcher之間的狀態(tài)同步。但是，Monitor的存在又引入了集中式單點(diǎn)缺陷，但不存在性能瓶頸問題。Monitor周期性的監(jiān)聽服務(wù)器狀態(tài)，并反饋給Dispatcher，這種周期性的監(jiān)聽信息量相比應(yīng)用請求訪問量小很多數(shù)量級。要徹底解決集中節(jié)點(diǎn)單點(diǎn)故障的問題，必須考慮完全的分布式結(jié)構(gòu)，比如讓所有的Dispatcher組成P2P拓?fù)浣Y(jié)構(gòu)，但是目前還沒有能力實(shí)現(xiàn)如此復(fù)雜的設(shè)計。相對簡單的做法是對Monitor采取簡單熱備份，當(dāng)Monitor出現(xiàn)故障時，切換到備用節(jié)點(diǎn)。引入Monitor后，TANSO的負(fù)載均衡框架如圖7所示。

圖7 引入Monitor的TANSO負(fù)載均衡框架Fig.7 Distributed load balance frame with monitor

引入Monitor后，TANSO負(fù)載均衡的流程如下：

1）應(yīng)用請求經(jīng)過Layer-4的網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備（試驗(yàn)中的客戶端代理），進(jìn)行初步的負(fù)載選擇。

2）Monitor周期性的監(jiān)聽服務(wù)器狀態(tài)，并將狀態(tài)統(tǒng)一反饋給Dispatcher。

3）Dispatcher修改涉及所有服務(wù)器的路由表項(xiàng)。

4）Dispatcher基于路由表中當(dāng)前服務(wù)器狀態(tài)選擇最優(yōu)服務(wù)器轉(zhuǎn)發(fā)請求。

Monitor監(jiān)聽服務(wù)器狀態(tài)仍然使用pub/sub通信系統(tǒng)，獲取應(yīng)用服務(wù)器的狀態(tài)主要包括連接數(shù)，CPU和內(nèi)存使用率。Monitor可以作為一個單獨(dú)節(jié)TANSO點(diǎn)存在，主要加載AS Manager TCI，通過Socket獲取服務(wù)器狀態(tài)信息，同時將狀態(tài)信息pub給各個訂閱的Dispatcher。此外，Monitor也可以作為一個插件（AS Manager TCI）存在，插在路由節(jié)點(diǎn)中，pub/sub通信系統(tǒng)提供了兩層的消息轉(zhuǎn)發(fā)機(jī)制，能夠滿足任何一種需求。

5 結(jié) 論

本文給出了云計算環(huán)境下的服務(wù)器管理平臺TANSO的簡單介紹，并基于 TANSO的前端路由系統(tǒng)，對云計算環(huán)境中涉及到的任務(wù)調(diào)度策略做了研究，包括流量控制策略，區(qū)分服務(wù)策略及負(fù)載均衡策略。任務(wù)調(diào)度策略是web應(yīng)用從傳統(tǒng)的web集群環(huán)境遷移到云環(huán)境中必須解決的問題，本文在提出問題背景的同時，分析了解決問題存在的挑戰(zhàn)，最后給出了解決方案。 云計算平臺在業(yè)界還沒有統(tǒng)一的定義和標(biāo)準(zhǔn)，雖然論文中的研究是基于TANSO平臺的，但是研究的問題具有普遍性，文中提出的問題解決方案為也為其他平臺的研究提供一定的參考意義。

[1]Google.Google App Engine[EB/OL].2004.http：//code.google.com/intl/en/appengine/

[2]Amazon.Amazon EC2 [EB/OL].2004.http：//aws.amazon.com/ec2/

[3]LI Li， TIAN Rui-xiong， YANG Bo， et al.TANSO：A componentized distributed service foundation in cloud environment[C]//2010 IEEE.Network Operations and Management Symposium （NOMS）， 2010：120-127.

[4]LILi.TANSO：A componentized distributed service foundation in cloud environment[EB/OL].http：//sourceforge.net/projects/tanso

[5]Cardellini V，Colajanni M，Yu P S.Dyamic load balancing on Web-server systems[J].IEEE.Internet Computing，1999，3（3）：28-39.

[6]Brisco T.DNS Support for Load Balancing [EB/OL].1995.http：//www.ietf.org/rfc/rfc1794.txt.

[7]Pail V S，Aront M，Bangat G，et al.Locality-aware request distribution in cluster-based Network Servers[C]//ASPLOS 98 VIII， 1998：127-139.

[8]DU Zeng-kai，JU Jiu-bin.Distributed content-aware request distribution in cluster-based Web servers[C]//IEEE.Parallel and Distributed Computing，Applications and Technologies.2003：99-103.

[9]Raghavan B，Vishwanath K，Ramabhadran S，et al.Cloud control with distributed rate limiting[C]//SIGCOMM’07，2007.