中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2014）30-7029-03
随着云计算平台的不断发展，以OpenStack为代表的云平台管理软件逐渐受到人们的关注。这类软件的交互对象涉及计算机中多个层次的程序，软件本身较为复杂。并且在企业级的运用过程中通常会具有较大的规模。因此云计算系统在运行时极其容易发生硬件和软件故障。在线故障检测技术可以帮助云计算平台获得系统级的可靠性保障。为了发现故障，需要对云平台进行监控，收集系统运行期间的各项特征。
系统运行时的特征来源，从已有的工作来看，可以大致分为三类。一是宿主机状态相关的特征，包括CPU使用情况、IO使用情况等；二是与代码相关的特征，包括程序特征、函数调用序列等；第三种是与数据相关，包括函数调用中的参数、寄存器与内存某位置上的值等[1]。
本文分析了面向消息的中间件中的通信消息与发出/接收这些通信消息的系统的故障行为之间的关系。从静态的代码角度，分析了故障的发生到传播至通信消息的机理；对AMQP协议构建的消息建立了模型，提出了一个简单的故障检测方式。通过故障注入实验得出了在OpenStack云计算平台上，能够通过通信消息得到反映的故障行为的比例。表明了使用通信消息作为故障检测的信息来源的可行性与有效性。
1 OpenStack故障传播分析
1.1 OpenStack故障捕捉方式
云计算管理软件是典型的分布式软件。不同的组件之间需要通过网络进行通信。常见的通信方式基于RPC实现。出于解耦等因素的考虑，RPC的实现又会依赖于中间件。OpenStack主要采用了两种通信机制。一种是在组件内部使用的AMQP通信协议。另一种是遵循REST风格的通信构架，主要用来与用户通信交互。前者是本文关注的对象。
OpenStack使用了多种方式尝试捕捉OpenStack运行时发生的故障。这些方式包括了检查函数调用的返回值、捕捉Python语言中被抛出的异常、对耗时操作设置超时时间以及对异步操作进行状态轮询等。
返回值被经常用来向调用者表示被调用者的执行情况。通常对封装良好的功能的返回值进行仔细得检查，并做出适当的处理能够避免很多情况下故障的传播[2]。
尽管人们早已认同对被调用者返回的返回值进行检查是一种良好的编程习惯。已有的工作还是发现，即使在一些组织构架的很好的项目中，很多软件故障的原因与对返回值不恰当的处理有关[3]。这些故障，以及一些其他来源的故障，会或多或少对软件的内部状态产生影响，即软件的内部存在差错。一旦这些差错被异常处理机制侦测时，程序控制流会跳转到异常控制流中进行相关异常的处理。避免了故障进一步不受控制的传播[4]。
同时在调用一些外部程序时，容易发生外部调用长时间不返回，最终阻塞住了调用者的情况。在分布式系统中，面对这种类型的故障，使用超时机制是十分常见，并且有效的。尽管存在难以界定超时时间的问题，超时机制还是被广泛的运用在OpenStack之中。
超时机制能够较好的解决同步阻塞操作的无限等待问题。但是面对异步调用，会发生调用者始终不进入期望的最终状态。如在OpenStack创建虚拟机的操作中，目标虚拟机的状态迁移从虚拟机不存在到BUILD，最终创建成功进入ACTIVE状态，创建过程中出现错误导致创建失败则进入ERROR状态。但是存在一定的可能性使得被创建的虚拟机始终停留在BUILD状态。面对这种情况，分布式系统可以采用轮询策略，并采用一定的超时/重试机制来发现此类故障。
OpenStack采用上述几种机制来检测内部发生的故障。通过阅读源码，发现故障被上述机制检测出后，存在有两种策略通知有关的模块。一是直接在故障被检测出的位置中断正常执行流程，并直接通知有关模块；另外一种是将相关的标志位设置为故障状态，通常还会中断当前的执行流程，最终在一个统一的位置处通知有关模块。前者通常出现在通过捕获异常发现故障的代码中；后者在一些调用较深的位置，并且需要执行后续代码的情况下被使用。无论是哪一种机制，都会通过试图通知有关的模块。在OpenStack中最重要的nova模块中，使用AMQP消息队列实现。
2 实验方案介绍
这一章节将介绍向OpenStack云计算平台进行故障注入，以及获取RabbitMQ消息的方案。
2.1 OpenStack的故障注入方案
OpenStack云计算平台使用了Python语言实现。Python语言内建了异常机制。并且OpenStack的实现中广泛使用了异常机制来实现内部错误、故障的捕获与处理。基于先前的工作，通过一种基于异常控制流的程序错误行为分析方法，该文构建了一套OpenStack的错误行为[5]。并以OpenStack的功能为依据，对这些错误行为进行了分类。
基于上述错误行为，可以根据差错引起的异常所在的位置，以及异常类型进行故障注入。通过手工修改OpenStack的代码，可以强制当OpenStack运行至有关位置的代码时，抛出特定类型的异常。通过观察手工插入的日志信息是否被打印来确定这些外部环境与功能入口是否确实能够激活特定的错误行为。这些信息将作为后续实验的负载。
2.2 影子队列技术
根据AMQP协议的设计，消息队列是消息储存和分发的实体。而消息队列又是接收来自消息交换器根据绑定关系分发而来的消息。“影子队列”技术的核心思想就是，为每一条实体消息队列创建一个对应的影子队列，这条影子队列使用相同的绑定关系与有关的消息交换器进行绑定。从而使得影子队列能够与其对应的实体消息队列一样，获得一份相同的消息。从而实现对通过AMQP进行传输的消息进行监控。
2.3 实验流程
由于OpenStack并没有在Python语言级别特别明确的API。因此通过OpenStack的Horizon组件中的提供的功能，以及Linux下nova工具提供的功能进行经验上的总结。得出了部分常用的且具有较高故障注入价值的功能入口。并通过在代码中写入日志的手段，确保待注入故障位置能够被特定的功能入口的指令覆盖。
本文在进行各个操作前，还收集了在未执行任何操作的情况下，OpenStack组件之间的通信消息。该文将这些通信消息称之为本底消息。收集这些消息的目的是希望尽可能的帮助区分出于操作相关的通信消息以及无关的通信消息。
在进行故障注入实验前，同样也收集了在未注入故障的情况下，操作正常返回的的前后的
所有通信消息。这些通信消息将直接与故障注入实验时，收集到的通信消息作为对比。观察两者的区别。
2.4 实验环境
实验平台由3台64位x86服务器构成。运行在其中的OpenStack版本为Grizzly。其中nova-compute等组件运行于服务器compute，组件quantum运行于服务器network，其余必要的组件运行于服务器manager。RabbitMQ同样运行于manager节点。
3 实验结果分析
本文针对OpenStack的共进行了668次故障注入。按照功能入口对这些故障注入实验进行分类。实现结果出现了以下三种情况：
1） 注入故障后，相关功能无法正确完成。收集到的通信消息与正常情况下收集到的通信消息具有显著的差别。
2） 注入故障后，相关功能无法正确完成。收集到的通信消息未出现原本应当出现的RPC调用相关的通信消息。
3） 注入故障后，相关功能无法正确完成。收集到的通信消息与正常情况下收集到的通信消息没有上述两种情况中描述的任何区别。
实验中还出现了一些少数情况。在这些情况下，注入故障后，OpenStack相关的组件无法启动；或者有关的功能依然能够正常完成。前一种情况下，无法收集到有效的通信消息。而后一种情况说明故障注入后，OpenStack能够容忍注入的故障。这两种情况不在本文需要的讨论的范围之内。
几种情况下故障注入后，收集到的通信消息情况如下表1所示。
由表1的统计数据可见，有相当一部分比例的故障可以通过通信消息进行区分。可以通过较为简单的建模后，有效的进行故障检测。
4 结论
通过代码分析以及实验可以看出，在云计算平台中，通过消息队列中的通信消息能够有效的检测出其中的故障。
参考文献：
[1] Avizienis A，Laprie J C，Randell B，et al.Basic concepts and taxonomy of dependable and secure computing[J]. Dependable and Secure Computing， IEEE Transactions on，2004，1（1）： 11-33.
[2] 单锦辉，徐克俊，王戟.一种软件故障诊断过程框架[J].计算机学报， 2011， 34（2）： 372-373.
[3] Ju X， Soares L， Shin K G， et al. On fault resilience of OpenStack[C]//Proceedings of the 4th annual Symposium on Cloud Computing. ACM， 2013： 2.
[4] Min-na X I A，De-liang G，Juan X.一种面向可靠云计算的自适应故障检测方法[J].计算机应用研究，2014， 31（2）.
