賈翔龍，吳 剛

(上海交通大學(xué)軟件學(xué)院，上海 200240)

1 引言

云計算[1,2]是當(dāng)前信息技術(shù)領(lǐng)域的熱門話題之一，它將大量計算資源和存儲資源連接起來，形成虛擬資源池。云平臺的一個基本目標(biāo)是，能夠根據(jù)應(yīng)用負(fù)載的波動，動態(tài)調(diào)整分配給某一應(yīng)用的資源，這種按需調(diào)配和使用資源的能力稱為彈性。彈性是云計算區(qū)別于網(wǎng)格計算等其它分布式計算的重要特征。

學(xué)術(shù)界和產(chǎn)業(yè)界從平臺的角度出發(fā)對彈性做了大量研究。云計算的本質(zhì)是分布式計算，增加分布式系統(tǒng)的資源有兩種途徑：升級(Scale Up)和擴(kuò)展(Scale Out)。升級是指提升系統(tǒng)內(nèi)節(jié)點(diǎn)的運(yùn)算能力，擴(kuò)展是指增加系統(tǒng)內(nèi)節(jié)點(diǎn)的數(shù)量。本文只考慮通過擴(kuò)展實(shí)現(xiàn)應(yīng)用彈性。不同類型的云平臺根據(jù)平臺特點(diǎn)采取不同手段實(shí)現(xiàn)平臺的彈性[3,4]。PaaS平臺通過虛擬化技術(shù)對用戶提供屏蔽了系統(tǒng)分布式拓?fù)浣Y(jié)構(gòu)的可升級計算節(jié)點(diǎn)，代表產(chǎn)品有GAE(Google App Engine)。IaaS平臺為用戶提供虛擬機(jī)實(shí)例，平臺根據(jù)請求生成和回收實(shí)例，代表產(chǎn)品有Amazon EC2[5]。上述平臺為保證通用性有一定限制，GAE不支持應(yīng)用對多線程和文件系統(tǒng)的操作，EC2把負(fù)載均衡、內(nèi)容部署等集群維護(hù)工作完全交給用戶處理。

然而，從應(yīng)用角度系統(tǒng)地研究彈性擴(kuò)展的工作卻很少。對于部署在云平臺上的應(yīng)用而言，如果自身沒有支持動態(tài)擴(kuò)展的機(jī)制，將無法利用平臺提供的資源實(shí)現(xiàn)彈性。因此，本文面向應(yīng)用本身的彈性需求和擴(kuò)展方法展開研究，提出了基本研究方法和實(shí)現(xiàn)手段，并重點(diǎn)以Web 2.0這一類應(yīng)用進(jìn)行了案例分析，提出了具體的應(yīng)用模式和彈性支撐平臺的解決方案。

本文后續(xù)內(nèi)容組織如下：第2節(jié)給出了從應(yīng)用特征分析到模式設(shè)計再到彈性支撐機(jī)制設(shè)計的基本研究方法；第3節(jié)對Web 2.0應(yīng)用進(jìn)行案例分析，給出具體的解決方案，并通過實(shí)驗(yàn)驗(yàn)證了模式有效性；第4節(jié)總結(jié)全文。

2 基本研究方法

本文的目標(biāo)是提高分布式應(yīng)用自身的彈性，以適應(yīng)云計算環(huán)境下隨著負(fù)載量變化而動態(tài)調(diào)整資源使用量的需求。影響分布式應(yīng)用彈性的因素有很多，但是從配合以虛擬機(jī)為粒度的資源擴(kuò)展角度，分布式系統(tǒng)的架構(gòu)設(shè)計起決定性作用。

不同的分布式系統(tǒng)其架構(gòu)可能會不一樣，設(shè)計者當(dāng)然可以針對每一個具體的系統(tǒng)進(jìn)行具體分析。但是，我們注意到，某一類的分布式應(yīng)用常常有著類似的架構(gòu)。比如，面向信息發(fā)布和共享的Web 1.0應(yīng)用，通常采取Web Server+Application Server+Database 的經(jīng)典三層架構(gòu)；再比如以社交網(wǎng)絡(luò)為代表的Web 2.0應(yīng)用，通常在三層架構(gòu)基礎(chǔ)上增加分布式文件系統(tǒng)并大量使用緩存，如人人網(wǎng)、新浪微博等。因此，本文認(rèn)為針對同一類應(yīng)用提出適合彈性的應(yīng)用模式(Pattern)，并據(jù)此提供相應(yīng)的彈性支撐機(jī)制，對應(yīng)用開發(fā)者和平臺提供者是具有參考意義和借鑒價值的。

我們把工作的步驟和內(nèi)容總結(jié)如下，其流程如圖1所示：

(1)分析應(yīng)用特征；

(2)根據(jù)特征提出適合彈性的應(yīng)用模式；

(3a)設(shè)計和優(yōu)化平臺架構(gòu)，以支撐該應(yīng)用模式的實(shí)現(xiàn)；

(3b)為方便應(yīng)用實(shí)現(xiàn)這種模式，平臺需要提供相關(guān)的彈性支撐庫，設(shè)計庫函數(shù)接口；

(4)搭建平臺，實(shí)現(xiàn)彈性支撐庫；

(5)實(shí)驗(yàn)驗(yàn)證(2)～(4)工作的有效性，如需進(jìn)一步提高彈性可返回(2)；

(6)平臺搭建成功。

Figure 1 Process diagram of basic approach圖1 基本方法的流程圖

下面我們以Web 2.0這一類應(yīng)用為案例，按照上述基本方法的步驟予以實(shí)踐，一方面驗(yàn)證上述方法的有效性，另一方面也切實(shí)針對這類應(yīng)用提出具體的擴(kuò)展機(jī)制。

3 面向Web 2.0的應(yīng)用模式與彈性支撐庫設(shè)計

3.1 Web 2.0應(yīng)用特征分析

維基百科對Web 2.0的定義是`“一個利用Web平臺、由用戶主導(dǎo)生成內(nèi)容的互聯(lián)網(wǎng)產(chǎn)品模式”。具有代表性的Web 2.0應(yīng)用是社交網(wǎng)絡(luò)服務(wù)(Service Network Service)，從技術(shù)角度看，Web 2.0應(yīng)用具有負(fù)載波動性強(qiáng)、對部分?jǐn)?shù)據(jù)的一致性要求較弱、需要支持大量音頻/視頻/圖片等格式的文件下載等特點(diǎn)。

3.2 提出應(yīng)用模式

根據(jù)Web 2.0應(yīng)用的特點(diǎn)，本文總結(jié)出適合實(shí)現(xiàn)彈性的PSP(Processor-State-Persistent)應(yīng)用模式，描述如下：

名字(Name)：Processor-State-Persistent(PSP)模式。

背景(Context)：分布式應(yīng)用有多種消息交換模式(Message Exchange Pattern)，Web 2.0是基于請求-響應(yīng)模式的分布式應(yīng)用。在這種模式下，用戶向應(yīng)用發(fā)送請求(Request)，應(yīng)用經(jīng)過運(yùn)算向用戶發(fā)送響應(yīng)(Response)。請求之間可能相互關(guān)聯(lián)構(gòu)成上下文關(guān)系，這樣的一組請求形成一次會話(Session)。應(yīng)用可能將處理請求得到的運(yùn)算結(jié)果持久化儲存，稱為持久數(shù)據(jù)(Persistent Data)。運(yùn)算可能依賴于過去的持久數(shù)據(jù)。

問題(Problem)：用戶的請求是不可預(yù)知的，包括響應(yīng)請求需要的運(yùn)算量、請求之間的關(guān)聯(lián)關(guān)系、單位時間內(nèi)應(yīng)用會收到多少請求、運(yùn)算依賴于哪些持久數(shù)據(jù)等方面。待解決的問題是：應(yīng)用需要具備怎樣的架構(gòu)，才能通過添加和移除節(jié)點(diǎn)的方法高效利用計算和存儲資源，應(yīng)對負(fù)載的波動。

因素(Forces)：添加節(jié)點(diǎn)后，系統(tǒng)的整體吞吐量應(yīng)該得到提升，使請求的平均響應(yīng)時間降低或持平；移除節(jié)點(diǎn)時，盡量不要中斷未完成的會話，平均響應(yīng)時間盡量持平；應(yīng)用在數(shù)據(jù)一致性和整體性能之間折衷，可以犧牲部分?jǐn)?shù)據(jù)的一致性提升應(yīng)用整體的吞吐量。

解決方案(Solution)：PSP模式有兩條原則，第一是會話數(shù)據(jù)與執(zhí)行運(yùn)算的節(jié)點(diǎn)分離，任何運(yùn)算節(jié)點(diǎn)都可以完成指定會話的運(yùn)算；第二是使用獨(dú)立緩存訪問持久數(shù)據(jù)，寫操作直接在保存持久數(shù)據(jù)的節(jié)點(diǎn)上進(jìn)行，讀操作僅在緩存上執(zhí)行，對用戶保證數(shù)據(jù)的弱一致性(Weak Consistency)。 PSP模式示意圖如圖2所示。

Figure 2 PSP pattern圖2 PSP模式

Processor：接收用戶請求，按業(yè)務(wù)邏輯執(zhí)行運(yùn)算，返回響應(yīng)。Processor本身是無狀態(tài)(Stateless)的，中間運(yùn)算結(jié)果由CN保存，會話數(shù)據(jù)由SDN保存，持久數(shù)據(jù)由PDN保存。

SDN(State Data Node)：保存會話數(shù)據(jù)。一次會話的所有數(shù)據(jù)保存在一個SDN上，SDN之間互相隔離，不同步任何數(shù)據(jù)。Processor和SDN沒有綁定關(guān)系。

PDN(Persistent Data Node)：保存持久數(shù)據(jù)，對Processor提供保證順序一致性的寫入數(shù)據(jù)的接口，對CN提供讀取數(shù)據(jù)的接口。

CN(Cache Node)：保存持久數(shù)據(jù)的緩存以及Processor的中間運(yùn)算結(jié)果，原則上Processor可以訪問CN保存的所有內(nèi)容。

PSP模式下，應(yīng)用通過調(diào)整Processor、SDN和CN的數(shù)量應(yīng)對負(fù)載的波動。在負(fù)載加重的情況下，添加Processor可以在單位時間內(nèi)接收更多的請求、完成復(fù)雜度更高的運(yùn)算；添加SDN可以維持更多的會話；添加CN可以緩存更多的持久數(shù)據(jù)，減輕讀操作對PDN的壓力。在負(fù)載減輕的情況下，移除Processor會中斷未完成的運(yùn)算，但不會中斷現(xiàn)有的會話；移除SDN時可以根據(jù)會話的重要程度選擇中斷或轉(zhuǎn)移會話；移除CN會減小緩存總量，可能會使命中率暫時降低。

3.3 平臺架構(gòu)

前文指出，體系架構(gòu)的設(shè)計對支撐彈性的應(yīng)用模式實(shí)現(xiàn)有決定性作用，本文給出了支持PSP模式應(yīng)用的平臺架構(gòu)，如圖3所示。

Figure 3 Architecture of platform for Web 2.0 applications圖3 Web 2.0平臺架構(gòu)

對各個組件的功能描述及其與PSP模式的映射關(guān)系如表1所示，其中還列舉了后續(xù)實(shí)驗(yàn)中各組件的配置情況，所有虛擬服務(wù)器通過Hyper-V提供，均安裝Ubuntu 12.04，內(nèi)核版本為3.2。

Table 1 Configuration and functionality of platform components表1 組件配置與功能

3.4 彈性支撐庫的設(shè)計

3.4.1 接口設(shè)計

如3.2節(jié)所述，符合PSP模式的Web 2.0應(yīng)用在平臺支持下可以實(shí)現(xiàn)彈性。然而，要求應(yīng)用開發(fā)者學(xué)習(xí)并恰當(dāng)?shù)貙?shí)踐一種新模式是很困難的，本文提供一系列貼近開發(fā)者編程習(xí)慣的庫函數(shù)，幫助應(yīng)用實(shí)現(xiàn)PSP模式。對彈性支撐庫的接口設(shè)計如下：

sess_open()、sess_close($sid)、sess_read($sid)、sess_write($sid,$data)：操作會話數(shù)據(jù)；

put($filename,$file)：以Key-Value形式在平臺上儲存一個文件；

getURL($filename)：獲取用戶對指定文件的訪問地址；

addSvr($type)、rmSvr($name)：添加、移除指定節(jié)點(diǎn)。

3.4.2 關(guān)鍵算法改進(jìn)

PSP模式實(shí)現(xiàn)彈性的核心在于通過添加和移除節(jié)點(diǎn)調(diào)整應(yīng)用的性能，對應(yīng)彈性支撐庫的addSvr和rmSvr函數(shù)。對于SDN和CN來說，需要找到一種算法，既能有效地把數(shù)據(jù)分散到各個節(jié)點(diǎn)上，又能在節(jié)點(diǎn)變動時減小數(shù)據(jù)的遷移量。本文采用改進(jìn)一致性哈希實(shí)現(xiàn)這一目標(biāo)，下面分別介紹一致性哈希的基本原理以及本文的改進(jìn)。

一致性哈希的基本原理[7]是給每個節(jié)點(diǎn)(Node)和待存儲對象(Object)生成一個鍵(Key)，這些鍵保存在同一個環(huán)形的哈希空間里，待存儲對象存放在順時針遇見的第一個節(jié)點(diǎn)上。一致性哈?；窘鉀Q了節(jié)點(diǎn)變動帶來的全局重哈希問題，但是會丟失需要重映射的存儲對象。PSP模式除了緩存之外還要維護(hù)會話數(shù)據(jù)，需要減少節(jié)點(diǎn)變動造成的無效查詢。

本文按PSP模式的需要對一致性哈希做出了改進(jìn)，使移除和增加節(jié)點(diǎn)后的首次訪問也能正確獲取數(shù)據(jù)。改進(jìn)的核心是訪問時把節(jié)點(diǎn)變動的狀態(tài)考慮進(jìn)去，在移除或增加節(jié)點(diǎn)前把此節(jié)點(diǎn)的數(shù)據(jù)拷貝到環(huán)形空間內(nèi)的下一節(jié)點(diǎn)上，拷貝過程中的寫操作在這兩個節(jié)點(diǎn)上同時進(jìn)行，失敗的讀操作在下一節(jié)點(diǎn)上嘗試一次。

實(shí)現(xiàn)的具體方法是設(shè)置標(biāo)志位$isAdjusting和循環(huán)鏈表$nodeList，節(jié)點(diǎn)按Key從小到大的順序存放在$nodeList中。當(dāng)新增或移除某節(jié)點(diǎn)開始時設(shè)置$isAdjusting為TRUE，把需要重映射的Object移動到$nodeList指向的這個節(jié)點(diǎn)的下一節(jié)點(diǎn)，移動完成后把$isAdjusting設(shè)置為FALSE。算法描述如表2所示。

3.5 彈性驗(yàn)證

Web 2.0應(yīng)用的負(fù)載較為復(fù)雜，很難給出綜合指標(biāo)反映應(yīng)用的性能。本文分別對會話訪問和文件下載這兩個比較重要的方面進(jìn)行彈性驗(yàn)證。

Table 2 Improved consistent Hashing algorithm表2 改進(jìn)的一致性哈希算法

動態(tài)調(diào)整Session Server數(shù)量驗(yàn)證對會話訪問的彈性。如圖4a所示，會話總數(shù)為50K，一臺Web Server持續(xù)以200并發(fā)量對會話進(jìn)行隨機(jī)讀寫(讀操作和寫操作概率相同)，橫坐標(biāo)為時間，縱坐標(biāo)為平均響應(yīng)時間。初始狀態(tài)有一臺Session Server，分別在第10、22、34、46分鐘執(zhí)行add、add、remove、remove操作。平均需要8分鐘完成虛擬機(jī)生成和會話數(shù)據(jù)拷貝，這段時間內(nèi)寫操作要在兩臺Session Server上進(jìn)行，讀操作可能會計算兩次存儲節(jié)點(diǎn)，拷貝要占用大量I/O，所以性能有明顯下降?？截愅瓿珊笃骄憫?yīng)時間恢復(fù)正常。

動態(tài)調(diào)整File Server數(shù)量驗(yàn)證文件下載的彈性。如圖4b所示，文件大小總和為4 GB，全部保存在File Server上，六臺與Web Server配置相同的虛擬機(jī)以總并發(fā)量696持續(xù)隨機(jī)下載大小為100 KB的文件，橫坐標(biāo)為時間，縱坐標(biāo)為平均響應(yīng)時間。初始狀態(tài)有一臺File Server，分別在第10、22、34、46分鐘執(zhí)行add、add、remove、remove操作。平均需要10分鐘完成虛擬機(jī)的生成和文件拷貝，拷貝過程中性能下降明顯，完成后平均響應(yīng)時間恢復(fù)正常。

Figure 4 Validation of elasticity圖4 彈性驗(yàn)證

4 結(jié)束語

本文面向應(yīng)用本身的彈性需求和擴(kuò)展方法展開研究，提出了實(shí)現(xiàn)彈性機(jī)制的基本研究方法：首先總結(jié)應(yīng)用特征，提出適合實(shí)現(xiàn)彈性的應(yīng)用模式，然后根據(jù)應(yīng)用模式設(shè)計平臺架構(gòu)和相應(yīng)的彈性支

撐庫，最后通過實(shí)驗(yàn)驗(yàn)證模式的有效性。對Web 2.0應(yīng)用采用基本方法進(jìn)行案例分析，提出了PSP模式并給出了支撐平臺解決方案，通過實(shí)驗(yàn)驗(yàn)證了平臺的彈性，證明了PSP模式和基本方法的有效性。

[1] Patterson G,Rabkin D A,Stoica A,et al.Above the clouds:A Berkeley view of cloud computing[R]. Berkeley:Technical Report UCB/EECS.Department of Electrical Engineer and Computer Sciences, University of California, 2009.

[2] Armbrust M, Fox A, Griffith R, et al. Amazon web services. health case study[EB/OL].[2012-10-10].http://aws.amazon.com/ec2.

[3] Nurmi D,Wolski R,Grzegorczyk C,et al.Eucalyptus:A technical report on an elastic utility computing architecture linking your programs to useful systems[C]∥Proc of UCSB Computer Science Technical Conference, 2008:45-58.

[4] Zhou J T, Zheng S, Jing D Li. An approach of creative application evolution on cloud computing platform[C]∥Proc of ACM SAC’11,2011:54-58.

[5] Amazon simple storage service(Amazon S3)[EB/OL].[2012-10-10].http://docs.amazonwebservices.com/AmazonS3/2006-03-01/.

[6] Zhang Wen-song. Linux virtual server:Linux server clusters for scalable network services[C]∥Proc of World Congress Conference, 2000:1-10.

[7] Karger D, Sherman A, Berkheimer A, et al. Web caching with consistent hashing[J]. Computer Networks, 1999,31(11-16):1203-1213.