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