云計算環境下的流量控制和負載均衡策略

宋 昕，宋歡歡

（1.河南省地方稅務局培訓中心 學員科，河南 開封 475000；2.北京郵電大學 網絡技術研究院，北京 100876）

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

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

在之前的工作中研究了開源的PasS形式的云環境平臺：TANSO（云環境下基于組件的分布式服務平臺）[3]。TANSO通過一系列的組件提供了平臺用于管理大規模web應用的接口[4]。 在 TANSO的組件層，Routing TCI（TANSO component instance）負責應用請求的轉發，流量控制和負載均衡。作為Routing TCI的實現，DRS被提出來。

下面將介紹關于流量控制和負載均衡的的相關工作。

1 相關工作

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

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

2 DRS的設計與實現

在TANSO的設計框架中，存在許多的前端轉發路由節點，如圖1所示，它們之間有組織的或者無組織的通過協調來實現轉發應用請求，流量控制和負載均衡控制。相比傳統web集群環境中的集中式轉發器，實現分布式轉發器需要解決以下問題。

1）需要提出一個有效的路由擴散算法用于在多個路由節點上更新應用路由信息。

2）為了實現對某種應用的流量控制，多個路由節點之間必須相互協調保證在一段時間間隔內的總流量速率。

3）相比集中式的轉發器，每個路由節點對后臺服務器狀態都有一個視圖，需要一種策略去同步不同轉發器之間的后臺服務器狀態。

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

3 分布式流量控制器

在集中式的流量控制器上，通過不斷統計經過該流量器的流量，判斷其是否超過流量上限決定丟棄或轉發。在TANSO路由子系統的設計中，每個TANSO節點上都存在一個路由TCI，它維護了一個全局的路由表，任何對云平臺服務的訪問都會經過路由TCI。現在需要協調在物理拓撲上處于局域網的多個流量控制節點來呈現出集中式流量控制器功能，通過使用分布式的隊列機制來限制不同應用的流量控制。

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

在實現上，使用單位時間內應用請求（HTTP請求）的個數來計算流量，每個流量控制器維護著局部流量并收集全局流量值。對于每個流量控制器，決定轉發/丟棄出隊的應用請求時，需要經過以下處理過程。

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

2）從其他流量控制器收集此種應用的流量，計算s間段內的全局流量。

3）根據收集全局流量，通過全局流量控制算法決定該請求的轉發或丟棄。

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

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

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

如圖4所示，在每一時段的初始階段，每一個流量控制器節點訂閱全局某一應用的請求流量，PS Master則訂閱所有流量控制器的局部流量。

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

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

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

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

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

4 負載均衡策略

在傳統的web集群應用中，web服務提供者將服務部署在自己的數據中心或者托管在別的數據中心，但是自己負責服務負載均衡實施。圖5描述了一種簡單的負載均衡框架。

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

用戶的請求首先經過DNS進行初步路由，之后經過4層或者7層的轉發器網絡設備（軟件模塊）再次進行負載選擇。在進行路由或者負載選擇時，可以采用輪詢或者隨機的靜態負載均衡算法。通常在DNS處采用簡單的靜態算法，在Dispatcher可以采用動態或者靜態算法。

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

考慮到集中式轉發器的單點故障和性能問題，TANSO根據平臺自身的特點，采用分布式的轉發器實施負載均衡。一方面這是性能的需求；另一方面，TANSO平臺的分布式路由子系統為構建分布式轉發器實施分布式負載均衡策略提供了基礎環境。在實現上，通過在路由系統中增加Dispatcher的功能，實施負載均衡策略。圖6描述TANSO平臺的負載均衡框架。

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

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

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

2）區別于傳統集群環境的應用獨享后臺服務器，TANSO中的應用共享服務器資源，如何處理不同應用對服務器負載的影響是另外一個問題。

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

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

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

1）應用請求經過Layer-4的網絡轉發設備（試驗中的客戶端代理），進行初步的負載選擇。

2）Monitor周期性的監聽服務器狀態，并將狀態統一反饋給Dispatcher。

3）Dispatcher修改涉及所有服務器的路由表項。

4）Dispatcher基于路由表中當前服務器狀態選擇最優服務器轉發請求。

Monitor監聽服務器狀態仍然使用pub/sub通信系統，獲取應用服務器的狀態主要包括連接數，CPU和內存使用率。Monitor可以作為一個單獨節TANSO點存在，主要加載AS Manager TCI，通過Socket獲取服務器狀態信息，同時將狀態信息pub給各個訂閱的Dispatcher。此外，Monitor也可以作為一個插件（AS Manager TCI）存在，插在路由節點中，pub/sub通信系統提供了兩層的消息轉發機制，能夠滿足任何一種需求。

5 結 論

本文給出了云計算環境下的服務器管理平臺TANSO的簡單介紹，并基于 TANSO的前端路由系統，對云計算環境中涉及到的任務調度策略做了研究，包括流量控制策略，區分服務策略及負載均衡策略。任務調度策略是web應用從傳統的web集群環境遷移到云環境中必須解決的問題，本文在提出問題背景的同時，分析了解決問題存在的挑戰，最后給出了解決方案。 云計算平臺在業界還沒有統一的定義和標準，雖然論文中的研究是基于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.