面向虛擬化系統(tǒng)的故障注入工具設計與實現(xiàn)

胡 慎，徐 珞，艾中良，李 寧

(華北計算技術研究所總體部，北京 100083)

0 引 言

面向虛擬化系統(tǒng)的故障注入技術可以給出對虛擬化系統(tǒng)的可靠性及容錯性評價，是對虛擬化系統(tǒng)進行評測的重要方法[1]。

目前存在的故障注入工具如DEFINE、NFTAPE、DOCTOR和Xception等多為傳統(tǒng)物理機故障注入工具[2]，不能直接應用到虛擬化系統(tǒng)上，且其缺少對虛擬化系統(tǒng)特有故障的測試，因此無法滿足對虛擬化系統(tǒng)可靠性及容錯性的評測。本文在分析典型虛擬化系統(tǒng)的體系結(jié)構(gòu)及虛擬化機制的基礎上，提出了一種面向虛擬化系統(tǒng)的故障注入工具架構(gòu)，并以該架構(gòu)為基礎以及Xen系統(tǒng)實現(xiàn)了一種故障注入工具，完成了向虛擬化系統(tǒng)的核心即虛擬化管理器層(virtual machine monitor，VMM)的故障注入實驗并依據(jù)實驗結(jié)果對系統(tǒng)的可靠性和容錯性進行分析，驗證了工具的有效性。

1 傳統(tǒng)故障注入技術

傳統(tǒng)故障注入技術可分為1.1節(jié)和1.2節(jié)中介紹的兩大類，此兩類技術的具體定義及優(yōu)缺點請參見文獻[3]。

1.1 基于模擬的故障注入

常見的基于模擬的故障注入工具有CECIUM、FOCUS和MEFISTO等。該方法的優(yōu)點是可以在系統(tǒng)設計的不同階段進行故障的注入，不存在可訪問性方面的限制。但是這種方法存在的缺點是在建模上比較復雜且比較耗時，不便于系統(tǒng)的便捷開發(fā)；并且需要準確的參數(shù)輸入，當設計改變復雜化歷史測試數(shù)據(jù)的使用時，很難獲取準確的參數(shù)輸入。

1.2 基于原型的故障注入

1.2.1 硬件故障注入

常見的硬件注入故障工具有Messaline、RIFLE等。其包含接觸式和非接觸式兩類注入方法：接觸式方法會直接接觸目標系統(tǒng)；非接觸式硬件故障注入不直接接觸目標系統(tǒng)的硬件設備。隨著硬件封裝密度的提高，硬件故障注入的使用也越來越少。

1.2.2 軟件故障注入

常見的軟件故障注入工具有DEFINE、NFTAPE、DOCTOR和Xception等。根據(jù)故障注入時刻的不同，可將軟件故障注入分為編譯時故障注入和運行時故障注入。編譯時故障注入是指在程序編譯連接時進行故障注入；運行時故障注入是指在程序運行時進行故障注入。

2 故障注入工具的設計與實現(xiàn)

2.1 工具總體架構(gòu)設計

與傳統(tǒng)物理機相比，虛擬化系統(tǒng)有一個重要的部分，即虛擬機管理器層，因此虛擬化系統(tǒng)的故障模型和注入方法都有其特殊性[4]。例如在虛擬化系統(tǒng)中可以對虛擬機管理器層的頁表進行修改從而實現(xiàn)虛擬機內(nèi)存故障的注入。顯然這是虛擬化系統(tǒng)特有的方法，物理機不能使用這種方法；與之相對，很多物理機故障的注入方法也不適用于虛擬化系統(tǒng)。本文提出了一種面向虛擬化系統(tǒng)的故障注入工具架構(gòu)，并在openstack云平臺上創(chuàng)建Xen虛擬機實現(xiàn)了原型系統(tǒng)工具。工具針對虛擬化系統(tǒng)的體系結(jié)構(gòu)特點，實現(xiàn)向虛擬機管理器層的故障注入，完成對虛擬化系統(tǒng)的可靠性和容錯性的分析。其總體架構(gòu)設計如圖1所示，它由以下幾部分組成：

(1)Xen虛擬機管理器，在虛擬化系統(tǒng)中，它負責所有虛擬化功能的實現(xiàn)，可以直接干涉虛擬機節(jié)點(virtual machine，VM)的CPU、內(nèi)存、硬盤等一切資源的使用。針對該層的特點，本文設計特定的故障類型，實現(xiàn)對其相關管理機制的故障注入。

(2)Xen虛擬機節(jié)點，當虛擬器管理器被注入故障時，由于其功能是對虛擬機節(jié)點進行管理，所以故障反應是通過其下的虛擬機節(jié)點表現(xiàn)出來的[5]，如系統(tǒng)崩潰、遷移失效等。

(3)前端，負責實現(xiàn)與測試者的交互，完成故障注入信息的傳入和故障注入結(jié)果收集。

圖1 故障注入工具總體架構(gòu)

2.2 故障建模方法

進行一次故障注入實驗的過程如圖2所示，因此建立故障模型是故障注入實驗的基礎。故障模型主要包括故障類型、發(fā)生位置和發(fā)生模型等信息。針對虛擬機體系結(jié)構(gòu)和虛擬化策略，結(jié)合物理計算機系統(tǒng)中的故障類型[6]，本文將虛擬機管理層的故障劃分為內(nèi)存管理、硬件資源分配、狀態(tài)查詢、虛擬機遷移、訪問控制、事件通道6類。

圖2 故障注入實驗過程

在實現(xiàn)虛擬化系統(tǒng)的故障注入時，為使故障注入能夠更貼近實際使用中的故障情況，除要設計故障類型、位置等靜態(tài)特征外，還需考慮故障的動態(tài)特征，即在虛擬化系統(tǒng)中各類型故障的發(fā)生次序及相互間的觸發(fā)關系等[7]。在實驗過程中，為建立故障發(fā)生模型，可以依據(jù)故障發(fā)生記錄來獲取各類故障發(fā)生的特點并建立相應的概率模型；另外，為降低建立模型的復雜度，縮短故障注入的周期，也可以基于人工經(jīng)驗直接建立滿足測試要求的模型，例如各類故障可以是依某種分布概率分布的，也可以是隨機分布的。

為實現(xiàn)對故障準確而簡明的描述，本文使用xml編寫測試腳本定義各類型故障及故障發(fā)生模型，建立起系統(tǒng)的故障注入模型，使得前端交互部分與注入工具得以解耦，并支持各類型故障的自動化注入。圖3為一個xml測試腳本文件示例，其以作為xml根標簽，其子標簽有和，分別定義故障模型和故障發(fā)生模型。故障模型下有故障類型、故障位置等標簽；故障發(fā)生模型下有故障開始時間、停止時間等標簽。

圖3 測試腳本文件

2.3 故障實現(xiàn)

通過對Xen系列虛擬化系統(tǒng)的體系結(jié)構(gòu)和虛擬化策略的研究分析，可知Xen系列虛擬化管理功能，包括內(nèi)存管理、虛擬機遷移等，都需要通過其超級調(diào)用hypercall來進行，因此可通過對各超級調(diào)用注入故障實現(xiàn)對對應管理功能的故障注入。

2.3.1 Xen超級調(diào)用

目前Xen系列虛擬化系統(tǒng)共有通用的超級調(diào)用37個，還有一些為具體機器環(huán)境特有的。為了唯一標識每個超級調(diào)用，Xen系統(tǒng)為每個超級調(diào)用定義了一個唯一的編號，即為超級調(diào)用號[8]，見表1；為記錄各個超級調(diào)用函數(shù)的入口地址，Xen系統(tǒng)定義超級調(diào)用表，可以通過超級調(diào)用號在其中定位到對應函數(shù)的入口地址。

表1 Xen系統(tǒng)超級調(diào)用號

表1(續(xù))

2.3.2 故障類型與超級調(diào)用對應關系

本文要實現(xiàn)的6種類型的故障注入均可通過超級調(diào)用實現(xiàn)，其與超級調(diào)用的對應關系見表2，可根據(jù)其中的超級調(diào)用號在表1中查得對應的超級調(diào)用名稱。實驗過程中對各超級調(diào)用注入故障即可完成對應類型的故障注入。

2.3.3 故障注入原理

在Xen系列虛擬化系統(tǒng)中，超級調(diào)用為一種類似系統(tǒng)調(diào)用的操作，其可以使處在1環(huán)的內(nèi)核能夠越權執(zhí)行一些在0環(huán)才能進行的操作，其軟中斷號為0x82，處理程序為hypercall。其申請和執(zhí)行過程是通過系統(tǒng)調(diào)用ioctl進行的，本文利用kprobe對其對用的內(nèi)核處理例程sys_ioctl進行攔截并對其參數(shù)進行修改，完成對超級調(diào)用的故障注入。

在Xen系列虛擬化系統(tǒng)中，kprobe是linux內(nèi)核中的一個輕量級動態(tài)內(nèi)核調(diào)試裝置，可以向正在運行的內(nèi)核中插入斷點。其實現(xiàn)了Kprobes、jprobes和kretprobes這3種類型的探針，此3類探針各有優(yōu)缺點及適用的情況，對其具體分析請參見文獻[9]。

依據(jù)文獻[9]，由于jprobes可以獲取到內(nèi)核函數(shù)的參數(shù)，本文使用jprobes進行對sys_ioctl的攔截。另外，jprobes雖然可以獲得內(nèi)核函數(shù)的參數(shù)，但不能修改。在jprobes對sys_ioctl成功攔截后，本文使用copy_to_user()和copy_from_user()這兩個函數(shù)對參數(shù)進行修改，完成故障的注入。其基本流程如圖4所示，具體過程為：首先使用jprobes攔截ioctl，攔截完成后通過copy_from_user()將超級調(diào)用的參數(shù)M修改改為N，然后利用copy_to_user()將N寫到用戶空間中。當執(zhí)行sys_ioctl()時，函數(shù)通過copy_from_user()獲得超級調(diào)用參數(shù)值，而此時獲得的參數(shù)N已經(jīng)是修改后的錯誤參數(shù)值，所以故障被成功注入。

圖4 故障注入原理

另外，由于sys_ioctl[10]是linux的通用系統(tǒng)調(diào)用接口，除超級調(diào)用外，其它很多功能也會觸發(fā)其執(zhí)行。因此在注入過程中需要對其本次執(zhí)行是否由超級調(diào)用觸發(fā)進行判定。sys_ioctl由3個參數(shù)組成：fd，IOCTL_PRIVCMD和&hcall，其分別為文件描述符、命令碼和指向系統(tǒng)調(diào)用參數(shù)的指針。sys_ioctl在其第二個參數(shù)中定義調(diào)用的觸發(fā)源，其格式定義如圖5所示，其共包含32位，前兩位是模式標記位，接下來14位表示數(shù)據(jù)結(jié)構(gòu)位數(shù)，然后8位是類型標記位，最后8位標記編號。

圖5 ioctl命令碼格式

宏IOCTL_PRIVCMD_HYPERCALL表示超級調(diào)用的命令碼[11]，由于不同環(huán)境下該值會發(fā)生變化，所以用X表示該值。在注入故障時，對sys_ioctl()的參數(shù)cmd進行判定，若其值為X，則進行故障注入；若不是則不進行故障注入。

2.3.4 故障注入過程

以本文提出的架構(gòu)實現(xiàn)的故障注入工具可以進行故障的自動化注入，測試者只需編寫符合條件的xml測試腳本，即可完成故障注入，圖6所示即為一次故障注入的流程。其中向虛擬機管理器注入故障為本工具的核心部分，其實現(xiàn)過程如下：

(1)在內(nèi)核函數(shù)sys_ioctl處插入jprobes探針，sys_ioctl函數(shù)在內(nèi)核的入口地址由/proc/kallsyms查得；

(2)在故障函數(shù)內(nèi)部判斷cmd的值，若cmd值為X，則本次系統(tǒng)調(diào)用為超級調(diào)用申請，程序繼續(xù)執(zhí)行；若不是，則不是超級調(diào)用申請，程序退出。

(3)經(jīng)判定為超級調(diào)用申請，使用copy_from_user()從傳入的指針org處得到超級調(diào)用的參數(shù)，然后將其存到hypercall中，變量類型為privcmd_hypercall，該變量數(shù)據(jù)結(jié)構(gòu)包含兩個成員：op定義hypercall號，另一個為一元數(shù)組，定義hypercall的各參數(shù)；

(4)取出超級調(diào)用號hypercall.op進行判斷，如果故障注入信息中的故障位置相同，那么本次超級調(diào)用是故障注入的目標，程序繼續(xù)執(zhí)行；如果不一致，則程序退出；

(5)確定本次超級調(diào)用是故障注入目標后，根據(jù)本次實驗要注入的故障類型及故障模式將對應超級調(diào)用值進行修改，然后把修改后的值傳入用戶空間；

(6)讀取故障注入信息中的故障停止時間，如果已達到要求，則取消jprobes的注冊。

進行以上步驟后，保存在用戶空間的超級調(diào)用參數(shù)是故障函數(shù)更改之后的，所以故障被成功注入。

圖6 自動化故障注入流程

2.4 前端部分

在本文的提出的架構(gòu)中，前端部分負責提供圖形化交互接口，實現(xiàn)與測試人員的信息交互功能。其具體作用為：在故障注入開始時，收到測試者編寫的測試腳本并對其進行解析，然后將解析出的故障注入信息傳入虛擬機管理器；故障注入完成時，收集故障虛擬機的日志信息并進行記錄以反饋給測試者，從而測試者可以以日志信息中提供的實驗環(huán)境、故障類型、系統(tǒng)各部分故障反應等信息為依據(jù)，對本次故障注入實驗進行結(jié)果分析。

3 實驗結(jié)果分析

為了驗證本文設計工具的故障注入效果，本文基于openstack云平臺搭建Xen虛擬化系統(tǒng)進行實驗。依據(jù)所提出的故障模型，本文初步實現(xiàn)了虛擬機管理器層6類故障的注入。這些故障能夠在一定程度上反映Xen系統(tǒng)發(fā)生故障時的行為反應。據(jù)實驗結(jié)果，Xen虛擬化系統(tǒng)對各類型故障的反應行為分別為：

(1)內(nèi)存管理故障，在該類型故障的實驗中，需將其分為多種故障模式進行，各種模式下的故障在實驗中的注入次數(shù)及對系統(tǒng)和其它各節(jié)點的影響是不同的。其中，頁表掛載和卸載故障的后果最為嚴重，通常會導致系統(tǒng)的崩潰，不過其故障反應不會由故障節(jié)點擴展到其它節(jié)點；頁表更新故障雖整體后果沒有上種類型嚴重，但其結(jié)果較為復雜，因為在Xen系統(tǒng)包含有高級頁表和低級頁表，需分別對此兩類頁表進行故障注入實驗，結(jié)果表明在注入次數(shù)較少的情況下(如每次實驗注入次數(shù)小于10次)，系統(tǒng)大概率可以對其容錯而不會有異常反應，但是當每次實驗注入故障次數(shù)增多時，系統(tǒng)無法繼續(xù)對該類故障保持容錯性，出現(xiàn)系統(tǒng)崩潰現(xiàn)象，同時在對兩類頁表實驗的對比中得出，系統(tǒng)對高級頁表的容錯性更低，更容易導致系統(tǒng)的崩潰，且恢復難度更大。實驗過程中，存在頁表掛載故障時，有時會出現(xiàn)異常而有時則不會，其結(jié)果是由特定因素決定的，若將操作碼置為一些特定值如1時就會發(fā)生異常，而其它情況則不會；低級頁表的更新故障在大多數(shù)情況下不會使系統(tǒng)發(fā)生錯誤，但實驗中將低級頁表項的機器地址置為一些高級頁表項的值時就會引發(fā)系統(tǒng)錯誤。

(2)硬件資源分配故障，其可分為Xen系統(tǒng)中各節(jié)點虛擬的CPU個數(shù)、內(nèi)存大小等故障模式，通過對其分別進行實驗發(fā)現(xiàn)各模式故障的后果一致性較強且系統(tǒng)對該類故障的容錯性較高，只有在故障存在的情況下新建節(jié)點時會造成異常，且該異常不會使系統(tǒng)出現(xiàn)嚴重后果。

(3)狀態(tài)查詢故障，該類型故障比較簡單，包括虛擬機管理器的版本信息及環(huán)境信息等，對系統(tǒng)注入該類型故障時沒有出現(xiàn)運行上的異常情況，只是在執(zhí)行狀態(tài)查詢時會出現(xiàn)結(jié)果的不符情況，并且實驗中只需重新啟動虛擬機管理器，該類故障就可完全修復。

(4)虛擬機遷移的故障，此類故障包括對故障節(jié)點和非故障節(jié)點進行遷移，如果只執(zhí)行非故障節(jié)點的遷移而不對故障節(jié)點執(zhí)行遷移，則系統(tǒng)無異常，即系統(tǒng)對該類型故障有較好隔離性，將其隔離在故障節(jié)點中而沒有使之擴散；但對故障節(jié)點執(zhí)行遷移操作時，系統(tǒng)沒有體現(xiàn)出進一步的容錯能力和隔離性，故障發(fā)生了擴散導致系統(tǒng)出現(xiàn)崩潰，即故障沒有被隔離。實驗中將虛擬機遷移故障注入到目標節(jié)點中，同時正常運行同一虛擬機管理器下的另外兩個節(jié)點進行對比，現(xiàn)象為故障節(jié)點開始時可以正常運行，但進行虛擬機的遷移時會發(fā)生異常，并導致虛擬化系統(tǒng)出現(xiàn)崩潰。

(5)訪問控制故障，包括節(jié)點間訪問權限和各節(jié)點對硬件資源訪問權限等故障模式，實驗中注入該類型故障時沒有導致系統(tǒng)運行出現(xiàn)故障，只是會出現(xiàn)節(jié)點之間和各節(jié)點對資源訪問的權限發(fā)生錯誤的情況。所以該類型故障造成后果較為輕微且容易修復，及系統(tǒng)對該類型故障有較好容錯性。

(6)事件通道故障，注入該類型故障時，系統(tǒng)運行沒有出現(xiàn)異常，但如果在該故障存在時對節(jié)點進行遷移操作，就會發(fā)現(xiàn)該操作會發(fā)生錯誤不能正常進行，不過此時發(fā)生的錯誤不會造成更加嚴重的后果，且如果及時重啟虛擬機管理器可以修復這些錯誤使功能正常執(zhí)行。例如實驗中存在事件通道故障時進行虛擬機遷移時，由于do_evtch_op負責處理事件通道，系統(tǒng)會報錯并提示該函數(shù)內(nèi)部發(fā)生了錯誤，即導致虛擬機遷移發(fā)生了失敗。

根據(jù)以上實驗結(jié)果分析可得，Xen虛擬化系統(tǒng)可以對超級調(diào)用故障做出容錯反應，但只限于故障次數(shù)較少的情況?？傮w而言后果較為嚴重，有很大幾率會導致虛擬化系統(tǒng)的管理功能故障，進而造成系統(tǒng)的崩潰，所以Xen系統(tǒng)對于虛擬機管理層的故障容錯能力較低。

4 結(jié)束語

本文設計了一種面向虛擬化系統(tǒng)的故障注入工具架構(gòu)，并依據(jù)該架構(gòu)以Xen虛擬化系統(tǒng)為基礎實現(xiàn)了原型系統(tǒng)工具，完成了對虛擬化管理層的自動化故障注入實驗，對工具的有效性進行了驗證。通過本工具，測試者可以使用xml語言編寫故障注入腳本，實現(xiàn)測試環(huán)境的自動化部署和各類故障的自動化注入。實驗結(jié)果表明，本工具可以有效實現(xiàn)虛擬化系統(tǒng)管理層各類故障的注入，并可以對故障結(jié)果進行收集以支撐對系統(tǒng)的可靠性和容錯性評測。

[1]LI Shulin,LUO Lin,YANG Yan.Research on cloud computing and virtualization[J].Software Guide,2013,12(1):141-143(in Chinese).[李樹林,羅林,楊艷.云計算與虛擬化技術研究[J].軟件導刊,2013,12(1):141-143.]

[2]LI Yi,XU Ping,WAN Han.Research on a QEMU-based processor fault simulation and injection method[J].Computer Engineering and Science,2014,36(1):19-27(in Chinese).[李毅,徐萍,萬寒.基于QEMU實現(xiàn)的處理器類故障模擬與注入方法研究[J].計算機工程與科學,2014,36(1):19-27.]

[3]LEI Wei,OU Yuyi.Summary of security test methods based on fault injection[J].Modern Computer,2012,4(1):20-23(in Chinese).[雷煒,歐毓毅.基于故障注入的安全測試方法綜述[J].現(xiàn)代計算機,2012,4(1):20-23.]

[4]FENG Gang.Research and design of fault injectors for virtual machine in cloud computing[D].Harbin:Harbin Institute of Technology,2013(in Chinese).[馮剛.面向云計算平臺的虛擬機故障注入工具研究與設計[D].哈爾濱:哈爾濱工業(yè)大學,2013.]

[5]HU Yao,XIAO Ruliang,JIANG Jun,et al.Virtual machine memory of real-time monitoring and adjusting on-demand based on Xen virtual machine[J].Journal of Computer Applications,2013,33(1):254-257(in Chinese).[胡耀,肖如良,姜軍,等.基于Xen虛擬機的內(nèi)存資源實施監(jiān)控與按需調(diào)整[J].計算機應用,2013,33(1):254-257.]

[6]Guan Q,Debardeleben N,Blanchard S,et al.F-SEFI:A fine-grained soft error fault injection tool for profiling application vulnerability[C]//IEEE 28th International Parallel and Distributed Processing Symposium.IEEE,2014:1245-1254.

[7]NI Zhen.A management system of virtual machine pool based on cloud computing[D].Chongqing:Chongqing University,2012(in Chinese).[倪珍.基于云計算架構(gòu)的虛擬機池管理系統(tǒng)[D].重慶:重慶大學,2012.]

[8]Wang Feifei,Chen Ping,Mao Bing,et al.RandHyp:Preventing attacks via Xen hypercall interface[J].IFIP Advances in Information & Communication Technology,2012,376(6):138-149.

[9]MA Yandong.Research and design of fault injection platform for virtualization system[D].Harbin:Harbin Institute of Technology,2015(in Chinese).[麻彥東.面向虛擬化系統(tǒng)的故障注入平臺的研究與設計[D].哈爾濱:哈爾濱工業(yè)大學,2015.]

[10]Pham C,Chen D,Kalbarczyk Z,et al.CloudVal:A framework for failure validation of virtualization environment in cloud infrastructure[C]//IEEE/IFIP International Confe-rence on Dependable Systems & networks,2013:189-196.

[11]Williams D,Jamjoom H,Weatherspoon H.The Xen-Blanket:Virtualize once,run everywhere[C]//Proceedings of 7th ACM European Conference on Computer Systems.ACM,2012:113-126.