分布式應(yīng)用彈性支撐機制的研究與實現(xiàn)

賈翔龍，吳 剛

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

1 引言

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

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

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

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

2 基本研究方法

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

不同的分布式系統(tǒng)其架構(gòu)可能會不一樣，設(shè)計者當(dāng)然可以針對每一個具體的系統(tǒng)進行具體分析。但是，我們注意到，某一類的分布式應(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)、新浪微博等。因此，本文認為針對同一類應(yīng)用提出適合彈性的應(yīng)用模式(Pattern)，并據(jù)此提供相應(yīng)的彈性支撐機制，對應(yīng)用開發(fā)者和平臺提供者是具有參考意義和借鑒價值的。

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

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

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

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

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

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

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

(6)平臺搭建成功。

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

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

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)用具有負載波動性強、對部分?jǐn)?shù)據(jù)的一致性要求較弱、需要支持大量音頻/視頻/圖片等格式的文件下載等特點。

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

根據(jù)Web 2.0應(yīng)用的特點，本文總結(jié)出適合實現(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)過運算向用戶發(fā)送響應(yīng)(Response)。請求之間可能相互關(guān)聯(lián)構(gòu)成上下文關(guān)系，這樣的一組請求形成一次會話(Session)。應(yīng)用可能將處理請求得到的運算結(jié)果持久化儲存，稱為持久數(shù)據(jù)(Persistent Data)。運算可能依賴于過去的持久數(shù)據(jù)。

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

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

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

Figure 2 PSP pattern圖2 PSP模式

Processor：接收用戶請求，按業(yè)務(wù)邏輯執(zhí)行運算，返回響應(yīng)。Processor本身是無狀態(tài)(Stateless)的，中間運算結(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的中間運算結(jié)果，原則上Processor可以訪問CN保存的所有內(nèi)容。

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

3.3 平臺架構(gòu)

前文指出，體系架構(gòu)的設(shè)計對支撐彈性的應(yīng)用模式實現(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ù)實驗中各組件的配置情況，所有虛擬服務(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)用在平臺支持下可以實現(xiàn)彈性。然而，要求應(yīng)用開發(fā)者學(xué)習(xí)并恰當(dāng)?shù)貙嵺`一種新模式是很困難的，本文提供一系列貼近開發(fā)者編程習(xí)慣的庫函數(shù)，幫助應(yīng)用實現(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é)點。

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

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

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

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

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

3.5 彈性驗證

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

Table 2 Improved consistent Hashing algorithm表2 改進的一致性哈希算法

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

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

Figure 4 Validation of elasticity圖4 彈性驗證

4 結(jié)束語

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

撐庫，最后通過實驗驗證模式的有效性。對Web 2.0應(yīng)用采用基本方法進行案例分析，提出了PSP模式并給出了支撐平臺解決方案，通過實驗驗證了平臺的彈性，證明了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.