基于Swiftstack的云存儲關(guān)鍵技術(shù)研究

嚴(yán)曄，王歡，蘇偉，秦雪，吳玉寧

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

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

1 基于Swiftstacak的云存儲架構(gòu)

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

圖1 云存儲邏輯結(jié)構(gòu)

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

圖2 云存儲體系結(jié)構(gòu)

2 負(fù)載均衡設(shè)置

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

圖3 大規(guī)模部署結(jié)構(gòu)

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

圖4 中規(guī)模部署結(jié)構(gòu)

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

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

存儲節(jié)點先通過取它的存儲路徑哈希值，然后將他們都映射到一個哈希環(huán)上。為確保數(shù)據(jù)存儲時可以較均勻的分布在各個物理存儲器內(nèi)，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ù)各個存儲器容量大小來決定，容量大則權(quán)重（weight）較大，所設(shè)的分區(qū)數(shù)就高。但在實際應(yīng)用中，容量較大的存儲器不一定有高的接入速度，如果僅僅只考慮容量大小來確定權(quán)重，往往會導(dǎo)致部署完成后，該節(jié)點的讀寫性能不佳。所以在確定虛擬分區(qū)數(shù)量時除了考慮存儲容量大小外，還要考慮存儲器的接入速度和讀寫性能。

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

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

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

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

3.4 誤刪除恢復(fù)

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

4 Swiftstack的性能測試

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

表1 測試環(huán)境

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

圖5 大文件寫入性能

圖6 小文件寫入性能

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

5 結(jié)論

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

［1］陳冬冬.云計算以及數(shù)字圖書館發(fā)展探析［J］.長春理工大學(xué)學(xué)報：自然科學(xué)版，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)懷，張曉，等.基于私有云的虛擬實驗平臺的設(shè)計與實現(xiàn)［J］.計算機與現(xiàn)代化，2013（8）：159-164.