嚴曄，王歡，蘇偉，秦雪，吳玉寧

（1.長春理工大學 計算機科學技術學院，長春 130022；2.長春理工大學 信息化中心，長春 130022）

云存儲的到來，讓用戶可以在有網(wǎng)絡服務的地方隨時訪問云端存儲的數(shù)據(jù)，避免了隨身攜帶存儲設備的麻煩。云存儲是指通過分布式文件系統(tǒng)、網(wǎng)絡技術、集群應用等功能，將網(wǎng)絡中各種類型的存儲設備，通過應用軟件集合起來協(xié)同工作，共同對外提供數(shù)據(jù)存儲和業(yè)務訪問功能的系統(tǒng)，所以云存儲可以認為是一個以數(shù)據(jù)存儲管理為核心的云計算系統(tǒng)［1］。IDC（International Data Corporation）根據(jù)2013年全球數(shù)據(jù)量分析預測，到2017年全球的數(shù)據(jù)存儲量將達到7235EB［2］，雖然數(shù)據(jù)量在爆炸式的增長，但云計算發(fā)展至今仍沒有一個較統(tǒng)一的行業(yè)標準，Amazon、Google、IBM、Microsoft、Swiftstack 等提供的云存儲服務在應對不同客戶要求時各有各的優(yōu)缺點。針對開源云計算、云存儲發(fā)展中系統(tǒng)架構和負載均衡問題，本文提出負載均衡設置策略以及數(shù)據(jù)處理過程，并進行了實驗測試。

1 基于Swiftstacak的云存儲架構

Swiftstack通過賬戶（account）、容器（container）、對象（object）［3］三層的邏輯結構來對存儲數(shù)據(jù)進行抽象并將其映射到物理存儲硬件中。云存儲使用這樣的邏輯結構可以為存儲的數(shù)據(jù)創(chuàng)建獨一無二的存儲路徑。在這里，賬戶（account）不是用戶ID而是存儲的區(qū)域（storage location）。云存儲邏輯結構如圖1所示。

圖1 云存儲邏輯結構

Swiftstack通過集群（cluster）、區(qū)域（region）、帶（zone）、節(jié)點（node）來劃分和定義其存儲體系結構，相當于平常所說的“點、線、面”，它們之間的相互關系如圖2所示。

圖2 云存儲體系結構

2 負載均衡設置

Swiftstack數(shù)據(jù)請求的主要過程是在接收到HTTP請求后，先通過proxy server進程來確定數(shù)據(jù)要存儲的路徑，再由proxy server通過改進的一致性哈希算法將請求指向它要到達的存儲位置。proxy server在大規(guī)模部署時常與storage server分開部署（如圖3），數(shù)據(jù)的讀寫請求到達proxy server的機會是均等的。實際經(jīng)驗證明，在大規(guī)模部署時將proxy server與storage server分開部署，不用在proxy server前進行負載均衡，可以完全由獨立部署的proxy server來處理數(shù)據(jù)的讀寫請求。

圖3 大規(guī)模部署結構

而在中規(guī)模部署的情況下，proxy server與storage server都部署在同一節(jié)點內（如圖4），proxy server只負責該節(jié)點內的數(shù)據(jù)存儲與讀取，其保存的哈希環(huán)信息也只有該節(jié)點內各個存儲點的位置信息。在中規(guī)模部署的情況下，在節(jié)點外進行負載均衡，可有效地控制數(shù)據(jù)請求到達各節(jié)點的均衡性，不會出現(xiàn)一些節(jié)點過載，一些節(jié)點空載的情況。現(xiàn)在較流行的負載均衡算法大都是從SHA（Secure Hash Algorithm）算法演化而來，其基本結構都是哈希算法，在應對不同部署要求時，可對算法進行相應調整。中規(guī)模部署下通過load balance和proxy server作兩次哈希均衡，將更好地控制數(shù)據(jù)訪問和存儲性能。

圖4 中規(guī)模部署結構

3 基于Swiftstack的數(shù)據(jù)處理

3.1 一致性哈希環(huán)

存儲節(jié)點先通過取它的存儲路徑哈希值，然后將他們都映射到一個哈希環(huán)上。為確保數(shù)據(jù)存儲時可以較均勻的分布在各個物理存儲器內，Swiftstack采用了哈希環(huán)虛擬分區(qū)的辦法，例如：實際存儲節(jié)點A，為其建立5個存儲路徑指向A的虛擬分區(qū)A-1，A-2，A-3，A-4，A-5，然后將這六個節(jié)點分別映射到哈希環(huán)上，此時的哈希環(huán)上將會較均勻的分布有這些節(jié)點。虛擬分區(qū)的數(shù)量是根據(jù)各個存儲器容量大小來決定，容量大則權重（weight）較大，所設的分區(qū)數(shù)就高。但在實際應用中，容量較大的存儲器不一定有高的接入速度，如果僅僅只考慮容量大小來確定權重，往往會導致部署完成后，該節(jié)點的讀寫性能不佳。所以在確定虛擬分區(qū)數(shù)量時除了考慮存儲容量大小外，還要考慮存儲器的接入速度和讀寫性能。

3.2 數(shù)據(jù)備份

云存儲，就一定會涉及到數(shù)據(jù)備份的問題［4］。傳統(tǒng)的數(shù)據(jù)備份都是在數(shù)據(jù)完成傳輸后再進行相應的數(shù)據(jù)拷貝和保存。Swiftstack在數(shù)據(jù)備份方面采用的方法是設置數(shù)據(jù)備份數(shù)，最小的備份數(shù)為2，在默認情況下為3，可以根據(jù)存儲數(shù)據(jù)重要程度的差異設定備份數(shù)目。與傳統(tǒng)的備份方式不同的是，Swiftstack在完成數(shù)據(jù)存儲的同時對數(shù)據(jù)進行備份。以默認情況下的3個備份為例，數(shù)據(jù)X通過一致性哈希環(huán)被定位存儲到dev1，在這同時，X的備份X-1，X-2，X-3也分別被映射到別的存儲點，在這一過程中，如果X和X-1先完成存儲，則X-2、X-3的存儲進程則會被移到后臺，待存儲節(jié)點處理數(shù)據(jù)請求空閑時再繼續(xù)進行，這樣可以確保存儲節(jié)點在處理數(shù)據(jù)請求繁忙時有足夠的讀寫性能。除此以外，Swiftstack還有備份數(shù)據(jù)鎖死機制，當某一分區(qū)發(fā)生改變時，位于該分區(qū)內的備份數(shù)據(jù)則會被鎖死，直到位于該分區(qū)內的數(shù)據(jù)確認被改動后才解除鎖死，這一鎖死機制時間的長短可以在min_part_hours文件內進行設置。

3.3 數(shù)據(jù)完整性

為保證存儲數(shù)據(jù)的完整性，Swiftstack在每個節(jié)點的后臺都運行有審計監(jiān)聽進程，該進程會不間斷的對存儲節(jié)點內各個賬戶內的容器和存儲對象進行掃描，確保所保存的數(shù)據(jù)不會因存儲設備故障而損壞，如果掃描到損壞的數(shù)據(jù)，該進程會將損壞的數(shù)據(jù)放入隔離區(qū)再進一步處理。若是無效的數(shù)據(jù)或者過期的數(shù)據(jù)，那么會將它刪除，若是有備份的數(shù)據(jù)，則會通過其該數(shù)據(jù)的其他備份來恢復。存儲節(jié)點內每個賬戶、容器保存有各自的哈希列表，這些列表也會在后臺不斷地被掃描并及時更新，確保數(shù)據(jù)路徑的準確及時性。

3.4 誤刪除恢復

Swiftstack在應對數(shù)據(jù)的誤刪除方面，有其相應的策略。通過Account reaper進程設置延遲刪除的時間，在收到用戶的刪除請求后只是將該賬戶內的數(shù)據(jù)全部標記成已刪除，待到達預設的刪除時間后再對該賬戶及內容進行徹底刪除。在這之前，用戶都可以通過各備份點重新恢復數(shù)據(jù)。

4 Swiftstack的性能測試

在測試環(huán)境下對Swiftstack進行安裝部署［5］。測試環(huán)境如表1所示。

表1 測試環(huán)境

測試環(huán)境下，設置了三個存儲節(jié)點，proxy server和storage server都部署在各節(jié)點內，采用小規(guī)模部署下的結構。對Swiftstack分別進行了5GB非結構化數(shù)據(jù)的大文件和1.5GB非結構化數(shù)據(jù)的小文件的寫入性能測試，測試結果如圖5和圖6所示。

圖5 大文件寫入性能

圖6 小文件寫入性能

從測試結果可以看出，在大文件寫入過程中，數(shù)據(jù)的寫入速度最高能達到16MB/s，寫入的IOPS可以達到近180，寫入速度的穩(wěn)定性不高，達到峰值后就開始下降，磁盤的寫入性能沒有完全發(fā)揮出來，從而可以看出Swiftstack在對大文件的寫入性能一般。在小文件寫入過程中，數(shù)據(jù)的最高速度能達到70MB/s，而且在達到峰值后能較好的維持在較高速度，而且其寫入時的IOPS也較穩(wěn)定的維持在350左右，無論是寫入的速度還是穩(wěn)定性，相對較大文件來說，Swiftstack在小文件的寫入性能方面較好。

5 結論

本文提出了大、中型云存儲部署架構的設計方法和負載均衡的設置策略。研究分析了云存儲架構、云存儲數(shù)據(jù)處理過程，通過實驗測試證明Swiftstack的存儲性能能夠滿足用戶對云存儲的使用要求，而大文件存儲方面的性能有待在后續(xù)的研究中對其改進。

［1］陳冬冬.云計算以及數(shù)字圖書館發(fā)展探析［J］.長春理工大學學報：自然科學版，2012，35（11）：265-266.

［2］NatalyaYezhkova.IDC'sOutlook fordatabyte density acrossthe globe hasbig implicationsfor the future［J/OL］.IDC.21 Oct 2013，http：//www.idc.com/getdoc.jsp?containerId=prUS24398613.

［3］Joe Arnold and members of the Swiftstack team.OpenStack Swift［M］.United States of America：O’Reilly Media，October 2014：21-23.

［4］鄧紅，王東興.基于開源云平臺OpenStack的存儲分析［J］.黑龍江科技信息，2012（32）：134.

［5］張瑞杰，李戰(zhàn)懷，張曉，等.基于私有云的虛擬實驗平臺的設計與實現(xiàn)［J］.計算機與現(xiàn)代化，2013（8）：159-164.