上下文感知的分布式緩存數據重均衡方法

朱 鑫，蒲 衛，秦秀磊，張文博，鐘 華

（1.中國科學院軟件研究所 軟件工程技術研究開發中心，北京100190；2.中國科學院研究生院，北京100190；3.解放軍衛生信息中心，北京100842）

0 引 言

作為一種新的基于互聯網的IT服務增值、使用和交付模式，云計算自產生以來就得到工業界和學術界的廣泛關注，目前正變成商業上的現實［1］。云計算環境下，為了解決傳統關系型數據庫的性能瓶頸，分布式緩存技術得到廣泛應用，為用戶提供高性能、高可用、可伸縮的數據緩存服務。從云計算三層服務模式（基礎設施即服務（IaaS）、平臺即服務（PaaS）、軟件即服務（SaaS））的角度劃分，分布式緩存位于PaaS層，提供應用加速與平臺的狀態維護服務。

由于應用數據訪問的不均衡性，緩存系統中往往存在若干熱點數據分區，包含較多熱點數據分區的節點負載較高，易達到性能瓶頸，而應用訪問模式的時變性也會導致熱點數據分區的分布隨時間而變化［2］。因此緩存系統需要定期地執行數據重均衡操作，以保障數據和負載在各節點間均衡分布，最大化資源利用率，提升系統性能。

數據遷移過程中，緩存系統的性能會下降。如根據淘寶Tair［3］的遷移數據訪問機制，對某些訪問請求需要增加一次服務器轉發操作，導致系統的平均響應時間增加。因此在制定數據重均衡方案時，應盡量縮短遷移時間。

當前主流的云平臺均使用虛擬化技術來屏蔽底層硬件的差異性及實現資源的快速部署。如亞馬遜的EC2和微軟的 Windows Azure分別使用了基于Xen［4］和基于 Hyper－V的虛擬化技術。對于部署在云平臺中的緩存系統而言，節點間的數據遷移會受到以下兩方面環境上下文的影響：

（1）遷移節點的物理位置：遷出節點（數據分區從其遷出的緩存服務器節點）和遷入節點（數據分區遷入的緩存服務器節點）所在的VM可能位于同一臺物理機，也可能位于不同的物理機。兩種情況下數據遷移的物理路徑有顯著差別，因而遷移速度不同。

（2）VM間性能干擾：由于VM間存在性能干擾，無論是同一物理機內還是跨物理機的數據遷移的速度都會隨著物理機上部署的VM數量和運行狀態的變化而變化。

本文在基于Xen虛擬化技術搭建的VM集群上部署分布式緩存系統，研究環境上下文對分布式緩存數據重均衡的影響，提出了一種上下文感知的分布式緩存數據重均衡方法。該方法由兩部分組成：①遷移時間預測模型。根據VM狀態預測物理機內和物理機間遷移一定數據量所需的數據遷移時間，為數據重均衡方案的制定提供依據。②上下文感知的數據重均衡算法?；趯彺鏀祿謪^數據量和網絡流量的細粒度監測，該算法同時考慮緩存數據量均衡，網絡流量均衡和遷移時間較短這3個優化目標，以制定有效的數據重均衡方案。使用Yahoo公司的云存儲服務測試基準YCSB［5］對上述方法進行了測試，實驗結果表明，該方法能夠準確預測遷移時間，上下文感知的數據重均衡算法與傳統數據重均衡算法相比，能夠提供較好的均衡效果及較短的遷移時間。

本文的研究工作基于中科院軟件所自主研發的分布式緩存系統OnceDC［6］進行。OnceDC采用類似亞馬遜Dynamo［7］的分區機制，數據被存儲在分區中，單個緩存服務器節點（簡稱緩存節點）可包含多個分區。此外OnceDC采用緩存客戶端主動路由及緩存集群管理器集中管理的方式。

1 研究動機

1.1 Xen的I／O模型

在基于Xen的虛擬化體系結構中，每個客戶操作系統都運行在一個虛擬域（domain）中。其中，dom0是特權域，擁有原生設備驅動，具有直接訪問I／O設備的特權，并通過和Xen虛擬機控制器（virtual machine monitor，VMM）的交互來控制和管理其它的虛擬域（稱為domU）。dom0向domU提供I／O設備模型和平臺，domU訪問IO資源均需經過dom0進行。如圖1所示。

圖1中，假設dom1（準確的講是對應的VM，下同）需要和dom2進行網絡通信，那么，他們之間發送的網絡包會通過dom0傳遞，但不會經過物理網卡。而如果dom1要和另一臺物理機上的某個VM通信，網絡包會經過兩臺物理機的dom0，同時會經過兩臺物理機的網卡。由于物理機內和物理機間VM通信均會經過dom0，因此一臺物理機上有多個VM同時進行網絡I／O操作時會發生性能干擾。

圖1 Xen的I／O模型

1.2 虛擬化環境上下文對遷移時間的影響

1.2.1 實驗方案

為了研究Xen虛擬化環境下遷移節點所處的物理位置以及VM間性能干擾對數據遷移產生的影響，我們基于YCSB生成客戶端負載，然后在不同環境上下文條件下遷移數據，尋找遷移時間的變化規律。實驗基于的軟硬件環境與3.1節一致。在每個VM上部署1個OnceDC緩存服務器節點。變化部署的VM數量時，通過改變YCSB實例的個數，保證每個緩存節點承擔的負載不變。執行一條遷移命令將定量數據從一個緩存節點遷移到另一個緩存節點，統計遷移時間。

1.2.2 實驗結果分析

圖2給出了遷出節點與遷入節點所在VM位于同一個物理機和不同物理機這兩種情況下分別遷移50M，100M，200M，300M數據所用的時間。可以看到跨物理機間的遷移相比同一物理機內的遷移，需要消耗更多的時間，并且隨著遷移數據量的增加，兩者之間的差距也在增大。

圖2 緩存節點物理位置對遷移時間的影響

圖3對比了部署不同數量VM的情況下，位于同一物理機內的兩個緩存節點間分別遷移50M，100M，200M，300M數據所用的時間。對于每種遷移數據大小的一組數據，均以僅部署兩個VM時的遷移時間為基準標準化。由圖3可知，同一物理機內的兩個緩存節點間遷移數據時，VM間的性能干擾使遷移時間最多增加了近2倍（遷移50M數據時）。

圖3 VM間性能干擾對遷移時間的影響（物理機內遷移）

圖4對比了部署不同數量VM的情況下，位于不同物理機的兩個緩存節點間分別遷移50M，100M，200M，300M數據所用的時間。VM＝（x，y）表示遷出節點和遷入節點所在的物理機中分別部署了x與y個VM。對于每種遷移數據大小的一組數據，均以VM＝（1，1）時的遷移時間為基準標準化。由圖4可知，物理機間遷移數據時，VM間的性能干擾對遷移時間的影響更為顯著，遷移時間最多增加了3倍。

綜上可見，遷移節點所處物理位置和VM間的性能干擾對緩存系統的數據遷移具有無法忽略的影響，因此在制定數據遷移計劃時需要考慮該因素。

1.3 XenMon工具數據分析

1.3.1 實驗方案

基于XenMon［8］工具對性能干擾因素進行深入分析。XenMon是由惠普實驗室開發的一款應用于Xen平臺的性能監測工具。其底層使用xentrace和xenbaked收集數據，前端使用Python編寫的xenmon提供界面展示。變化物理機上緩存節點（VM）的部署數量，分別在物理機內和物理機間遷移100M數據，使用XenMon監測遷移過程中Xen平臺的性能。其它實驗設計與1.2節一致。

1.3.2 實驗結果分析

圖5給出了在物理機內遷移時，遷出節點所在domain（dom1）部分性能指標隨VM數量的變化情況。各監測指標均以部署2個VM時的測量值為基準標準化。隨著VM數量的增加，VM對網絡資源的競爭越來越激烈，因而dom1在I／O等待隊列的時間逐漸增長（blocked（%）＿dom1）；系統中運行隊列的長度得以降低，處于可運行狀態（runnable）的VM獲得時間片相對容易，導致等待時間逐步降低（waited（%）＿dom1）；I／O阻塞越來越多，導致消耗的CPU資源降低（cpu（%）＿dom1），同時每秒執行次數降低（ex／s＿dom1）。

圖6給出了在物理機間遷移時，遷出節點所在domain（dom1）及其所在物理機的dom0部分性能指標隨VM數量的變化情況。各監測指標以VM＝（1，1）時的測量值為基準標準化。隨著VM數量的增加，各VM間I／O競爭越來越激烈，因而dom0進入阻塞狀態及I／O切換的次數增加（Block＿dom0與Switch＿dom0），內存頁映射次數增加（PageMap＿dom0）；系統中運行隊列的長度得以降低，遷出節點所在VM處于可運行狀態（runnable）時獲得時間片相對容易，導致每次執行的等待時間降低（Waited／ex＿dom1）。

圖6 XenMon監測指標隨VM數量的變化（物理機間遷移）

可見，XenMon的監測數據反映了VM間性能干擾的程度。

2 上下文感知的分布式緩存數據重均衡方法

由上文可知，①遷移節點所處的物理位置以及VM間性能干擾對分布式緩存的數據遷移具有無法忽略的影響。②XenMon收集的監控數據指標較好的反映了Xen虛擬化環境下VM間的性能干擾。③數據重均衡過程的一個重要的優化目標是盡可能的減少數據遷移時間。因此本章首先基于統計學習方法建立虛擬化環境下XenMon收集的底層監測數據與遷移時間之間的映射關系，即遷移時間預測模型；然后以該模型為基礎，提出一種基于細粒度資源監測的上下文感知的數據重均衡算法，從而改善虛擬化環境下緩存系統的性能。

2.1 遷移時間預測模型

2.1.1 模型目標

我們的目標是建立XenMon監測數據，遷移數據量與遷移時間的映射關系。具體來說，希望建立如下函數

pi（1＜＝i＜＝m），qi（1＜＝i＜＝n）分別為物理機內和物理機間遷移時間預測模型選取的監測指標。M＿Size表示遷移數據量，y表示遷移時間。

2.1.2 監測指標的選取

XenMon包含的監測指標較多，在分析了各指標的意義后，我們選擇關注如表1所示的監測指標。

表1 XenMon監測指標的選取

表1中包含的各監測指標的含義說明如下：

·CPU（%）：domU使用cpu的時間占對應統計間隔的百分比。

·Blocked（%）：domU由于等待I／O事件發生而阻塞的時間占對應統計間隔的百分比。

·Waited（%）：domU處于可運行狀態，等待被調度的時間占對應統計間隔的百分比。

·Waited／ex：domU平均每次被調度運行需要等待被調度的時間。

·Ex／s：domU每秒被調度運行的次數。

·Wake：統計間隔內dom0被喚醒的次數。

·Block：統計間隔內dom0等待I／O事件發生所用的時間。

·Switch：統計間隔內系統中發生的domU切換次數。

·PageMap：統計間隔內發生的頁映射次數。

2.1.3 數據預處理

為了減少監測指標數量級間的差異對建模過程產生的影響，我們對收集到的監測數據進行Z標準化（Z－standardization）處理，如式（4）所示

式中：μ、σ——所有樣本的均值、方差，X——樣本值，X＊——標準化后的值。

2.1.4 線性模型

我們基于回歸分析的方法構建線性預測模型，函數關系式如式（5）、式（6）所示。物理機內數據遷移

式中：αi，βi，δi，μ——回歸系數，c1——常量。

物理機間數據遷移

式中：αi，δi，βi，χi，μ——回歸系數，c2——常量。

在構建線性模型的過程中，我們采用了兩種方法：主成分分析法和逐步回歸法。

（1）主成分分析法

主成分分析（principal components analysis，PCA）也稱為主分量分析，是一種對高維變量進行綜合與降維的統計分析方法。我們先使用主成分分析從原變量中提取出若干具有最佳解釋能力的新綜合變量（也稱成分），這些綜合變量由原變量線性組合得到，可以反映初始變量的大部分信息，如式（7）所示。然后將上述成分作為回歸變量進行最小二乘回歸分析得到最終的模型。我們稱這種方法建立的線性模型為PCA－LM。

（2）逐步回歸法

在線性回歸模型中，若干變量或全部變量的樣本觀測值之間可能存在某種線性關系，這種現象即多重共線性，該現象會降低模型估計的精度。逐步回歸（stepwise regression）是一種常用的消除多重共線性、選取 “最優”回歸方程的方法。其做法是逐個引入自變量，引入的條件是該自變量經F檢驗（F－test）是顯著的，每引入一個變量后，對已選入的變量進行逐個檢驗，如果原來引入的變量由于后面變量的引入而變得不再顯著，那么就將其剔除。引入一個變量或從回歸方程中剔除一個變量，為逐步回歸的一步，每一步都要進行F檢驗，以確保每次引入新變量之前回歸方程中只包含顯著的變量。這個過程反復進行，直到既沒有不顯著的變量選入回歸方程，也沒有顯著變量從回歸方程中剔除為止。我們首先使用逐步回歸方法消除冗余指標，然后基于最小二乘法求解模型。將使用這種方法建立的線性模型稱作Stepwise－LM。

2.1.5 非線性模型（nonlinear models）

我們首先采用主成分分析法對監測指標進行降維處理，然后構建一個面向主成分的完全二次多項式函數，如式（8）所示

式中：ai，bij、di——回歸系數，c——常量，Fi（1≤i≤m）為主成分。在構建該函數時，采用高斯－牛頓（Gaussi－Newton）法進行最小二乘擬合。將這種方法建立的非線性模型簡稱為PCA－NLM。

2.1.6 模型的訓練

我們使用迭代的方法完成模型的訓練，選用的訓練參數如表2所示。具體做法是首先選取參數的邊界值組合作為輸入，運行實驗并收集采樣數據，接下來隨機選取邊界之間的若干組值再次作為輸入收集訓練數據。對訓練得到的模型的預測錯誤率進行評估，如果高于設定的閾值（如30%），則進一步將輸出值細分，判斷每個區間的覆蓋情況。如果沒有覆蓋，則增加能較好覆蓋這部分區間的訓練數據。

表2 訓練模型使用的輸入負載

2.2 上下文感知的數據重均衡算法

根據上一節得到的遷移時間預測模型，對于給定的上下文（遷入遷出節點的物理位置，相關domain的XenMon監測數據），可以求得遷移指定數據量所需的遷移時間。為了改善數據重均衡的效果，同時降低遷移時間，本節基于上述模型提出一種上下文感知的數據重均衡算法（contextaware data rebalancing algorithm），簡稱CADR算法。

為方便描述，先給出如下定義：

定義1 緩存集群C中包含n個緩存節點，分別用S1，S2，……，Sn表示。size［Si］為Si上的分區個數，Si上的第j個數據分區用Sij表示。

定義2mem［Sij］，net［Sij］分別為Sij的數據量和網絡流量。mem［Si］和net［Si］分別為Si上各分區數據量與網絡流量之和，mem－cap［Si］，net－cap［Si］分別為Si的內存限額和網絡流量限額。

定義3 分別用mem－rate［Si］和net－rate［Si］表示節點Si的內存利用率和網絡利用率，mem－rate［Si］＝mem［Si］／mem－cap［Si］，net－rate［Si］＝net［Si］／netcap［Si］。定義節點Si的綜合利用率為內存利用率和網絡利用率之乘積，用mn－rate［Si］表示。

約束1：為了減少遷移時間，我們設定單個緩存節點的遷移方向是固定的，即在一次數據重均衡過程中不會同時有數據分區的遷入和遷出。

CADR算法存在以下3個優化目標：①緩存節點的數據量均衡；②緩存節點的網絡流量均衡；③數據遷移所需時間盡可能短。

CADR算法偽代碼如圖7所示，說明如下：

（1）1－2行，按照mn－rate將節點劃分進遷出節點集合out－set及遷入節點集合in－set。ε為一個大于1的常數，變化ε可以調整算法最終的均衡度及遷移的數據量。

（2）第4行從out－set中選出mn－rate值最高的節點Sf作為當前步的遷出節點。第5－8行從Sf中選出當前步的遷移分區，使得遷出節點的內存利用率和網絡利用率之比盡量接近緩存集群的平均值。

（3）第9－19行基于3.1節得到遷移時間預測模型，從in－set中選出一個節點St存放分區P，使得遷移時間最短。

（4）第20行將＜Sf，St，P＞加入遷移計劃中，第21－22行更新Sf，St相應的統計量。

第9行比較耗時，設其平均時間復雜度為O（l），再設緩存集群中分區總數為m，緩存節點數為n，則CADR算法的整體復雜度為O（m（n（l）。遷移時間預測模型使用離線訓練的方式得到，在線預測遷移時間時所需的Xen－Mon監控數據通過運行在dom0上的agent收集并定期發送給緩存集群管理器。

CADR算法由緩存集群管理器觸發執行。根據其返回結果能夠生成新的分區路由信息及遷移計劃。為了避免遷移流量過大影響緩存系統的持續可用性，可在遷出節點實施流量控制。此外，應實現遷移數據訪問協議以能持續訪問遷移中的數據分區。這兩方面內容在［6］中作了討論。

圖7 CADR算法

3 實驗結果與分析

我們在OnceDC上實現了上下文感知的分布式緩存數據重均衡方法。本章通過實驗證明該方法的有效性。

3.1 實驗方案

實驗環境拓撲結構圖如圖8所示。S1，S2，S3為三臺16核的刀片機，我們在所有刀片機上安裝了Xen虛擬化環境。在每個刀片上部署若干個VM，并在每個VM上部署一個緩存服務器節點。測試客戶端使用YCSB，且每個YCSB實例部署在4核的普通PC上。YCSB所在物理機和S1，S2，S3之間使用1Gbps的以太網連接。OnceDC的緩存集群管理器部署在一臺4核PC上。表3給出了實驗環境配置。

圖8 實驗環境拓撲結構

表3 實驗環境配置

在兩次實驗中，每個YCSB實例運行500線程，讀寫比設為4∶1，每條緩存數據的大小為4KB。

3.2 實驗1：遷移時間預測模型的準確度

對于2.1節使用3種方法分別創建的遷移時間預測模型PCA－LM、Stepwis－LM和PCA－NLM，通過實驗測量預測錯誤率的方法來評價其準確度。預測錯誤率定義為

3.2.1 物理機內遷移

在S2和S3上分別部署8和10個VM（緩存節點）。部署6個YCSB實例產生負載，YCSB使用uniform負載模式。變化S1上部署的VM（緩存節點）的數目（4，6，8，10），對于這4種情況，通過緩存集群管理器發出將定量數據（50M，100M）從S1上的一個緩存節點遷移到另一個緩存節點的命令，統計遷移時間，同時收集VM性能數據，按照各模型計算預測的遷移時間。每組配置重復實驗5次，分別計算預測錯誤率，最后取平均值。這樣得到物理機內遷移時3種模型的預測錯誤率如圖9所示。

由圖9可知，在物理機內遷移時，3種模型的預測錯誤率差別比較大，如在VM＝4時，PCA－LM模型的錯誤率超過30%，而Stepwise－LM模型的錯誤率為10%左右。Stepwise－LM模型在各種配置下均具有較低的預測錯誤率（低于13%）。

圖9 3種遷移時間預測模型的錯誤率（物理機內遷移）

3.2.2 物理機間遷移

在S3部署10個VM（緩存節點），部署6個YCSB實例來產生負載，YCSB使用uniform負載模式。變化S1，S2上部署的VM及緩存服務器的數目（（3，3），（5，3），（5，5），（3，7），（7，7））。對于這5種情況，通過緩存集群管理器發出將定量數據（50M，100M）從S1上的一個緩存節點遷移到S2上另一個緩存節點的命令，統計遷移時間，同時收集VM性能數據，按照各模型計算預測的遷移時間。每組配置重復實驗5次，分別計算預測錯誤率，最后取平均值。這樣得到物理機間遷移時3種模型的預測錯誤率如圖10所示。

圖10 3種遷移時間預測模型的錯誤率（物理機間遷移）

由圖10可知，在物理機間遷移時，3種模型的預測效果都比較理想。其中PCA－NLM模型具有最低的預測錯誤率（低于10%）。

由本實驗可知，遷移時間預測模型具有較高的準確度。

3.3 實驗2：數據重均衡算法的有效性

OnceDC原有的數據重均衡算法，也以整個緩存集群的數據量和網絡流量均衡為目標，不過其只對每個緩存節點具有的數據量和網絡流量進行了監測，因此在制定遷移計劃時將一個節點上的多個分區等同對待，忽略了各分區之間數據量和網絡流量的差異；同時它也沒有考慮虛擬化環境上下文對遷移時間的影響。我們稱之為SPDR算法（simple partition based data rebalancing algorithm）。本節比較分別使用CADR算法和SPDR算法進行數據重均衡的效果，以驗證CADR算法的有效性。

實驗時，在S1，S2，S3上分別部署12，8，10個VM及緩存服務器節點。使用6個YCSB實例來生成訪問負載，YCSB按照表4所示的負載模式訪問緩存集群。配置緩存集群每2分鐘執行一次數據重均衡操作。分別配置SPDR算法和CADR算法進行實驗，結果如圖11所示。

表4 實驗2YCSB的負載模式

圖11 SPDR算法與CADR算法比較

緩存集群初始時按照基于負載權重的分區機制在各緩存節點分配數據分區［6］。由于YCSB的負載模式是latest，導致各緩存節點存在數據量和網絡流量不均衡的現象，部分緩存節點cpu和網絡利用率接近100%，而某些節點的資源未得到充分使用。在120s，緩存系統第一次運行數據重均衡算法，緩存系統進入不穩定（遷移）狀態。在重均衡過程中，由于訪問遷移中的數據開銷較大，緩存系統的平均響應時間增大。在重均衡完成后，瓶頸緩存節點得到消除，因此系統的平均響應時間與重均衡前相比變小。在180 s，YCSB的負載模式從latest變成zipfian。各緩存節點的負載分布再一次出現不均衡，平均響應時間增大。240s時，第二次數據重均衡操作被觸發。與第一次類似，在重均衡過程中，平均響應時間增大，重均衡結束后平均響應時間降到比重均衡前更小的水平。

與SPDR算法相比，CADR算法基于對每個分區的細粒度監控，更好地實現了數據量和網絡流量的均衡，因此執行完數據重均衡后平均響應時間更低；同時在制定數據重均衡方案時考慮了虛擬機環境上下文的影響，優先選取遷移時間較短的方案，因此系統的性能抖動區間更小。

上述兩個實驗表明，針對部署在虛擬化環境下的緩存系統而言，本文提出的遷移時間預測模型具有較高的準確度；上下文感知的數據重均衡算法具有更好的均衡效果且遷移時間更短，能夠有效降低緩存系統的平均響應時間，提高系統性能。

4 相關工作

Mei等人［9－10］針對虛擬化環境下VM間的性能干擾問題進行了研究。該研究工作表明，當網絡I／O密集型或cpu密集型應用部署在同一物理機時，應用的性能會受到VM間性能干擾的影響。

現有工業界的分布式緩存系統如 Memcached，Terracotta EX，Oracle Coherence等大多不支持在運行時動態地進行數據重均衡，無法適應異構集群環境及實際數據訪問情況的多樣性。

美國東北大學的Kunkle［11］等人的研究工作在制定遷移計劃的同時考慮了遷移開銷的優化。作者定義了定值（constant）、線性（linear）、基于經驗的（empirical）和非線性（non－linear）等多種模型。遷移算法迭代地選取開銷最小的分區遷移方案。該工作的不足是未考慮遷移時間的影響。

加州大學圣巴巴拉分校的Das等人［12－13］針對多承租場景下數據庫集群的數據遷移問題，提出了一種輕量級的、基于迭代復制的數據遷移方法，目標是盡可能降低遷移開銷。作者同時給出了遷移過程中各種失效的處理及正確性證明。

Kari［14］將存儲系統的數據遷移問題規約為圖著色（multi－edge coloring problem）問題，目標是在滿足各存儲節點傳輸約束的前提下，使數據遷移消耗的時間片最少，即使用的顏色數量最少。與本文關注數據重均衡方案的制定不同，該文關注的是數據重均衡方案制定好后，如何有效的制定遷移計劃，縮短全局遷移持續時間的問題。

本文提出的上下文感知的分布式緩存數據重均衡方法面向云虛擬化環境，同時考慮數據量和網絡流量的均衡，并且盡可能的減少了遷移時間。

5 結束語

虛擬化環境中，遷移節點的物理位置及VM間性能干擾會對緩存數據遷移產生無法忽略的影響。本文提出一種遷移時間預測模型建模這種影響，在此基礎提出一種基于細粒度資源監測的上下文感知的數據重均衡算法。實驗結果表明，本文方法能夠準確預測遷移時間，有效地均衡應用變化的負載，同時降低遷移時間，從而改善緩存系統性能。

［1］Armbrust M.Above the clouds：A berkeley view of cloud computing［R］.Berkeley，California：EECS Department，University of California，2009：1－25.

［2］Zhang Gong，Chiu L，Liu Ling.Adaptive data migration in multi－tiered storage based cloud environment［C］／／Miami，FL：Proc of IEEE 3rd Int’l Conf on Cloud Computing，2010：148－155.

［3］Taobao tair［EB／OL］.［2012－03－12］.http：／／code.taobao.org／p／tair／wiki／aboutus／.

［4］Barham P，Dragovic B，Fraser K，et al.Xen and the art of virtualization［C］／／New York，USA：Proc of ACM SOSP，2003.

［5］Cooper B，Silberstein A，Tam E，et al.Benchmarking cloud serving systems with YCSB［C］／／Indianapolis，Indiana，USA：Roceedings of the 1st ACM Symposium on Cloud Computing，2010：143－154.

［6］ZHU Xin，QIN Xiulei，WANG Lianhua，et al.Research on dynamic scaling of elastic distributed cache systems［J］.Frontiers of Computer Sciences and Technology，2012，6（2）：97－108（in Chinese）.［朱鑫，秦秀磊，王聯華，等.彈性分布式緩存動態擴展方法研究［J］.計算機科學與探索，2012，6（2）：97－108.］

［7］Hastorun D，Jampani M，Kakulapati G，et al.Dynamo：Amazon’s highly available key－value store［C］／／Washington State，USA：Proc of ACM Symp on Operating Systems Principles，2007：205－220.

［8］Gupta D，Gardner R，Cherkasova L.XenMon：QoS monitoring and performance profiling tool［R］.Hewlett－Packard Labs，Technical Report HPL－2005－187，2005.

［9］Mei Yiduo，Liu Ling，Pu Xing，et al.Performance measurements and analysis of network I／O applications in virtualized cloud［C］／／Miami，FL：CLOUD，2010.

［10］Pu Xing，Liu Ling，Mei Yiduo，et al.Understanding performance interference of I／O workload in virtualized cloud environments［C］／／Miami，FL：CLOUD，2010.

［11］Kunkle D，Schindler J.A load balancing framework for clustered storage systems［C］／／Berlin，Heidelberg：Proceedings of 15th International Conference on High Performance Computing，2008：57－72.

［12］Das S，Nishimura S，Agrawal D，et al.Albatross：Lightweight elasticity in shared storage databases for the cloud using live data migration［J］.Proceedings of the VLDB Endowment，2011，4（8）：494－505.

［13］Elmore AJ，Das S，Agrawal D，et al.Zephyr：Live migration in shared nothing databases for elastic cloud platforms［C］／／Athens，Greece：SIGMOD，2011：301－312.

［14］Kari C，Kim Y，Russell A.Data migration in heterogeneous storage systems［C］／／Minneapolis，MN：In Proceedings of The 31st Int’l Conference on Distributed Computing Systems，2011：143－150.