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