崔競松,路昊宇,郭 遲,何 松

(1.武漢大學(xué)a.計算機學(xué)院;b.空天信息安全與可信計算教育部重點實驗室,武漢430072; 2.武漢大學(xué)衛(wèi)星導(dǎo)航定位技術(shù)研究中心,武漢430079)

基于事件驅(qū)動機制的虛擬化故障檢測恢復(fù)系統(tǒng)

崔競松1a,1b,路昊宇1a,郭 遲2,何 松1a

(1.武漢大學(xué)a.計算機學(xué)院;b.空天信息安全與可信計算教育部重點實驗室,武漢430072; 2.武漢大學(xué)衛(wèi)星導(dǎo)航定位技術(shù)研究中心,武漢430079)

為解決虛擬化條件下云平臺故障排除不及時的問題,在開源云平臺OpenStack上設(shè)計并實現(xiàn)一種虛擬化故障檢測恢復(fù)系統(tǒng)。該系統(tǒng)由GUI層、調(diào)度層、邏輯層和功能層組成,以事件驅(qū)動機制為核心,將系統(tǒng)中傳遞的信息作為事件按時序進行處理。以感知模塊、策略模塊、執(zhí)行模塊為主體,調(diào)用OpenStack API和Libvirt API實現(xiàn)與虛擬機管理層的交互。建立以信息獲取、分析處理、故障恢復(fù)為主要內(nèi)容的故障檢測恢復(fù)體系,通過對云平臺運行環(huán)境的實時檢測,獲取狀態(tài)參數(shù),根據(jù)策略對參數(shù)進行分析判斷并制定應(yīng)對措施,實現(xiàn)對故障的自動恢復(fù)。實驗結(jié)果證明,該系統(tǒng)可以在無代理情況下對云平臺進行實時檢測和故障自動恢復(fù),增強云環(huán)境的安全性,提升云平臺的高可用性。

OpenStack云平臺;負載均衡;事件驅(qū)動機制;高可用性;虛擬化;云計算

1 概述

云計算將大量的計算資源、存儲資源與軟件資源鏈接在一起,形成巨大規(guī)模的共享虛擬IT資源池[1],綜合分布式計算、虛擬化技術(shù)、負載均衡技術(shù)、網(wǎng)絡(luò)存儲技術(shù)等傳統(tǒng)計算機技術(shù)[2],屏蔽了底層的差異,把不同的、獨立的計算機資源抽象成統(tǒng)一的、共享的資源統(tǒng)一向外界提供服務(wù)[3]。在云計算環(huán)境下,IT領(lǐng)域按需服務(wù)的理念得到了真正體現(xiàn),云計算通過整合分布式資源,構(gòu)建應(yīng)對多種服務(wù)要求的計算環(huán)境,滿足用戶定制化要求,并可通過網(wǎng)絡(luò)訪問相應(yīng)的服務(wù)資源[4]。

云平臺資源的高度集中化使得其高可用性變得非常重要,任何系統(tǒng)維護與宕機都可能引起較大規(guī)模的服務(wù)缺失[5]。對于一個計算中心而言,提供一種高可用性的能力服務(wù)于所有在其上運行的應(yīng)用是要考慮的關(guān)鍵問題之一[6]?，F(xiàn)有的云平臺都提供了一定的技術(shù)保證了云的高可用性,比如VMware vSphere[7]能夠檢測虛擬機所在物理主機運行情況,但是對運行中的虛擬機及應(yīng)用程序方面的監(jiān)測較少,一旦發(fā)生故障將不能得到及時處理,導(dǎo)致服務(wù)中斷。本文在OpenStack基礎(chǔ)上設(shè)計并實現(xiàn)一種基于事件驅(qū)動機制的虛擬化故障檢測恢復(fù)系統(tǒng),從物理機、虛擬機、虛擬機應(yīng)用3個層次對云平臺環(huán)境進行監(jiān)控,實時獲取運行參數(shù),實現(xiàn)對故障的無代理檢測恢復(fù)。

2 系統(tǒng)設(shè)計

OpenStack[8]是美國國家航空航天局和Rackspace公司共同開發(fā)的開源云計算平臺,旨在為公共及私有云的建設(shè)與管理提供各種組件。系統(tǒng)在OpenStack基礎(chǔ)上,通過API調(diào)用整合形成GUI層、Scheduler[9]調(diào)度層、邏輯層和功能層,并按邏輯將功能層和邏輯層劃分為感知模塊、策略模塊和執(zhí)行模塊三大核心模塊,采用事件驅(qū)動機制將各部分有機結(jié)合起來,通過對事件的處理實現(xiàn)系統(tǒng)對故障的檢測和恢復(fù)功能。系統(tǒng)架構(gòu)如圖1所示。

圖1 系統(tǒng)架構(gòu)

(1)功能層:通過對Libvirt API[10]和OpenStack API的封裝調(diào)用,實現(xiàn)OpenStack和Libvirt進行交互,連接系統(tǒng)和虛擬機管理層,同時功能層作為整個系統(tǒng)的最底層為其它各層的函數(shù)調(diào)用及相關(guān)功能提供支持。

(2)邏輯層:采用事件驅(qū)動機制,將系統(tǒng)中傳遞的信息規(guī)范為事件由相應(yīng)的對象進行處理。事件主要分為感知事件、策略事件和執(zhí)行事件。

(3)調(diào)度層:負責(zé)對事件隊列進行操作,作為系統(tǒng)運行的樞紐進行調(diào)度,保證事件有條不紊地被執(zhí)行,對事件隊列滿、事件隊列空等各種異常進行處理。

(4)GUI層:用來與用戶進行交互,用戶可以通過該界面,獲得系統(tǒng)的運行參數(shù),主要包括虛擬機的運行狀態(tài)、虛擬機的資源占用等情況。同時,用戶可以通過界面控制虛擬機的運行狀況(比如停止某臺虛擬機),對系統(tǒng)的部分基本配置(比如打撈時間的設(shè)置等)進行更改。

(5)核心模塊:三大模塊均由對應(yīng)的Handler和Function組成。感知模塊負責(zé)感知整個系統(tǒng)的運行情況;策略模塊根據(jù)感知的結(jié)果進行處理;執(zhí)行模塊負責(zé)執(zhí)行策略模塊制定的恢復(fù)策略,共同構(gòu)成系統(tǒng)的檢測恢復(fù)核心。

3 事件驅(qū)動機制

為了實現(xiàn)不同層面、不同模塊、不同進程(線程)之間通信和信息處理,系統(tǒng)采用事件驅(qū)動的方式,將感知到的信息、制定的策略等系統(tǒng)中傳遞的信息作為事件,由事件處理進程進行處理,平時事件處理進程處于等待狀態(tài),由接收到的任何一個事件進行驅(qū)動[11]。事件驅(qū)動主要設(shè)計3個類:Event事件類, Handler邏輯類,Scheduler調(diào)度類。在事件驅(qū)動機制中,Event是派生所有事件的基類,用來標識系統(tǒng)中各種行為,比如啟動虛擬機;Handler是派生所有事件處理對象的基類,用來處理相應(yīng)Event事件類; Scheduler調(diào)度類負責(zé)調(diào)度事件,事件隊列Queue定義在Scheduler類中,Scheduler對事件隊列進行維護,用來保證事件被有序處理。事件驅(qū)動機制總體設(shè)計如圖2所示。

圖2 事件驅(qū)動機制總體設(shè)計

事件驅(qū)動的過程主要分3個步驟:首先是將事件放入全局的事件隊列Queue中,然后按時間順序從事件隊列中取出事件,再通過指定的事件處理對象(即Handler)處理事件,在處理過程中可能會往事件隊列中加入新的事件。這樣不斷取出事件并處理一直到事件隊列為空,就實現(xiàn)了一次感知過程。

Scheduler主要負責(zé)事件的調(diào)度,采用基于事件[12]的周期輪詢機制,按時序?qū)ο到y(tǒng)中的事件進行統(tǒng)一的調(diào)度和處理。事件隊列是由優(yōu)先級和時間決定的有序隊列,按照優(yōu)先級由高到低的順序執(zhí)行,在優(yōu)先級相同的情況下按照事件執(zhí)行時間先后排序執(zhí)行,確保隊首永遠是第一個要執(zhí)行的事件。Scheduler采取每執(zhí)行一個事件就在后臺啟動一個線程的方式防止事件等待加快并行,將隊列設(shè)置成靜態(tài)變量防止多線程隊列,實現(xiàn)對隊列的高度維護。由于事件的插入和取出并執(zhí)行相互獨立,可能會發(fā)生隊列中第一個事件還沒到執(zhí)行時間,Scheduler正在休眠,實然插入一個需要立即執(zhí)行的新事件需要喚醒隊列,為此引入鎖機制。Scheduler休眠需滿足2個條件:(1)執(zhí)行時間不小于現(xiàn)在系統(tǒng)的時間;(2)鎖必須是關(guān)閉的。當(dāng)Scheduler休眠時,新到達的事件執(zhí)行時間小于現(xiàn)在系統(tǒng)時間,系統(tǒng)就會打開鎖,從而破壞Scheduler休眠的必要條件,喚醒Scheduler。

4 關(guān)鍵技術(shù)

系統(tǒng)的主體是由功能層和邏輯層共同組成的感知模塊、策略模塊和執(zhí)行模塊,在此基礎(chǔ)上通過事件驅(qū)動機制進行調(diào)度,實現(xiàn)對故障的自動檢測和恢復(fù)功能,具體工作流程如圖3所示。

圖3 系統(tǒng)工作流程

通過感知模塊獲取系統(tǒng)運行信息,由策略模塊對感知的信息進行分析并區(qū)別制定策略,執(zhí)行模塊根據(jù)策略進行故障恢復(fù)、提示系統(tǒng)管理員或者在系統(tǒng)運行正常的情況下無動作。從而在云平臺中某臺物理服務(wù)器發(fā)生故障時,能夠自動檢測故障并選擇合適的物理機重建運行在該物理機上所有虛擬機;當(dāng)物理機上某臺虛擬機發(fā)生故障時,能夠刪除故障虛擬機,根據(jù)其快照或鏡像快速進行重建;當(dāng)虛擬機中的某個應(yīng)用進程發(fā)生故障時(進程非正常退出、非正常掛起),在無代理的情況下,直接操作GuestOS內(nèi)核對象,恢復(fù)啟動虛擬機里的進程。

4.1 感知模塊

感知模塊由感知Function和Handler組成,其中,Function主要封裝Libvirt API獲取信息實現(xiàn)底層功能,完成對上層Handler的支持。感知模塊Function類結(jié)構(gòu)如圖4所示。

圖4 感知模塊Function類

感知模塊通過感知Function類中的F_Host、F_ VM、F_APP 3個子類分別獲取物理機、虛擬機、虛擬機應(yīng)用的信息,由相應(yīng)的Handler類進行處理,生成對應(yīng)的感知事件進入策略模塊進行處理。其中,物理機主要考察主機狀態(tài)、內(nèi)存、CPU、網(wǎng)絡(luò)、磁盤等信息,虛擬機主要考察全局(指定)虛擬機狀態(tài)、網(wǎng)絡(luò)、磁盤、內(nèi)存等信息,虛擬機應(yīng)用主要考察進程狀態(tài)、進程數(shù)、內(nèi)存等信息。以物理機狀態(tài)獲取為例,Function類獲取信息流程為:(1)確定獲得物理主機狀態(tài)的類F_hostStatus;(2)通過與主機建立Libvirt連接調(diào)用函數(shù)getConnect()獲得與物理機的連接conn;(3)對conn進行判斷,若conn為fals則相應(yīng)的物理機狀態(tài)為0(0表示物理機斷電),若conn為ture,則相應(yīng)物理機狀態(tài)為1(1表示物理機正常)。

4.2 策略模塊

策略模塊對感知模塊傳送來的感知事件進行分析,根據(jù)策略機制來判斷平臺出現(xiàn)何種故障,并生成相應(yīng)的策略事件。策略機制是整個模塊的核心,不同的事件對應(yīng)不同的策略機制。以恢復(fù)虛擬機的機制為例,共有3張表需要維護,第1張表Instance_ Info,信息主要來自nova的數(shù)據(jù)庫并由nova進行維護,保存虛擬機的基本信息。它是一個字典的結(jié)構(gòu),每一項也是一個字典,格式為{虛擬機的序列號: {‘id’:’ ’,’isActive’:’ ’}。第2張表VM_ State,主要由Libvirt維護,它的信息主要是感知模塊感知到的信息,它也是一個字典結(jié)構(gòu),每一項為{虛擬機的id:虛擬機的狀態(tài)}。第3張表Execution_ State,記錄一個虛擬機正在進行恢復(fù)的操作,其信息主要是根據(jù)Instance_Info表和VM_State表,信息的修改主要由執(zhí)行Handler來執(zhí)行。恢復(fù)虛擬機的邏輯機制如表1所示。

表1 虛擬機恢復(fù)的邏輯機制

4.3 執(zhí)行模塊

執(zhí)行模塊主要是對策略模塊分析制定的策略響應(yīng)并采取相應(yīng)措施,對故障進行恢復(fù)。執(zhí)行模塊Function類圖如圖5所示。

圖5 執(zhí)行模塊Function類圖

F_ExeHost主要處理物理主機異常,可以對物理機進行關(guān)閉、重啟、配置網(wǎng)絡(luò)、殺死進程、向管理員發(fā)送異常報告的操作;F_ExeVM主要處理虛擬機出現(xiàn)異常,可以重新開啟一臺虛擬機,對運行的虛擬機進行關(guān)閉、銷毀、配置網(wǎng)絡(luò)、向管理員發(fā)送異常報告的操作;F_EAPP主要處理虛擬應(yīng)用出現(xiàn)異常,包括殺死進程、重啟應(yīng)用程序、向管理員發(fā)送異常報告等。執(zhí)行Handler類的核心是OpenStack API的調(diào)用。Handler類通過調(diào)用OpenStack平臺提供的對外接口,用類與OpenStack進行交互,利用OpenStack的現(xiàn)有功能完成操作。

4.4 負載平衡

為了在創(chuàng)建和恢復(fù)虛擬機時實現(xiàn)負載均衡、提高資源利用率,由Nova-Scheduler[13]分析并選擇性能最佳的物理主機創(chuàng)建并啟動虛擬機,共分3個步驟:

(1)主機過濾:在獲取到集群中所有物理主機列表的情況下,根據(jù)特定的屬性過濾掉不滿足條件的主機,生成新的主機列表。過濾器可以使用OpenStack提供的默認過濾器,也可以根據(jù)需要進行設(shè)置,創(chuàng)建特定的過濾器。

(2)權(quán)值計算:將過濾后的主機列表進行性能評估。在此采取權(quán)值算法,給主機的每個特性設(shè)定權(quán)重值,將內(nèi)存大小、磁盤容量、網(wǎng)絡(luò)流量等特性值分別相應(yīng)的權(quán)重相乘,把得到的數(shù)值加起來就得到主機的綜合權(quán)值。

(3)主機選擇:根據(jù)每臺主機的綜合權(quán)值對列表內(nèi)的主機進行排序,從而選擇合適的主機進行虛擬機的創(chuàng)建與重啟。根據(jù)虛擬機的不同特性要求,也可以選擇主機的部分特性進行權(quán)值計算后進行排序。

5 實驗結(jié)果與分析

5.1 實驗環(huán)境

實驗平臺由5臺主機組成,其中主控節(jié)點1臺,主要配置nova,glance,keystone,horizon,mysql服務(wù),向計算節(jié)點發(fā)送命令;共享存儲1臺,主要配置oracle服務(wù),具有數(shù)據(jù)庫、共享存儲功能;計算節(jié)點3臺(分別為B1,B2,B3),主要配置有novacompute,nova-network服務(wù),運行虛擬機提供虛擬應(yīng)用。計算節(jié)點3臺主機運行的虛擬機分別為VM1, VM2,VM3,操作系統(tǒng)依次為Windows Xp Sp3, Ubuntu12.04 LTS和Windows 7 Sp2。實驗環(huán)境配置如表2所示。

表2 實驗環(huán)境配置

5.2 實驗測試

實驗測試過程如下:

(1)物理主機故障:在物理主機B1上正在運行有虛擬機VM1,因為B1突然斷電不能正常工作, B2,B3均正常工作,系統(tǒng)檢測到后重建了虛擬機VM1,并向管理員發(fā)送異常報告。在其他條件不定的情況下改變B2、B3的硬盤大小,虛擬機在2臺物理主機上重建的概率分布如圖6所示。

圖6 物理主機選擇分布

(2)虛擬機故障:在計算節(jié)點的物理主機B1, B2,B3上分別運行有虛擬機VM1,VM2,VM3,對以下2種情形測試:1)在終端利用Libvirt命令刪除虛擬機導(dǎo)致虛擬機崩潰,系統(tǒng)檢測到異常后在物理主機上重建了虛擬機,重建的虛擬機與崩潰的虛擬機一樣并保存了原虛擬機的永存數(shù)據(jù);2)在虛擬機上打開多個任務(wù)窗口導(dǎo)致虛擬機宕機,系統(tǒng)檢測到異常后對虛擬機進行了重啟。虛擬機恢復(fù)時間如表3所示。

表3 虛擬機恢復(fù)時間

(3)虛擬應(yīng)用故障:在虛擬機上運行有FTP服務(wù)器、在線視頻庫和Web服務(wù)器為用戶提供FTP下載、在線視頻觀看和網(wǎng)站訪問服務(wù),在虛擬機上通過任務(wù)管理器將應(yīng)用程序進程關(guān)閉,系統(tǒng)檢測到進程異常后進行恢復(fù),繼續(xù)為用戶提供服務(wù)。虛擬應(yīng)用恢復(fù)時間如表4所示。

表4 虛擬應(yīng)用恢復(fù)時間

通過實驗結(jié)果表明,本文系統(tǒng)能夠在虛擬化條件下自動檢測云平臺運行狀態(tài)并獲取相關(guān)參數(shù),通過對數(shù)據(jù)分析判斷發(fā)現(xiàn)異常,根據(jù)既定策略進行故障排除,完成虛擬機及應(yīng)用的重啟重建,恢復(fù)中斷的服務(wù),實現(xiàn)對云平臺故障實時無代理恢復(fù)。

6 結(jié)束語

隨著云計算應(yīng)用日益廣泛,云服務(wù)的可靠性要求也越來越高,云平臺中的物理主機崩潰、虛擬機宕機、云應(yīng)用無響應(yīng)等故障都會導(dǎo)致云服務(wù)的中斷,影響用戶體驗。本文利用OpenStack云平臺設(shè)計實現(xiàn)的基于事件驅(qū)動機制的虛擬化故障檢測恢復(fù)系統(tǒng),通過對云平臺運行參數(shù)的獲取和分析處理,同時充分考慮負載均衡,實現(xiàn)了對云平臺的實時檢測和故障的無代理自動恢復(fù),有效縮短了故障時間,提升了云平臺的高可用性。由于本文方法并未考慮大數(shù)量故障的情況,數(shù)量增多會對故障的檢測和恢復(fù)造成不利的影響,比如耗時較多、負載過大等,因此提高大數(shù)量故障檢測效率將是下一步研究的重點。

[1] Feng Dengguo,Zhang Min,Zhang Yan,et al.Study on Cloud Computing Security[J].Journal of Software, 2011,22(1):71-83.

[2] Zissis D,LekkasD.AddressingCloudComputing SecurityIssues[J].FutureGenerationComputer Systems,2012,28(3):583-592.

[3] Varia J.CloudArchitectures-AmazonWebService[EB/OL].(2009-03-01).http://acmbangalore, org/events/monthly-talk/may-2008-cloud-architecturesamazon-web-services.html.

[4] 林 闖,蘇文博,孟 坤,等.云計算安全:架構(gòu),機制與模型評價[J].計算機學(xué)報,2013,36(9):1765-1784.

[5] 陳海波,夏虞斌,陳 榕.高可信、高擴展與高可用云計算平臺的研究與展望[J].高性能計算發(fā)展與應(yīng)用, 2013,43(2):29-34.

[6] Calzolari F,ArezziniS,CiampaA,etal.High Availability Using Virtualization[J].Journal of Physics, 2010,219(5).

[7] Tate J,Kelley R,Maliska S R R,et al.IBM SAN Solution Design Best Practices for VMware vSphere ESXi[Z].IBM Redbooks,2013.

[8] OpenStack[EB/OL].(2014-02-01).http://www. openstack.org.

[9] Litvinski O,GherbiA.ExperimentalEvaluationof OpenStack Compute Scheduler[J].Procedia Computer Science,2013,19(1):116-123.

[10] Sotomayor B,Montero R S,Llorente I M,et al.Virtual InfrastructureManagementinPrivateandHybrid Clouds[J].IEEE Internet Computing,2009,13(5): 14-22.

[11] 王 莉,李新明,李 藝,等.高可用性系統(tǒng)軟件HHA的事件驅(qū)動機制[J].計算機工程與應(yīng)用,2003, 39(4):145-147.

[12] Pimentel J R.An Incremental Approach to Task and Message SchedulingforAutosarBasedDistributed Automotive Applications[C]//Proceedings of the 4th International Workshop on Software Engineering for Automotive Systems.[S.1.]:IEEE Computer Society, 2007:1-7.

[13] Wen X,Gu G,Li Q,et al.Comparison of Open-source CloudManagementPlatforms:OpenStackand OpenNebula[C]//Proceedings of the 9th International ConferenceonFuzzySystemsandKnowledge Discovery.[S.1.]:IEEE Press,2012:2457-2461.

編輯 索書志

Virtualization Fault Detection Recovery System Based on Event-driven Mechanism

CUI Jingsong1a,1b,LU Haoyu1a,GUO Chi2,HE Song1a
(1a.School of Computer Science;b.Key Laboratory of Aerospace Information and Trusted Computing, Wuhan University,Wuhan 430072,China;2.Global Navigation Satellite System Research Center, Wuhan University,Wuhan 430079,China)

In order to solve the problem that the fault troubleshooting of cloud platforms is not timely,and guarantee the continuity of cloud services,this paper designs and implements a virtualization fault detection and recovery system based on event-driven mechanism,which is on the open-source cloud platform——OpenStack.The system is composed of GUI layer,scheduling layer,logic layer and functional layer,and processes the information transmitted in the system by timing as an event on the basis of event-driven mechanism.It mainly uses perception module,policy module and execution module,which call OpenStack API and Libvirt API to interact with the management of virtual machines.The established fault detection recovery system mainly includes information acquisition,analysis and processing,fault recovery,and by real-time detection of the cloud platform’s runtime environment,it can obtain state parameters,analyze the parameters and develop countermeasures according to established policy,and achieve automatic fault recovery.Experimental results show that the system can detect and recover cloud platforms’fault with agentless method,enhance the security of cloud environments,and improve the high availability of cloud platforms.

OpenStack cloud platform;load balancing;event-driven mechanism;high availability;virtualization; cloud computing

崔競松,路昊宇,郭 遲,等.基于事件驅(qū)動機制的虛擬化故障檢測恢復(fù)系統(tǒng)[J].計算機工程, 2015,41(2):7-11,16.

英文引用格式:Cui Jingsong,Lu Haoyu,Guo Chi,et al.Virtualization Fault Detection Recovery System Based on Eventdriven Mechanism[J].Computer Engineering,2015,41(2):7-11,16.

1000-3428(2015)02-0007-05

:A

:TP302.1

10.3969/j.issn.1000-3428.2015.02.002

國家“863”計劃基金資助項目(2013AA12A206);國家自然科學(xué)基金資助項目(41104010,91120002,61170026);中央高?；究蒲袠I(yè)務(wù)費專項基金資助項目(2042014kf0237)。

崔競松(1975-),男,副教授、博士,主研方向:信息安全,云安全;路昊宇,碩士研究生;郭 遲(通訊作者),講師、博士;何 松,碩士研究生。

2014-03-21

:2014-05-09E-mail:guochi@whu.edu.cn