嚴(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è)試。
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)
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ù)的讀寫(xiě)請(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ù)的讀寫(xiě)請(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)空載的情況?,F(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)
存儲(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)的讀寫(xiě)性能不佳。所以在確定虛擬分區(qū)數(shù)量時(shí)除了考慮存儲(chǔ)容量大小外,還要考慮存儲(chǔ)器的接入速度和讀寫(xiě)性能。
云存儲(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í)有足夠的讀寫(xiě)性能。除此以外,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è)置。
為保證存儲(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í)性。
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ù)。
在測(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ù)的小文件的寫(xiě)入性能測(cè)試,測(cè)試結(jié)果如圖5和圖6所示。
圖5 大文件寫(xiě)入性能
圖6 小文件寫(xiě)入性能
從測(cè)試結(jié)果可以看出,在大文件寫(xiě)入過(guò)程中,數(shù)據(jù)的寫(xiě)入速度最高能達(dá)到16MB/s,寫(xiě)入的IOPS可以達(dá)到近180,寫(xiě)入速度的穩(wěn)定性不高,達(dá)到峰值后就開(kāi)始下降,磁盤(pán)的寫(xiě)入性能沒(méi)有完全發(fā)揮出來(lái),從而可以看出Swiftstack在對(duì)大文件的寫(xiě)入性能一般。在小文件寫(xiě)入過(guò)程中,數(shù)據(jù)的最高速度能達(dá)到70MB/s,而且在達(dá)到峰值后能較好的維持在較高速度,而且其寫(xiě)入時(shí)的IOPS也較穩(wěn)定的維持在350左右,無(wú)論是寫(xiě)入的速度還是穩(wěn)定性,相對(duì)較大文件來(lái)說(shuō),Swiftstack在小文件的寫(xiě)入性能方面較好。
本文提出了大、中型云存儲(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.