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