馬振威,張海明,溫亮明,黎建輝*

1.中國科學院計算機網絡信息中心，北京 100190

2.中國科學院大學，北京 100049

引言

隨著科學技術的發(fā)展，各類軟件應運而生，數(shù)據(jù)傳輸無處不在，數(shù)據(jù)也變成現(xiàn)代企業(yè)的石油，保存有價值的數(shù)據(jù)，在需要時候方便快捷地查詢數(shù)據(jù)已是當務之急?，F(xiàn)階段傳統(tǒng)的關系型數(shù)據(jù)庫和非關系型數(shù)據(jù)庫已經無法滿足日益增長的數(shù)據(jù)處理需求，在處理巨型文件時，面臨超出本地服務器存儲上限的瓶頸。此外，一味地增加服務器數(shù)量，也會產生巨大的經濟成本，無法實現(xiàn)快速、統(tǒng)一的數(shù)據(jù)管理優(yōu)化。此時，對象云存儲服務應運而生，對象云存儲服務是基于對象的海量云存儲服務，為用戶提供海量、安全、高可靠性、低廉成本的數(shù)據(jù)存儲能力，可以快速地通過Web、API 接口等方式對云存儲服務器進行創(chuàng)建目錄、刪除目錄、修改目錄、上傳對象、下載對象、刪除對象等。云端服務器由統(tǒng)一的存儲引擎對數(shù)據(jù)進行專門管理，保證了存儲的安全可靠。解除了客戶對海量文件的存儲難題，用戶可以在任何時間、任何電腦、任何地點存儲和訪問任意類型的數(shù)據(jù)[1]。

在云存儲系統(tǒng)進行測試階段，現(xiàn)在主要有兩大類方式，人工手動測試與自動化測試。手動測試大多依靠測試人員手工完成，由于人工不善于執(zhí)行重復枯燥的工作，因此手工測試不僅速度緩慢、精確度低，而且出錯概率較大，往往會將不準確的測試結果反饋給開發(fā)團隊。自動化測試是將自動化工具與技術應用于軟件測試，由相關程序和算法自動重復執(zhí)行相同的測試操作，不僅測試結果精準，而且能將測試結果快速反饋給相關人員，有助于以更少的工作量構建質量更好的軟件，但是在云存儲測試時候也無法完全發(fā)揮優(yōu)越性能。

隨著數(shù)據(jù)規(guī)模不斷擴大，功能更加復雜，網絡帶寬緊張，給傳統(tǒng)的測試工具帶來了巨大壓力，以至于無法快速準確的進行測試。分布式測試框架可以根據(jù)不同的測試用例，通過中控系統(tǒng)統(tǒng)一指揮調度進行工作，達到完成不同測試用例的任務，分布式系統(tǒng)又可以并發(fā)執(zhí)行，大大節(jié)省測試時間。因此分布式測試框架相較人工測試和單節(jié)點自動化測試有明顯的時間和空間優(yōu)越性。

1 研究現(xiàn)狀分析

目前軟件測試和靜態(tài)分析是兩種使用最為廣泛的缺陷檢測技術[2]，可以檢測出系統(tǒng)運行時性能的優(yōu)劣。軟件測試主要是通過大量測試用例進行集中測試，需要提前準備充足的資源；靜態(tài)分析能在程序較早階段發(fā)現(xiàn)程序缺陷。但是在對云存儲系統(tǒng)性能瓶頸檢測時候，這兩種手段往往達不到理想的效果。針對這一問題，學術界雖然進行了一些探討，但研究結果相對匱乏：Ma Chunyan 等提出了Stream X-machine[3]模型，該模型能比較直觀地觀察服務器的測試結果；Ipate F 等提出了RFSM[4]測試模型。以上研究從不同方面解決了Web 服務器測試用例的自動化生成問題，但是并沒有解決服務器的并發(fā)傳輸性能問題。鞠煒剛等提出了基于環(huán)境資源自動匹配的云測試框架[5]，解決了測試環(huán)境的合理利用，但是沒有解決根本的高并發(fā)問題。眾包測試[6]利用到了分布式的思想對軟件進行測試，采用請求者與工人的模式進行分布式測試，但是對于云存儲系統(tǒng)不能快速的啟動工人測試?；诖?，本文主要運用分布式測試，對系統(tǒng)傳輸功能不斷增壓，從而在系統(tǒng)結構和系統(tǒng)資源上進行優(yōu)化。通過大量用戶長時間同時向服務器傳輸數(shù)據(jù)，測試系統(tǒng)接收速率變化，監(jiān)控和分析資源性能指標。

2 框架設計

本文設計的分布式測試框架整體采用管理-執(zhí)行(Master-Task)形式。Master主機負責判斷區(qū)分下傳指令或者下傳文件來進行算法選擇，Task集群負責對實際命令的執(zhí)行。圖1為整個分布式測試框架的結構示意圖，整體框架主要包含Master主機維護模塊、待測試文件同步系統(tǒng)模塊、下達系統(tǒng)命令模塊。

圖1 分布式測試框架Fig.1 Distributed testing framework

2.1 分布式Task集群部署方案

Task集群節(jié)點眾多，并且根據(jù)測試任務的大小，單次上傳的文件可能達到TB級別，所以對集群之間的數(shù)據(jù)快速備份要求極高，并要求得到快速反饋。因此，傳統(tǒng)的單一數(shù)據(jù)傳輸和接收模式在效果和效率上顯然難以滿足需求，傳統(tǒng)模式數(shù)據(jù)以線性的模式進行傳輸，時間效率為N，在面對龐大數(shù)據(jù)時候將面臨災難性的考驗。本文借鑒Hadoop 生態(tài)環(huán)境中Spark[7]的管理模式，結合Linux 系統(tǒng)多進程服務，通過分布式部署客戶主機，設計了一套基于二叉樹遞歸的傳輸算法，并在實踐中得到了良好的效果。

在實際部署環(huán)境中，管理(Master)主機需要將客戶端主機上傳的文件拷貝到執(zhí)行(Task)集群上，然后通過集群進行壓力測試。首先考慮到中控管理主機性能問題，因為測試環(huán)境并不是超級計算機，沒有龐大的計算性能，所以同時開啟的最高線程數(shù)設定為5個，可以并行將待測試文件上傳到執(zhí)行集群中，這是在傳統(tǒng)的上傳模式上通過Linux 多線程實現(xiàn)，但本質還是線性傳輸，速度只能提高5倍，在面臨上千集群時顯然不是理想的。因此，本文采取二叉樹遞歸傳輸算法進行文件上傳，不但降低了中控管理主機的傳輸壓力和負載，而且大幅度縮短了傳輸時間。

二叉樹遞歸傳輸算法是利用二叉樹的樹形結構，將Task集群以二叉樹的形式進行邏輯排列，二叉樹之間的傳輸通過Master主機分配任務進行2倍遞增的速率，從而將Masker 對Task集群的控制時間從N 變?yōu)榱薼og2n，大大縮短了集群啟動時間，從而為傳輸減少了系統(tǒng)等待。先由Master主機向其子Task主機傳遞一份數(shù)據(jù)，然后Task主機再將數(shù)據(jù)下發(fā)給它的子節(jié)點，以此類推最終達到快速的文件傳輸，完成Task集群部署。

2.2 Master 中控架構

在自動化測試系統(tǒng)中，Master主機發(fā)揮重要作用，它主要負責所有Task主機的控制、文件下發(fā)、命令傳達、幫助客戶端主機管理Task集群等。由于客戶端主機想要進行測試任務，首先要經過Master主機將需要的環(huán)境部署好，壓力測試本身就是一種破壞性的性能測試，隨時都有可能使待測試系統(tǒng)崩潰，因此本文設計的測試系統(tǒng)采取了聚合模式，每一個Task集群都可以和Master主機直接通信，保證單個節(jié)點的損壞情況能影響到測試的準確性。最后將每一臺主機的測試日志整理反饋給Master主機以快速進行系統(tǒng)日志整理，以便檢查工作情況。

Master主機具備良好的文件管理性能，其能將所有的文件拷貝到備用(Secondary)主機上，以防止單點故障引發(fā)的全系統(tǒng)崩潰，當中控主機發(fā)生故障時，Secondary 主機會自動代替中控主機的位置成為新的中控主機并操控Task集群。由于基于操控所下發(fā)的命令所占字節(jié)較小，因此測試實驗中采用了并行傳輸策略。在進行中控時，Task集群的200個節(jié)點對于Master主機而言都是受信任狀態(tài)并免密接受Master 控制，Master主機向Task集群下達工作指令，Task集群在收到指令后立刻向Master主機反饋成功接收指令并執(zhí)行工作指令，整個過程的延遲只需要0.1秒。在后續(xù)Task集群工作環(huán)節(jié)，Master主機將每個Task集群的反饋情況記錄到日志中，在8 核的Master主機下可以無影響的并發(fā)執(zhí)行8個控制，將命令下達至整個集群耗時僅2.5s，取得了較好的部署效果。

節(jié)點修復問題在實際應用中也占據(jù)非常重要的地位，只有先確定哪個節(jié)點發(fā)生故障，才能據(jù)此實行解決方案。當收到節(jié)點反饋時，中控主機會自動識別未反饋的主機并標注，再次向未反饋主機發(fā)送執(zhí)行命令，如此重復發(fā)送3次，如果始終得不到回復，則將未反饋節(jié)點列為損壞節(jié)點。一般情況下，中控主機無法對執(zhí)行主機進行控制，主要原因是因為中控主機的權限較低，重新設置免密登陸即可解決。圖2為單節(jié)點流程控制示意圖。

圖2 單節(jié)點流程控制Fig.2 Single node flow control

2.3 測試框架實現(xiàn)流程

2.3.1 Master主機維護模塊實現(xiàn)

Master主機維護模塊主要記錄Task集群之間的信任關系和控制情況。在進行集群擴展時，只需要在本模塊添加記錄并更新即可達到快速擴展的目標。主機控制模式采用遞歸搜索二叉樹方式進行遍歷整個Task集群。中控主機維護列表如表1。

表1 信任關系Table1 Relationship of trust

每個Task主機都包含私有子節(jié)點，Task主機可以對子節(jié)點下達命令，私有子節(jié)點的地址由如下步驟計算得到。

Begin讀取主機IP 地址；將IP 地址寫入配置文件；for i = 1..n個節(jié)點{本機所控制主機為：主機地址+i*2 and主機地址+i*2+1}End

2.3.2 待測試文件同步系統(tǒng)模塊實現(xiàn)

待測試文件同步系統(tǒng)的主要功就是將被測試的文件高效地傳輸?shù)秸麄€Task集群，以通過集群去完成對象云存儲系統(tǒng)的測試分析。在進行文件同步時，用到了上文所描述的Task集群部署方案中的二叉樹遞歸傳輸算法，可以達到快速部署的目標，具體實現(xiàn)細節(jié)如下。

Begin讀取子節(jié)點IP 地址；scp 傳輸待測試文件給子節(jié)點and scp 傳輸子節(jié)點需要執(zhí)行的命令}End

2.3.3 下達系統(tǒng)命令模塊實現(xiàn)

本模塊主要是中控主機對每個集群節(jié)點的下達命令傳輸，通過主機控制執(zhí)行節(jié)點進行工作的命令僅占據(jù)KB級別的內存。如果使用遞歸算法，則時間耗費較大，因此本文采用并行傳輸方式，由于Master主機對整個Task集群具有控制權限，其會快速地將指令下達給Task集群，每一個正常的Task節(jié)點都會收到來自Master主機發(fā)送的執(zhí)行命令，Task節(jié)點收到命令后會向Master主機確認接收，Task節(jié)點根據(jù)接收到的命令執(zhí)行測試任務，任務執(zhí)行完畢之后將執(zhí)行結果等信息一并發(fā)送給Master主機，生成完整的日志文件。如果某些Task節(jié)點沒有執(zhí)行測試任務，則會被Master主機標記并再次下達命令，3次無法啟動將會重啟免密登陸服務，然后再次下達命令，如果仍然無法得到反饋結果，該節(jié)點則會被記錄到日志文件，交由人工判斷處理。

3 測試環(huán)境

3.1 分布式測試系統(tǒng)環(huán)境

本文工作主要通過自行研發(fā)的分布式測試框架對系統(tǒng)性能進行測試、分析，框架主要思想也是通過壓力測試[8]進行實現(xiàn)。壓力測試主要通過對系統(tǒng)加壓，讓它在極限工作環(huán)境下工作，觀察運行情況，發(fā)現(xiàn)性能缺陷，進而對系統(tǒng)結構進行優(yōu)化調整。由于響應時間、最大并發(fā)用戶數(shù)、吞吐量和資源利用率可以分別用來衡量軟件的及時性、擴充能力和容量、處理能力、運行狀態(tài)，且系統(tǒng)處理速率越快、吞吐量越大、并發(fā)數(shù)越多說明系統(tǒng)性能越好，反之越差[9]。因此本文選擇并發(fā)用戶數(shù)、持續(xù)運行時間、傳輸數(shù)據(jù)量三個角度進行測試分析。用戶可以通過中控系統(tǒng)的中控主機將要測試的文件以二叉樹遞歸傳輸算法發(fā)送到每個執(zhí)行節(jié)點上進行工作，用戶只需要在Master 下達命令即可完成所有Task 測試工作，無需關心每一個Task的運行情況。表2為整個測試系統(tǒng)所用到的主機的詳細信息。

表2 測試環(huán)境系統(tǒng)信息Table2 Test environment system information

3.2 對象云存儲系統(tǒng)架構

實驗涉及的對象云存儲系統(tǒng)主體架構通過Django 開發(fā)框架完成，雖然Django 框架無法滿足高可用性，但是結合Nginx 進行負載均衡，對外透明對內平均分配資源，從而達到高可用性。

由于數(shù)據(jù)的安全性和隱私性問題日益突出[10-11]，為了解決此問題，我們的底層存儲采用的是優(yōu)化的Ceph[12]存儲系統(tǒng)。Ceph 集群作為高可用、高擴展、高性能、低成本的分布式存儲系統(tǒng)代表，具備很多優(yōu)越的性能，如其開源特性以及提供塊存儲、對象存儲和文件系統(tǒng)的統(tǒng)一存儲能力已在越來越多的企業(yè)中得到應用[13]。圖3為整個系統(tǒng)的實驗環(huán)境結構。

圖3 實驗環(huán)境結構Fig.3 Experimental environment

4 測試結果

在對象云存儲系統(tǒng)上線之前需要進行大規(guī)模測試，對性能進行分析、度量、優(yōu)化，保證系統(tǒng)上線之后的穩(wěn)定運行。本文基于上述章節(jié)所述的分布式測試框架，通過不同時間段的上傳，統(tǒng)計分析出網絡高峰期對系統(tǒng)的影響。壓力測試作為測量系統(tǒng)瓶頸的主要方式，要求其具備大規(guī)模、持續(xù)性、并發(fā)性等特點。

分布式框架主要目的是快速、便捷、并發(fā)的執(zhí)行任務，快速和便捷在于通過中控系統(tǒng)短時間啟動上百個節(jié)點工作，并發(fā)在于每個節(jié)點互不影響、相互獨立的進行工作。下面將針對這些特性展開相關測試工作。

4.1 并發(fā)測試

分布式測試框架的快速部署源于中控系統(tǒng)通過二叉樹遞歸算法對系統(tǒng)的啟動。圖4為通過傳統(tǒng)模式傳輸待測試文件和通過二叉樹遞歸傳輸算法進行待測試文件傳輸?shù)膶Ρ葓D。

圖4 傳輸算法對比圖Fig.4 Transmission algorithm comparison chart

圖4中藍色虛線表示二叉樹遞歸傳輸算法，紅色虛線表示傳統(tǒng)線性傳輸算法。試驗中待測試文件的體量為5GB，測試框架之間主機配置和主機之間的連接完全相同，兩個主機之間傳輸文件平均耗時1分鐘。中控主機打開5 線程傳輸時可以同時傳輸數(shù)據(jù)給5個執(zhí)行主機，用時1分鐘，但此時中控主機已經要達到飽和狀態(tài)。通過10分鐘部署環(huán)境測試，很容易發(fā)現(xiàn)二叉樹遞歸傳輸算法比傳統(tǒng)的線性傳輸算法性能優(yōu)越，雖然最初2分鐘內線性傳輸算法啟動比二叉樹遞歸算法快，但是隨著規(guī)模增加，尤其是達到10分鐘時，線性傳輸算法只能部署50臺Task主機，而二叉樹遞歸傳輸算法則可以達到1000臺Task主機。實驗表明二叉樹遞歸傳輸算法在部署Task主機時候有高效性、合理性。

4.2 單桶測試

對象云存儲系統(tǒng)是對象的存儲，將對象放到設定的測試桶中，由系統(tǒng)對桶進行管理維護。每個桶的容量以及查詢、寫入速率是考察對象云存儲系統(tǒng)的重要指標。

本次通過模擬200個用戶進行傳輸測試，每個用戶單次上傳大小為1MB的文件，重復進行1000次傳輸，預計單桶總文件量達到200000個。測試初期打開查詢桶中記錄的耗時在1秒之內，基本可以達到用戶對系統(tǒng)測試時間的要求。但隨著桶中文件數(shù)量的增加，查詢速率會變得越來越慢，甚至達到了4秒左右，嚴重影響了用戶體驗，測試結果如圖5所示。

圖5 效果對比圖Fig.5 Comparison chart of effect

通過測試發(fā)現(xiàn)，數(shù)據(jù)庫的選用是影響性能的主要因素，發(fā)現(xiàn)的系統(tǒng)瓶頸，為后續(xù)工作中調整優(yōu)化系統(tǒng)結構提供了方向。

4.3 吞吐量測試

由于系統(tǒng)可能遇到大規(guī)模用戶同時上傳數(shù)據(jù)的問題，因此服務器處理并發(fā)數(shù)據(jù)流的能力是評價系統(tǒng)優(yōu)劣的重要指標。本節(jié)將發(fā)揮測試框架分布式的優(yōu)勢，測試系統(tǒng)接收用戶數(shù)據(jù)的性能，通過分布式測試框架模擬200個用戶同時向對象云存儲系統(tǒng)分別持續(xù)傳輸1MB、100MB、1GB、10GB、100GB 大小的文件，統(tǒng)計所用時間然后進行分析。以1MB 小文件上傳為例，其單用戶速率可達到4個/每秒左右，每秒鐘上傳文件數(shù)量所占比例如圖6所示。

圖6 每秒鐘上傳文件數(shù)量所占比例圖Fig.6 The proportion of the number of uploaded files per second

在進行1GB、10GB 大文件并行傳輸測試時，服務器需要持續(xù)接收并處理所有用戶的數(shù)據(jù)，此時我們使用團隊搭建的大規(guī)模監(jiān)控框架[14]——Zabbix進行觀察。在進行長達兩個小時的測試中，發(fā)現(xiàn)單節(jié)點上傳速率可以達到0.9Gbps。

本次測試還從不同時間段角度分析系統(tǒng)性能，分別選用周六20:20、周一20:20、周二20:20、周三20:20 通過外網對1MB 大小待測試文件進行上傳。外網主機正常傳輸速率為10MB/s，測試結果如圖7所示。

圖7 累計用時Fig.7 Cumulative time

通過對比用戶在實際網絡中的文件傳輸速率，我們發(fā)現(xiàn)在不同時間段內文件傳輸結果有所差異，其中周六網絡高峰期傳輸速率明顯比工作日緩慢，據(jù)此可以推斷外部環(huán)境因素是影響用戶體驗的重要原因之一。

實驗整體表明，本文所設計的大規(guī)模分布式測試框架可以高效地對不同大小、不同格式的文件進行同步上傳測試，系統(tǒng)整體具有較高的靈活性；可以快速遞歸啟動Task 進行壓力測試，節(jié)省大量時間；可以在不同時間段進行分布式測試，排查各種影響性能的因素。從而實現(xiàn)分布式測試框架便捷、快速、并發(fā)的目標。

5 結語

本文通過自行設計的分布式測試框架從多個角度對云存儲系統(tǒng)進行測試，在實際應用中達到了一定的測試效果，對云存儲平臺的優(yōu)化具有一定實踐指導意義。雖然分布式測試框架前期的搭建需要投入一定的精力，但是這些投入可以得到長期回報，可以減少工作量，保證系統(tǒng)的穩(wěn)定運行，提高準確性，最終節(jié)省成本和時間。

本分布式測試框架在硬件測試上也能發(fā)揮穩(wěn)定的性能優(yōu)勢，如進行硬盤讀寫速率測試和網卡性能測試時，傳統(tǒng)的單物理機測試可能無法達到高性能硬件的峰值，從而產生錯誤的數(shù)據(jù)，而分布式測試框架則可以通過多節(jié)點同時工作輕松達到硬件峰值，從而快速測出硬件性能。

雖然分布式測試框架在云存儲系統(tǒng)和硬盤、網卡等性能測試上體現(xiàn)出較好的效果，但是在對mysql、redis 等數(shù)據(jù)庫進行性能測試時候效果不甚理想，原因在于通過外部環(huán)境對數(shù)據(jù)庫注入數(shù)據(jù)本身有延遲，會干擾到數(shù)值的準確性。未來，將繼續(xù)探索干擾數(shù)據(jù)傳輸?shù)耐獠坑绊懸蛩?，依托機器學習相關算法進一步優(yōu)化系統(tǒng)響應時間。

利益沖突聲明

所有作者聲明不存在利益沖突關系。