基于分层模型的服务故障管理系统

时间:2022-10-16 10:06:21

基于分层模型的服务故障管理系统

【摘要】在基于服务的体系结构(SOA)中,可以根据服务间的依赖关系对网络服务进行分层,在分层模型的基础上建立了服务故障管理系统。系统主要由三部分组成:服务监测系统、故障诊断系统和故障影响分析系统。最后,以实际运行的网络服务为实例,对系统进行测试,结果表明该系统能及时发现故障,准确定位故障源,并对故障进行影响分析。

【关键词】分层模型 网络服务 故障定位 故障管理

在SOA架构下,服务具有黑盒特性,用户根据需要动态的查找和绑定服务。这种黑盒特性和动态组合特性能方便的开发出新的组合服务,但对服务的可用性和可靠性提出了更高的要求。因此,新型基于服务的软系统必须建立有效服务管理机制,特别是服务故障管理机制,才能确保服务的有效性和可用性。

目前,网络服务故障管理系统主要面临以下几个问题:一是服务发生故障时,服务症状难以获取。往往是造成较大损失时,我们才认识到故障产生的症状,从而错过了及时修复故障,减小损失的时机;二是故障定位不准确,获取症状后很难准备定位故障,因此浪费了大量的人力物力进行复查,最终确定故障源需要多次的尝试;三是故障影响分析不到位,当一个故障发生并报告时,我们很难直观的判断该故障会造成多大损失,例如一个小的功能服务看起来是无关紧要的,然而当许多重要的服务需要改服务的支持,则该服务的故障可能造成巨大影响;四是故障发生时责任不明确,故障的发生可能是服务本身出现问题,如绑定错误,参数错误等,但也可能是网络设备出现故障,故障发生后,基础设备供应商和服务提供商责任不明,可能互相推诿责任。

为解决上述问题,本系统将被管对象向下延伸,把服务器,路由器等网络设备作为被管对象并根据服务分层模型建立了服务故障管理系统,根据分层模型的特性可以以较小看开销快速获取症状,准确定位故障并进行故障影响分析。

一、相关工作

目前,SOA架构下的服务故障管理主要有以下几个框架:问责制框架、基于连接件的服务自愈框架、自律式管理框架、基于主动探测的故障管理框架。

问责制框架包括责任和责任监管,负责收集每个运行服务的状态,当监测到某个服务出现症状时,将症状信息发送给服务监管,服务监管负责故障诊断、故障影响分析和故障修复。然而问责制的困难在于不能准确确定服务的规模,部署过多时,服务故障诊断的准确率较高,然而增大了监管的开销;服务部署过少时,会明显影响服务故障诊断的精度。

基于连接件的服务自愈框架是一种轻量级的服务自愈框架,该框架有以下优点:一是能独立于服务组合方法和组合语言;二是连接件是服务信息交换与行为执行的中转站,能够直接进行状态监控;三是能够透明的实现服务故障自愈。缺点是降低了整体服务运行的效率和性能。

IBM提出了自律计算,马会彬等根据自律计算设计了具有自律特征的网络故障管理框架[4-5]该框架下每个服务都自成一个闭合的控制环,实现了服务的自我管理。但是自律是管理框架的缺点是加大了服务开发的难度,每一次服务的开发都需要形成闭合控制环。特别是在组合服务的场景下,该实现更加复杂。

在产品方面,国内还没有比较成熟的产品和解决框架,然而国外已有多种解决面向服务架构下管理的的工具或技术方案。Amber Point的SOA Management System是基于策略的管制软件套件,该套件包括了运行时知识库、服务网络监控、SOA安全和服监控等;BMC的AppSight则关注于服务投放到市场前的性能测试来获取知识,并在投放到市场后依据该知识进行管理;Wily SOA解决方案用于监控Web服务性能和可用性,主要组建包括服务发现,依赖图发现等;HP的SOA Manager则定义和维护一个动态的服务模型,在SOA模型中管理应用程序和Web性能;IBM的IBM Tivoli Composite Application Manager(ITCAM) for SOA主要用于监控和管理Web 服务层,并定位系统的缺陷和瓶颈。

二、总体结构设计

(一)服务分层模型

在服务分层时,我们把网络设备也作为被管对象考虑进去。服务和网络设备所在的层次仅与其关联关系有关,而与其是否为服务或设备无关。服务分层模型的结构如图1所示,在分层模型中,服务的依赖为高层依赖低层,故障发生时,故障从低层向高层根据依赖关系开始传播症状。

(二)故障管理系统框架

故障管理系统框架如图2所示,在故障管理系统中,症状的获取主要有三种途径,一是又系统自身的探针获取,探针的设计和部署将在关键技术分析中详细阐明;二是通过性能管理系统获取,在系能管理系统中,如果出现了较大规模的性能不满足要求,或者是某些性能出现严重违背,则可以考虑该违背是由某些故障引起的;三是通过网络管理中心获取,网络管理中心可以实时监测网络设备的状态。

症状获取后,将症状加入症状数据库,并根据数据库中的历史故障数据和故障分层模型进行故障诊断,故障诊断的主要功能是进行故障定位,即定位故障的故障源头。

确定故障源头后,要进行故障处置并将该次故障管理过程进行可视化。故障处置主要包括故障影响评估、故障处理和可视化。因为管理权限问题,故障处理的手段分为以下2种:一是自身具备处理权限,如网络服务,则该系统直接进行处置;二是不具备管理权限,如网络设备出现故障,则将故障诊断结果通报给网络管理系统,由网管系统进行处置。

(三)功能模块划分和定义

故障管理系统分为三大模块:症状监测模块、故障诊断模块和故障处置模块。其中症状监测模块包括主动监测模块和被动监测模块。主动监测模块主要是平时对服务进行测试,发生故障时获取相关症状;被动监测模块主要负责用户反馈症状的获取。故障诊断模块分为拓扑图生辰模块和故障定位模块,拓扑图生成模块主要是以一个特定的周期生成服务的拓扑图(依赖图);故障定位模块主要是在收集症状的基础上,对故障实施定位。故障处置模块分故障影响评估子模块和故障处理子模块。故障影响评估子模块是在故障定位后,对故障影响进行分析和分级,并在监控端实行可视化;故障处理模块是根据故障影响,采取特定的处理手段。

(四)数据库定义

本系统的知识库有两部分组成:一是故障的贝叶斯模型;二是故障的历史统计数据。前者的数据时根据服务组合时初始化并根据后者信息综合得到,二后者为统计信息。两种信息库以如下所示:

表1和表2信息略有不同,因为我们无法准确知道一件事情发生的准确概率,因此在系统初始化时给出的表1可能是不准确的,需要不断的根据表二去修正。可以猜测,经过无数次学习后,表1将无限接近于表2。

三、关键技术分析

(一)症状获取技术

在第二部分我们讨论了症状获取的三种主要途径,下面就探针获取症状着重讨论

服务分层后,我们仅对跟节点进行周期性探测。探测的主要工具是探针。

探针可以分为计划(preplanned)探针和实时(Active)探针。计划探针包括线下探针集的选择,探针站周期性的这些探针并收集结果,根据结果得到症状;实时探针是根据已观测到的服务症状等调整探针策略,可以探查到更精确更全面的信息,为故障定位做准备。

周期性探针主要探测服务的可用性,定期查询服务是否可用,如果服务可用,则返回一个正症状;返回负症状或者无返回均需向症状数据库中添加症状。

实时探针有三种:一是探测与服务相关的资源探针,主要用于探测网络状态和服务器资源等;该种探针可通过SNMP协议实现。二是探测服务的可用性信息,与周期性探针相同;三是探测服务的语义信息,即对服务进行完整的测试,不仅测试服务的性能、可用性,而且对服务返回结果的正确性和格式进行测试。

(二)故障定位技术

在周期性探针获取症状后,需要分析症状,如果发现有负症状,则进入故障定位制。故障定位是指找出最大概率的故障集,使得故障集的故障传播导致的症状能覆盖周期性探针的探针集。分析后,在用实时探针确认故障源,如果不能确认,则将实时探针的探测结果加入症状集,重新进行故障定位。

贝叶斯网络的推理是NP难问题,为减少推理复杂度,我们用贪婪算来进行推理。主要思想是在每次循环中,选取拥有最大权值的节点s加入假设,并删除其对应的症状。当负症状集为空时,算法停止

(三)故障影响分析技术

传统的故障影响分析主要是在故障定位后,根据服务的拓扑图计算该故障的影响,其难点是服务本身很难知道被谁调用,因此难以计算。我们的思路是为每一个节点确定其影响力,在故障定位后直接给出影响,而不用重新计算。我们在生成分层结构和动态更新分层结构时,可以根据动态变化实时更新知识库。

在评测一个服务故障引起的影响时,我们参考了google的PageRank(PR)算法,即网站的重要程度与与其关联的网站数成正比,与关联其的网站的重要性成正比。服务重要程度(SID)的评判与PR稍有不同,一是网站的损害不会导致引用其的网站变得不可用,而每一个服务对于引用其的上层服务都是重要的,考虑如果一个服务引用多个服务,被其引用的服务的SID受引用个数的影响应该较小;二是服务的引用存在因果关系系数,应该考虑进去;三是如果上层服务能引用的相同功能的子服务较多,那么下层被引用服务的增加度会降低;四是根据服务属不同,其具有初始的重要程度;

理论上,我们是无法区分出一个服务是被其他服务调用还是被用户直接调用,但是调用其的服务会对其SID的权值产生影响。仅凭调用其上层服务进行SID计算是不公平。有的服务可能直接面向用户更多,因此也要考虑由最终用户直接引用施加的影响。

上面各项数据的意思为在一特定的测量时间段内,该服务的总的调用数是n,由用户直接完成的调用数是m,x是由其固有属性决定的重要程度影响因子,d是阻尼系数;SID(i)表示调用该服务的第i个上层服务点SID值;r是该调用的关联因子;S是与该服务具有相同功能的服务家族中服务的个数,C(i)是调用该服务的上层服务i的子服务的个数。

四、系统实例演示

系统运行实例如图4所示,在图四中,监控的服务为CombineService2,该服务依赖于2个子服务和一台服务器,我们可以看出,因为其中一个子服务发生故障,CombineService2出现了症状。

我们采用认为制造故障的方法来验证故障定位的准确率和误判率,在具有100个节点的服务网络中,我们认为的造成0-5个故障,让故障自然传播并用该系统捕捉症状并定位,与实际制造的故障相对比,结果如图5和图6所示。其中两条不同的曲线代表了系统中2中不同的定位方法,分别直接关联的故障定位算法和间接关联的故障定位算法。

五、 总结

组合服务的黑盒特性和动态组合特性给服务故障管理带来了新挑战。本文介绍了分层结构下网络服务故障管理系统的设计与实现。系统能及时监测出现的网络故障或服务故障,并进行故障影响分析以便于后续采取适当的处理结果。

本系统的监管对象为部分网络设备和SOA架构下的网络服务,在下一步工作中,将继续扩大被管对象的范围,将服务管理与网络管理、数据中心的管理等相结合,使系统能将故障源定位更准确,故障的分析更到位。同时,系统还考虑引入故障处理机制,使得故障发生时,系统能采取适当措施进行服务替换或故障修复。

参考文献:

[1]白伟华. 基于 SOA 的多 Agent 协商服务及其应用[J]. 计算机工程, 2007, (23).

[2]吴迪, 张国清. 一种基于移动的网络服务关联模型构建方法[J]. 计算机工程, 2003, (12).

[3]任洪敏, 刘晋. 基于连接件的 Web 服务自愈框架研究[J]. 计算机应用研究, 2012, (8).

[4]Du Wan CHEUN,Hyun Jung La, Soo Dong KIM. A taxonomic framework for autonomous service management in Service_Oriented Architercture. Journal of Zhejiang University-Science C(Computer&Electronics),2012,(5).

[5]马会彬, 赵晓南, 李战怀. 具有自律特征的网络故障管理框架[J]. 微电子学与计算机, 2006, (8).

[6]Bieberstein, Norbert, ed. Service-oriented architecture (SOA) compass: business value, planning, and enterprise roadmap. FT Press, 2006.

[7]Natu M, Sethi A S. Active probing approach for fault localization in computer networks[C]//End-to-End Monitoring Techniques and Services, 2006 4th IEEE/IFIP Workshop on. IEEE, 2006.

[8]褚灵伟, 邹仕洪, 程时端,等.概率和噪声环境下基于主动探针的 Internet 服务故障管理[J]. 中国科学: E 辑, 2008, (10).

上一篇:浅谈如何转化后进学生 下一篇:我国货币政策传导机制的分析