摘 要： 隨著云計(jì)算的不斷發(fā)展,，基于OpenStack的開源云得到了國內(nèi)外IT廠商的廣泛關(guān)注。從服務(wù)響應(yīng)時(shí)間和服務(wù)吞吐量兩個(gè)維度來對比萬兆網(wǎng)卡和千兆網(wǎng)卡對OpenStack Swift對象存儲方案性能的影響,。在此基礎(chǔ)上,，模擬Swift采用萬兆網(wǎng)卡適配器后在各種場景下的性能表現(xiàn)。進(jìn)一步,，采用固態(tài)硬盤檢驗(yàn)其對Swift存儲性能的影響,。最后進(jìn)行代理節(jié)點(diǎn)和存儲節(jié)點(diǎn)的配比實(shí)驗(yàn)，挖掘云存儲技術(shù)的價(jià)值,，設(shè)計(jì)更加符合最終用戶需要的云存儲解決方案,。
關(guān)鍵詞： 云計(jì)算；OpenStack,；對象存儲,；Swift；性能實(shí)驗(yàn)
0 引言
近些年來,，諸如微博,、在線游戲、在線視頻,、企業(yè)私有云等應(yīng)用一直保持爆發(fā)式的增長,，這些應(yīng)用產(chǎn)生了海量非結(jié)構(gòu)化數(shù)據(jù)，這些數(shù)據(jù)以讀取請求為主,，更新和刪除的頻率較低,，這為傳統(tǒng)的縱向擴(kuò)展存儲解決方案在容量擴(kuò)展、數(shù)據(jù)使用性能等方面提出了越來越嚴(yán)峻的挑戰(zhàn),；而可橫向擴(kuò)展的對象存儲解決方案越來越受到市場的青睞,。
1 Swift項(xiàng)目背景
OpenStack Object Storage（Swift）是OpenStack開源云計(jì)算的子項(xiàng)目之一。Swift并非傳統(tǒng)的File System或者Raw Block,，而是通過標(biāo)準(zhǔn)硬件構(gòu)建冗余的,、可擴(kuò)展的,、支持多租戶的分布式對象存儲系統(tǒng)，通過REST API操作對象文件,，適合存儲媒體庫（音頻,、視頻等）、壓縮日志文件的存檔,、備份存檔,、鏡像文件等[1]。
2 實(shí)驗(yàn)
2.1 實(shí)驗(yàn)?zāi)康?/p>
驗(yàn)證及優(yōu)化OpenStack Swift對象存儲方案在不同應(yīng)用環(huán)境下的最佳性能,、配置及拓?fù)浣Y(jié)構(gòu),。
2.2 實(shí)驗(yàn)內(nèi)容
（1）在千兆和萬兆網(wǎng)絡(luò)環(huán)境分別實(shí)驗(yàn)OpenStack Swift存儲方案,，評估萬兆網(wǎng)絡(luò)環(huán)境對OpenStack Swift在各方面的提升情況,，包括：系統(tǒng)能支持的并發(fā)數(shù)量、數(shù)據(jù)吞吐量的變化情況,、系統(tǒng)的穩(wěn)定性以及系統(tǒng)資源的使用情況,。
（2）將萬兆網(wǎng)絡(luò)環(huán)境應(yīng)用于各個(gè)場景,，檢驗(yàn)其性能,。
（3）測試固態(tài)硬盤存放賬戶和容器等元數(shù)據(jù)信息,，評估對OpenStack Swift提升情況,。
（4）測試代理節(jié)點(diǎn)和存儲節(jié)點(diǎn)的配比,，力圖找到最佳配置,。
2.3 實(shí)驗(yàn)環(huán)境
本次實(shí)驗(yàn)的方案架構(gòu)如圖1[2]所示。
如圖1所示,，服務(wù)端由1臺負(fù)載均衡服務(wù)器,、2臺代理服務(wù)器、8個(gè)存儲節(jié)點(diǎn)服務(wù)器組成,?？蛻舳擞?臺收集實(shí)驗(yàn)數(shù)據(jù)服務(wù)器和5臺壓力測試服務(wù)器組成。硬件配置如表1所示,，軟件環(huán)境如表2所示,。
3 千兆、萬兆網(wǎng)絡(luò)環(huán)境對比實(shí)驗(yàn)
3.1 實(shí)驗(yàn)場景
?。?）文件大?。?0 KB~200 KB。
（2）操作場景：模擬萬維網(wǎng)使用場景,，PUT,、GET和DELETE操作的比例分別為：5%、90%,、5%,，持續(xù)運(yùn)行30 min。
?。?）網(wǎng)絡(luò)環(huán)境：采用2.3節(jié)的實(shí)驗(yàn)環(huán)境,，千兆、萬兆測試負(fù)載均衡設(shè)備分別采用1 GbE網(wǎng)卡,、10 GbE網(wǎng)卡,。
3.2 實(shí)驗(yàn)結(jié)果
3.2.1 千兆網(wǎng)實(shí)驗(yàn)結(jié)果及分析
如圖2所示，在千兆網(wǎng)環(huán)境下,，隨著并發(fā)數(shù)的增加，服務(wù)響應(yīng)時(shí)間增長,。
如圖3所示,，在千兆網(wǎng)環(huán)境下，隨著并發(fā)數(shù)量的上升,，服務(wù)吞吐量并無明顯變化,。
實(shí)驗(yàn)結(jié)果：（1）負(fù)載均衡服務(wù)器帶寬使用量：在100并發(fā)連接情況下，負(fù)載均衡服務(wù)器帶寬使用量為817 Mb/s,，理論帶寬基本用完,；（2）對象存儲系統(tǒng)吞吐量：在100、500,、 2 000并發(fā)連接情況下,，整個(gè)系統(tǒng)的服務(wù)吞吐量在830 op/s左右，并無明顯變化,；（3）服務(wù)響應(yīng)時(shí)間：在100,、500、2 000并發(fā)連接情況下,，呈明顯上升趨勢,，在500并發(fā)連接時(shí)，數(shù)據(jù)平均響應(yīng)時(shí)間達(dá)500 ms,，2 000并發(fā)連接時(shí),，數(shù)據(jù)平均響應(yīng)時(shí)間2 s以上。但是所有存儲節(jié)點(diǎn)服務(wù)器的處理器,、內(nèi)存,、網(wǎng)絡(luò)使用率都很低。
實(shí)驗(yàn)結(jié)論：負(fù)載均衡服務(wù)器網(wǎng)卡的數(shù)據(jù)吞吐能力是存儲節(jié)點(diǎn)利用率的瓶頸。
3.2.2 萬兆網(wǎng)實(shí)驗(yàn)結(jié)果及分析
如圖4所示,，在萬兆網(wǎng)環(huán)境下,，隨著并發(fā)數(shù)的增加，服務(wù)響應(yīng)時(shí)間線性增長,。
如圖5所示,，在萬兆網(wǎng)環(huán)境下，隨著并發(fā)數(shù)量的上升,，服務(wù)吞吐量先增加后趨于穩(wěn)定,。
實(shí)驗(yàn)結(jié)果：（1）負(fù)載均衡服務(wù)器帶寬使用量：在300并發(fā)連接情況下，5臺壓力測試客戶端實(shí)際使用帶寬為4.2 Gb/s,，已經(jīng)接近理論最大輸出帶寬,，而且此時(shí)8臺存儲節(jié)點(diǎn)的網(wǎng)卡流量持續(xù)在600 Mb/s左右，但是負(fù)載均衡和代理服務(wù)器的帶寬使用率僅在25%左右,；（2）對象存儲系統(tǒng)吞吐量：持續(xù)增加并發(fā)連接數(shù)量到2 000個(gè),，整個(gè)系統(tǒng)的服務(wù)吞吐量維持在4 500 op/s左右；（3）服務(wù)響應(yīng)時(shí)間方面：在2 000并發(fā)連接時(shí),，數(shù)據(jù)讀操作的平均響應(yīng)時(shí)間在500 ms以下,。
實(shí)驗(yàn)結(jié)論：在超高并發(fā)連接時(shí)，存儲節(jié)點(diǎn)的帶寬基本用完,，而負(fù)載均衡節(jié)點(diǎn)和代理節(jié)點(diǎn)的帶寬還有富余,，可以通過增加存儲節(jié)點(diǎn)來應(yīng)對請求數(shù)量的繼續(xù)增長。
3.2.3 千兆,、萬兆網(wǎng)絡(luò)環(huán)境實(shí)驗(yàn)結(jié)果對比
如圖6所示,，在千兆網(wǎng)環(huán)境下，隨著并發(fā)數(shù)的增加,，服務(wù)響應(yīng)時(shí)間高速增長,；而萬兆網(wǎng)一直穩(wěn)定在500 ms以下。
如圖7所示,，在千兆網(wǎng)環(huán)境下,，服務(wù)吞吐量比較穩(wěn)定；而在萬兆網(wǎng)環(huán)境下,，隨著并發(fā)數(shù)的增加,，服務(wù)吞吐量先增加后趨于穩(wěn)定。
實(shí)驗(yàn)結(jié)果說明：（1）單純依靠將負(fù)載均衡和代理服務(wù)器節(jié)點(diǎn)的以太網(wǎng)服務(wù)器適配器由千兆更換為萬兆,，可帶來5倍以上的服務(wù)吞吐量,。按照500 ms的平均響應(yīng)時(shí)間計(jì)算，支持的并發(fā)連接數(shù)為4倍以上,。（2）千兆環(huán)境的系統(tǒng)吞吐量出現(xiàn)瓶頸,，無法滿足萬維網(wǎng)這樣要求大并發(fā)的應(yīng)用場景，需要通過額外手段增加帶寬，以增加服務(wù)吞吐量,。
實(shí)驗(yàn)結(jié)論：使用萬兆網(wǎng)絡(luò)環(huán)境,，是提升對象存儲性能的一個(gè)有效手段。
4 其他場景在萬兆環(huán)境下的實(shí)驗(yàn)
為了充分認(rèn)證在各種應(yīng)用場景下的性能,，繼續(xù)在同樣的配置下模擬在線游戲,、在線視頻兩個(gè)常見應(yīng)用場景。
4.1 在線游戲托管
4.1.1 實(shí)驗(yàn)場景
?。?）文件大?。?0 KB~200 KB。
?。?）操作場景：本場景用來模擬在線游戲托管服務(wù)的文件服務(wù),，PUT、GET和DELETE操作的比例分別為：90%,、5%,、5%，持續(xù)運(yùn)行30 min,。
4.1.2 實(shí)驗(yàn)結(jié)果及分析
如圖8和圖9所示,，從實(shí)測數(shù)據(jù)看，系統(tǒng)的平均響應(yīng)時(shí)間隨并發(fā)數(shù)量增加而增長,，系統(tǒng)的吞吐量隨并發(fā)數(shù)量增加而增長,。
4.2 在線視頻分享
4.2.1 實(shí)驗(yàn)場景
?。?）文件大?。?0 MB~100 MB。
?。?）操作場景：本場景模擬在線視頻分享服務(wù),，PUT、GET和DELETE操作的比例分別為：5%,、90%,、5%，持續(xù)運(yùn)行30 min,。
4.2.2 實(shí)驗(yàn)結(jié)果及分析
如圖10和圖11所示,，實(shí)測并發(fā)到100后，再增加并發(fā)數(shù)量,，系統(tǒng)的吞吐量并不明顯,。
5 萬兆環(huán)境下SSD實(shí)驗(yàn)
5.1 實(shí)驗(yàn)環(huán)境
在基于OpenStack Swift的對象存儲解決方案中，當(dāng)一個(gè)容器內(nèi)對象文件數(shù)量很多,，由于需要耗費(fèi)更多時(shí)間用于元數(shù)據(jù)信息的更新,，再向該容器內(nèi)寫入新的文件時(shí)，系統(tǒng)的整體性能會受到影響，因此,，本實(shí)驗(yàn)采取了機(jī)械硬盤,、SSD硬盤兩種介質(zhì)存儲元數(shù)據(jù)來評估SSD給系統(tǒng)性能帶來的提升率[1]。
工作負(fù)載說明如表3所示,。
實(shí)驗(yàn)環(huán)境：拓?fù)漕愃朴?.3節(jié),，服務(wù)端由1臺代理服務(wù)和8臺存儲服務(wù)構(gòu)成，客戶端由2臺機(jī)器作為打壓服務(wù)器,。
5.2 實(shí)驗(yàn)結(jié)果及分析
結(jié)果說明：在使用傳統(tǒng)機(jī)械硬盤時(shí),，系統(tǒng)的服務(wù)吞吐量在3 500 op/s左右，數(shù)據(jù)平均響應(yīng)時(shí)間在580 ms左右,。采用一塊英特爾320系列固態(tài)硬盤,，用于存儲元數(shù)據(jù)（賬戶信息和容器信息）后，系統(tǒng)的服務(wù)吞吐量增長到4 200 op/s左右,，數(shù)據(jù)平均響應(yīng)時(shí)間縮短到480 ms,。
實(shí)驗(yàn)表明：使用SSD存儲元數(shù)據(jù)能為OpenStack Swift的對象存儲解決方案帶來20%的整體性能提升。
6 代理節(jié)點(diǎn)和存儲節(jié)點(diǎn)配比實(shí)驗(yàn)
通過以上實(shí)驗(yàn),，可以看到實(shí)驗(yàn)中配比各角色服務(wù)器的CPU,、內(nèi)存、帶寬等沒有得到充分利用,，如何得到最佳的配置,，需要進(jìn)行代理節(jié)點(diǎn)和存儲節(jié)點(diǎn)的配比實(shí)驗(yàn)。
6.1 實(shí)驗(yàn)環(huán)境
文件大?。? MB,。
操作場景：使用6臺COSBench打壓服務(wù)器，持續(xù)運(yùn)行10 min,，實(shí)驗(yàn)代理節(jié)點(diǎn)和存儲節(jié)點(diǎn)最佳性能,、最佳配置和最佳拓?fù)浣Y(jié)構(gòu)。
網(wǎng)絡(luò)環(huán)境：打壓服務(wù)器使用Intel X520 10 GbE萬兆網(wǎng)卡,，存儲節(jié)點(diǎn)配置8個(gè) 7200 RPM HDD,。
6.2 實(shí)驗(yàn)結(jié)果及分析
實(shí)驗(yàn)結(jié)果如表4所示。
實(shí)驗(yàn)結(jié)論：（1）1個(gè)代理節(jié)點(diǎn)時(shí),，上傳代理節(jié)點(diǎn)成為瓶頸,，導(dǎo)致存儲節(jié)點(diǎn)壓力小,；（2）2個(gè)代理節(jié)點(diǎn)時(shí),，輸入和輸出總量基本一致，磁盤負(fù)載較大,；（3）4個(gè)代理節(jié)點(diǎn)時(shí),，輸入和輸出總量基本一致,，磁盤負(fù)載較大，吞吐量較2PN場景并無明顯提升,，此時(shí)磁盤為瓶頸,，需增加磁盤數(shù)量或改變磁盤類型；（4）6個(gè)代理節(jié)點(diǎn)時(shí),，輸入和輸出總量基本一致,，磁盤負(fù)載較大，吞吐量較2PN場景并無明顯提升,，此時(shí)磁盤為瓶頸,，需增加磁盤數(shù)量或磁盤類型。
合理的配置能提升系統(tǒng)的效率,，也是整體方案重要的評價(jià)指標(biāo),。
7 結(jié)論
制定對象存儲方案前，需清晰認(rèn)識每個(gè)版本的特征,；根據(jù)具體項(xiàng)目定義工作負(fù)載,、成功率、響應(yīng)時(shí)間等關(guān)鍵指標(biāo)落實(shí)配置及拓?fù)?，獲取最佳性能及效率,。隨著OpenStack Swift的不斷完善及發(fā)展，相信其會在更多場合得到廣泛應(yīng)用,。
參考文獻(xiàn)
[1] OpenStack Swift架構(gòu)[EB/OL].[2014-05-20].https：//swiftstack.com/openstack-swift/architecture/.
[2] Swift官方開發(fā)指南[EB/OL].[2014-05-20].http：//docs.openstack.org/developer/swift/index.html.