基于事件驱动机制的虚拟化故障检测恢复系统

崔竞松,路昊宇,郭 迟,何 松

(1.武汉大学a.计算机学院;b.空天信息安全与可信计算教育部重点实验室,武汉430072; 2.武汉大学卫星导航定位技术研究中心,武汉430079)

基于事件驱动机制的虚拟化故障检测恢复系统

崔竞松1a,1b,路昊宇1a,郭 迟2,何 松1a

(1.武汉大学a.计算机学院;b.空天信息安全与可信计算教育部重点实验室,武汉430072; 2.武汉大学卫星导航定位技术研究中心,武汉430079)

为解决虚拟化条件下云平台故障排除不及时的问题,在开源云平台OpenStack上设计并实现一种虚拟化故障检测恢复系统。该系统由GUI层、调度层、逻辑层和功能层组成,以事件驱动机制为核心,将系统中传递的信息作为事件按时序进行处理。以感知模块、策略模块、执行模块为主体,调用OpenStack API和Libvirt API实现与虚拟机管理层的交互。建立以信息获取、分析处理、故障恢复为主要内容的故障检测恢复体系,通过对云平台运行环境的实时检测,获取状态参数,根据策略对参数进行分析判断并制定应对措施,实现对故障的自动恢复。实验结果证明,该系统可以在无代理情况下对云平台进行实时检测和故障自动恢复,增强云环境的安全性,提升云平台的高可用性。

OpenStack云平台;负载均衡;事件驱动机制;高可用性;虚拟化;云计算

1 概述

云计算将大量的计算资源、存储资源与软件资源链接在一起,形成巨大规模的共享虚拟IT资源池[1],综合分布式计算、虚拟化技术、负载均衡技术、网络存储技术等传统计算机技术[2],屏蔽了底层的差异,把不同的、独立的计算机资源抽象成统一的、共享的资源统一向外界提供服务[3]。在云计算环境下,IT领域按需服务的理念得到了真正体现,云计算通过整合分布式资源,构建应对多种服务要求的计算环境,满足用户定制化要求,并可通过网络访问相应的服务资源[4]。

云平台资源的高度集中化使得其高可用性变得非常重要,任何系统维护与宕机都可能引起较大规模的服务缺失[5]。对于一个计算中心而言,提供一种高可用性的能力服务于所有在其上运行的应用是要考虑的关键问题之一[6]。现有的云平台都提供了一定的技术保证了云的高可用性,比如VMware vSphere[7]能够检测虚拟机所在物理主机运行情况,但是对运行中的虚拟机及应用程序方面的监测较少,一旦发生故障将不能得到及时处理,导致服务中断。本文在OpenStack基础上设计并实现一种基于事件驱动机制的虚拟化故障检测恢复系统,从物理机、虚拟机、虚拟机应用3个层次对云平台环境进行监控,实时获取运行参数,实现对故障的无代理检测恢复。

2 系统设计

OpenStack[8]是美国国家航空航天局和Rackspace公司共同开发的开源云计算平台,旨在为公共及私有云的建设与管理提供各种组件。系统在OpenStack基础上,通过API调用整合形成GUI层、Scheduler[9]调度层、逻辑层和功能层,并按逻辑将功能层和逻辑层划分为感知模块、策略模块和执行模块三大核心模块,采用事件驱动机制将各部分有机结合起来,通过对事件的处理实现系统对故障的检测和恢复功能。系统架构如图1所示。

图1 系统架构

(1)功能层:通过对Libvirt API[10]和OpenStack API的封装调用,实现OpenStack和Libvirt进行交互,连接系统和虚拟机管理层,同时功能层作为整个系统的最底层为其它各层的函数调用及相关功能提供支持。

(2)逻辑层:采用事件驱动机制,将系统中传递的信息规范为事件由相应的对象进行处理。事件主要分为感知事件、策略事件和执行事件。

(3)调度层:负责对事件队列进行操作,作为系统运行的枢纽进行调度,保证事件有条不紊地被执行,对事件队列满、事件队列空等各种异常进行处理。

(4)GUI层:用来与用户进行交互,用户可以通过该界面,获得系统的运行参数,主要包括虚拟机的运行状态、虚拟机的资源占用等情况。同时,用户可以通过界面控制虚拟机的运行状况(比如停止某台虚拟机),对系统的部分基本配置(比如打捞时间的设置等)进行更改。

(5)核心模块:三大模块均由对应的Handler和Function组成。感知模块负责感知整个系统的运行情况;策略模块根据感知的结果进行处理;执行模块负责执行策略模块制定的恢复策略,共同构成系统的检测恢复核心。

3 事件驱动机制

为了实现不同层面、不同模块、不同进程(线程)之间通信和信息处理,系统采用事件驱动的方式,将感知到的信息、制定的策略等系统中传递的信息作为事件,由事件处理进程进行处理,平时事件处理进程处于等待状态,由接收到的任何一个事件进行驱动[11]。事件驱动主要设计3个类:Event事件类, Handler逻辑类,Scheduler调度类。在事件驱动机制中,Event是派生所有事件的基类,用来标识系统中各种行为,比如启动虚拟机;Handler是派生所有事件处理对象的基类,用来处理相应Event事件类; Scheduler调度类负责调度事件,事件队列Queue定义在Scheduler类中,Scheduler对事件队列进行维护,用来保证事件被有序处理。事件驱动机制总体设计如图2所示。

图2 事件驱动机制总体设计

事件驱动的过程主要分3个步骤:首先是将事件放入全局的事件队列Queue中,然后按时间顺序从事件队列中取出事件,再通过指定的事件处理对象(即Handler)处理事件,在处理过程中可能会往事件队列中加入新的事件。这样不断取出事件并处理一直到事件队列为空,就实现了一次感知过程。

Scheduler主要负责事件的调度,采用基于事件[12]的周期轮询机制,按时序对系统中的事件进行统一的调度和处理。事件队列是由优先级和时间决定的有序队列,按照优先级由高到低的顺序执行,在优先级相同的情况下按照事件执行时间先后排序执行,确保队首永远是第一个要执行的事件。Scheduler采取每执行一个事件就在后台启动一个线程的方式防止事件等待加快并行,将队列设置成静态变量防止多线程队列,实现对队列的高度维护。由于事件的插入和取出并执行相互独立,可能会发生队列中第一个事件还没到执行时间,Scheduler正在休眠,实然插入一个需要立即执行的新事件需要唤醒队列,为此引入锁机制。Scheduler休眠需满足2个条件:(1)执行时间不小于现在系统的时间;(2)锁必须是关闭的。当Scheduler休眠时,新到达的事件执行时间小于现在系统时间,系统就会打开锁,从而破坏Scheduler休眠的必要条件,唤醒Scheduler。

4 关键技术

系统的主体是由功能层和逻辑层共同组成的感知模块、策略模块和执行模块,在此基础上通过事件驱动机制进行调度,实现对故障的自动检测和恢复功能,具体工作流程如图3所示。

图3 系统工作流程

通过感知模块获取系统运行信息,由策略模块对感知的信息进行分析并区别制定策略,执行模块根据策略进行故障恢复、提示系统管理员或者在系统运行正常的情况下无动作。从而在云平台中某台物理服务器发生故障时,能够自动检测故障并选择合适的物理机重建运行在该物理机上所有虚拟机;当物理机上某台虚拟机发生故障时,能够删除故障虚拟机,根据其快照或镜像快速进行重建;当虚拟机中的某个应用进程发生故障时(进程非正常退出、非正常挂起),在无代理的情况下,直接操作GuestOS内核对象,恢复启动虚拟机里的进程。

4.1 感知模块

感知模块由感知Function和Handler组成,其中,Function主要封装Libvirt API获取信息实现底层功能,完成对上层Handler的支持。感知模块Function类结构如图4所示。

图4 感知模块Function类

感知模块通过感知Function类中的F_Host、F_ VM、F_APP 3个子类分别获取物理机、虚拟机、虚拟机应用的信息,由相应的Handler类进行处理,生成对应的感知事件进入策略模块进行处理。其中,物理机主要考察主机状态、内存、CPU、网络、磁盘等信息,虚拟机主要考察全局(指定)虚拟机状态、网络、磁盘、内存等信息,虚拟机应用主要考察进程状态、进程数、内存等信息。以物理机状态获取为例,Function类获取信息流程为:(1)确定获得物理主机状态的类F_hostStatus;(2)通过与主机建立Libvirt连接调用函数getConnect()获得与物理机的连接conn;(3)对conn进行判断,若conn为fals则相应的物理机状态为0(0表示物理机断电),若conn为ture,则相应物理机状态为1(1表示物理机正常)。

4.2 策略模块

策略模块对感知模块传送来的感知事件进行分析,根据策略机制来判断平台出现何种故障,并生成相应的策略事件。策略机制是整个模块的核心,不同的事件对应不同的策略机制。以恢复虚拟机的机制为例,共有3张表需要维护,第1张表Instance_ Info,信息主要来自nova的数据库并由nova进行维护,保存虚拟机的基本信息。它是一个字典的结构,每一项也是一个字典,格式为{虚拟机的序列号: {‘id’:’ ’,’isActive’:’ ’}。第2张表VM_ State,主要由Libvirt维护,它的信息主要是感知模块感知到的信息,它也是一个字典结构,每一项为{虚拟机的id:虚拟机的状态}。第3张表Execution_ State,记录一个虚拟机正在进行恢复的操作,其信息主要是根据Instance_Info表和VM_State表,信息的修改主要由执行Handler来执行。恢复虚拟机的逻辑机制如表1所示。

表1 虚拟机恢复的逻辑机制

4.3 执行模块

执行模块主要是对策略模块分析制定的策略响应并采取相应措施,对故障进行恢复。执行模块Function类图如图5所示。

图5 执行模块Function类图

F_ExeHost主要处理物理主机异常,可以对物理机进行关闭、重启、配置网络、杀死进程、向管理员发送异常报告的操作;F_ExeVM主要处理虚拟机出现异常,可以重新开启一台虚拟机,对运行的虚拟机进行关闭、销毁、配置网络、向管理员发送异常报告的操作;F_EAPP主要处理虚拟应用出现异常,包括杀死进程、重启应用程序、向管理员发送异常报告等。执行Handler类的核心是OpenStack API的调用。Handler类通过调用OpenStack平台提供的对外接口,用类与OpenStack进行交互,利用OpenStack的现有功能完成操作。

4.4 负载平衡

为了在创建和恢复虚拟机时实现负载均衡、提高资源利用率,由Nova-Scheduler[13]分析并选择性能最佳的物理主机创建并启动虚拟机,共分3个步骤:

(1)主机过滤:在获取到集群中所有物理主机列表的情况下,根据特定的属性过滤掉不满足条件的主机,生成新的主机列表。过滤器可以使用OpenStack提供的默认过滤器,也可以根据需要进行设置,创建特定的过滤器。

(2)权值计算:将过滤后的主机列表进行性能评估。在此采取权值算法,给主机的每个特性设定权重值,将内存大小、磁盘容量、网络流量等特性值分别相应的权重相乘,把得到的数值加起来就得到主机的综合权值。

(3)主机选择:根据每台主机的综合权值对列表内的主机进行排序,从而选择合适的主机进行虚拟机的创建与重启。根据虚拟机的不同特性要求,也可以选择主机的部分特性进行权值计算后进行排序。

5 实验结果与分析

5.1 实验环境

实验平台由5台主机组成,其中主控节点1台,主要配置nova,glance,keystone,horizon,mysql服务,向计算节点发送命令;共享存储1台,主要配置oracle服务,具有数据库、共享存储功能;计算节点3台(分别为B1,B2,B3),主要配置有novacompute,nova-network服务,运行虚拟机提供虚拟应用。计算节点3台主机运行的虚拟机分别为VM1, VM2,VM3,操作系统依次为Windows Xp Sp3, Ubuntu12.04 LTS和Windows 7 Sp2。实验环境配置如表2所示。

表2 实验环境配置

5.2 实验测试

实验测试过程如下:

(1)物理主机故障:在物理主机B1上正在运行有虚拟机VM1,因为B1突然断电不能正常工作, B2,B3均正常工作,系统检测到后重建了虚拟机VM1,并向管理员发送异常报告。在其他条件不定的情况下改变B2、B3的硬盘大小,虚拟机在2台物理主机上重建的概率分布如图6所示。

图6 物理主机选择分布

(2)虚拟机故障:在计算节点的物理主机B1, B2,B3上分别运行有虚拟机VM1,VM2,VM3,对以下2种情形测试:1)在终端利用Libvirt命令删除虚拟机导致虚拟机崩溃,系统检测到异常后在物理主机上重建了虚拟机,重建的虚拟机与崩溃的虚拟机一样并保存了原虚拟机的永存数据;2)在虚拟机上打开多个任务窗口导致虚拟机宕机,系统检测到异常后对虚拟机进行了重启。虚拟机恢复时间如表3所示。

表3 虚拟机恢复时间

(3)虚拟应用故障:在虚拟机上运行有FTP服务器、在线视频库和Web服务器为用户提供FTP下载、在线视频观看和网站访问服务,在虚拟机上通过任务管理器将应用程序进程关闭,系统检测到进程异常后进行恢复,继续为用户提供服务。虚拟应用恢复时间如表4所示。

表4 虚拟应用恢复时间

通过实验结果表明,本文系统能够在虚拟化条件下自动检测云平台运行状态并获取相关参数,通过对数据分析判断发现异常,根据既定策略进行故障排除,完成虚拟机及应用的重启重建,恢复中断的服务,实现对云平台故障实时无代理恢复。

6 结束语

随着云计算应用日益广泛,云服务的可靠性要求也越来越高,云平台中的物理主机崩溃、虚拟机宕机、云应用无响应等故障都会导致云服务的中断,影响用户体验。本文利用OpenStack云平台设计实现的基于事件驱动机制的虚拟化故障检测恢复系统,通过对云平台运行参数的获取和分析处理,同时充分考虑负载均衡,实现了对云平台的实时检测和故障的无代理自动恢复,有效缩短了故障时间,提升了云平台的高可用性。由于本文方法并未考虑大数量故障的情况,数量增多会对故障的检测和恢复造成不利的影响,比如耗时较多、负载过大等,因此提高大数量故障检测效率将是下一步研究的重点。

[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] 林 闯,苏文博,孟 坤,等.云计算安全:架构,机制与模型评价[J].计算机学报,2013,36(9):1765-1784.

[5] 陈海波,夏虞斌,陈 榕.高可信、高扩展与高可用云计算平台的研究与展望[J].高性能计算发展与应用, 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] 王 莉,李新明,李 艺,等.高可用性系统软件HHA的事件驱动机制[J].计算机工程与应用,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

崔竞松,路昊宇,郭 迟,等.基于事件驱动机制的虚拟化故障检测恢复系统[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);国家自然科学基金资助项目(41104010,91120002,61170026);中央高校基本科研业务费专项基金资助项目(2042014kf0237)。

崔竞松(1975-),男,副教授、博士,主研方向:信息安全,云安全;路昊宇,硕士研究生;郭 迟(通讯作者),讲师、博士;何 松,硕士研究生。

2014-03-21

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