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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4 誤刪除恢復(fù)

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

4 Swiftstack的性能測(cè)試

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

表1 測(cè)試環(huán)境

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

圖5 大文件寫入性能

圖6 小文件寫入性能

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

5 結(jié)論

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

［1］陳冬冬.云計(jì)算以及數(shù)字圖書(shū)館發(fā)展探析［J］.長(zhǎng)春理工大學(xué)學(xué)報(bào)：自然科學(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］鄧紅，王東興.基于開(kāi)源云平臺(tái)OpenStack的存儲(chǔ)分析［J］.黑龍江科技信息，2012（32）：134.

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