面向虚拟化系统的故障注入工具设计与实现
2018-03-16艾中良
胡 慎，徐 珞，艾中良，李 宁
(华北计算技术研究所总体部，北京 100083)
0 引 言
面向虚拟化系统的故障注入技术可以给出对虚拟化系统的可靠性及容错性评价，是对虚拟化系统进行评测的重要方法[1]。
目前存在的故障注入工具如DEFINE、NFTAPE、DOCTOR和Xception等多为传统物理机故障注入工具[2]，不能直接应用到虚拟化系统上，且其缺少对虚拟化系统特有故障的测试，因此无法满足对虚拟化系统可靠性及容错性的评测。本文在分析典型虚拟化系统的体系结构及虚拟化机制的基础上，提出了一种面向虚拟化系统的故障注入工具架构，并以该架构为基础以及Xen系统实现了一种故障注入工具，完成了向虚拟化系统的核心即虚拟化管理器层(virtual machine monitor，VMM)的故障注入实验并依据实验结果对系统的可靠性和容错性进行分析，验证了工具的有效性。
1 传统故障注入技术
传统故障注入技术可分为1.1节和1.2节中介绍的两大类，此两类技术的具体定义及优缺点请参见文献[3]。
1.1 基于模拟的故障注入
常见的基于模拟的故障注入工具有CECIUM、FOCUS和MEFISTO等。该方法的优点是可以在系统设计的不同阶段进行故障的注入，不存在可访问性方面的限制。但是这种方法存在的缺点是在建模上比较复杂且比较耗时，不便于系统的便捷开发；并且需要准确的参数输入，当设计改变复杂化历史测试数据的使用时，很难获取准确的参数输入。
1.2 基于原型的故障注入
1.2.1 硬件故障注入
常见的硬件注入故障工具有Messaline、RIFLE等。其包含接触式和非接触式两类注入方法：接触式方法会直接接触目标系统；非接触式硬件故障注入不直接接触目标系统的硬件设备。随着硬件封装密度的提高，硬件故障注入的使用也越来越少。
1.2.2 软件故障注入
常见的软件故障注入工具有DEFINE、NFTAPE、DOCTOR和Xception等。根据故障注入时刻的不同，可将软件故障注入分为编译时故障注入和运行时故障注入。编译时故障注入是指在程序编译连接时进行故障注入；运行时故障注入是指在程序运行时进行故障注入。
2 故障注入工具的设计与实现
2.1 工具总体架构设计
与传统物理机相比，虚拟化系统有一个重要的部分，即虚拟机管理器层，因此虚拟化系统的故障模型和注入方法都有其特殊性[4]。例如在虚拟化系统中可以对虚拟机管理器层的页表进行修改从而实现虚拟机内存故障的注入。显然这是虚拟化系统特有的方法，物理机不能使用这种方法；与之相对，很多物理机故障的注入方法也不适用于虚拟化系统。本文提出了一种面向虚拟化系统的故障注入工具架构，并在openstack云平台上创建Xen虚拟机实现了原型系统工具。工具针对虚拟化系统的体系结构特点，实现向虚拟机管理器层的故障注入，完成对虚拟化系统的可靠性和容错性的分析。其总体架构设计如图1所示，它由以下几部分组成：
(1)Xen虚拟机管理器，在虚拟化系统中，它负责所有虚拟化功能的实现，可以直接干涉虚拟机节点(virtual machine，VM)的CPU、内存、硬盘等一切资源的使用。针对该层的特点，本文设计特定的故障类型，实现对其相关管理机制的故障注入。
(2)Xen虚拟机节点，当虚拟器管理器被注入故障时，由于其功能是对虚拟机节点进行管理，所以故障反应是通过其下的虚拟机节点表现出来的[5]，如系统崩溃、迁移失效等。
(3)前端，负责实现与测试者的交互，完成故障注入信息的传入和故障注入结果收集。
图1 故障注入工具总体架构
2.2 故障建模方法
进行一次故障注入实验的过程如图2所示，因此建立故障模型是故障注入实验的基础。故障模型主要包括故障类型、发生位置和发生模型等信息。针对虚拟机体系结构和虚拟化策略，结合物理计算机系统中的故障类型[6]，本文将虚拟机管理层的故障划分为内存管理、硬件资源分配、状态查询、虚拟机迁移、访问控制、事件通道6类。
图2 故障注入实验过程
在实现虚拟化系统的故障注入时，为使故障注入能够更贴近实际使用中的故障情况，除要设计故障类型、位置等静态特征外，还需考虑故障的动态特征，即在虚拟化系统中各类型故障的发生次序及相互间的触发关系等[7]。在实验过程中，为建立故障发生模型，可以依据故障发生记录来获取各类故障发生的特点并建立相应的概率模型；另外，为降低建立模型的复杂度，缩短故障注入的周期，也可以基于人工经验直接建立满足测试要求的模型，例如各类故障可以是依某种分布概率分布的，也可以是随机分布的。
为实现对故障准确而简明的描述，本文使用xml编写测试脚本定义各类型故障及故障发生模型，建立起系统的故障注入模型，使得前端交互部分与注入工具得以解耦，并支持各类型故障的自动化注入。图3为一个xml测试脚本文件示例，其以
图3 测试脚本文件
2.3 故障实现
通过对Xen系列虚拟化系统的体系结构和虚拟化策略的研究分析，可知Xen系列虚拟化管理功能，包括内存管理、虚拟机迁移等，都需要通过其超级调用hypercall来进行，因此可通过对各超级调用注入故障实现对对应管理功能的故障注入。
2.3.1 Xen超级调用
目前Xen系列虚拟化系统共有通用的超级调用37个，还有一些为具体机器环境特有的。为了唯一标识每个超级调用，Xen系统为每个超级调用定义了一个唯一的编号，即为超级调用号[8]，见表1；为记录各个超级调用函数的入口地址，Xen系统定义超级调用表，可以通过超级调用号在其中定位到对应函数的入口地址。
表1 Xen系统超级调用号
表1(续)
2.3.2 故障类型与超级调用对应关系
本文要实现的6种类型的故障注入均可通过超级调用实现，其与超级调用的对应关系见表2，可根据其中的超级调用号在表1中查得对应的超级调用名称。实验过程中对各超级调用注入故障即可完成对应类型的故障注入。
2.3.3 故障注入原理
在Xen系列虚拟化系统中，超级调用为一种类似系统调用的操作，其可以使处在1环的内核能够越权执行一些在0环才能进行的操作，其软中断号为0x82，处理程序为hypercall。其申请和执行过程是通过系统调用ioctl进行的，本文利用kprobe对其对用的内核处理例程sys_ioctl进行拦截并对其参数进行修改，完成对超级调用的故障注入。
在Xen系列虚拟化系统中，kprobe是linux内核中的一个轻量级动态内核调试装置，可以向正在运行的内核中插入断点。其实现了Kprobes、jprobes和kretprobes这3种类型的探针，此3类探针各有优缺点及适用的情况，对其具体分析请参见文献[9]。
依据文献[9]，由于jprobes可以获取到内核函数的参数，本文使用jprobes进行对sys_ioctl的拦截。另外，jprobes虽然可以获得内核函数的参数，但不能修改。在jprobes对sys_ioctl成功拦截后，本文使用copy_to_user()和copy_from_user()这两个函数对参数进行修改，完成故障的注入。其基本流程如图4所示，具体过程为：首先使用jprobes拦截ioctl，拦截完成后通过copy_from_user()将超级调用的参数M修改改为N，然后利用copy_to_user()将N写到用户空间中。当执行sys_ioctl()时，函数通过copy_from_user()获得超级调用参数值，而此时获得的参数N已经是修改后的错误参数值，所以故障被成功注入。
图4 故障注入原理
另外，由于sys_ioctl[10]是linux的通用系统调用接口，除超级调用外，其它很多功能也会触发其执行。因此在注入过程中需要对其本次执行是否由超级调用触发进行判定。sys_ioctl由3个参数组成：fd，IOCTL_PRIVCMD和&hcall，其分别为文件描述符、命令码和指向系统调用参数的指针。sys_ioctl在其第二个参数中定义调用的触发源，其格式定义如图5所示，其共包含32位，前两位是模式标记位，接下来14位表示数据结构位数，然后8位是类型标记位，最后8位标记编号。
图5 ioctl命令码格式
宏IOCTL_PRIVCMD_HYPERCALL表示超级调用的命令码[11]，由于不同环境下该值会发生变化，所以用X表示该值。在注入故障时，对sys_ioctl()的参数cmd进行判定，若其值为X，则进行故障注入；若不是则不进行故障注入。
2.3.4 故障注入过程
以本文提出的架构实现的故障注入工具可以进行故障的自动化注入，测试者只需编写符合条件的xml测试脚本，即可完成故障注入，图6所示即为一次故障注入的流程。其中向虚拟机管理器注入故障为本工具的核心部分，其实现过程如下：
(1)在内核函数sys_ioctl处插入jprobes探针，sys_ioctl函数在内核的入口地址由/proc/kallsyms查得；
(2)在故障函数内部判断cmd的值，若cmd值为X，则本次系统调用为超级调用申请，程序继续执行；若不是，则不是超级调用申请，程序退出。
(3)经判定为超级调用申请，使用copy_from_user()从传入的指针org处得到超级调用的参数，然后将其存到hypercall中，变量类型为privcmd_hypercall，该变量数据结构包含两个成员：op定义hypercall号，另一个为一元数组，定义hypercall的各参数；
(4)取出超级调用号hypercall.op进行判断，如果故障注入信息中的故障位置相同，那么本次超级调用是故障注入的目标，程序继续执行；如果不一致，则程序退出；
(5)确定本次超级调用是故障注入目标后，根据本次实验要注入的故障类型及故障模式将对应超级调用值进行修改，然后把修改后的值传入用户空间；
(6)读取故障注入信息中的故障停止时间，如果已达到要求，则取消jprobes的注册。
进行以上步骤后，保存在用户空间的超级调用参数是故障函数更改之后的，所以故障被成功注入。
图6 自动化故障注入流程
2.4 前端部分
在本文的提出的架构中，前端部分负责提供图形化交互接口，实现与测试人员的信息交互功能。其具体作用为：在故障注入开始时，收到测试者编写的测试脚本并对其进行解析，然后将解析出的故障注入信息传入虚拟机管理器；故障注入完成时，收集故障虚拟机的日志信息并进行记录以反馈给测试者，从而测试者可以以日志信息中提供的实验环境、故障类型、系统各部分故障反应等信息为依据，对本次故障注入实验进行结果分析。
3 实验结果分析
为了验证本文设计工具的故障注入效果，本文基于openstack云平台搭建Xen虚拟化系统进行实验。依据所提出的故障模型，本文初步实现了虚拟机管理器层6类故障的注入。这些故障能够在一定程度上反映Xen系统发生故障时的行为反应。据实验结果，Xen虚拟化系统对各类型故障的反应行为分别为：
(1)内存管理故障，在该类型故障的实验中，需将其分为多种故障模式进行，各种模式下的故障在实验中的注入次数及对系统和其它各节点的影响是不同的。其中，页表挂载和卸载故障的后果最为严重，通常会导致系统的崩溃，不过其故障反应不会由故障节点扩展到其它节点；页表更新故障虽整体后果没有上种类型严重，但其结果较为复杂，因为在Xen系统包含有高级页表和低级页表，需分别对此两类页表进行故障注入实验，结果表明在注入次数较少的情况下(如每次实验注入次数小于10次)，系统大概率可以对其容错而不会有异常反应，但是当每次实验注入故障次数增多时，系统无法继续对该类故障保持容错性，出现系统崩溃现象，同时在对两类页表实验的对比中得出，系统对高级页表的容错性更低，更容易导致系统的崩溃，且恢复难度更大。实验过程中，存在页表挂载故障时，有时会出现异常而有时则不会，其结果是由特定因素决定的，若将操作码置为一些特定值如1时就会发生异常，而其它情况则不会；低级页表的更新故障在大多数情况下不会使系统发生错误，但实验中将低级页表项的机器地址置为一些高级页表项的值时就会引发系统错误。
(2)硬件资源分配故障，其可分为Xen系统中各节点虚拟的CPU个数、内存大小等故障模式，通过对其分别进行实验发现各模式故障的后果一致性较强且系统对该类故障的容错性较高，只有在故障存在的情况下新建节点时会造成异常，且该异常不会使系统出现严重后果。
(3)状态查询故障，该类型故障比较简单，包括虚拟机管理器的版本信息及环境信息等，对系统注入该类型故障时没有出现运行上的异常情况，只是在执行状态查询时会出现结果的不符情况，并且实验中只需重新启动虚拟机管理器，该类故障就可完全修复。
(4)虚拟机迁移的故障，此类故障包括对故障节点和非故障节点进行迁移，如果只执行非故障节点的迁移而不对故障节点执行迁移，则系统无异常，即系统对该类型故障有较好隔离性，将其隔离在故障节点中而没有使之扩散；但对故障节点执行迁移操作时，系统没有体现出进一步的容错能力和隔离性，故障发生了扩散导致系统出现崩溃，即故障没有被隔离。实验中将虚拟机迁移故障注入到目标节点中，同时正常运行同一虚拟机管理器下的另外两个节点进行对比，现象为故障节点开始时可以正常运行，但进行虚拟机的迁移时会发生异常，并导致虚拟化系统出现崩溃。
(5)访问控制故障，包括节点间访问权限和各节点对硬件资源访问权限等故障模式，实验中注入该类型故障时没有导致系统运行出现故障，只是会出现节点之间和各节点对资源访问的权限发生错误的情况。所以该类型故障造成后果较为轻微且容易修复，及系统对该类型故障有较好容错性。
(6)事件通道故障，注入该类型故障时，系统运行没有出现异常，但如果在该故障存在时对节点进行迁移操作，就会发现该操作会发生错误不能正常进行，不过此时发生的错误不会造成更加严重的后果，且如果及时重启虚拟机管理器可以修复这些错误使功能正常执行。例如实验中存在事件通道故障时进行虚拟机迁移时，由于do_evtch_op负责处理事件通道，系统会报错并提示该函数内部发生了错误，即导致虚拟机迁移发生了失败。
根据以上实验结果分析可得，Xen虚拟化系统可以对超级调用故障做出容错反应，但只限于故障次数较少的情况。总体而言后果较为严重，有很大几率会导致虚拟化系统的管理功能故障，进而造成系统的崩溃，所以Xen系统对于虚拟机管理层的故障容错能力较低。
4 结束语
本文设计了一种面向虚拟化系统的故障注入工具架构，并依据该架构以Xen虚拟化系统为基础实现了原型系统工具，完成了对虚拟化管理层的自动化故障注入实验，对工具的有效性进行了验证。通过本工具，测试者可以使用xml语言编写故障注入脚本，实现测试环境的自动化部署和各类故障的自动化注入。实验结果表明，本工具可以有效实现虚拟化系统管理层各类故障的注入，并可以对故障结果进行收集以支撑对系统的可靠性和容错性评测。
[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实现的处理器类故障模拟与注入方法研究[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].现代计算机,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].哈尔滨:哈尔滨工业大学,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虚拟机的内存资源实施监控与按需调整[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).[倪珍.基于云计算架构的虚拟机池管理系统[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).[麻彦东.面向虚拟化系统的故障注入平台的研究与设计[D].哈尔滨:哈尔滨工业大学,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.
