一种基于运行时模型的云计算容错机制配置方法

摘要

本发明公开了一种基于运行时模型的云计算容错机制配置方法。本方法为：1)构造云平台的云容错运行时模型和目标应用的构件依赖图；云平台根据该构件依赖图对该目标应用的各个构件设置容错机制；2)云平台根据步骤1)中设置的容错机制制定容错部署方案，将该容错机制部署到该云容错运行时模型中；3)利用该云容错运行时模型将容错机制代码部署至运行时系统中，并维护该云容错运行时模型与运行时云平台的双向同步。本发明通过对目标应用结构分析，选择合适的容错机制，根据容错机制以及用户需求，制定合适的容错部署方案，并在运行时模型中实现容错测试。

说明书

技术领域

本发明涉及一种容错机制配置方法，针对云计算中多样化的容错需求，提出了一种基于 运行时模型的容错配置方法，进行容错机制的选择和容错配置的规划，属于软件技术领域。

背景技术

云计算可以便捷地从可配置的资源池中获得计算、存储、网络等形式的资源，这些资源 能够便捷地申请和释放，使资源管理和使用成本大大降低。随着云平台的普及和其规模的扩 大，其可靠性所面临的问题也越来越严重。而容错技术可保证云平台发生故障时，使系统持 续提供有效服务，提升系统的可靠性。容错是指系统在出现错误的情况下继续对外提供服务 的能力。容错一般包括两个步骤：错误检测和恢复。错误检测的目的是及时发现系统内出现 的错误，恢复的目的是将系统恢复到正确状态并防止错误再次发生，包括错误处理和故障处 理两个阶段。研究表明，容错技术是防止系统失效的有效手段(Avizienis A.；Lapri J-C.,Randell  B.；Landwehr C.2004.Basic Conceptsand Taxonomy of Dependable and Secure Computing. IEEETransactions on Dependable and Secure Computing.1:11-33)，并已在航空航天、医疗、银 行等系统实践中得到广泛应用。

容错配置是根据软件和运行环境对容错机制进行选择、部署和测试。在传统单机和局域 网环境下，上层软件独占底层基础设施，软件部署时容错需求明确，软件运行时容错需求不 变或基本不变，因此，可针对固定的容错需求实现容错配置。在云计算环境下，由于基础设 施共享、资源规模超大、应用种类多、数量大且容错需求多样化，云计算容错配置面临开放 性挑战。为保证用户部署的服务持续可用，容错配置过程中的容错机制选择和部署等步骤， 均需结合应用业务逻辑来实现。而由于应用的多样性和规模化，目前云平台更多在系统层提 供通用的容错机制及配置方式，无法结合应用业务逻辑实现容错配置。这种未考虑应用业务 逻辑的容错配置方式，难以满足多样化应用的容错需求。例如，在容错机制选择时，考虑到 可靠性与容错成本比最大化的需求，需要在应用结构分析的基础上，为各个构件选择不同的 容错机制，如对关键构件选择可靠性高且容错成本高的双工机制(Zhang Y；Zheng Z；Lyu M R. 2011.BFTCloud:A byzantine fault tolerance framework for voluntary-resource cloud computing. Cloud Computing(CLOUD),IEEE International Conference on.444-451.)，对非关键构件选择可 靠性较低且容错成本低的温备份机制(Dantas J.；et al.2012.An availability model for eucalyptus  platform:An analysis of warm-standy replication mechanism.IEEE International Conference on  Systems,Man,and Cybernetics.1664-1669.)。

发明内容

针对云平台中容错配置开放性问题，本发明的目的在于提供一种基于运行时模型的容错 配置方法。本发明通过对目标应用结构分析，选择合适的容错机制，根据容错机制以及用户 需求，制定合适的容错部署方案，并在运行时模型中实现容错测试。

本发明是通过如下技术方案实现的：

一种基于运行时模型的容错机制配置方法，其步骤为：

1)管理员构造目标应用的构件依赖图，该图描述了应用中各个构件之间的依赖关系。云 平台容错配置框架对该构件依赖图进行分析，对目标应用的各个构件进行排序。进一 步的，按照此排序结果和动态规划算法为各个构件推荐容错机制，实现容错效果与容 错成本的最优比；

2)云平台容错配置框架构造云容错运行时模型，维护运行时模型与运行时云平台的双向 同步，即运行时云平台系统状态变化会实时同步至运行时模型，反之，运行时模型的 变化也会同步至系统；

3)云平台容错配置框架根据步骤一中推荐的容错机制，制定容错部署方案，并将容错机 制部署到运行时模型中。利用步骤二中运行时模型与运行时云平台的同步能力，将容 错机制代码部署至运行时云平台中。

4)云平台容错配置框架对运行时模型进行错误注入，并评估容错效果。

进一步的，在分析目标应用结构特征的过程中，对该目标应用的构件重要性程度进行排 名，按照该排名，从容错机制库中为各个构件选择容错机制(容错库中包括双工、热备、冷 备、重启、重试、优先迁移和软件恢复七种容错机制)，以实现容错性价比的最优化，其中， 容错效果使用软件可靠性进行度量，容错成本使用容错机制对硬件资源的消耗进行度量。

进一步的，云平台容错配置框架中的用户需求，包括可靠性(R_i)、可用性(A_i)、故障转移 时间(T_i)。

进一步的，容错机制的选择过程包含两个步骤：(1)构件排名。为实现可靠性与容错成 本的最优比，本文针对目标应用的结构信息，基于场景的可靠性分析算法SBRA(Sherif Y., Bojan C.,and Hany H.Ammar.A Scenario-Based Reliability Analysis Approach for  Component-Based Software.IEEE transactions on reliability 2004,53(4):465-480.)实现构件重要 性排名，(2)针对各个构件分别推荐容错机制。本发明提出动态规划算法,以实现目标应用的 容错性价比最优化，该动态规划算法中，将可靠性与容错成本比作为优化目标，将用户需求 (包括可靠性、可用性、故障转移时间)作为约束。

进一步的，构件重要性排名的思路是，分别对单个构件提升其可靠性，然后利用SBRA 计算整个应用的可靠性，根据整体可靠性的提升程度对构件重要性进行排名。算法流程图如 图2所示，所有构件的可靠性初始值为0.8，构件个数为N，对单个构件可靠性分别提升0.2， 然后使用基于场景的可靠性分析算法SBRA，对全局可靠性R_app-i进行计算，最终按照整体应 用可靠性提升程度对构件排名。

进一步的，对单个构件进行容错机制推荐，包括两个步骤。首先，根据故障类型和故障 源对容错机制进行过滤：

其中，set₀是所有容错机制构成的集合，set₁是 经过对故障源以及故障类型进行匹配后满足该条件的容错机制集合。u₁描述用户指定的故障 类型，u₂描述用户指定的故障源。ft_i和fs_i分别表示第i个容错机制能够处理的故障类型集合 以及故障源集合。然后，根据用户约束选择容错机制。此处的用户约束包括可靠性(R_i)、可 用性(A_i)、故障转移时间(TF_i)三个属性。u₁，u₂，u₃分别表示用户在可用性，可靠性，故障转 移时间方面的约束，在满足约束的前提下最优化可靠性与资源消耗比。动态规划数学公式为：

最大化目标：

${\Sigma }_{j=1}^n{\Sigma }_{i=1}^m{R}_i^j\times x_i^j/{\Sigma }_{j=1}^n{\Sigma }_{i=1}^m{C}_i^j\times x_i^j$

约束条件：

${\Sigma }_{j=1}^n{\Sigma }_{i=1}^m{x}_i^j\le n$

$x_i^j\in \{0,1\}$

上述公式中，m表示容错机制个数，n表示某个目标应用的构件个数。R_i^j表示为第j个构 件选择第i个容错机制，C_i^j表示第j个构件选择第i个容错机制所消耗的资源，A_i^j表示第j 个构件选择第i个容错机制后的可用性，TF_i^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中的Storage Controller，主要用于保存运行虚拟机实例，该存储在集群范围内 被虚拟机共享。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的算法在应用结构分析的基础上进行容错 机制推荐，能够实现更优的容错性价比。

上述具体实施例和附图用以帮助理解本发明的技术原理并据以实施，而不对本发明构成 限制。本领域的技术人员可以理解：在不脱离本发明的权利要求的精神和范围内，各种替换、 变化和修改都是可能的。本发明要求保护的范围应以权利要求书的界定为准。