CN105005509B - 一种基于运行时模型的云计算容错机制配置方法 - Google Patents
一种基于运行时模型的云计算容错机制配置方法 Download PDFInfo
- Publication number
- CN105005509B CN105005509B CN201510393804.7A CN201510393804A CN105005509B CN 105005509 B CN105005509 B CN 105005509B CN 201510393804 A CN201510393804 A CN 201510393804A CN 105005509 B CN105005509 B CN 105005509B
- Authority
- CN
- China
- Prior art keywords
- fault
- tolerant
- model
- component
- cloud platform
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Debugging And Monitoring (AREA)
- Hardware Redundancy (AREA)
Abstract
本发明公开了一种基于运行时模型的云计算容错机制配置方法。本方法为:1)构造云平台的云容错运行时模型和目标应用的构件依赖图;云平台根据该构件依赖图对该目标应用的各个构件设置容错机制;2)云平台根据步骤1)中设置的容错机制制定容错部署方案,将该容错机制部署到该云容错运行时模型中;3)利用该云容错运行时模型将容错机制代码部署至运行时系统中,并维护该云容错运行时模型与运行时云平台的双向同步。本发明通过对目标应用结构分析,选择合适的容错机制,根据容错机制以及用户需求,制定合适的容错部署方案,并在运行时模型中实现容错测试。
Description
技术领域
本发明涉及一种容错机制配置方法,针对云计算中多样化的容错需求,提出了一种基于运行时模型的容错配置方法,进行容错机制的选择和容错配置的规划,属于软件技术领域。
背景技术
云计算可以便捷地从可配置的资源池中获得计算、存储、网络等形式的资源,这些资源能够便捷地申请和释放,使资源管理和使用成本大大降低。随着云平台的普及和其规模的扩大,其可靠性所面临的问题也越来越严重。而容错技术可保证云平台发生故障时,使系统持续提供有效服务,提升系统的可靠性。容错是指系统在出现错误的情况下继续对外提供服务的能力。容错一般包括两个步骤:错误检测和恢复。错误检测的目的是及时发现系统内出现的错误,恢复的目的是将系统恢复到正确状态并防止错误再次发生,包括错误处理和故障处理两个阶段。研究表明,容错技术是防止系统失效的有效手段(Avizienis A.;Lapri J-C.,Randell B.;Landwehr C.2004.Basic Conceptsand Taxonomy ofDependable and Secure Computing. IEEETransactions on Dependable and SecureComputing.1:11-33),并已在航空航天、医疗、银行等系统实践中得到广泛应用。
容错配置是根据软件和运行环境对容错机制进行选择、部署和测试。在传统单机和局域网环境下,上层软件独占底层基础设施,软件部署时容错需求明确,软件运行时容错需求不变或基本不变,因此,可针对固定的容错需求实现容错配置。在云计算环境下,由于基础设施共享、资源规模超大、应用种类多、数量大且容错需求多样化,云计算容错配置面临开放性挑战。为保证用户部署的服务持续可用,容错配置过程中的容错机制选择和部署等步骤,均需结合应用业务逻辑来实现。而由于应用的多样性和规模化,目前云平台更多在系统层提供通用的容错机制及配置方式,无法结合应用业务逻辑实现容错配置。这种未考虑应用业务逻辑的容错配置方式,难以满足多样化应用的容错需求。例如,在容错机制选择时,考虑到可靠性与容错成本比最大化的需求,需要在应用结构分析的基础上,为各个构件选择不同的容错机制,如对关键构件选择可靠性高且容错成本高的双工机制(Zhang Y;Zheng Z;Lyu M R. 2011.BFTCloud:A byzantine fault tolerance framework forvoluntary-resource cloud computing. Cloud Computing(CLOUD),IEEE InternationalConference on.444-451.),对非关键构件选择可靠性较低且容错成本低的温备份机制(Dantas J.;et al.2012.An availability model for eucalyptus platform:Ananalysis of warm-standy replication mechanism.IEEE International Conferenceon Systems,Man,and Cybernetics.1664-1669.)。
发明内容
针对云平台中容错配置开放性问题,本发明的目的在于提供一种基于运行时模型的容错配置方法。本发明通过对目标应用结构分析,选择合适的容错机制,根据容错机制以及用户需求,制定合适的容错部署方案,并在运行时模型中实现容错测试。
本发明是通过如下技术方案实现的:
一种基于运行时模型的容错机制配置方法,其步骤为:
1)管理员构造目标应用的构件依赖图,该图描述了应用中各个构件之间的依赖关系。云平台容错配置框架对该构件依赖图进行分析,对目标应用的各个构件进行排序。进一步的,按照此排序结果和动态规划算法为各个构件推荐容错机制,实现容错效果与容错成本的最优比;
2)云平台容错配置框架构造云容错运行时模型,维护运行时模型与运行时云平台的双向同步,即运行时云平台系统状态变化会实时同步至运行时模型,反之,运行时模型的变化也会同步至系统;
3)云平台容错配置框架根据步骤一中推荐的容错机制,制定容错部署方案,并将容错机制部署到运行时模型中。利用步骤二中运行时模型与运行时云平台的同步能力,将容错机制代码部署至运行时云平台中。
4)云平台容错配置框架对运行时模型进行错误注入,并评估容错效果。
进一步的,在分析目标应用结构特征的过程中,对该目标应用的构件重要性程度进行排名,按照该排名,从容错机制库中为各个构件选择容错机制(容错库中包括双工、热备、冷备、重启、重试、优先迁移和软件恢复七种容错机制),以实现容错性价比的最优化,其中,容错效果使用软件可靠性进行度量,容错成本使用容错机制对硬件资源的消耗进行度量。
进一步的,云平台容错配置框架中的用户需求,包括可靠性(Ri)、可用性(Ai)、故障转移时间(Ti)。
进一步的,容错机制的选择过程包含两个步骤:(1)构件排名。为实现可靠性与容错成本的最优比,本文针对目标应用的结构信息,基于场景的可靠性分析算法SBRA(SherifY., Bojan C.,and Hany H.Ammar.A Scenario-Based Reliability Analysis Approachfor Component-Based Software.IEEE transactions on reliability 2004,53(4):465-480.)实现构件重要性排名,(2)针对各个构件分别推荐容错机制。本发明提出动态规划算法,以实现目标应用的容错性价比最优化,该动态规划算法中,将可靠性与容错成本比作为优化目标,将用户需求(包括可靠性、可用性、故障转移时间)作为约束。
进一步的,构件重要性排名的思路是,分别对单个构件提升其可靠性,然后利用SBRA 计算整个应用的可靠性,根据整体可靠性的提升程度对构件重要性进行排名。算法流程图如图2所示,所有构件的可靠性初始值为0.8,构件个数为N,对单个构件可靠性分别提升0.2,然后使用基于场景的可靠性分析算法SBRA,对全局可靠性Rapp-i进行计算,最终按照整体应用可靠性提升程度对构件排名。
进一步的,对单个构件进行容错机制推荐,包括两个步骤。首先,根据故障类型和故障源对容错机制进行过滤:
其中,set0是所有容错机制构成的集合,set1是经过对故障源以及故障类型进行匹配后满足该条件的容错机制集合。u1描述用户指定的故障类型,u2描述用户指定的故障源。fti和fsi分别表示第i个容错机制能够处理的故障类型集合以及故障源集合。然后,根据用户约束选择容错机制。此处的用户约束包括可靠性(Ri)、可用性(Ai)、故障转移时间(TFi)三个属性。u1,u2,u3分别表示用户在可用性,可靠性,故障转移时间方面的约束,在满足约束的前提下最优化可靠性与资源消耗比。动态规划数学公式为:
最大化目标:
约束条件:
上述公式中,m表示容错机制个数,n表示某个目标应用的构件个数。Ri j表示为第j个构件选择第i个容错机制,Ci j表示第j个构件选择第i个容错机制所消耗的资源,Ai j表示第j 个构件选择第i个容错机制后的可用性,TFi j表示第j个构件选择第i个容错机制后的故障转移时间。 的取值范围为0或1,当结果为1时表示为第j个构件选择第i个容错机制。上述公式可通过扩展,引入更多容错约束。
进一步的,云平台容错运行时模型的构造分为两个步骤:构造容错元模型以及实例化容错元模型。第一,构造云平台容错元模型。该元模型包括两个子模型,即云平台元模型以及容错机制元模型。首先,本发明对CloudStack、OpenStack和Eucalyptus三大开源云平台的管理能力进行统计,取其并集构造出通用云平台元模型。其次,本发明对目前云平台中7种常用的容错机制进行建模,包括类、属性和关联,形成容错机制元模型。最后,本发明将通用云平台元模型与容错机制元模型进行合并得到云平台容错元模型。第二,构造面向容错的云平台运行时模型,即对元模型的实例化。元模型是平台无关模型,定义了云平台管理能力以及运行时信息的结构,而运行时模型是平台相关模型,通过对各个平台管理能力的绑定实现对元模型的实例化。本文实现了两种运行时模型构造方法,即基于访问模型的构造方法(如图3)与基于模型转换的构造方法(如图4)。SM@RT(宋晖,黄罡,武义涵,等.运行时软件体系结构的建模与维护[J].软件学报,2013,24(8):1731-1745)提供了基于访问模型的运行时模型构造方法,将管理功能集中定义在访问模型中,通过代码生成工具构造维护运行时模型的引擎。此外,针对已经具有运行时模型管理能力的云平台,本文提供一种更为便捷的运行时模型实现方式,即模型转换。通过构造模型转化器,将其原有的运行时模型转化为符合本文元模型约束的运行时模型。
进一步的,云平台元模型从两个方面进行构造,1)云平台通用部署结构的角度。包含如下类:数据中心、集群、共享存储、集群存储、物理机、虚拟机、虚拟存储以及应用。2)云平台通用层次(应用层、虚拟层和物理层)和模块(计算、存储和网络)的角度。云平台元模型如图5所示。
进一步的,容错机制元模型的构造包括目标应用类和容错类。如图6,描述了三种容错机制实例运行时所需要的信息,分别是应用双工机制,虚拟机热备以及虚拟机心跳检测。
进一步的,云平台容错配置框架中的容错部署方案包括容错对象、故障类型、容错机制以及容错范围四类属性。容错对象是指云平台中可能会发生故障并需要进行容错的实体,故障类型是指对潜在故障的假设,容错机制则描述了一种针对故障源中的某种故障类型实现容错能力的策略及其参数设置,容错范围是针对云环境下容错机制的一种部署范围的描述。利用容错部署方案,管理员可实现基于运行时模型的容错机制部署。
本发明的主要内容包括:
步骤一:分析目标应用结构信息,对目标应用进行构件排名,按照排名推荐容错机制。
步骤二:构造面向容错的云平台运行时模型。建立云平台元模型以及容错机制元模型;建立维护面向容错的运行时模型与云平台之间同步的访问模型;自动化生成与该云平台同步的面向容错的云平台运行时模型。
步骤三:制定容错部署方案。
步骤四:允许用户使用QVT脚本对运行时模型注入错误,测试容错效果,计算可靠性。
步骤一中提出了一种应用构件排名算法。首先将目标应用描述为构件依赖图,描述构件信息及构件间的交互信息,其中最重要的属性是构件可靠性,但该属性在实际环境中是难以估计的,因此本文使用静态分析方法,即对所有构件分别提升其可靠性,并基于整体可靠性的提升程度对构件进行排名。
步骤二中的云平台容错运行时模型包括两个子模型,即云平台运行时模型、容错机制运行时模型,分别描述云平台运行时信息和容错机制运行时信息。云平台运行时信息的内容定义在云平台元模型中,如图5所示。包括:数据中心信息(名称,标识符,物理位置,集群个数),集群信息(名称,标识符,虚拟化方式,物理机个数),存储信息(名称、标识符、容量、使用率),主机信息(名称、标识符、内存信息、CPU信息、网络信息、操作系统、虚拟机个数),虚拟机信息(名称、标识符、内存信息、CPU信息、网络信息、操作系统),应用信息(名称、标识符、重要性、是否备份、CPU占用率、内存占用率、网络)。这些信息之间的关系为:云平台部署图包含零到多个数据中心,数据中心包含若干集群和存储,集群包含零到多个物理机,存储包含零到多个存储设备,物理机包含零到多个虚拟机,存储设备包含零到多个虚拟存储,虚拟机包含零到多个应用。容错机制运行时信息的内容定义在容错机制元模型中,如图6所示,包括:目标应用信息(名称、标识符、重要性、是否备份、 CPU占用率、内存占用率、网络),目标应用所在虚拟机信息(名称、标识符、内存信息、 CPU信息、网络信息、操作系统),容错机制运行信息(名称、标识符、配置信息、部署信息)。运行时模型最主要的特征是与运行时云平台具有双向关联,即运行时模型的变化会引起云计算平台运行时的变化(由云计算平台API中的set方法实现),反之,云计算平台运行时的变化也会引起运行时模型的变化(由API中的get方法实现)。
步骤二中建立面向容错的运行时模型,具体包含面向容错的云平台元模型的构造以及访问模型的构造。元模型中定义了面向容错的可管理元素及其组织结构,即需要管理的信息。访问模型定义了访问这些元素的具体方法,即通过调用该云平台的API实现某管理元素的读写。
步骤三中,容错机制部署方案包括四种类型的属性:容错对象、故障类型、容错机制、容错范围。(1)容错对象是指在云平台中可能会发生故障且需要进行容错的主体,例如虚拟机、应用等。本文从计算(如图7)、存储(如图8)、网络(如图9)三个模块分别描述其在应用层、虚拟化层以及物理层的容错对象。(2)故障类型是对故障源中可能出现的故障类型的一种假设,本文将故障类型分为三种:瞬时性故障、fail-stop故障、拜占庭故障(Chen J.;Lu Y.;Comsa I.;et al..A scalability hierarchical fault tolerance strategy:Community Fault Tolerance.Automation and Computing.2014.212-217)。瞬时性故障是一种具有不确定性的随机发生的故障,具有难以重现的特点,一般可采取重启等方式实现容错。Fail-stop故障是云平台中常出现的故障之一,例如,由于软硬件错误导致虚拟机或物理机停止运行,或由于硬件老化等因素导致磁盘坏道都属于这类故障。拜占庭故障是指在运行阶段发生的任意类型的故障,尤其是指由于受到攻击产生的故障(范捷,易乐天,舒继武.拜占庭系统技术研究综述.软件学报,2013.24(6):1346-1360)。(3)容错机制属性,是指在容错机制部署时对参数进行初始化,例如热备机制中的心跳频率,双工机制中的冗余个数等。(4)容错范围是指容错机制被激活的范围,在容错范围外部无法观察到容错过程。根据云平台的部署模型,我们将容错范围分为五个级别:虚拟机范围(VM)、物理机范围(PM)、集群范围(Cluster)、数据中心范围(Datacenter)、以及云平台范围(Cloud)。
步骤四中,使用基于模型的故障注入技术和可靠性分析技术实现容错测试。运行时模型描述了系统的运行状态,通过QVT对运行时模型的操作模拟系统故障。当容错机制检测到系统错误,并实现容错后,通过基于模型的可靠性分析方法计算系统可靠性等指标,评估容错效果。
与现有技术相比,本发明的积极效果为:
采用本发明的方法,系统化地为目标云平台实现容错配置,降低管理员的容错管理成本。基于静态分析的容错机制推荐算法能够达到较高可靠性与资源消耗比,基于模型的容错配置相比于基于文本的配置大幅度提升了配置效率,减轻云管理员容错配置负担,基于模型的容错测试可提升测试效率,自动化分析容错效果。
附图说明
图1为基于运行时模型的容错配置框架;
图2为基于SBRA的构建重要性排名算法
图3为基于访问模型的运行时模型构造;
图4为基于模型转化的运行时模型构造;
图5为云平台元模型;
图6为容错机制元模型;
图7为计算模块容错对象;
图8为存储模块容错对象;
图9为网络模块容错对象;
图10容错效果对比;
图11事务成功率与容错成本比。
具体实施方式
以下结合附图和具体实施例对本发明进行详细说明。
基于运行时模型的容错配置框架,如图1,包括如下步骤:
首先,在构件级别为目标应用选择容错机制,实现可靠性与容错成本的最优化。选择容错机制的过程,包括两个阶段:基于可靠性分析的构件排名、基于动态规划的容错机制选择。在构件排名过程中,将目标应用描述为构件依赖图,该图描述了构件的属性以及构件之间的调用关系及频率。其中,处于关键路径或被调用次数较多的构件,其重要性更高,基于该思路,本文通过比较各个构件的可靠性提升对整个应用可靠性的影响,对构件进行排名,算法如图2。在基于动态规划的容错机制选择算法中,将可靠性、可用性、资源消耗等指标作为约束,将可靠性与容错开销比作为最优化目标,为各个构件选择容错机制,算法描述如图3。
其次,建立面向容错的云平台运行时模型。构造运行时模型分为两个步骤:构造元模型和实例化元模型。为了便于管理员构造运行时模型,我们通过对三大开源云平台部署结构和管理能力两个维度定义出通用元模型。(1)本文从云平台通用部署结构的角度构造云平台管理元模型。如图6左半部分,根节点为Deployment,包含多个数据中心。该数据中心对应于 CloudStack中的Zone、Eucalyptus中的Datacenter以及OpenStack中的Datacenter。数据中心内包含零到多个集群以及存储。集群Cluster分别对应OpenStack、CloudStack以及Eucalyptus 中Cluster的概念。存储分别对应OpenStack中的Swift存储、CloudStack中的Secondary Storage 以及Eucalyptus中的Walrus存储,表示位于数据中心内部可供该数据中心内所有虚拟机和物理机共享的存储设备,用于保存虚拟机镜像、模板。集群内包含存储(Storage)和物理机(Physical Machine)。集群内Storage对应于OpenStack中的Galance、CloudStack中的Primary Storage 以及Eucalyptus中的StorageController,主要用于保存运行虚拟机实例,该存储在集群范围内被虚拟机共享。PhysicalMachine表示计算节点,对应于OpenStack的Nova-compute、CloudStack 中的Agent以及Eucalyptus中的Node Controller,是用于管理该物理节点,执行相应的指令,例如启动、关闭虚拟机等。其对应关系见表1。(2)本文从云平台通用层次和模块化的角度补充云平台管理元模型。从云平台自底向上层次结构的角度来看,包含物理层、虚拟化层和应用层。从横向模块化的角度来看,包括计算模块、存储模块和网络模块。这是所有云平台都具备的通用结构,因此本文从这一角度完善元模型。其正交关系及实例如表2所示。首先,物理层的计算、存储、网络设备分别是指服务器小型机等物理计算节点、硬盘等硬件存储设备、交换机路由器等物理网络设备。虚拟层的计算、存储、网络设备分别是指虚拟机、虚拟机的存储块(给虚拟机分配的磁盘)、虚拟路由器等虚拟网络设备(例如CloudStack中的虚拟路由器)。应用层的计算、网络、存储都体现在应用内部,例如Mysql、Apache中涉及网络交互的构件。在以上构造的元模型基础上,本文实现两种运行时模型构造方法:基于访问模型的方法和基于模型转换的方法。访问模型描述了对系统管理API调用的过程,即直接通过对目标平台API的封装获取元模型中所定义的属性(封装get方法),以及执行相应的操作(封装set方法)。此外,对于基于模型管理的云平台,可以使用模型转换的方法将原有运行时模型转化为符合面向容错元模型的运行时模型。这两种方法各有优缺点,第一种需要调用目标平台的管理接口,实现方式较为复杂。第二种方式仅在模型层面进行操作,无需对目标系统进行交互,但其局限性在于要求目标系统已经存在某种类型的运行时模型。
表1通用元模型元素与云平台元素类比
通用元模型元素 | OpenStack | CloudStack | Eucalyptus |
Deployment | Cloud | Cloud | Cloud |
Datacenter | Zone | Datacenter | Datacenter |
Cluster | Cluster | Cluster | Cluster |
Datacenter Storage | Swift | Primary Storage | Walrus |
Cluster Storage | Galance | Secondary Storage | Storage Controller |
Physical Machine | Nova-compute | Agent | Node Controller |
Virtual Machine | Virtual Machine | Virtual machine | Virtual Machine |
Virtual Storage | Virtual Storage | Virtual Storage | Virtual Storage |
Application | Application | Application | Application |
表2云平台模块举例
接着,部署容错机制。本发明所提出的方法是一种基于运行时模型的容错机制部署方法。管理员按照容错部署方案将容错机制部署到运行时模型中。管理员需要定义部署方案中的以下四类属性:容错对象,描述云平台中可能会发生故障并需要进行容错的实体;故障类型,描述对潜在故障类型的预判;容错机制,描述一种针对故障源中的某种故障类型实现容错能力的策略及其参数设置;容错范围,描述针对云环境下容错机制的一种部署范围,该范围外对容错机制透明。本发明允许管理员通过以上四类属性,定义出某个容错机制的部署方案,并在云平台中自动实现部署。
最后,实现容错测试。在运行阶段对云平台中的故障源注入故障,并对运行时模型以及机制的运行状态进行分析,计算可靠性指标。管理员通过QVT脚本对运行时模型进行故障注入,模拟系统故障。例如,通过QVT对运行时模型进行操作,将指定的应用状态从running 设置为error,此时容错机制的监测模块观察到该错误,并由执行模块实现故障转移。状态调整后,利用QVT脚本在模型层面对系统进行可靠性分析。
下面通过一个实例说明本发明的方法。实现基于CloudStack云平台的容错配置过程。
CloudStack是Apache基金会支持的一个具有高可用性及扩展性的云计算平台。同时 CloudStack是一个开源云计算解决方案,可以加速高伸缩性的公共和私有云(IaaS)的部署、管理、配置。
在CloudStack中,用户能够设置虚拟机是否启用HA(高可用)。所有的路由器虚拟机和系统虚拟机都会自动启用HA。当HA虚拟机所在的物理机出现故障,CloudStack能够监测该事件并且自动在同一个集群中重新启动该虚拟机。CloudStack实现相应的策略,确保任何时刻都不会有两个相同的虚拟机实例同时运行。CloudStack允许将物理机标记为HA-enable,为 HA虚拟机预留硬件资源。此外,CloudStack还提供了以下容错机制。
1)基于状态监测的虚拟机重启。云平台周期性地检查关键虚拟机状态是否与数据库VM 表中status字段所存储的内容一致,若不一致则认为虚拟机状态错误,并重启该虚拟机。
2)虚拟机优先迁移。当云平台中某台物理机负载超过阈值后(该阈值管理员可设定),云平台会将该物理机上的虚拟机迁移至其它负载较低的物理机。
3)多管理节点。CloudStack管理节点是无状态的Web应用,管理员可将管理节点部署在多台物理机上,避免管理节点的单点故障。
4)数据库备份。CloudStack使用Mysql数据库,云平台可以利用数据库的备份机制提供数据容错。
上述容错机制均是在系统层提供特定的容错机制及配置。目前,云平台更多在系统层提供通用的容错机制及配置方式,无法结合应用业务逻辑实现容错配置。这种未考虑应用业务逻辑的容错配置方式,难以满足多样化应用的容错需求。造成这种现状的原因有两点:(1)云平台中应用的规模大和种类多,云平台难以为单个应用分别提供具有针对性的容错机制及配置方式;(2)云平台提供者的管理能力仅能涉及到系统层,上层的应用对系统层透明。然而,容错配置过程中的容错机制选择和部署等步骤的实施,均需要结合应用业务逻辑和系统环境信息来实现。
为此本文提出由管理员实现基于应用结构的容错机制推荐、部署方法,并实现容错测试。本次试验中,首先使用基于SBRA的算法对目标应用内部结构进行分析,对应用构件进行排名,然后使用动态规划算法推荐各个构件的容错机制,以实现可靠性提升与资源消耗的最大比。实验针对的目标应用为RUBiS基准测试程序。
首先,通过对RUBiS运行时构件调用关系进行分析,构造出构件依赖图。
然后,使用基于SBRA的可靠性分析算法对构件进行排名,通过提升各个构件的可靠性计算应用可靠性,按照应用可靠性提升程度对构件重要性进行排名。
在构件排名的基础上使用动态规划算法,对各个构件推荐容错机制,以实现最优化目标。容错机制推荐结果见表3。
表3容错机制推荐结果
容错机制 | 构件名称 |
双工机制 | AboutMe,SearchItemByCatagory,ViewItem |
热备机制 | BrowseCatagories |
冷备机制 | Auth |
重启机制 | ViewUserInfo |
重试机制 | 无 |
无容错机制 | 其他构件 |
最后,通过故障注入测试该应用在不同容错机制下的事务成功率。其中双工机制容错效果最佳,见图10。但由于双工机制资源消耗过大,并不适合于所有构件。图11展示了成功率与资源消耗的比值。结果表明,通过基于SBRA的算法在应用结构分析的基础上进行容错机制推荐,能够实现更优的容错性价比。
上述具体实施例和附图用以帮助理解本发明的技术原理并据以实施,而不对本发明构成限制。本领域的技术人员可以理解:在不脱离本发明的权利要求的精神和范围内,各种替换、变化和修改都是可能的。本发明要求保护的范围应以权利要求书的界定为准。
Claims (8)
1.一种基于运行时模型的云计算容错机制配置方法,其步骤为:
1)构造云平台的云容错运行时模型和目标应用的构件依赖图;云平台根据该构件依赖图对该目标应用的各个构件设置容错机制;
2)云平台根据步骤1)中设置的容错机制制定容错部署方案,将该容错机制部署到该云容错运行时模型中;
3)利用该云容错运行时模型将容错机制代码部署至运行时云平台中,并维护该云容错运行时模型与运行时云平台的双向同步;
其中,对该目标应用的各个构件设置容错机制的方法为:首先根据故障类型和故障源对容错机制进行过滤:set1={mi|u1∈fti,u2∈fsi,mi∈set0};其中,set0是所有容错机制构成的集合,set1是经过对故障源以及故障类型进行匹配后满足设定条件的容错机制集合,u1为故障类型,u2为故障源,fti表示第i个容错机制能够处理的故障类型集合,fsi表示第i个容错机制能够处理的故障源集合;然后根据计算下述公式的最大化值为每个构件选择容错机制;
最大化目标:
约束条件:
集合中最小值>μ1
集合中最小值>μ2
集合中最大值<μ3
其中,用户约束包括可靠性Ri、可用性Ai、故障转移时间TFi;μ1为可用性约束,μ2为可靠性约束,μ3为故障转移时间约束,m表示容错机制个数,n表示该目标应用的构件个数;表示为第j个构件选择第i个容错机制,表示第j个构件选择第i个容错机制所消耗的资源,表示第j个构件选择第i个容错机制后的可用性,表示第j个构件选择第i个容错机制后的故障转移时间,的取值范围为0或1,当结果为1时表示为第j个构件选择第i个容错机制。
2.如权利要求1所述的方法,其特征在于,所述根据该构件依赖图对该目标应用的各个构件设置容错机制的方法为:首先对该目标应用的构件进行重要性排名,然后将该目标应用可靠性与容错成本比作为优化目标,将用户需求作为约束,针对各个构件分别设置容错机制。
3.如权利要求2所述的方法,其特征在于,对该目标应用的构件进行重要性排名的方法为:分别对目标应用中的每一构件提升其可靠性,然后利用SBRA算法计算该构件可靠性提升后目标应用的可靠性提升程度,然后根据该可靠性提升程度对构件重要性进行排名。
4.如权利要求1所述的方法,其特征在于,所述容错部署方案包括四种类型的属性:容错对象、故障类型、容错机制、容错范围;其中,容错对象是指在云平台中会发生故障且需要进行容错的主体;故障类型包括:瞬时性故障、Fail-stop故障、拜占庭故障;容错机制属性是指在容错机制部署时对参数进行初始化;容错范围是指容错机制被激活的范围。
5.如权利要求4所述的方法,其特征在于,所述容错范围分为五个级别:虚拟机范围、物理机范围、集群范围、数据中心范围、以及云平台范围。
6.如权利要求1所述的方法,其特征在于,使用基于模型的故障注入技术和可靠性分析技术进行容错测试:通过QVT对运行时模型的操作模拟系统故障,当容错机制检测到系统错误并实现容错后,通过基于模型的可靠性分析方法计算系统可靠性指标,评估容错效果。
7.如权利要求1所述的方法,其特征在于,所述云容错运行时模型包括云平台元模型和容错机制元模型;其中,云平台元模型包括若干数据中心,所述数据中心包括若干集群和存储,所述集群包含若干物理机,所述存储包括若干存储设备,所述物理机包含若干虚拟机,所述存储设备包括若干虚拟存储,所述虚拟机包含若干应用;容错机制元模型的构造包括目标应用类和容错类。
8.如权利要求7所述的方法,其特征在于,所述云平台元模型中设有云平台运行时信息,包括:数据中心信息,集群信息,存储信息,主机信息,虚拟机信息,应用信息;所述容错机制元模型中设有容错机制运行时信息,包括:目标应用信息,目标应用所在虚拟机信息,容错机制运行信息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510393804.7A CN105005509B (zh) | 2015-07-07 | 2015-07-07 | 一种基于运行时模型的云计算容错机制配置方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510393804.7A CN105005509B (zh) | 2015-07-07 | 2015-07-07 | 一种基于运行时模型的云计算容错机制配置方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105005509A CN105005509A (zh) | 2015-10-28 |
CN105005509B true CN105005509B (zh) | 2018-08-14 |
Family
ID=54378189
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510393804.7A Active CN105005509B (zh) | 2015-07-07 | 2015-07-07 | 一种基于运行时模型的云计算容错机制配置方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105005509B (zh) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107870801B (zh) * | 2016-09-26 | 2020-05-26 | 中国电信股份有限公司 | 虚拟机高可用功能自动开通方法、装置和系统 |
CN106603696B (zh) * | 2016-12-28 | 2019-06-25 | 华南理工大学 | 一种基于超融合基础框架的高可用系统 |
CN106850354A (zh) * | 2017-02-22 | 2017-06-13 | 郑州云海信息技术有限公司 | 一种单点故障的处理方法及装置 |
CN108804271A (zh) * | 2018-06-28 | 2018-11-13 | 北京潘达互娱科技有限公司 | 接口容错测试方法及装置 |
CN110187989B (zh) * | 2019-05-24 | 2022-08-09 | 广东致盛技术有限公司 | 雾环境下基于Markov Chain的容错策略选择方法 |
CN111143133B (zh) * | 2019-12-31 | 2020-09-01 | 广州鼎甲计算机科技有限公司 | 虚拟机备份方法和备份虚拟机恢复方法 |
CN112559358B (zh) * | 2020-12-21 | 2022-04-12 | 北京航空航天大学 | 一种面向策略选择的自适应运行的可靠性预计方法 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102104496A (zh) * | 2010-12-23 | 2011-06-22 | 北京航空航天大学 | 一种云计算环境下中间数据的容错性优化方法 |
CN102521128A (zh) * | 2011-12-08 | 2012-06-27 | 华中科技大学 | 面向云平台的软件故障容忍方法 |
CN102629224A (zh) * | 2012-04-26 | 2012-08-08 | 广东电子工业研究院有限公司 | 一种基于云平台的一体化数据容灾方法及其装置 |
CN103500126A (zh) * | 2013-10-28 | 2014-01-08 | 北京大学 | 一种云计算平台的自动化容错配置方法 |
CN103716182A (zh) * | 2013-12-12 | 2014-04-09 | 中国科学院信息工程研究所 | 一种面向实时云平台的故障检测与容错方法及系统 |
-
2015
- 2015-07-07 CN CN201510393804.7A patent/CN105005509B/zh active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102104496A (zh) * | 2010-12-23 | 2011-06-22 | 北京航空航天大学 | 一种云计算环境下中间数据的容错性优化方法 |
CN102521128A (zh) * | 2011-12-08 | 2012-06-27 | 华中科技大学 | 面向云平台的软件故障容忍方法 |
CN102629224A (zh) * | 2012-04-26 | 2012-08-08 | 广东电子工业研究院有限公司 | 一种基于云平台的一体化数据容灾方法及其装置 |
CN103500126A (zh) * | 2013-10-28 | 2014-01-08 | 北京大学 | 一种云计算平台的自动化容错配置方法 |
CN103716182A (zh) * | 2013-12-12 | 2014-04-09 | 中国科学院信息工程研究所 | 一种面向实时云平台的故障检测与容错方法及系统 |
Non-Patent Citations (2)
Title |
---|
《A Scenario-Based Reliability Analysis Approach for Component-Based Software》;Sherif Y.,Bojan C.,and Hany H.Ammar;《IEEE transactions on reliability》;20041231;第465-480页 * |
《Fast memory state synchronization for virtualization-based fault tolerance》;Lu M,Chiueh T;《Dependable Systems&Networks,2009》;20091231;第534-543页 * |
Also Published As
Publication number | Publication date |
---|---|
CN105005509A (zh) | 2015-10-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105005509B (zh) | 一种基于运行时模型的云计算容错机制配置方法 | |
Campbell et al. | Extreme scale with full sql language support in microsoft sql azure | |
CN102103518B (zh) | 一种在虚拟化环境中管理资源的系统及其实现方法 | |
US7779298B2 (en) | Distributed job manager recovery | |
Jhawar et al. | Fault tolerance management in IaaS clouds | |
Yan et al. | Carousel: Low-latency transaction processing for globally-distributed data | |
Zhang et al. | Overview on fault tolerance strategies of composite service in service computing | |
Rajput et al. | Multi-agent architecture for fault recovery in self-healing systems | |
Halalai et al. | Zoofence: Principled service partitioning and application to the zookeeper coordination service | |
Smara et al. | Robustness improvement of component-based cloud computing systems | |
Danilecki et al. | ReServE service: An approach to increase reliability in service oriented systems | |
Brzeziński et al. | D-reserve: Distributed reliable service environment | |
Rahimzadeh et al. | ECHO: Efficiently overbooking applications to create a highly available cloud | |
Bouteiller et al. | Implicit actions and non-blocking failure recovery with MPI | |
Abderrahim et al. | Brokerage-based dependability integration in cloud computing services | |
CN107147733A (zh) | 基于soa的服务恢复方法 | |
Adeshiyan et al. | Using virtualization for high availability and disaster recovery | |
Ledmi et al. | Fault tolerance in cloud computing: A survey | |
Liu et al. | Reliability modeling and analysis of hospital information system based on microservices | |
Anderson | Privacy technology lessons from healthcare | |
Limam et al. | A self-adaptive conflict resolution with flexible consistency guarantee in the cloud computing | |
Neng | Construction of high-availability bank system in virtualized environments | |
Oussane et al. | Fault Tolerance in The IoT: A Taxonomy Based on Techniques | |
RU2714602C1 (ru) | Способ и система для обработки данных | |
Somasekaram | Bayesian Prognostic Framework for High-Availability Clusters |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |