蔣 溢，孫雪濤，楊 川

（1.重慶郵電大學(xué) 計算機科學(xué)與技術(shù)學(xué)院，重慶400065；2.中國電信股份有限公司瀘州分公司，四川 瀘州646000）

0 引 言

云存儲通過集群技術(shù)、網(wǎng)格技術(shù)或分布式文件系統(tǒng)等，將網(wǎng)絡(luò)中不同類型的存儲設(shè)備協(xié)同起來，共同對外提供數(shù)據(jù)存儲和業(yè)務(wù)訪問服務(wù)。云存儲提出后，得到了眾多廠商的支持和關(guān)注。Amazon推出了EC2［1］（彈性計算云）云存儲產(chǎn)品S3［2］，旨在為用戶提供互聯(lián)網(wǎng)服務(wù)形式同時提供更強的存儲和計算功能。隨后微軟也已經(jīng)推出了提供網(wǎng)絡(luò)移動 硬 盤 服 務(wù) 的 Windows Live SkyDrive［3］。Apache 根 據(jù)Google的 GFS［4］和 Bigtable［5］也 先 后 推 出 了 HDFS［6］和HBase［7］，為云計算環(huán)境提供計算和存儲的支持。

本文基于開源Openstack［8］的對象存儲環(huán)境，首先分析了Openstack的Swift［9］對象存儲架構(gòu)，針對其對象存儲沒有元數(shù)據(jù)中心節(jié)點、系統(tǒng)數(shù)據(jù)讀寫通過哈希一致性算法［10］完成，并沒有充分利用對象存儲系統(tǒng)的備份機制來改善系統(tǒng)數(shù)據(jù)讀取速度的現(xiàn)狀，給出了一種能夠均衡存儲設(shè)備I／O負載的策略，并在文章最后給出了相關(guān)實驗過程，實驗結(jié)果驗證了本文給出的策略的有效性。

1 Swift對象存儲架構(gòu)

1.1 swift簡介

OpenStack Object Storage （Swift）是 OpenStack開 源云計算項目的子項目之一，被稱為對象存儲。Swift適用于永久類型的靜態(tài)數(shù)據(jù)的長期存儲，尤其適合存儲虛擬機鏡像、圖片存儲、郵件存儲和存檔備份等類型的數(shù)據(jù)。

1.2 Swift架構(gòu)概述

Swift主要有4個組成部分：Proxy Server（代理服務(wù)）、Storage Server （存儲服 務(wù)）、Consistency Server （一致性服務(wù)）、Ring（環(huán)狀結(jié)構(gòu)）文件，結(jié)構(gòu)如圖1所示。

圖1 Swift組件結(jié)構(gòu)

其中，Proxy Server是提供Swift API的服務(wù)器進程，負責(zé)Swift其余組件間的相互通信；Storage Server提供了磁盤設(shè)備上的存儲服務(wù)；Consistency Servers是保持一致性的服務(wù)器，其目標(biāo)是查找并解決由數(shù)據(jù)損壞和硬件故障引起的不一致性；Ring文件是它整個Swift中最重要的組件，其主要作用是用于記錄存儲對象與物理位置間的映射關(guān)系，Ring使用域 （Zone）、設(shè)備 （Device）、分區(qū) （Partition）和副本 （Replica）來維護這些映射信息。

2 Swift對象存儲文件讀取策略

Swift中存儲對象通過3個邏輯層次來實現(xiàn)的，分別是Account（賬戶）、Container（容器）、Object（對象）。一個Account包含多個Container，而一個Container又包含多個Object。所有每個對象的邏輯路徑都是／Account name／Container name／Object name。Swift中對對象 （Object）的讀寫是通過Ring文件來完成的。Ring文件的作用就是將上面的對象邏輯路徑和實際對象存儲的物理位置的映射。

2.1 哈希一致性算法

哈希一致性算法是1997年由麻省理工學(xué)院提出的一種分布式哈希 （DHT）實現(xiàn)算法，其基本原理是將機器節(jié)點和key值都按照一樣的hash算法映射到一個0～2＾32的圓環(huán)上。當(dāng)有一個寫／讀的請求到來時，計算Key值k對應(yīng)的哈希值Hash（k），如果該值正好對應(yīng)之前某個機器節(jié)點的Hash值，則直接寫／讀該機器節(jié)點，如果沒有對應(yīng)的機器節(jié)點，則順時針查找下一個節(jié)點，進行寫／讀，如果超過2＾32還沒找到對應(yīng)節(jié)點，則從0開始查找 （因為是環(huán)狀結(jié)構(gòu)）。如圖2所示。

在Swift中為了系統(tǒng)的擴展性在哈希環(huán)上對應(yīng)的不再是真實的硬盤或者分區(qū)，而是采用了虛擬節(jié)點，然后再由虛擬節(jié)點對應(yīng)到真實的節(jié)點 （多對一）。這里的虛擬節(jié)點即是上文中提到的Ring中的Partition，Device則對應(yīng)真實的節(jié)點。

圖2 哈希一致性算法

2.2 Swift中基于哈希一致性算法的讀取策略

首先，當(dāng)系統(tǒng)接受到客戶發(fā)來的請求，先進行用戶身份的驗證，當(dāng)驗證成功后，再將請求傳給Proxy Server。其次，Proxy Server通過Ring來將對象的邏輯路徑通過哈希一致性算法進行處理，將生成的哈希字符串的前一部分與Ring文件中的partition列表中的partition哈希值進行對比，如果值相等，則該對象在這個partition中。再通過Devices表讀取該Partition所存在的物理位置，最后讀取數(shù)據(jù)對象本身，并將讀取數(shù)據(jù)通過Proxy Server返回給用戶。其讀取流程如圖3所示。

圖3 讀策略流程

由此可見，文件讀取的時候非常容易出現(xiàn)磁盤利用率不平衡的情況，如果某一個磁盤I／O請求隊列中有大量請求，而受硬盤串行工作機制的限制，讀寫文件的速度會大幅降低，這是由于磁盤臂會頻繁地尋道。并且當(dāng)并發(fā)請求量越大，讀寫的速度會越低。例如IDE 7200轉(zhuǎn)的硬盤讀寫速度一般能達到30M／S左右，但是當(dāng)同時讀取兩個文件時，硬盤讀寫速度只有10M／s左右。

由于讀取負載不均衡問題極大地限制了系統(tǒng)整體I／O性能，所以設(shè)法均衡各個磁盤的I／O請求，實現(xiàn)并行的讀取成為必要。

3 基于I／O負載均衡的讀取策略

3.1 策略分析

由于Swift為了數(shù)據(jù)的存儲安全每個partition都有2個副本，也就是說一個系統(tǒng)中將有3份同樣的數(shù)據(jù)存在。這兩個副本的作用是用來做數(shù)據(jù)安全備份的，一旦當(dāng)swift數(shù)據(jù)損壞時，可以用這兩個副本進行恢復(fù)。但是當(dāng)進行文件讀取的時候，這兩個備份文件一般情況下去沒有起到作用。Swift還有一個特性，那就是為了數(shù)據(jù)的安全，這3份數(shù)據(jù)每兩份都不能存在于系統(tǒng)的同一個Zone中。（zone可以是一個硬盤，一個服務(wù)器，一個機架，一個交換機，甚至是一個數(shù)據(jù)中心）。所以可以得出不同的Zone肯定不在同一塊硬盤上，如果能利用3個備份在不同硬盤上的特點，使讀取的請求更加平均的分布在不同的硬盤上，將提高swift的讀取效率。本文仍然基于原有的哈希一致性算法實現(xiàn)數(shù)據(jù)的讀寫，采用添加加權(quán)法來使讀取負載更加均衡。

本文策略的核心在于使文件讀取的請求盡可能平均地分布在各個硬盤上，并為每個存儲的partition維護一個權(quán)值，文件讀取的時候總是選擇權(quán)值最小的硬盤中的那個partition去讀取。

策略實現(xiàn)通過在Ring的Devices列表中添加相應(yīng)字段，并記錄每一個Device當(dāng)前的讀寫請求量。當(dāng)proxy收到客戶已驗證過的請求后，先在Ring中通過哈希一致性算法找到存儲該對象的partition。然后再通過Ring查找該partition的備份，根據(jù)這三份數(shù)據(jù)在Devices列表中找到設(shè)備表中對應(yīng)的設(shè)備。最后，根據(jù)存儲設(shè)備的負載按照一定的方法計算權(quán)值，并按權(quán)值進行排序，實現(xiàn)負載小的device中的partition優(yōu)先被選擇。如果3個備份的負載量相同那么就選取列表中的第一個，當(dāng)選擇完成后，更新List of Devices中的負載權(quán)值。

基于I／O負載均衡的讀取策略理論分析如下：

設(shè)系統(tǒng)的平均讀取速率為P，Rs為系統(tǒng)讀取請求的數(shù)量，Ci為某硬盤的I／O讀取極限速率，Rci為某塊硬盤上的請求數(shù)量，θci為該塊硬盤I／O極限速率和多個并行讀取請求時的速率之比

假如我們所有使用的硬盤都是同樣的，在Ci是相同的。則該式可簡化為

因為硬盤的串行工作機制的限制，當(dāng)我們并行讀寫多個文件時，速度比串行讀寫多個文件還要慢，多文件并行操作時，時間都花在磁頭擺動上了，所以θci隨著Rci的增加會迅速下降。由上面的公式中可以得出，當(dāng)Rci之間的值越接近，則P的值越大。

3.2 策略實現(xiàn)

對3.1描述的策略采用如圖4所示的實現(xiàn)流程：

首先當(dāng)系統(tǒng)接收到用戶的讀請求后。根據(jù)邏輯路徑的哈希值在列表中找到對應(yīng)的partition，然后在通過partition，找到該partition的備份replica。接著從一個partition和兩個replica所對應(yīng)的Device中找到負載最小的一個進行讀操作，并將對應(yīng)的Device的Load值加1。讀操作執(zhí)行完畢之后將該Device的Load值在減1。

圖4 策略流程

4 仿真實驗

4.1 實驗環(huán)境及方法

實驗采用Unix／Linux下提供的iostat來觀察物理磁盤的活動時間及其平均傳輸速度，并將結(jié)果寫入到監(jiān)測文件中。選擇1G字節(jié)大小的文件進行讀取實驗，原因在于大文件有利于查看測試數(shù)據(jù)并進行比對，便于對平均硬盤I／O數(shù)據(jù)進行分析。

實驗分為兩組。第一組是采用原有策略進行讀取實驗，第二組是采用基于I／O負載均衡的讀取策略進行實驗。兩組實驗中都分別對，1個、10個、50個、100個、500個、1000個、2000個文件同時讀取進行測試。

測試環(huán)境的物理架構(gòu)圖如圖5所示，Auth Node作為身份驗證主機Proxy Node作為接收和轉(zhuǎn)發(fā)客戶的讀寫請求，3個Storage Node作為3個Zone。

系統(tǒng)配置見表1。

圖5 實驗物理架構(gòu)

表1 系統(tǒng)配置

4.2 實驗結(jié)果

通過iostat監(jiān)測原有策略及本文基于I／O負載均衡策略的數(shù)據(jù)讀取速率，見表2。

表2 改進前策略數(shù)據(jù)平均讀取速率

通過iostat監(jiān)測更改算法后的讀取速率數(shù)據(jù)見表3。

將監(jiān)測到的數(shù)據(jù)在兩種策略下對比，并繪制成圖表如圖6所示。

表3 改進后策略數(shù)據(jù)平均讀取速率

圖6 數(shù)據(jù)平均速率對比

4.3 結(jié)果分析

由圖6可見，對單個文件進行讀取時，不存在并行讀取多文件，所以兩種算法速率一樣，且都接近硬盤的極限I／O速率。當(dāng)文件的讀取任務(wù)請求為10時。此時原有策略不會將讀取請求負載均衡到各個存儲設(shè)備上，所以整體讀取效率比較基于I／O負載均衡的讀取策略低。

隨后的兩組數(shù)據(jù)隨著讀取文件的數(shù)量逐漸上升，基于I／O負載均衡的讀取策略由于更好地均衡了讀取請求，所以速度下降的較慢。

實驗結(jié)果表明，原有策略隨著讀取請求負載的上升，讀取請求分配不均的現(xiàn)象會變得比較明顯，從而導(dǎo)致系統(tǒng)整體吞吐量下降。而改進后的算法，由于更好地分散了負載，所以能夠獲取更好的系統(tǒng)吞吐量。

5 結(jié)束語

云存儲集群具有即時并行讀取量大的特點，因此如何能將這些請求更加合理地平均的分配到各個硬盤上，對于提高整個系統(tǒng)的吞吐量尤為重要。本文主要通過改進數(shù)據(jù)讀取策略，均衡系統(tǒng)讀取負載，將讀取請求平均分配到各個存儲設(shè)備上，使得各個設(shè)備之間的I／O負載更加均衡，實現(xiàn)了并行讀取，提高了存儲平臺的整體讀取性能，文章通過實驗驗證了本文策略的有效性。

［1］Amazon Elastic Compute Cloud（Amazon EC2）［EB／OL］.［2012－11－18］.http：／／aws.amazon.com／cn／ec2／.

［2］Amazon Simple Storage Service （Amazon S3）［EB／OL］.［2012－11－18］.http：／／aws.amazon.com／cn／s3／.

［3］MicrosoftSkyDrive ［EB／OL］.［2012－11－18］.http：／／zh.wikipedia.org／zh－cn／Microsoft＿SkyDrive.

［4］Ghemawat S，Gobioff H，Leung S T.The Google file system［J］.ACM SIGOPS Operating Systems Review.ACM，2003，37 （5）：29－43.

［5］Hall K B，Gilpin S，Mann G.MapReduce／Bigtable for distributed optimization ［C］／／NIPS LCCC Workshop，2010.

［6］Tom Wbite.Hadoop the definitive guide ［M］.Tsang Tairan，ZHOU Aoying，transl.Beijing：Tsinghua University Press，2010 （in Chinese）.［Tom Wbite.Hadoop權(quán)威指南 ［M］.曾大冉，周傲英，譯.北京：清華大學(xué)出版社，2010.］

［7］Hbase Development Team.HBase：Bigtable－like structured storage for Hadoop HDFS ［EB／OL］.［2012－11－18］.http：／／wiki.a－pache.orglhadoop／Hbase.

［8］Open source software for building private and public clouds［EB／OL］.［2012－11－18］. http：／／www.openstack.org／http：／／www.chinacloud.cn／show.aspx？id＝766＆cid＝30.

［9］Swift1.7.6－dev documentation ［EB／OL］. ［2012－11－18］.http：／／docs.openstack.org／developer／swift／.

［10］Lewin D.Consistent hashing and random trees： Algorithms for caching in distributed networks ［D］.Cambridge， Massachusetts： Massachusetts Institute of Technology，Department of Electrical Engineering and Computer Science，1998.