針對云計算IaaS隔離性的測試系統①

趙 炎, 程紹銀, 蔣 凡

?

針對云計算IaaS隔離性的測試系統①

趙 炎, 程紹銀, 蔣 凡

(中國科學技術大學計算機科學與技術學院, 合肥 230027)

為解決IaaS云計算隔離性的測試問題, 通過分析和總結已有的隔離性的測試方法, 設計并實現了針對云計算IaaS基于消息中間件的分布式測試系統. 實現時, 采用基于消息中間件的分布式架構, 并將控制端與測試端獨立, 降低了耦合性, 增強了可擴展性. 在OpenStack云計算環境中進行測試, 驗證了系統設計的可行性. 該測試系統適用于云服務安全的其他能力測試.

云計算; IaaS; 分布式測試; 隔離性; OpenStack

IDC發布的《中國公有云服務追蹤研究》[1]表明, 國內公有云服務市場將在2015年至2018年持續高速增長, 其中IaaS(Infrastructure as a Service)增長最為明顯, 將由2013年的44%上升至2018年的61.3%. 2015年4月1日開始實施的中國國家標準《信息安全技術云計算服務安全能力要求》[2], 明確對系統虛擬化、網絡虛擬化和存儲虛擬化的安全能力提出了要求, 反復強調了隔離性的重要性, 隔離性是第三方測評機構針對云服務安全能力的測評重點.

隔離性是虛擬化的重要功能, Jeanna Neefe Matthews[3]測試了幾種不同虛擬技術的隔離性, 采用的測試方法是在1臺物理機器上創建4臺虛擬機, 每個虛擬機上都運行apache web server, 其中1臺虛擬機做壓力測試, 在進行壓力測試時觀察是否對未做壓力測試的虛擬機有影響. Jeanna等人的測試方法雖然能在一定程度上比較不同虛擬化技術的隔離性, 但是測試并沒有體現出云計算的大規模性. Rally[4]是針對Openstack的性能測試[5]工具, 其有幾種不同的測試方式: (1)在不具有OpenStack環境的硬件上自動部署OpenStack環境, 然后模擬真實用戶的負載, 最后評估測試結果; (2)使用已經部署好的OpenStack云環境, 模擬真實用戶的負載, 最后評估測試結果; (3)在特定的硬件上部署OpenStack, 運行指定的基準測試集并保存性能數據. Rally雖然能夠自動化的對云計算進行性能測試, 但是其局限于OpenStack, 同時也僅對性能做出了評估, 并沒有體現出對隔離性的測試.

本文實現了一種針對云計算IaaS的大規模分布式測試系統, 重點針對處理器、網絡、存儲的隔離性進行測試, 彌補Jeanna測試方法的不足, 可擴展性強, 可針對每一臺虛擬機模擬真實用戶的負載, 同時能夠模擬大規模用戶在線的情況, 對云平臺造成嚴重負載, 并檢測在高負荷情況下云平臺的隔離性, 同時, 該測試系統適用于云服務安全的其他能力測試.

1　系統架構設計與關鍵技術

1.1 系統結構設計

隔離性測試系統分為三類節點, 每一個節點為一臺虛擬主機.

① 控制節點C: 控制節點在不同階段, 其作用有所不同. 在隔離性測試系統部署階段, 控制節點主要作用為調用云平臺API創建虛擬機, 并虛擬主機指定角色, 將角色分為中繼節點和測試節點; 在測試階段, 其主要作用是向中繼節點發送測試命令或測試例, 并從中繼節點收集測試結果并分析得出測試結論;

② 中繼節點R: 主要作用是將控制節點的測試命令或測試例轉發給測試節點, 收集測試節點的監控信息, 將測試節點的測試結果及監控信息轉發給控制節點, 每一個中繼節點即為消息中間的broker;

③ 測試節點T: 主要作用是從中繼節點接收測試命令或測試例, 實時監控虛擬主機狀態, 并將測試結果和監控信息發送給中繼節點. 測試節點從測試例庫中調用測試例, 進行計算、網絡、存儲等隔離性測試, 同時也能進行其他安全能力測試.

圖1 測試系統結構

圖1所示為隔離性測試系統架構. 在這個隔離性測試系統中, 控制節點只需要一個, 中繼節點和測試節點為多個. 三者之間的連接關系: 控制節點與多個中繼節點通訊, 中繼節點又與多個測試節點通訊, 中繼節點還可與多個中繼節點通訊. 將隔離性測試系統分為三類節點的主要原因是測試節點在高負荷的情況下, 可能出現無法優先為其它節點轉發消息, 導致其他節點不能正常進行測試. 同時, 多個中繼節點可以緩解大量測試節點給控制節點帶來的壓力. 一種典型的隔離性測試系統拓撲如圖2所示. 采用圖2所示的拓撲結構使測試系統主要優點是松散耦合, 系統擴展性強. 相比于傳統的采用RPC的分布式架構[6], 基于消息中間件的分布式架構將控制節點與測試節點之間的通訊全部交給消息中間件, 降低了兩者的耦合程度. 同時, 控制節點無需管理與測試節點的連接, 只需要增加中繼節點即可增加更多的測試節點, 系統擴展性強.

圖2 隔離性測試系統拓撲

1.2 關鍵技術

1.2.1 系統部署

圖2中的每一個節點即為一臺虛擬主機, 所以測試系統需要大量的虛擬主機. 在云平臺創建所有虛擬主機前, 需要一臺虛擬主機作為控制節點, 控制節點連接云平臺創建大量虛擬主機. 在系統部署前修改云平臺提供的系統鏡像, 在鏡像中預先安裝測試程序, 以便在虛擬主機啟動后自動連接控制節點. 控制節點創建虛擬主機的流程如圖3所示, 具體描述如下:

步驟1: 控制節點判斷是否具有云平臺管理員權限, 若是則跳至步驟2, 否則跳至步驟3;

步驟2: 控制節點利用管理員權限創建一批用于測試的臨時租戶, 至步驟4;

步驟3: 控制節點等待測試人員提供用于測試的租戶認證信息;

步驟4: 控制節點利用用于測試的租戶信息, 使用定制鏡像創建大量虛擬主機;

步驟5: 虛擬主機創建成功后即可進行隔離性測試.

圖3 控制節點創建虛擬主機流程

1.2.2 隔離性測試方法

針對IaaS的計算、網絡、存儲資源的隔離性測試主要集中在CPU、內存、文件I/O與網絡的隔離性測試.

① CPU隔離性測試是在用戶指定的一段時間內循環進行高強度的浮點運算. 在進行浮點運算的過程中, 不斷檢查運算結果是否正確. 如果結果不正確, 會將結果信息保存在結果文件中, 并將錯誤信息發送給中繼節點. 中繼節點收集CPU使用情況和測試結果, 并分析測試結果, 將收集和分析的結果發送給控制節點. CPU的隔離性測試, 我們采取1個測試節點不進行高強度的浮點運算, 其他測試節點進行高強度的浮點運算的方式, 通過分析測試結果, 判斷浮點運算測試節點是否對沒有進行浮點運算的節點產生影響. 如果出現浮點運算結果錯誤或沒有進行浮點運算的節點CPU使用率波動較大, 則說明云平臺的隔離性欠佳.

② 內存隔離性測試大致分為兩種測試例: 負載和輕負載. 內存負載采取不斷的申請、鎖定和釋放內存的方式, 如果申請指定大小的內存失敗, 則會自動降低指定的內存大小, 然后再次申請, 以此往復, 導致測試節點內存基本被消耗盡. 輕負載則是指測試節點不進行高強度的內存消耗, 保持常態運行. 通過實時監控內存負載與輕負載的測試節點, 比較兩者在同時間段內內存最大值及使用量的變化判斷隔離性是否符合要求.

③ 文件I/O隔離性測試主要測試在大量測試節點同時讀寫文件時是否對文件I/O速度造成影響. 針對隔離性的測試主要測試兩種情況下的文件I/O速度, 第一種是所有測試節點同一時段進行大量文件讀寫, 第二種是在每一簇中隨機選取一個測試節點進行大量文件讀寫. 通過比較兩種情況下文件I/O的速度來判斷隔離性是否符合要求.

④ 網絡隔離性測試不同于CPU、內存和文件I/O的隔離性測試, 后三種測試時測試節點運行測試例不需要其他測試節點的協助, 而網絡隔離性測試需要其他測試節點協助, 模擬網絡通信, 其中一方作為服務端, 另一方作為客戶端. 《信息安全技術云計算服務安全能力要求》中明確提出了對虛擬主機的帶寬進行管理, 因此測試虛擬主機的帶寬需要兩個測試節點間協助測試. 典型的情景是假設兩個測試節點A、B分別位于不同簇內, 則A、B互為服務端和客戶端. 一種簡單的網絡隔離性測試拓撲如圖4所示, 圖中虛線表示網絡隔離性測試. 通過分析測試結果, 判斷是否對虛擬主機網絡帶寬進行了管理, 是否影響其他虛擬主機網絡. 測試節點A、B的選擇則采取編號相差最小且在不同簇的測試節點, 如果某簇中有未匹配成功的測試節點, 則該測試節點與中繼節點或簇內其他尚未匹配的測試節點間進行網絡隔離性測試, 具體的描述見算法1, 其中步驟4會判斷是否是不同簇且未配對節點, 滿足這兩個條件則會配對, 步驟10則是在節點首次匹配失敗時嘗試與中繼節點匹配, 如果中繼節點已經與其他測試節點匹配, 則測試節點與本簇中其他測試節點匹配, 算法2中步驟11-17則是嘗試與簇內其它節點匹配, 以上條件都不滿足的節點則不進行網絡隔離性測試. 網絡隔離性測試要比較所有虛擬主機并發進行網絡帶寬測試得到的帶寬值是否與虛擬主機單次測試的網絡帶寬相同, 如果兩者相差較大則說明云平臺沒有對虛擬主機的網絡帶寬進行妥善的管理, 不滿足網絡隔離性的要求.

圖4 網絡隔離性測試拓撲

算法 1. 網絡隔離性測試節點匹配算法

輸入:-所有測試節點編號,

-中繼節點編號.

Function NetMatch(testIndexs,){步驟1 for each i in testIndexs{步驟2 if i is matched then continue;步驟3 else for each j>i in testIndexs{步驟4 if j in another cluster and j is not matched {步驟5 i and j matches;步驟6 break;步驟7 }步驟8 }步驟9 if i is not matched {步驟10 if rIndex is not matched then i and rIndex matches;步驟11 else for each j in testIndexs{步驟12 if j and i is not in the same cluster then continue;步驟13 else if j is not matched {步驟14 i and j matches;步驟15 break;步驟16 }步驟17 }步驟18 }步驟19 }}

1.2.3 消息傳遞

控制端與測試端間的通訊協議采用MQTT[7]協議. MQTT協議是基于發布/訂閱的輕量級的消息協議. 既然是消息便涉及到生產者和消費者, 生產者發布消息, 消費者通過訂閱獲取消息. 考慮到測試系統中需要控制多個虛擬主機, 即一個生產者發送消息給多個消費者, 控制節點于測試節點通過消息中間件進行交互. 控制端與測試端間的通訊主要分為兩種方式:

① 控制端發布消息: 控制端創建消息主題(topic), 測試端訂閱該topic接受消息;

② 測試端發送消息給控制端: 控制端創建一個消息隊列, 測試端向消息隊列中發送發送消息.

2　系統評估與實驗

2.1 系統性能評估

對于系統的性能, 由于主控節點MC和控制節點C不進行隔離性測試, 只是擔當協調者的角色, 所以評估測試系統的性能主要針對監控終端. 監控終端在虛擬主機中運行前后資源占比如圖5所示, 可知監控終端對主機影響很小.

2.2 實驗

為了對云計算IaaS隔離性進行測試, 本文利用兩臺PC搭建了一個小型的OpenStack云計算系統, 兩臺PC分別作為controller節點和compute節點, 其硬件信息如下:

① controller: 4核cpu, 8GB內存, 500GB硬盤, 雙千兆網卡;

② compute: 4核cpu, 16GB內存, 1TB硬盤, 雙千兆網卡.

測試工具創建10臺虛擬機實例, 其中一臺作為測試系統的控制節點C, 一臺作為中繼節點R, 剩余8臺作為測試節點.

圖5 監控終端運行前后資源占比

2.2.1 CPU隔離性測試

實驗時從8個節點中隨機選取了一臺虛擬機作為不進行高強浮點運算度負載, 其他虛擬機負載作高強度的浮點運算. 對負載節點的CPU使用率取均值得到如圖6所示結果. 圖中負載即為進行高強度浮點運算, 未負載則沒有進行浮點運算. 從圖中可以看出, 負載節點CPU使用率從08:45逐步增加, 10:15左右使用率達到100%, 而后逐步降低. 在此期間未負載節點CPU使用率基本保持不變. 同時通過分析, 浮點運算結果均正確. 從而可以得知, OpenStack實驗環境滿足基本的CPU隔離性要求.

圖6 CPU負載與未負載使用百分率

2.2.2 內存隔離性測試

實驗隨機選取一臺虛擬機, 使其不進行內存負載, 而其余8臺虛擬機進行內存負載, 內存負載即是盡可能占用系統內存. 實時監控所有測試節點內存使用率, 并對負載測試節點內存使用量取平均值得到如圖7所示的內存消耗圖. 由圖可知, 在31:30處, 負載虛擬機內存消耗迅速上升后, 在43:30左右后恢復正常, 期間未負載虛擬機內存消耗基本不變. 同時, 在進行內存隔離性測試的時間段內, 負載與未負載虛擬機內存大小基本保持不變, 如圖8所示. 由兩圖分析可知, 實驗環境基本滿足內存隔離性要求.

圖7 內存測試-用戶內存消耗

圖8 內存測試-總內存大小變化

2.2.3 網絡隔離性測試

網絡隔離性測試分兩步進行. 第一步是隨機選擇兩臺虛擬機實例, 其中一臺作為服務器端, 另外一臺作為客戶端, 測試兩者之間的最大網絡帶寬, 稱其為單點測試; 第二步是多個點同時開始第一步中的測試, 根據網絡測試的節點匹配方法, 節點間相互匹配, 作為服務器端和客戶端進行最大網絡帶寬測試, 并對各節點對的測試結果取均值. 兩步測試得到的結果如圖9所示.

從圖9中數據分析可知, 單點測試時其網絡帶寬較大, 而多點測試時其網絡帶寬值幾乎只有單點測試時的1/4, 足以見得云平臺沒有對每臺虛擬主機的帶寬進行妥善管理, 不符合《信息安全技術云計算服務安全能力要求》標準.

圖9 網絡隔離性測試

2.2.4 磁盤I/O隔離性測試

磁盤I/O隔離性測試采取兩步進行: 一臺虛擬機單獨進行磁盤I/O隔離性測試和多臺虛擬機同時進行磁盤I/O隔離性測試. 磁盤I/O隔離性測試分別測試文件的讀寫速度、重復讀寫速度, 以及隨機讀寫速度, 將兩步測試分別稱為async和sync. async是隨機選取一臺虛擬主機進行磁盤I/O速度測試, sync是8臺虛擬主機同時進行磁盤I/O速度測試, 得到如圖10所示的測試結果.

圖10 磁盤I/O隔離性測試結果

由圖10分析可知, sync測試得到的磁盤I/O速度明顯小于async. 由此可知云計算虛擬機的磁盤I/O性能受其他虛擬機影響明顯, 或者說是云計算平臺在負載較大時租戶的虛擬機磁盤I/O性能會受到明顯影響. 因此可知其不能滿足某些對存儲性能要求較高的租戶, 磁盤I/O隔離性欠佳.

由于硬件特性, 相比于CPU和內存, 磁盤I/O速度一直阻礙著計算機的性能提升, 同時也考慮到成本問題, 對磁盤的投入也比較少. 但是, 對于云計算服務提供商而言, 還是可以通過一些軟硬件的方法來改善虛擬機磁盤I/O的性能, 以提高隔離性和對用戶的公平. 例如, 可以參考Dingding Li等人[8]通過降低Xen硬盤協議棧上的額外開銷來提升虛擬機磁盤I/O性能, 也可參考Ajay Gulati等人[9]提到的VMware DRS系統, 通過資源的合理調用和管理來提高系統的資源利用率和系統性能

3　結語

本文實現了一種針對IaaS云計算服務基于消息中間件的分布式測試系統, 重點針對處理器、網絡、存儲的隔離性進行測試, 可擴展性強, 可針對每一臺虛擬機模擬真實用戶的負載, 同時能夠模擬大規模用戶在線的情況, 對云平臺造成嚴重負載, 并檢測在高負荷情況下云平臺的隔離性. 下一步工作是完善在不同云平臺的自動部署, 并參照《信息安全技術云計算服務安全能力要求》設計測試例.

1 新浪科技.IDC:阿里云成國內最大IaaS云計算廠商, 2015-1-23.

2 左曉棟,陳興蜀,張建軍,等.GB/T 32268-2014,信息安全技術云計算服務安全能力要求.北京:中國標準化委員會,2014.

3 Matthews JN, Hu W, Hapuarachchi M, et al. Quantifying the performance isolation properties of virtualization systems. Proc. of the 2007 workshop on Experimental computer science. ACM. 2007. 6.

4 OpenStack Foundation. http://rally.readthedocs.org.Cloud Computing.

5 Jayasinghe D, Swint G, Malkowski S, et al. Expertus: A generator approach to automate performance testing in IaaS clouds. 2012 IEEE 5th International Conference on Cloud Computing (CLOUD). IEEE. 2012. 115–122.

6 蔣雄偉,馬范援.中間件與分布式計算.計算機應用,2002, 22(4):6–8.

7 賈軍營,王月鵬,王少華.基于MQTT協議IM的研究和實現.計算系統應用,2015,24(7):9–14.

8 Li D, Jin H, Liao X, et al. Improving disk I/O performance in a virtualized system. Journal of Computer and System Sciences, 2013, 79(2): 187–200.

9 Gulati A, Holler A, Ji M, et al. Vmware distributed resource management: Design, implementation, and lessons learned. VMware Technical Journal, 2012, 1(1): 45–64.

Testing System for Cloud Computing IaaS Isolation Properties

ZHAO Yan, CHENG Shao-Yin, JIANG Fan

(School of Computer Science and Technology, University of Science and Technology of China, Hefei 230027, China)

By analyzing and summarizing the existing test methods for isolation of cloud IaaS, a large-scale distributed testing system based on message middleware is designed and implemented for validating the isolation of a cloud IaaS. The system is a message-based distributed architecture; the control nodes and the testing nodes are separated, which helps to reduce the coupling of the system and enhance scalability. By testing the isolation of cloud IaaS in operation, the feasibility of the testing system is verified on the OpenStack platform. The testing system is suitable for testing other security abilities of cloud services.

cloud; IaaS; distributed testing; isolation; OpenStack

2016-04-22;收到修改稿時間:2016-05-26

[10.15888/j.cnki.csa.005558]