分布式應用彈性支撐機制的研究與實現

賈翔龍，吳 剛

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

1 引言

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

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

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

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

2 基本研究方法

本文的目標是提高分布式應用自身的彈性，以適應云計算環境下隨著負載量變化而動態調整資源使用量的需求。影響分布式應用彈性的因素有很多，但是從配合以虛擬機為粒度的資源擴展角度，分布式系統的架構設計起決定性作用。

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

我們把工作的步驟和內容總結如下，其流程如圖1所示：

(1)分析應用特征；

(2)根據特征提出適合彈性的應用模式；

(3a)設計和優化平臺架構，以支撐該應用模式的實現；

(3b)為方便應用實現這種模式，平臺需要提供相關的彈性支撐庫，設計庫函數接口；

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

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

(6)平臺搭建成功。

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

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

3 面向Web 2.0的應用模式與彈性支撐庫設計

3.1 Web 2.0應用特征分析

維基百科對Web 2.0的定義是`“一個利用Web平臺、由用戶主導生成內容的互聯網產品模式”。具有代表性的Web 2.0應用是社交網絡服務(Service Network Service)，從技術角度看，Web 2.0應用具有負載波動性強、對部分數據的一致性要求較弱、需要支持大量音頻/視頻/圖片等格式的文件下載等特點。

3.2 提出應用模式

根據Web 2.0應用的特點，本文總結出適合實現彈性的PSP(Processor-State-Persistent)應用模式，描述如下：

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

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

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

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

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

Figure 2 PSP pattern圖2 PSP模式

Processor：接收用戶請求，按業務邏輯執行運算，返回響應。Processor本身是無狀態(Stateless)的，中間運算結果由CN保存，會話數據由SDN保存，持久數據由PDN保存。

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

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

CN(Cache Node)：保存持久數據的緩存以及Processor的中間運算結果，原則上Processor可以訪問CN保存的所有內容。

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

3.3 平臺架構

前文指出，體系架構的設計對支撐彈性的應用模式實現有決定性作用，本文給出了支持PSP模式應用的平臺架構，如圖3所示。

Figure 3 Architecture of platform for Web 2.0 applications圖3 Web 2.0平臺架構

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

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

3.4 彈性支撐庫的設計

3.4.1 接口設計

如3.2節所述，符合PSP模式的Web 2.0應用在平臺支持下可以實現彈性。然而，要求應用開發者學習并恰當地實踐一種新模式是很困難的，本文提供一系列貼近開發者編程習慣的庫函數，幫助應用實現PSP模式。對彈性支撐庫的接口設計如下：

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

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

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

addSvr($type)、rmSvr($name)：添加、移除指定節點。

3.4.2 關鍵算法改進

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

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

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

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

3.5 彈性驗證

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

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

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

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

Figure 4 Validation of elasticity圖4 彈性驗證

4 結束語

本文面向應用本身的彈性需求和擴展方法展開研究，提出了實現彈性機制的基本研究方法：首先總結應用特征，提出適合實現彈性的應用模式，然后根據應用模式設計平臺架構和相應的彈性支

撐庫，最后通過實驗驗證模式的有效性。對Web 2.0應用采用基本方法進行案例分析，提出了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.