云应用系统由运行在多个云端节点上的服务组件协同构成, 考虑到云环境中失效已经成为一种常态, 故为云应用系统提供高效且持续可用的容错服务, 以保障其可靠运行是至关重要的^[1].软硬件容错技术^{[2, 3]}已得到广泛应用, 但在云环境中提供容错服务仍存在一个问题, 即若单独由云基础架构服务提供商为上层运行的各个云应用系统提供可用的容错机制, 很难顾全不同云应用系统的容错需求差异; 而单独将容错机制集成到云应用系统开发中, 又很难充分利用底层的云基础架构资源和效能.目前, 由第三方容错服务提供商以容错即服务的模式为云应用系统运行提供持续可用的容错服务, 已成为首选的容错服务实用模式^[4].

容错即服务的相关研究大都以较固定的容错技术方案为基础, 未全面、适时地考虑云应用系统在运行时的容错需求变化, 容错开销较大且支撑容错服务的云资源利用率较低.具体而言, 首先, 容错解决的主要问题是提高被容错应用系统的可靠性, 但固定容错技术后, 容错需求并未直接反映云应用系统最关心的可靠性, 也很难适应云应用系统在运行时的容错需求变化.此外, 如果云应用系统使用固定的容错技术, 那么支撑该容错服务的云资源无论容错需求是否变化都将是固定的, 易导致容错开销大.同时, 云容错服务提供商只能为固定数量的云应用系统提供容错服务, 其容错服务资源得不到合理且充分的利用, 对云容错服务提供商的收益影响较大.

本文采用容错即服务的模式, 提出了一种优化的云容错服务动态提供方法, 从云应用组件的可靠性、响应时间等方面描述云应用容错需求, 以常用的复制、检查点和NVP(N-version programming)等容错技术为基础, 充分考虑容错服务动态切换开销, 分别针对支撑容错服务的底层云资源是否足够的场景, 给出可用容错即服务提供方案的最优化求解方法.实验结果表明, 本文所提方法降低了云应用系统支付的容错服务费用及支撑容错服务的底层云资源的开销, 提高了容错服务提供商为多个云应用实施高效可靠容错即服务的能力.

本文第1节概述相关工作.第2节给出云应用系统容错需求的具体描述.第3节阐述3种容错技术的资源开销约束分析, 对其资源需求、执行开销和响应时间进行计算.第4节给出容错服务间的动态切换开销.第5节分别针对支撑容错服务的底层云资源是否足够的场景, 给出可用容错即服务提供方案的最优化求解方法.第6节应用具体实例进行实验验证本文所提方法的可用性及优势.第7节总结全文.

1 相关工作

在针对云环境中容错技术的典型研究中, 文献[5]对容错架构进行了综述.文献[6]提出了动态可适配的复制容错和检查点容错方法, 并进行了分析、建模和评估.文献[7]针对当前计算机系统计算和存储资源丰富而并行文件系统写带宽提高相对滞后的特点, 提出了基于内存缓存的异步检查点容错技术.文献[8]针对云计算系统的软故障恢复, 提出了能源感知的容错调度框架.文献[9]为分布式组件系统提出了一种容错框架.

在针对容错即服务的相关研究中, 文献[4]提出将容错作为服务层的框架设计, 但并没有提出具体的容错即服务方案.文献[10]从容错服务提供商的角度, 研究了选择为哪些租户提供容错服务才能使云容错服务提供商的收益最大的问题, 但要求在容错需求中必须指定组件将要使用的具体容错技术.文献[11]提出了一种基于用户约束的容错弹性系统, 该系统内置的容错控制器将根据用户约束为用户适配容错方法, 但并未考虑底层云资源的利用率.文献[12]基于系统运行时的资源和负载情况, 为用户动态地适配复制容错技术或者检查点容错技术, 但没有考虑被容错对象对时间及容错效果的要求.

通过以上分析可知, 针对现有相关研究的不足, 本文以容错即服务模式为切入点, 切实考虑可靠性等云应用容错需求, 提出一种优化的云容错服务动态提供方法.

2 云应用系统容错需求的定义

云应用系统中不同云服务组件(具有一定功能的独立程序体)的重要程度不同, 重要性越高的组件对容错的需求更高.服务组件在不同时间段的重要程度也可能不同, 例如, 若某个服务组件在某个时间段被调用的次数较多, 则该组件在该时间段的重要性和容错需求就较高.可靠性是云应用系统容错需求的核心问题, 并且, 由于非重要性组件对可靠性要求不是很严格, 那么通过定义可靠性误差, 即允许可靠性稍有降低, 会使云应用系统需支付的容错费用降低.此外, 不同服务组件对响应时间和数值容错的要求不同, 例如, 多媒体组件对响应时间的要求比较严格, 但对数据正确性要求并不严格.通过以上分析, 我们将云应用系统的容错需求描述为下面的七元组定义.

〈AID_CID, periodT, Critic_{AID_CID}(periodT), URelia_{AID_CID}(periodT), DRelia_{AID_CID}(periodT), RT_{AID_CID}(periodT), vFault_{AID_CID}(periodT)〉.

其中, AID标识具体云应用系统, CID标识该云应用系统中的具体服务组件, 且AID∈N⁺, CID∈N⁺.periodT描述服务组件向云容错服务提供商请求容错服务的时间段.Critic_{AID_CID}(periodT)表示服务组件AID_CID在时间段periodT内是否为关键组件(重要性较高), Critic_{AID_CID}(periodT)∈{0, 1}, 关键性组件取值为1, 否则, 取值为0. URelia_{AID_CID}(periodT)描述服务组件在给定时间段内的容错可靠性需求, 且应满足0 < URelia_{AID_CID}(periodT) < 1. DRelia_{AID_CID}(periodT)描述服务组件在给定时间段内允许的容错可靠性误差, 满足0≤DRelia_{AID_CID}(periodT) < 1. RT_{AID_CID}(periodT)描述服务组件在给定时间段内对响应时间的要求.vFault_{AID_CID}(periodT)描述服务组件在给定时间段内对数值容错效果的要求, 即当组件要求保证数据准确时取值为1, 否则, 取值为0.

给出一个云应用系统的容错需求示例性描述为〈1-3, 0-1, 1, 0.991, 0.003, 3.5, 1〉, 该容错需求可解释为:1号云应用系统中的3号服务组件是完成关键任务的组件, 期望容错可靠性达到0.991, 允许存在可靠性误差不超过0.3%, 要求组件处理请求的响应时间不超过3.5s, 要求对组件的容错服务能够处理数值错误故障.

3 3种容错技术的资源开销约束分析

选择当前普遍使用的复制容错技术、NVP容错技术与检查点容错技术支撑云容错服务提供商提供容错即服务, 为此, 本文重点考虑容错技术在虚拟机、存储资源和软件运行方面的执行开销.在计算复制和NVP容错技术的开销时, 将特定时间段内使用虚拟机运行组件代码产生的费用作为虚拟机开销; 将使用存储资源存储组件代码产生的费用作为存储资源开销.根据文献[10], 检查点容错技术除了使用虚拟机和存储资源运行并存储检查点程序外, 还有生成及应用检查点引起的软件运行开销.此外, 为各种开销增加了权重因子, 设置α为存储开销权重因子, β为虚拟机开销权重因子, γ为软件运行开销权重因子.下文将以组件i在时间段[0, T]内的可靠性需求URelia_i(T)为例, 计算使用不同容错技术满足可靠性需求时的资源需求、执行开销和响应时间.

3.1 复制容错技术的资源需求、执行开销和响应时间

本文采用被动复制容错技术, 即设置某一个副本为主副本, 其他为备份副本.当主副本失效时, 选择某个备份副本作为新的主副本, 接替旧主副本的工作.为了确保新的主副本能够继续接替旧主副本的工作, 旧主副本在运行期间周期性地保存状态信息到备份副本.可为每个副本都分配一台虚拟机.假设一个副本的失效对其他副本没有影响, 那么, 根据被动复制容错技术的运行机制可知, 当在时间段[0, T]内使用复制容错技术满足组件i的可靠性需求URelia_i(T)时, 至少需要的副本个数numRep可由公式(1)求得.假设服务组件初始可靠性为R.

$ 1 - {\left( {1 - R} \right)^{numRep}} \ge UReli{a_i}\left( T \right) $

(1)

● 复制容错技术的资源需求

根据复制容错技术的运行机制, 资源需求量为numRep-1台虚拟机和numRep-1个存储单元.虚拟机用来运行容错需要的numRep-1个副本程序, 存储单元用来存储容错的numRep-1个副本程序.

● 复制容错技术的执行开销

根据文献[13]中提出的云计算下数据管理成本模型, 存储开销可用公式(2)表示.其中, 假设程序运行所需存储单元大小为n_m, 数据中心大小为s, 其调节系数为u.虚拟机开销可用公式(3)表示, priceVmHour描述云容错服务提供商每台虚拟机每小时的价格.进而, 使用复制容错技术产生的总开销可用公式(4)表示.

$ Cos{t_{storRep}}{\rm{ = }}\frac{u}{{2\sqrt s }} \times {n_m} \times (numRep-1) \times T $

(2)

$ Cos{t_{vmRep}} = \left( {numRep-1} \right) \times priceVmHour \times T $

(3)

$ Cos{t_{sumRep}} = a \times Cos{t_{storRep}} + b \times Cos{t_{vmRep}} $

(4)

● 复制容错技术的响应时间

根据文献[14], 假设组件处于正常态和闲置态的请求到达率分别为λ和λ', 平均响应时间分别为W_O和W_I, 组件修复属于延时修复, 副本的寿命服从均值为1/f的指数分布, 每个任务的服务时间服从均值为1/μ的指数分布, 修复一个故障的时间服从均值为1/δ的指数分布, 组件可用性为avail, 检查点间隔为1/c(周期性保存状态到备份副本), 设置一个检查点的时间为T_chk, 有i个副本处于正常态的概率为P_i, 组件处于正常态的概率为P_q.那么, 在使用复制容错技术时, 请求的响应时间W_rep可用公式(5)表示.

$ {W_{rep}} = \frac{{\lambda {P_q}}}{{\lambda {P_q} + \lambda '{P_0}}} \times {W_O} + \frac{{\lambda '{P_0}}}{{\lambda {P_q} + \lambda '{P_0}}} \times {W_I} $

(5)

其中,

$ {W_O} = \frac{1}{{avail \times \mu-\lambda }}, $

$ {W_I} = \frac{{numRep}}{{2\delta }} + \frac{{\lambda 'numRep}}{{2\mu \delta }}, $

$ avail = \frac{1}{{1{\rm{ + }}c(numRep-1){T_{chk}} + \frac{{f\lambda }}{{2\mu c}}}}, $

$ f = \frac{{\ln \left( {\frac{1}{{UReli{a_i}(T)}}} \right)}}{{60 \times 60}}, $

$ {p_q} = \sum\limits_{i = 1}^{numRep} {{P_i}}, $

$ {P_i} = C_{numRep}^i{R^i}{(1-R)^{numRep-i}}. $

3.2 NVP容错技术的资源需求、执行开销和响应时间

在NVP容错技术中, N个版本的子程序同时执行用户请求(子程序运行在不同的虚拟机上), 并将执行结果传到表决器, 其根据表决算法确定处理是否正确.本文选择大数表决算法^[15]及并行子程序执行的投票流程^[16], 即当新的子程序执行完毕后, 如果已经完成执行操作的子程序个数大于(numNVP/2)+1, 则执行投票算法.根据文献[17], 在时间段[0, T]内, 当满足组件i可靠性需求URelia_i(T)时, 至少需要的子程序个数numNVP可由公式(6)求得.

$ \sum\limits_{j = \frac{{numNVP}}{2} + 1}^{numNVP} {C_{numNVP}^j} {R^j}{(1-R)^{numNVP-j}} \ge UReli{a_i}(T) $

(6)

●  NVP容错技术的资源需求

NVP容错技术的资源需求量为numNVP-1台虚拟机和numNVP-1个存储单元.虚拟机用来运行容错所需的numNVP-1个子程序, 存储单元用来存储容错所需的numNVP-1个子程序.

●  NVP容错技术的执行开销

根据文献[13], 存储开销可用公式(7)表示.虚拟机开销可用公式(8)表示.进而, 使用NVP容错技术产生的总开销可用公式(9)表示.

$ Cos{t_{storNVP}}{\rm{ = }}\frac{u}{{2\sqrt s }}{n_m}(numNVP-1)T $

(7)

$ Cos{t_{vmNVP}} = \left( {numNVP--1} \right) \times priceVmHour \times T $

(8)

$ Cos{t_{sumNVP}} = a \times Cos{t_{storNVP}} + \beta \times Cos{t_{vmNVP}} $

(9)

●  NVP容错技术的响应时间

使用执行时间和投票时间的和作为可度量请求响应时间.假设第i个子程序执行一个服务需要的时间服从均值为1/u_i的指数分布, 投票时间服从参数为l_d的指数分布.那么, 根据文献[16], 当第j个((numNVP/2)+1≤j≤ numNVP)子程序执行完毕后, 服务组件产生正确结果的概率p_j及执行时间t_j可分别用公式(10)和公式(11)表示.进而, 服务组件的执行时间timeExec可用公式(12)表示, 请求的响应时间W_NVP可用公式(13)表示.

$ {p_j} = C_{j-1}^{\left( {\frac{{numNVP}}{2} + 1} \right)-1} \cdot {R^{\frac{{numNVP}}{2} + 1}} \cdot {(1-R)^{j - \left( {\frac{{numNVP}}{2} + 1} \right)}} $

(10)

$ {t_j} = 1/{u_j} + 1/{\lambda _d} $

(11)

$ timeExec = \frac{1}{{\sum\limits_{j = \frac{{numNVP}}{2}{\rm{ + }}1}^{numNVP} {C_{numNVP}^j{R^j}{{(1-R)}^{numNVP-j}}} }} \cdot \sum\limits_{j = \frac{{numNVP}}{2}{\rm{ + }}1}^{numNVP} {{p_j}} \cdot {t_j} $

(12)

$ {W_{NVP}} = timeExec + 1/{\lambda _d} $

(13)

3.3 检查点容错技术的资源需求、执行开销和响应时间

本文采用最基本的完全检查点容错技术, 即周期性地保存云应用系统的关键状态, 当系统发生故障时, 可恢复到最新的检查点处并继续运行.

● 检查点容错技术的资源需求

检查点容错技术的资源需求量为1台虚拟机和1个存储单元.虚拟机用来运行检查点程序, 该程序主要是周期性地完成检查点工作, 存储单元用来存储检查点程序.

● 检查点容错技术的执行开销

根据文献[13], 存储开销可用公式(14)表示.虚拟机开销可用公式(15)表示.

$ Cos{t_{storCP}}{\rm{ = }}\frac{u}{{2\sqrt s }}{n_m} \cdot 1 \cdot T $

(14)

$ Cos{t_{vmCP}} = 1 \times priceVmHour \times T $

(15)

计算检查点容错技术的软件运行开销时, 根据文献[10], 首先计算出在时间段[0, T]内检查点的个数, 之后用该时间段内检查点的个数与每设置一次检查点所产生的开销的乘积作为其软件运行开销.假设设置检查点需要的时间为T_chk, 使用一次检查点引起的开销为costPerInnovation, 根据文献[6], 满足组件i在时间段[0, T]内的可靠性需求为URelia_i(T)时的检查点间隔ΔT可用公式(16)表示.进而, 软件运行开销可用公式(17)表示, 检查点容错技术的总开销可用公式(18)表示.

$ \Delta T = {\left( {\frac{{{T_{chk}}}}{{\ln \frac{1}{{UReli{a_i}(T)}}}}} \right)^{0.5}} $

(16)

$ Cos{t_{otherCP}} = (T/\Delta T) \times costPerInnovatio $

(17)

$ Cos{t_{sumCP}} = \alpha \times Cos{t_{storCP}} + \beta \times Cos{t_{vmCP}} + \gamma \times Cos{t_{otherCP}} $

(18)

● 检查点容错技术的响应时间

假设所有在检查点和故障期间被执行的事务在恢复期间都将被重新执行, 系统可用性为avail, 系统执行一个服务需要的时间服从均值为1/μ的指数分布, 故障率为γ ', 事务请求到达率为λ.那么, 根据文献[18], 使用检查点容错技术时的响应时间W_cp可用公式(19)表示.

$ {W_{cp}} = \frac{{\frac{1}{\mu } + avai{l^2}\left( {\gamma {{(\mu \Delta T)}^2} + \frac{{{T_{chk}}^2}}{{\Delta T}}} \right)}}{{avail-\frac{\lambda }{\mu }}} $

(19)

其中, avail=1/(1+μ×ΔT×γ '+T_chk /ΔT), γ '=1-URelia_i(T).

4 容错技术切换开销的计算

为保证提供商的利益, 在生成容错服务时, 需要把时间段间容错技术的切换开销考虑在内.包括不同容错技术间的切换, 以及都使用复制容错技术但是副本个数不同, 或者都使用NVP容错技术但是子程序个数不同的情况.假设在时间段[0, T](简记为T)内使用容错技术M1, 在时间段[T, T+1](简记为T1)内使用容错技术M2, 那么, 在T的末期不仅需要保证M1的正常运行, 还需完成M2所需资源的准备, 但此时, M2所需资源未被使用.因此, 用准备期间M2所用资源的成本开销作为从M1容错技术切换到M2容错技术的切换开销.

用numRepT1表示T1内使用复制容错满足容错需求时所需的副本个数, 同理, numNVPT1表示所需的子程序个数.ΔT_vm表示准备一台虚拟机的时间, ΔT_stor表示准备一个存储单元的时间.perSecdVm表示每台虚拟机每时间单位的开销, 并用公式(20)表示, perSecdStor表示每个存储单元每时间单位的开销, 并用公式(21)表示.

$ perSecdVm = priceVmHour/(60 \times 60) $

(20)

$ perSecdStor = \frac{{\frac{u}{{2\sqrt s }}{n_m}}}{{60 \times 60}} $

(21)

(1) 复制容错技术或NVP容错技术切换到检查点容错技术的开销

因为检查点容错技术需要一台虚拟机和一个存储单元的支持, 所以, 切换开销Cost_toCP可表示为

Cost_toCP=perSecdVm×ΔT_vm+perSecdStor×ΔT_stor.

(2) 检查点容错技术或NVP容错技术切换到复制容错技术的开销

因为在T1内需要numRepT1-1台虚拟机和numRepT1-1个存储单元, 所以, 切换开销Cost_toRep可表示为

Cost_toRep=(perSecdVm×ΔT_vm+perSecdStor×ΔT_stor)×(numRepT1-1).

(3) 检查点容错技术或复制容错技术切换到NVP容错技术的开销

因为在T1内需要numNVPT1-1台虚拟机和numNVPT1-1个存储单元, 所以, 切换开销Cost_toNVP可表示为

Cost_toNVP=(perSecdVm×ΔT_vm+perSecdStor×ΔT_stor)×(numNVPT1-1).

(4) 不同副本个数的复制容错技术间的切换开销

当numRepT1>numRep时, 切换开销Cost_ReptoRep可表示为

Cost_ReptoRep=(perSecdVm×ΔT_vm+perSecdStor×ΔT_stor)×(numRepT1-numRep),

否则, 无切换开销.

(5) 不同子程序个数的NVP容错技术间的切换开销

当numNVPT1>numNVP时, 切换开销Cost_NVPtoNVP可表示为

Cost_NVPtoNVP=(perSecdVm×ΔT_vm+perSecdStor×ΔT_stor)×(numNVPT1-numNVP),

否则, 无切换开销.

5 容错即服务提供方案的最优化求解 5.1 容错服务的描述

用下面的多元组表示云容错服务提供商为服务组件i在时间段[0, T]内提供的容错即服务.

〈Rep_i(T), NVP_i(T), CP_i(T), vFaultResult_i(T), LRelia_i(T), FRelia_i(T), Para_i(T), costRelia_i(T)〉,

其中, Rep_i(T)、NVP_i(T)和CP_i(T)分别表示在T内, 是否为组件i应用复制、NVP或检查点容错技术, 应用时值为1, 否则, 值为0.vFaultResult_i(T)表示是否为组件i提供了数值容错服务, 提供时值为1, 否则值为0.LRelia_i(T)表示组件i的可靠性需求是否在提供容错服务时被降低, 被降低时值为1, 否则, 值为0.FRelia_i(T)表示为组件i应用容错即服务时最终达到的可靠性值, 即若LRelia_i(T)=1, 那么FRelia_i(T)=URelia_i(T)-DRelia_i(T).Para_i(T)表示为组件i提供特定容错服务时相应的容错数据参数, 如若应用复制容错服务, 则给出使用的副本个数; 若应用NVP容错服务, 则给出使用的子程序个数; 若应用检查点容错服务, 则给出设置的检查点间隔.costRelia_i(T)表示在T内, 当组件i被服务的可靠性为FRelia_i(T)时, 组件支付给云容错服务提供商的费用.当组件可靠性没有被降低时, 使用分配给组件i的容错服务带来的总开销(包括容错服务切换开销), 作为组件i支付给供应商的费用.另外, 为了鼓励更多的云应用系统将不重要的组件设置为非关键性组件, 以便当容错服务提供商可利用的云资源不足时, 可通过降低组件可靠性需求, 提供更多的容错服务以提高收益.当组件可靠性被降低时, 使用分配给组件i的容错服务带来的总开销的一部分, 作为组件应该支付给容错服务提供商的费用.本文用w表示组件可靠性被降低后, 组件支付的费用占总开销的比重.下面以时间段T和T1为例, 分别针对支撑容错服务的底层云资源是否足够的场景, 给出可用容错即服务提供方案的最优化求解方法.

5.2 场景1:支撑容错服务的底层云资源足够

在支撑容错服务的底层云资源足够时, 使云容错服务提供商总开销最低的容错即服务提供方法就是最优方案.首先给出本节分析所需的一些变量定义.

(1) rep_Tcheck_T1(i):若在T时间段为组件i提供复制容错服务, 且在T1时间段为组件提供检查点容错服务, 则rep_Tcheck_T1(i)取值为1, 否则, 取值为0.提供其他容错服务时可同理相关定义.

(2) Cost_rep-cp(i):表示在T时间段为组件i提供复制容错服务, 且在T1时间段提供检查点容错服务的成本开销, 计算方法为Cost_rep-cp(i)=Cost_sumRep(T)+Cost_sumCP(T1).提供其他容错服务时可同理计算这类开销变量.

下文使用最优化方法求解最优的容错即服务提供方案.设置Rep_i(T)、NVP_i(T)、CP_i(T)的初值均为1, 后续计算根据服务组件的容错需求得到最适合的一种容错服务.设k=T或T1.因为云容错服务提供商的虚拟机和存储资源足够, 故组件可靠性需求无需被降低, LRelia_i(T)和LRelia_i(T1)的值恒为0, 即求解最优容错服务提供方案应满足条件式(22);因为复制容错和检查点容错不能满足数值容错要求, 故求解方案应满足条件式(23);因为对于任何组件, 如果能够满足该组件对响应时间和数值容错效果的需求, 就应为其提供一种容错服务, 故求解方案应满足条件式(24);因为所提供的容错技术需满足组件对响应时间的要求, 故求解方案应满足条件式(25)~式(27).

$ FReli{a_i}\left( k \right) = UReli{a_i}\left( k \right) $

(22)

$ vFaul{t_i}\left( k \right) \times \left( {Re{p_i}\left( k \right) + C{P_i}\left( k \right)} \right) = 0 $

(23)

$ \left( {Re{p_i}\left( k \right) + NV{P_i}\left( k \right) + C{P_i}\left( k \right)} \right) \times \left( {1--\left( {Re{p_i}\left( k \right) + NV{P_i}\left( k \right) + C{P_i}\left( k \right)} \right)} \right) = 0 $

(24)

$ \left( {{W_{rep}}-R{T_i}\left( k \right)} \right) \times Re{p_i}\left( k \right) \le 0 $

(25)

$ \left( {{W_{NVP}}-R{T_i}\left( k \right)} \right) \times NV{P_i}\left( k \right) \le 0 $

(26)

$ \left( {{W_{cp}}-R{T_i}\left( k \right)} \right) \times C{P_i}\left( k \right) \le 0 $

(27)

通过上述分析, 目标函数定义为云容错服务提供商为所有组件在时间段[0, T]和时间段[T, T+1]内, 提供容错服务的总开销最小.该目标函数可用公式(28)描述.

$ {\rm{MIN}}\left( {\sum\limits_{i = 1}^p {\left( {\sum\limits_{n = 1}^8 {{x_n}} } \right)} } \right) $

(28)

其中, p为请求服务的组件个数, x_n描述了时间段T和T1为组件i提供容错即服务时, 云容错服务提供商的总开销, 具体计算方法见表 1.例如, x₁描述了在T时间段为组件i提供复制容错服务, 且在T1时间段提供检查点容错服务时, 总开销包括复制容错技术和检查点容错技术本身的资源开销及容错服务切换开销的总和.

这样, 满足约束条件式(22)~式(27)并使目标函数最小的解, 就是本场景下在时间段T和T1内, 应为云应用系统中各服务组件提供的最优化容错即服务方案.

5.3 场景2:支撑容错服务的底层云资源不足

当云容错服务提供商用于支撑容错服务的底层云资源不足时, 某些非关键性组件的可靠性允许被降低, 所需的云资源量会有所缓解.此外, 云容错服务提供商可外租虚拟机及存储资源, 重新生成新的容错服务方案, 满足更多组件的容错需求.基于对资源利用灵活性的分析, 本文假设云容错服务供应商在为所有可提供容错服务的组件提供容错服务之前, 外包资源引起的成本低于云容错服务供应商因为外包增加的资源使得能提供更好的容错服务而多得的收益.因此, 在这种场景下, 本文给出的容错即服务提供方法应能保证容错服务提供商在为所有可提供容错服务的组件实施容错服务的条件下, 其开销与因为降低组件可靠性而少收取的费用之和最低.首先给出本节分析所需的一些变量定义.

(1) y_i(T):表示组件i在T内是否被提供容错服务.即若Rep_i(k)+NVP_i(k)+CP_i(k)=0, 则y_i(T)=0, 否则, y_i(T)=1.

(2) numRep'表示组件可靠性被降低并应用复制容错技术时需要的副本的个数.numNVP'表示组件可靠性被降低并应用NVP容错技术时需要的子程序个数.

(3) $C_{vm}^0$表示外租一台虚拟机的价格, $C_s^0$表示外租一个存储单元的价格.outV(T)和outS(T)分别表示在T内外租的虚拟机和存储单元的数量.外租资源引起的费用outFee(T)=$C_{vm}^0$×outV(T)+$C_{s}^0$×outS(T).

(4) preVm_i(T)和postVm_i(T)分别表示组件i在时间段T内的可靠性没有被降低和降低后容错所需的虚拟机数量.其中,

preVm_i(T)=(numRep-1)×Rep_i(T)+(numNVP-1)×NVP_i(T)+1×CP_i(T);

postVm_i(T)=(numRep'-1)×Rep_i(T)+(numNVP'-1)×NVP_i(T)+1×CP_i(T).

(5) preStor_i(T)和postStor_i(T)分别表示组件i在时间段T内的可靠性没有被降低和降低后容错所需的存储单元数量.通过计算数值可知, preStor_i(T)=preVm_i(T); postStor_i(T)=postVm_i(T).

(6) sumLoseFee(T)表示在时间段T内, 因为降低组件i的可靠性而使容错服务提供商少收取的费用, 即

sumLoseFee(T)=costRelia_i(T)×(1-w)×LRelia_i(T)×y_i(T).

(7) Cost_i(T)表示在时间段T内为组件i提供容错服务时的总成本开销, 即

Cost_i(T)=Rep_i(T)×Cost_sumRep(T)+NVP_i(T)×Cost_sumNVP(T)+CP_i(T)×Cost_sumCP(T).

下文使用最优化方法求解最优的容错即服务提供方案.同场景1中的设置, Rep_i(T)、NVP_i(T)、CP_i(T)的初值均为1.设k=T或T1.因为只有非关键性组件才能降低其可靠性, 故求解最优容错服务提供方案应满足条件式(29);因为支撑容错服务而使用的虚拟机数量不能超过容错服务提供商现有的虚拟机数量(可描述为V(T))与外租的虚拟机数量之和, 支撑容错服务而使用的存储单元数量同理, 故求解方案应满足条件式(30)和式(31).此外, 求解最优容错服务提供方案时还应满足前述提到的条件式(23)~式(27).

$ LReli{a_i}\left( k \right) + Criti{c_i}\left( k \right) \le 1 $

(29)

$ \sum\limits_{i = 1}^p {(preV{m_i}(k) \cdot {C_i}(k) + (postV{m_i}(k) \cdot LReli{a_i}(k) + \\preV{m_i}(k) \cdot (1-LReli{a_i}(k))) \cdot (1-{C_i}(k)))} \cdot {y_i}(k) \le v(k) + outV(k) $

(30)

$ \sum\limits_{i = 1}^p {(preSto{r_i}(k) \cdot {C_i}(k) + (postSto{r_i}(k) \cdot LReli{a_i}(k) + \\preSto{r_i}(k) \cdot (1-LReli{a_i}(k))) \cdot (1-{C_i}(k)))} \cdot {y_i}(k) \le s(k) + outS(k) $

(31)

通过上述分析, 目标函数定义为云容错服务提供商为所有组件在时间段[0, T]和时间段[T, T+1]内, 提供容错服务的总开销与因为降低组件可靠性而少收取的费用之和最小.该目标函数可用公式(32)描述.

$ {\rm{MIN}}\left( {\sum\limits_{i = 1}^p {\left( {\sum\limits_{n = 1}^8 {{x_n}} + servedTnonT{1_i}(T) + servedT{\rm{1}}non{T_i}(T)} \right)} + sumLoseFeeTT{\rm{1}}} \right) $

(32)

其中, sumLoseFeeTT1是sumLoseFee(T)和sumLoseFee(T1)之和.servedTnonT1_i(T)表示仅为组件i在时间段T内提供容错服务时的开销.同理, servedT1nonT_i(T1)表示仅在时间段T1内提供容错服务时的开销, 即

servedTnonT1_i(T)=Cost_i(T)×y_i(T)×(1-y_i(T1));

servedT1nonT_i(T1)=Cost_i(T1)×y_i(T1)×(1-y_i(T)).

这样, 满足约束条件式(23)~式(27)以及式(29)~式(31), 并使目标函数最小的解, 就是本场景下在时间段T和T1内, 应为云应用系统中各服务组件提供的最优化容错即服务方案.需要特别说明的是, 若两个相继的时间段内云容错服务提供商的资源出现不足, 如时间段T内资源足够而在时间段T1内资源不足, 那么求解最优方案时使用公式(32)描述目标函数, 且k=T时满足约束条件式(22)~式(27), k=T1时满足约束条件式(23)~式(27)及式(29)~式(31).

6 实验及分析

本文使用CloudSim^[19]建立云应用系统运行的云数据中心, 使用Lingo^[20]求解最优化容错即服务方案.将本文提出的容错服务提供方法(记为非固定容错服务)与预先设置容错技术的容错服务提供方法(记为固定容错服务), 在提供商支付开销、云服务组件支付费用及组件服务质量等方面进行比较.本文将组件个数分别设置为6、9、19和29, 以模拟不同大小规模的云应用系统.下面分别针对支撑容错服务的底层云资源是否足够的两种实验场景, 给出可用容错即服务提供方案的最优化求解过程, 并完成本文所提方法的优势分析.

6.1 实验数据准备

不失一般性, 参照文献[13, 21]完成本实验所需各类数据的设置.将数据中心大小s设置为60TB, 数据中心的调节系数u设置为1.设置组件在[0, 1]时间段请求容错服务; URelia设置为初始可靠性与(0, 0.01)之间的任一随机数的和, 初始可靠性由云应用系统研发者初始确定, 本文将其设置为(0.935, 1)之间的随机数.设置可靠性误差DRelia为(0, 0.01)之间的任一随机数.设置组件响应时间为(0.5, 4.5)之间的随机数.表 2给出了一个具体云应用系统(AID为1)的6个服务组件在[0, 1]时间段的容错需求(注:^{[1, 2]}时间段的组件容错需求设置过程相同).

设置实验中用到的其他参数的数值.根据亚马逊云平台的资源价格, 设置priceVmHour为0.085, 即每小时每台虚拟机的费用为＄0.085;perCostStorage为0.15, 即1G大小的数据每月的存储费用为＄0.15;$C_{vm}^0$为＄0.09;$C_s^0$为＄0.2;T_chk为2s;w为0.9;权重因子均为1.设置costPerInnovation=2×(0.085+0.15/(30×24))/(60×60)≈0.00005.设置λ=6, λ'=0.1, μ=8, c=0.001s, δ=0.00025s, τ_v=0.5s, τ₁=1/μ, τ_j=1/μ+0.005, ΔT_vm=ΔT_stor=1.

6.2 实验场景1:支撑容错服务的底层云资源足够

云容错服务提供商总开销的实验结果如图 1所示; 组件平均支付费用的实验结果如图 2所示.

分析可知, 与固定容错服务模式相比, 非固定容错服务提供模式不但降低了云容错服务供应商的总开销, 还降低了组件平均支付费用.也就是说, 当用于支撑容错服务的云资源足够时, 本文所提方法降低了云应用系统需支付的容错服务费用且云应用系统容错需求得到很好的满足.同时, 支撑容错服务的底层云资源的开销有所下降, 这样, 云容错服务提供商收益更好, 提高了容错服务提供商为多个云应用实施高效、可靠容错即服务的能力.

6.3 实验场景2:支撑容错服务的底层云资源不足

组件平均支付费用的实验结果如图 3所示; 云容错服务提供商因为降低组件可靠性而少收取的费用, 即降低的容错服务质量的实验结果如图 4所示; 云容错服务提供商的总开销实验结果如图 5所示.

分析可知, 与固定容错服务模式相比, 非固定容错服务提供模式不但降低了云容错服务供应商的总开销, 还降低了组件平均支付费用, 同时很好地保障了云应用系统的容错服务质量.也就是说, 当用于支撑容错服务的云资源不足时, 本文所提方法降低了云应用系统需支付的容错服务费用且云应用系统容错需求和容错服务质量得到很好的满足.同时, 支撑容错服务的底层云资源的开销有所下降, 这样, 云容错服务提供商收益更好, 同样提高了容错服务提供商为多个云应用实施高效、可靠容错即服务的能力.

7 结束语

本文应用云环境下容错即服务的新型模式, 提出了一种优化的云容错服务动态提供方法, 云应用系统的容错需求重点从服务组件的可靠性、响应时间及数值容错等方面描述, 以复制、检查点和NVP这3种容错技术为基础, 分别针对支撑容错服务的底层云资源是否足够的场景, 给出可用容错即服务提供方案的最优化求解方法, 且容错服务提供方案重点考虑了容错服务动态切换产生的开销.对不同规模的云应用系统容错实际需求进行实验分析, 结果表明, 与固定容错服务模式相比, 从云容错服务提供商实施云容错服务的角度, 用于支撑容错服务的底层云资源的开销有所下降, 使服务收益更好, 且提高了实施高效、可靠容错即服务的能力; 而从云应用系统容错需求的角度, 降低了云应用系统需支付的容错服务费用且云应用系统容错需求和容错服务质量得到很好的满足.下一步研究中, 一方面将扩展更多容错技术来验证本文所提方法的可用性, 另一方面将尝试在真实云应用系统的容错需求环境中确认本文所提方法的实际执行效果.