CN104951367B

CN104951367B - 一种虚拟化云中容错任务调度方法

Info

Publication number: CN104951367B
Application number: CN201510422524.4A
Authority: CN
Inventors: 朱晓敏; 包卫东; 刘忠; 王吉; 纪浩然; 肖文华; 陈超
Original assignee: National University of Defense Technology
Current assignee: National University of Defense Technology
Priority date: 2015-07-17
Filing date: 2015-07-17
Publication date: 2018-02-16
Anticipated expiration: 2035-07-17
Also published as: CN104951367A

Abstract

本发明公开了一种虚拟化云中容错任务调度方法，其特征在于，获取已到达的依赖任务组信息与虚拟化云的物理主机信息；使用PB模型为依赖任务组中的每个任务建立主版本与副版本；为依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间；在每个被激活的物理主机上划分出多个虚拟机，获取每个被激活的物理主机上的每个虚拟机信息；将依赖任务组中的每个任务的每个版本按照每个被激活的物理主机上的任务分布情况在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中；按照指定的时间安排运行被加载的依赖任务组中的每个任务的每个版本；完成依赖任务组的全部任务并返回任务结果。

Description

一种虚拟化云中容错任务调度方法

技术领域

本发明涉及云计算领域，特别地，涉及一种虚拟化云中容错任务调度方法。

背景技术

由于计算机系统出错的不可预测性，在设计调度算法时加入对容错性的支持至关重要。容错调度算法大体上可以分为两类，即静态容错调度和动态容错调度：静态容错调度在任务提交之前进行调度决策，通常用来调度周期性任务；动态容错调度通常用来调度非周期性任务，其任务到达时间不确定。

目前，在分布式计算环境下主要有两种主要的容错调度手段，即重提交和复制。重提交是指当一个任务所分配的计算节点出现故障后，该任务被重新提交。采用重提交方式将会导致一些任务的完成时间推迟，甚至可能会不满足任务的截止期。复制是指通过将一个任务复制成多个版本，之后把每个复制的版本分配到不同的计算节点，以保证即便在资源出现故障的情况下，任务仍能在截止期前成功完成。任务被复制的版本越多，系统的容错能力越强，但这将不可避免地造成大量的资源消耗。因此，采用两个版本的复制方式，即主版本与副版本模型(primary-backup model，下文中简称为PB模型)成为目前广为采用的容错手段。

为了在保障容错的前提下提高系统可调度性和资源利用率，有不少学者在采用PB模型时研究了如何通过重叠技术减少系统开销。目前主要有两种的重叠模式：副版本-副版本重叠(backup-backup overlapping，简称BB重叠)，即多个不同的副版本可在同一个计算单元上进行重叠；主版本-副版本重叠(primary-backup overlapping，简称PB重叠)，即一个主版本可以和其他任务的副版本在同一个计算单元上重叠。在PB模型中，副版本可进一步分为两种类型，即被动副版本(passive backup)和主动副版本(active backup)。被动副版本只在其对应的主版本不能成功完成时开始执行，如果主版本成功完成，副版本将被撤销。尽管上述方法可以减少资源占用，但不能保证所有的任务可在截止期内完成；相反，主动副版本允许一个任务的主版本和副版本在执行时间上有重叠，采用主动副版本执行方式可以减小任务错失截止期的概率，但同时资源利用率也会随之降低。现有技术中已经存在对实时任务进行重叠处理的技术方案，但这些技术方案并未考虑系统的虚拟化，因此仅适用于传统的分布式系统，并不适合虚拟化云计算环境。

近来，也有一些云中依赖任务调度方面的研究。但是这些工作都没有在调度时考虑系统出错的情况，不能解决云中容错问题。针对现有技术中缺乏云计算环境下容错任务调度方法的问题，目前尚未有有效的解决方案。

发明内容

针对现有技术中缺乏云计算环境下容错任务调度方法的问题，本发明的目的在于提出一种虚拟化云中容错任务调度方法，能够在云计算环境下采用PB模型进行容错任务的调度，提高资源利用率与容错任务的可调度性。

基于上述目的，本发明提供的技术方案如下：

根据本发明的一个方面，提供了一种虚拟化云中容错任务调度方法，包括：

获取已到达的依赖任务组信息与虚拟化云的物理主机信息；

使用PB模型为依赖任务组中的每个任务建立主版本与副版本；

根据依赖任务组信息为依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间；

根据依赖任务组信息激活多个物理主机，并在每个被激活的物理主机上划分出多个虚拟机，获取每个被激活的物理主机上的每个虚拟机信息；

根据依赖任务组中的每个任务的每个版本的最早开始时间与最晚完成时间、以及每个被激活的物理主机上的每个虚拟机信息，将依赖任务组中的每个任务的每个版本按照每个被激活的物理主机上的任务分布情况在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中；

在每个被激活的物理主机上的每个虚拟机中按照指定的时间安排运行被加载的依赖任务组中的每个任务的每个版本；

完成依赖任务组的全部任务并返回任务结果。

其中，依赖任务组信息包括任务集合、任务间关系集合与任务截止期，任务集合记载了依赖任务组中每个任务的大小，任务间关系集合记载了依赖任务组中任意两个任务之间的依赖关系，任务截止期为依赖任务组的最晚完成时间；物理主机信息包括物理主机集合，物理主机集合记载了每个物理主机处理能力的大小；虚拟机信息包括每个被激活的物理主机上的虚拟机集合，虚拟机集合记载了每个虚拟机所在的物理主机以及每个虚拟机处理能力的大小。

并且，使用PB模型为依赖任务组中的每个任务建立主版本与副版本，为在依赖任务组中依次指定每个任务，并为被指定的任务创建一个主版本与一个副版本，其中，同一个任务的主版本与副版本重复进行相同的工作。

并且，多个被激活的物理主机之间存在传输时延；根据依赖任务组信息为依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间包括：

对于任一子任务的主版本，其最早开始时间为其多个父任务中每个父任务的完成时间加上父任务所在物理主机与子任务所在物理主机之间的传输时延之和中的最大值；

对于任一子任务的副版本，其最早开始时间为其多个父任务中每个父任务的完成时间加上父任务所在物理主机与子任务所在物理主机之间的传输时延之和、以及同一任务的主版本任务长度二者的较大值；

对于任一非子任务的主版本，其最早开始时间为该任务的主版本所在物理主机的所在虚拟机为执行该任务的主版本而准备就绪的时间与该任务所在的依赖任务组信息到达时间中的较大值；

对于任一非子任务的副版本，其最早开始时间为该任务的副版本所在物理主机的所在虚拟机为执行该任务的副版本而准备就绪的时间与该任务所在的依赖任务组信息到达时间中的较大值；

对于任一任务的任意版本，其最晚完成时间为该任务的截止时间；

其中，一子任务与一父任务为一依赖任务对，子任务依赖于父任务，子任务必须获得父任务的执行结果才能执行。

同时，将依赖任务组中的每个任务的每个版本按照每个被激活的物理主机上的任务分布情况在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中，为先将依赖任务组中的每个任务的主版本在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中，并使得依赖任务组中的每个任务的主版本尽量均匀的分布在所有主机上；再将依赖任务组中的每个任务的副版本在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中并使得依赖任务组中的每个任务的副版本尽量集中分布到数台副版本分布数量较多的主机上。

并且，将依赖任务组中的每个任务的主版本在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中，并使得依赖任务组中的每个任务的主版本尽量均匀的分布在所有主机上，包括：

选取一个待调度任务的主版本；

将激活主机集合中的所有主机按已被调度主版本数量由小到大排序，分割为多个主机组，并指定已被调度主版本数量最小的主机所在的主机组为候选主机组；

在候选主机组中选取一个虚拟机，使得在该虚拟机上待调度任务的主版本能够在截止期之前被完成，且待调度任务的主版本被完成的时间最早；

若未找到前述虚拟机，则继续指定下一个主机组为候选主机组并选取符合前述条件的虚拟机，直到符合前述条件的虚拟机被找到或所有候选主机组都被指定过；

若所有候选主机组都被指定过但仍未能选取符合前述条件的虚拟机，则调用资源扩展机制增加计算资源以完成待调度任务的主版本；

若调用资源扩展机制增加计算资源后仍不能完成待调度任务的主版本，则将待调度任务的主版本调度到待调度任务的主版本被完成的时间最早的虚拟机上，并返回待调度任务的主版本不能在截止期之前完成的提示信息。

同时，将依赖任务组中的每个任务的副版本在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中并使得依赖任务组中的每个任务的副版本尽量集中分布到数台副版本分布数量较多的主机上，包括：

选取一个待调度任务的副版本；

将激活主机集合中的所有主机按已被调度副版本数量由大到小排序，分割为多个主机组，并指定已被调度副版本数量最小的主机所在的主机组为候选主机组；

在候选主机组中选取一个虚拟机，使得在该虚拟机上待调度任务的副版本能够在截止期之前被完成，且待调度任务的副版本被完成的时间最早；

若所有候选主机组都被指定过但仍未能选取符合前述条件的虚拟机，则调用资源扩展机制增加计算资源以完成待调度任务的副版本；

若调用资源扩展机制增加计算资源后仍不能完成待调度任务的副版本，则将待调度任务的副版本调度到待调度任务的副版本被完成的时间最早的虚拟机上，并返回待调度任务的副版本不能在截止期之前完成的提示信息。

从上面所述可以看出，本发明提供的技术方案通过建立虚拟化云中实时容错模型代替传统的PB模型，建立了一种充分利用空闲资源的容错任务调度方法，提高容错保障下的资源利用率与容错任务的可调度性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为根据本发明实施例的一种虚拟化云中容错任务调度方法流程图；

图2为根据本发明实施例的一种虚拟化云中容错任务调度方法中，强主版本的消息或数据传递关系图；

图3为根据本发明实施例的一种虚拟化云中容错任务调度方法中，弱主版本的消息或数据传递关系图；

图4为根据本发明实施例的一种虚拟化云中容错任务调度方法中，强主版本在第三种情况中、子任务主版本开始时间晚于父任务副版本的结束时间的情况下的消息或数据传递关系图；

图5为根据本发明实施例的一种虚拟化云中容错任务调度方法中，强主版本在第三种情况中、子任务主版本开始时间早于父任务副版本的结束时间的情况下的消息或数据传递关系图；

图6为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的GR-count柱形图；

图7为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的HAT-count柱形图；

图8为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的RTH-count柱形图；

图9为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的GR-intervalTime柱形图；

图10为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的HAT-intervalTime柱形图；

图11为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的RTH-intervalTime柱形图；

图12为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的GR-α柱形图；

图13为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的HAT-α柱形图；

图14为根据本发明实施例的一种虚拟化云中容错任务调度方法中，FASARD与6种基准算法在随机合成依赖任务组上工作时的RTH-α柱形图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进一步进行清楚、完整、详细地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本发明保护的范围。

根据本发明的实施例，提供了一种虚拟化云中容错任务调度方法。

如图1所示，根据本发明实施例的提供的一种虚拟化云中容错任务调度方法包括：

步骤S101，获取已到达的依赖任务组信息与虚拟化云的物理主机信息；

步骤S103，使用PB模型为依赖任务组中的每个任务建立主版本与副版本；

步骤S105，根据依赖任务组信息为依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间；

步骤S107，根据依赖任务组信息激活多个物理主机，并在每个被激活的物理主机上划分出多个虚拟机，获取每个被激活的物理主机上的每个虚拟机信息；

步骤S109，根据依赖任务组中的每个任务的每个版本的最早开始时间与最晚完成时间、以及每个被激活的物理主机上的每个虚拟机信息，将依赖任务组中的每个任务的每个版本按照每个被激活的物理主机上的任务分布情况在指定的时间段上加载到每个被激活的物理主机上的每个虚拟机中；

步骤S111，在每个被激活的物理主机上的每个虚拟机中按照指定的时间安排运行被加载的依赖任务组中的每个任务的每个版本；

步骤S113，完成依赖任务组的全部任务并返回任务结果。

选取一个待调度任务的主版本；

选取一个待调度任务的副版本；

下面根据具体实施例进一步阐述本发明的技术特征。

由于任务到达通常不具有周期性，在本实施例中，我们考虑动态到达的依赖任务。一组依赖任务可以表示为一个有向无环图(Directed Acyclic Graph，下文中简称为DAG)。一个DAG可被定义为G＝{T,E}，其中，T＝{t₁,t₂,…,t_n}表示实时的非周期任务集合，E表示任务间的关系集合。e_ij＝(t_i,t_j)表示任务t_j依赖于任务t_i，即只有t_j获得t_i的执行结果或者消息才能执行。因此，我们称t_i为t_j的父任务，t_j为t_i的子任务。对任一任务t_i∈T，P(t_i)和C(t_i)分别表示任务t_i的父任务集合和子任务结合。表示任务t_i没有父任务，表示任务t_i没有子任务。一个DAG的达到时间和截止期分别表示为a(G)和d(G)。任务t_i可以描述成一个三元组t_i＝(a_i,d_i,s_i)，其中，a_i、d_i和s_i分别表示任务t_i的达到时间、截止期和任务大小。任务t_i的截止期d_i可以通过其所在DAG的截止期d(G)计算得到。任务大小用百万指令数(million instructions，下文中简称为MI)衡量。在PB模型中，对于任一任务t_i∈T，存在两个版本，分别表示为主版本和副版本和被分配到不同的主机上以实现容错。和分别表示主版本的开始时间和完成时间。类似地，和分别表示副版本的开始时间和完成时间。和分别表示和的父任务集合，和分别表示和的子任务集合。

虚拟化云可描述为一个物理主机的无限集合H＝{h₁,h₂,…}。虽然云中的主机数量是无限的，但活动主机的数量是有限的。集合表示云中活动主机集合，H-H_a表示关闭主机集合。对任一主机h_k∈H，其处理能力p_k用每秒百万指令数(million instructionsper second，下文中简称为MIPS)衡量。每个主机h_k上有多个虚拟机，用集合表示，每个虚拟机v_jk∈V_k有不同的处理能力p_jk。对于主机h_k上的虚拟机，其处理能力满足v_jk的就绪时间表示为r_jk。

在一个虚拟化云中，一个主机可以有一个或多个虚拟机在其上运行，因此任务被分配到每个虚拟机而非直接分配到某个主机。我们假设，虚拟机的处理能力具有异构性，即虚拟机可以有不同的处理能力。一个任务的主版本和副版本在这些虚拟机上的执行时间可分别用矩阵E^P和E^B表示，其中元素和分别表示和在虚拟机v_jk上的执行时间。我们用和分别表示任务主版本和副版本与虚拟机v_jk之间的映射关系：如果被分配到虚拟机v_jk上则否则类似地，如果被分配到虚拟机v_jk上则否则和分别表示和所分配到的虚拟机，和则表示和所分配到的主机。因此，意味着意味着

表示和之间的边，其中X,Y∈{P,B}，即可以是也可以是同样，既可以是也可以是对每个边从到的数据或消息传输时间表示为若和具有依赖关系且被分配到同一主机，则此外，令dv_ij表示任务t_i到任务t_j的数据或消息传输量，表示主机到的传输速度，可知其中任务t_j主版本和副版本最早开始时间可分别计算为：

的最晚完成时间由任务的截止期决定，因此有：

的实际开始时间是被调度后开始执行的时间。可以放置在由和限定的空闲时间槽内。我们的调度目标即找到合适的任务开始时间，尽量接受更多的实时DAG，提高系统的吞吐量。

需要特别指出的是，本发明的技术方案所述的错误为针对主机出错，主机出错导致其他层级如虚拟机和应用的中断运行。错误既可以是暂时的也可以是永久的，但各个错误相互独立，一台主机的出错不会影响其他主机。同时，由于两个主机同时出错的概率很小，因此假设在任一时间，至多一台主机出错。一台主机出错后，主版本在该主机上的任务可在另一个主机出错之前由其副版本成功完成。并且，系统中存在一个出错探测机制，可以提供出错信息，新任务不会被调度到已出错的主机上。系统还采用回收机制，即如果主版本成功完成，那么副版本的执行被中断，所占用的资源被回收。

针对多个主机同时失效的情况，该失效模型可以通过下面两个步骤进行扩展。首先，将云中主机分为若干组；之后，在每个组内采用上述错误模型。可通过在各个组内采用本文所提出的容错机制，以解决多主机失效的情况。

下文将给出采用PB模型实现的容错任务调度算法。

为方便分析，我们首先定义强主版本与弱主版本。

定义1，强主版本：对任意一个任务主版本如果其所在的主机不出错，一定可以执行，则称为强主版本。

图2给出了强主版本的一个例子。如图2所示，t_i是t_j的父任务，即t_j必须接收到t_i传来的消息或数据才能开始执行，带箭头的虚线表示从主版本到副版本的消息传递关系及方向。由图2可知，只要所在的主机h₃不出错，就能成功执行，可以收到其父任务传来的消或数据。因此，是一个强主版本。

定义2，弱主版本：对任意一个任务主版本如果其所在的主机不出错，也不一定可以执行，则称为弱主版本。

图3给出了弱主版本的一个例子。如图3所示，假设所在的主机h₁在完成之前出错，那么将执行。但是由于不能接收到传来的消息或数据，尽管所在的主机不出错，仍不能执行。因此，是一个弱主版本。

根据定义1与定义2，我们有如下命题：

命题1，如果以下三种情况中有任意一种成立，则是强主版本：

(1)

(2)t_i∈P(t_j)，

(3)t_i∈P(t_j)，

否则，是弱主版本。

第一种情况可以直接根据定义1推出。第二种情况可根据图2推出。对于第三种情况，图4与图5给出了两个例子，其中主版本被分配到同一主机，副版本被分配到不同的主机。其中，图4为子任务主版本开始时间晚于父任务副版本的结束时间的情况，图5为子任务主版本开始时间早于父任务副版本的结束时间的情况。

从图4与图5中，我们可以发现，不管是否能够收到的消息或数据，都能收到的消息或数据。根据定义1，若主机h₁在完成之前不出错，则一定可以成功执行完成。因此是强主版本。

本实施例提出了一种虚拟化云中实时依赖任务动态容错调度与资源弹性供给策略，被称为FASARD。在FASARD中，当一组依赖任务到达时，该组内的所有任务都会被复制为两个版本，即主版本与副版本。FASARD根据先到先服务(First Come First Service)的规则依次调度各组依赖任务，在调度一个任务时，首先调度该任务的主版本，而后调度其副版本。考虑到一个任务超过截止期并不一定意味着整组任务无法在截止期前完成，当出现一个任务超过截止期时，FASARD尝试调度其子任务让其更早地完成。为了降低算法复杂性，若其子任务也无法在截止期前成功完成，那么系统拒绝该依赖任务组。一旦依赖任务组被拒绝，该任务组内所有已分配的资源都将被收回。

具体地，FASARD的任务调度方法在算法1中以伪代码的形式示出。在算法1中，当一个依赖任务组到达系统时，FASARD首先根据任务组(DAG)的截止期估算各个任务的截止期。当一个任务没有父任务，或者父任务都已被调度时，先调度该任务的主版本，后调度副版本。只有当一个任务的主版本与副版本都被调度到截止期前完成时，该任务才可被视为已成功调度。如果一个任务没有被成功调度，那么系统将重新计算其子任务的最早可能开始时间并使该时间适当提前以消除该任务延时造成的影响。然而，如果其子任务再次超时，则拒绝该依赖任务组，并回收所有已分配的资源。

为了保证任务在截止期前完成，FASARD的主版本调度算法应尝试尽可能早地完成主版本。同时，为了避免一台主机故障导致大量主版本失效，主版本调度算法应尽量将主版本均匀分布在所有活动主机上；另一方面，均匀分布主版本还可以增加PB重叠的可能性，从而提高系统的资源利用率。FASARD的主版本调度算法的步骤伪代码详见算法2。

算法2首先选择主版本数最少的前α％的主机作为候选主机(见1-2行)，接着从候选主机集合中找到一个合适的虚拟机，在该虚拟机上主版本的完成时间最早(见5-12行)。如果在候选主机集合上没有虚拟机能在截止期前完成主版本，那么算法将轮训下一个α％的主机。通过这种方法，一个新的主版本将被优先分配到主版本数量较少的主机上，从而使主版本均匀分布在所有活动主机上。如果没有虚拟机可以在截止前完成主版本，那么算法将调用资源扩展机制，通过增加现有的计算资源来执行该任务。如果该主版本仍然无法在截止前被成功执行，那么算法2将把该主版本调度到完成时间最早的虚拟机上，并返回false表明该主版本不能在截止期前成功完成。

我们知道，弱主版本相比强主版本而言会带来更多的调度约束，因此我们应尽可能得使主版本成为强主版本以降低调度难度。同时，命题1表明，一个主版本成为弱主版本的主要原因是其父任务的副版本无法在该主版本开始前将结果信息传递给它。考虑到这两条因素，我们不使用目前流行的As Late As Possible策略，而是使FASARD尝试尽可能早地完成副版本，从而降低其子任务的主版本成为弱主版本的可能性。此外，本文所提出的算法将尝试将副版本调度到副版本数量较多的主机上，从而形成若干台主要容纳副版本的主机。当系统处于高可靠性状态时，仅有少量主版本失效，大部分副版本将被取消执行，这些主要容纳副版本的主机便可以被及时关闭，以提高系统资源利用率。算法3给出了副版本调度算法的步骤伪代码。

与算法2类似，算法3首先选择副版本数量较多的主机作为候选主机(见1-2行)，然后，在候选主机中找到可以最早完成副版本的虚拟机(见5-12行)。当在现有的虚拟机中没有找到合适的虚拟机时，第18行将调用资源扩展机制。若扩展资源后仍无法完成该任务的副版本，那么21-23行把该副版本调度到完成时间最早的虚拟机上，并返回false值表明该副版本不能在截止期前成功完成。

实验证明，FASARD在随机合成依赖任务组与真实依赖任务组上都具有更好的技术效果。

我们将FASARD与6种基准算法进行比较，包括Non-Overlapping-FASARD(NOFASARD)、Non-VM-Consolidation-FASARD(NCFASARD)、Non-Vertical-Scaling-Up-FASARD(NVUFASARD)、Non-Vertical-Scaling-Down-FASARD(NVUFASARD)、Non-Backward-Shift-FASARD(NBSFASARD)，以及现有技术中的经典的容错调度算法eFRD。

这6种算法的简要描述如下:

NOFASARD：与FASARD的区别在于没有采用重叠技术。二者的比较可以检验重叠技术的有效性。

NCFASARD：与FASARD的区别在于NCFASARD在资源收缩机制中没有虚拟机迁移整合的过程。二者的比较可以检验虚拟机迁移整合收缩的有效性。

NVUFASARD：与FASARD的区别在于NVUFASARD没有采用垂直扩展方式，从而对比检验垂直扩展方式的有效性。

NVDFASARD：与FASARD的区别在于NVDFASARD没有采用垂直收缩方式。二者的比较检验垂直收缩方式的有效性。

NBSFASARD：与FASARD的区别在于NBSFASARD中没有采用任务后移策略，通过对比NBSFASARD与FASARD检验任务后移策略的有效性。

eFRD是一种经典的依赖任务容错调度算法。eFRD采用As Early As Possible策略调度主副版本。然而，该算法不具备动态调整资源规模的能力。

我们采用完成率、主机活动时间与任务时间与主机时间百分比来检验系统的性能。其中，完成率(Guarantee Ratio，GR)表示能成功完成的依赖任务组占所有提交任务组的百分比；主机活动时间(Host Active Time，HAT)表示所有活动主机的总开机时间，该指标反映了系统的资源开销情况；任务时间与主机时间百分比(Ratio of Task time overHosts time，RTH)表示所有任务的执行时间的总和与主机活动时间的比值，该指标反映了系统的资源利用率。

首先，我们进行基于随机合成依赖任务组(DAG)的实验。为保证实验的可重复性，我们采用仿真模拟的方式测试上述算法。在本文的模拟实验中，我们使用了一种在工业界、学术界常用的云平台仿真工具CloudSim。云平台中各参数设置如下:

每台主机的处理能力为1000、1500、2000或3000MIPS，并由1Gbps网络互连；系统中共有四种类型的虚拟机，处理能力分别为250、500、700或1000MIPS；开启一台主机的时间为90s，创建一台虚拟机的时间为15s；依赖任务组按平均到达时间为1/λ的泊松分布到达云系统，1/λ在[1/λ₀,1/λ₀+2]之间均匀分布。依赖任务组的截止期设定为其中表示该依赖任务组可能的最短执行时间，α符合均匀分布U(1.5,2.5)。依赖任务组按下述步骤生产:首先确定依赖任务组中的任务数量N以及依赖关系的数量U，本文实验中假设U＝4N；依赖任务组内各个任务的大小在范围[1×10⁵,2×10⁵]MI内均匀分布；在依赖任务组内不产生环的前提下，随机选定各依赖关系的前驱任务与后继任务，各依赖关系所表示的消息的容量大小在[10,100]MB内均匀分布；根据依赖任务组的截止期计算各任务的截止期。

关于任务组数量对性能的影响方面，图6至图8示出的是FASARD与6种基准算法在随机合成依赖任务组上工作时的算法性能-依赖任务组数量柱形比较图。具体地，图6是GR-count柱形图；图7是HAT-count柱形图；图8是RTH-count柱形图。

从图6可以看出，无论任务组数量如何变化，除eFRD外所有算法均能保持一个较为稳定的完成率。这是由于其他算法充分考虑了云环境下资源规模庞大的特征，可根据任务组数量的变化动态地调整资源规模，而eFRD不具备这种在线调整资源规模的能力，资源规模一定，因此在任务组数量增加时，eFRD的完成率下降。由于NOFASARD没有采用重叠技术，副版本需要消耗更多的资源，所以任务完成率要低于FASARD。此外，我们还可以发现，NBSFASARD的任务完成率同样低于FASARD，这说明任务后移策略可以通过充分利用各个已调度任务之间的空闲时间槽，插入新的任务，从而提高系统的可调度性。值得注意的是，图6表明FASARD与NCFASARD具有相近的较高的任务完成率，对于FASARD这是由于该算法综合采用了重叠、任务后移策略、资源弹性供给等多种策略，有效地提高了系统的可调度性；而对于NCFASARD，则是由于消耗了更多的计算资源。

图7则表明，相比除eFRD外的其他算法，FASARD始终保持一个更低的HAT值，这说明FASARD中采用的各项技术与策略能有效地提高系统的资源利用率。另外，由于没有采用虚拟机整合收缩方法，NCFASARD算法会产生大量空闲资源，所以资源开销最大，特别是随着任务组数量的增加，资源浪费的情况更加明显。此外，我们还可以发现NVUFASARD的资源开销是除NCFASARD以往的第二高，这是由于该算法无法通过垂直扩展方式来容纳新的任务，必须通过水平扩展方式开启更多的虚拟机，而导致主机活动时间明显上升。由于缺少任务后移策略，一些任务无法插入到各个空闲的时间槽内，致使出现资源浪费，NBSFASARD的HAT也较高。随着任务组数量的增加，eFRD的HAT值也出现了一些上升，然而eFRD不具备资源动态调整能力，这种上升只是因为系统运行的时间更长。

在图8中，FASARD有最高的RTH值，即资源利用率最高。这再次说明FASARD中融合的多种技术与策略可以有效地提高系统的资源利用率。NCFASARD由于没有采用资源整合收缩方法，造成了大量资源浪费，而导致RTH值偏低，这表明虚拟机整合收缩对提高资源利用率有重要作用。随着任务组数量的增多，前六种算法均由于接收更多的任务而资源利用率上升。然而，eFRD的RTH值随着任务组数量的增加，先上升后下降，当任务组数量从50增加到100时，更多的任务组可以被系统接收，而由于主机数量固定，主机活动时间仅少量增加，因此RTH值上升，而当任务组数量进一步增加时，由于可接收的任务组数基本保持不变，而系统运行时间增加，导致RTH值下降。

关于任务组到达率对性能的影响方面，图9至图11示出的是FASARD与6种基准算法在随机合成依赖任务组上工作时的算法性能-依赖任务组到达率柱形比较图。具体地，图9是GR-intervalTime柱形图；图10是HAT-intervalTime柱形图；图11是RTH-intervalTime柱形图。其中，参数1/λ₀从以2为步长，从0增加到10。

图9显示前6种算法由于可以动态调整资源规模，因此任务完成率均高于eFRD。随着1/λ₀的增加，前六种算法的完成率均略有增加，这是由于当到达间隔时间较短时，系统负载较重，扩展资源需要主机开机时间、虚拟机创建时间等额外的调整时间，导致大量任务无法在截止前完成而被拒绝。相对应的，当间隔时间边长时，系统有较为充裕的时间进行资源扩展，更多的任务可以在截止期内成功完成。同时，FASARD与NCFASARD有更高的完成率，原因与图6中的类似。从图9还可以看出，由于无法动态扩展资源规模，eFRD的任务完成率较低。

从图10我们可以发现，FASARD始终在前六种算法中保持最低的HAT值，这又一次说明FASARD中所用的各种技术与策略的有效性。当间隔时间变长是，NCFASARD与其他算法之间在资源开销上的差别变得更加明显，这说明缺少虚拟机整合收缩方法会在间隔时间变长时明显导致更多的资源开销。此外，当1/λ₀为0时，NOFASARD的HAT值也较高，这是由于当大量任务组几乎同时涌入系统时，缺乏重叠技术会导致副版本的资源开销显著增大，系统必须通过开启更多的主机才能应对这种过载情况。同时，我们还可以发现，随着间隔时间的增大，由于接收任务数量增多，系统运行时间更长，eFRD的HAT值也略有上升。

图11显示，随着间隔时间的变化，FASARD的RTH值始终保持最高，表明FASARD在不同的任务到达情况下，均能有效地提高系统的资源利用率。而NCFASARD与eFRD的RTH值在4到10之间下降，这是由于NCFASARD没有采用整合收缩方式，eFRD无法动态调整资源规模，因此在系统负载变轻时出现更多的资源浪费，导致资源利用率下降。

关于任务组截止期对性能的影响方面，图12至图14示出的是FASARD与6种基准算法在随机合成依赖任务组上工作时的算法性能-依赖任务组截止期柱形比较图。具体地，图12是GR-α柱形图；图13是HAT-α柱形图；图14是RTH-α柱形图。其中，确定截止期的参数α以0.2为步长，从1.5变化到2.5。

从图12可以看出，截止期对各算法的完成率均有显著的影响。当截止期非常紧张时(如，α＝1.5)，由于系统无法在短时间内完成资源扩展，大多数任务组都被拒绝。然而，当截止期变得宽松时，前6种算法几乎可以接收所有任务组。值得注意的是，当截止期非常紧张时，NVUFASARD的完成率明显低于除eFRD以外的所有算法，这是由于垂直扩展方式可以在短时间内完成计算资源的扩展，响应系统变化的能力更强，我们可以认为，缺乏垂直扩展能力时，系统的可调度性将大大恶化，特别是在任务截止期非常紧张的情况下。此外，由于无法动态调整资源规模，我们再一次发现eFRD的任务完成率最低。

图13显示，随着α的增加，所有算法的HAT值都随之增加。这是由于当α增加时，系统可以接纳更多的任务组，需要更多的主机时间来执行这些任务。值得注意的是，NCFASARD的HAT值的上升速度明显快于其他算啊，这表明当截止期变宽松时，NCFASARD由于无法充分利用已有资源，必须消耗更多的计算资源。此外，NVDFASARD的HAT值仅次于NCFASARD，这是由于当截止期变宽松时，NVDFASARD缺少垂直收缩方式，无法及时缩小闲置的资源，造成了一定的资源浪费。

FASARD的优势在图14中再一次得到展现。当截止期非常紧张时(α＝1.5)，NCFASARD与NVDFASARD同样具有较高的RTH值。这是由于在这种情况下，系统过载，很少会收缩计算资源规模，因此缺少虚拟机整合收缩方法与垂直收缩方式并不会对系统的资源利用率造成很大影响。然而，当截止期变得宽松时，NCFASARD与NVDFASARD的资源利用率明显劣于其他算法。eFRD的RTH值在截止期非常紧张时同样比较高，这是由于系统中几乎所有资源都被使用了，而当截止期变得宽松时，出现闲置的计算资源，RTH值下降。

完成了基于随机合成依赖任务组(DAG)的实验之后，我们进一步进行基于真实依赖任务组的实验。为了检验本文所提出的算法在真实应用下的可行性，我们基于5种真实应用:LIGO，Montage，CyberShake，Epegenomics与SIPHT进一步开展实验。对于每种应用，我们使用Workflow Generator分别生成包含50、100、200和500个任务的不同大小的任务组。对于每种大小的任务组，我们基于真实任务分别生成20组。因此，基于真实应用的任务组共5类，分别有4种任务组大小，又分别有20个实例，共400个依赖任务组。

在基于真实依赖任务组的实验中，假设200个依赖任务组按平均间隔时间为4s的泊松分布达到云系统，任务组截止期的计算方法与上文相似。为反映云系统中任务组的多样性，我们从上述生成的400个依赖任务组中随机选择任务组。

表1基于真实依赖任务组的实验结果

实验结果如表1所示。从表中可以看出，在基于真实依赖任务组的实验中，FASARD的性能同样优于其他算法。与基于随机合成依赖任务组的实验结果相比，本组实验中任务完成率要明显高于前一组实验，特别是FASARD与NCFASARD的完成率接近100％。这是由于真实依赖任务组内的依赖关系约束要明显弱于随机合成任务组，在真实依赖任务组中，存在大量的并行任务，可以通过创建更多的虚拟机并行完成这些任务。然而，eFRD由于缺乏资源动态调整能力，大量的并行任务无法在有限的计算资源上完成，因而完成率要低于随机合成任务组中的完成率。该结果说明，资源动态调整机制是提升真实依赖任务组下可调度性的一种重要机制。

由于真实依赖任务组中，各任务的大小要大于随机合成任务组中任务的大小，该组实验下HAT值高于基于随机合成任务组中的值。可以发现，FASARD在提高系统资源利用率方面同样展示了较好的性能。特别是相比于NCFASARD与NBSFASARD而言，资源利用率分别提升了45.0％与25.5％。这种相比于上组实验更为显著的性能提升同样是由于真实依赖任务组中存在大量的并行任务。为了处理这些并行任务，系统需要创建大量虚拟机，而当这些并行任务完成后，这些虚拟机将闲置，并最终被关闭。对于NVFASARD，由于缺乏虚拟机整合收缩机制，活动主机无法在虚拟机关闭后被及时调整到休眠状态，造成了计算资源浪费；对于NBSFASARD，随着并行任务数量的增加，各个并行任务完成时间上的差异会更加明显，缺少任务后移策略会导致大量已完成任务的虚拟机闲置，等待其他并行任务的完成，而造成计算资源浪费。通过上述实验，我们可以认为，本文所提出的技术、策略与算法可以在真实应用环境下有效地提高系统的可调度性与资源利用率。

综上所述，借助于本发明的上述技术方案，通过建立虚拟化云中实时容错模型代替传统的PB模型，建立了一种充分利用空闲资源的容错任务调度方法，提高了容错保障下的资源利用率与容错任务的可调度性。

所属领域的普通技术人员应当理解：以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种虚拟化云中容错任务调度方法，其特征在于，包括：

获取已到达的依赖任务组信息与虚拟化云的物理主机信息；

使用PB模型为所述依赖任务组中的每个任务建立主版本与副版本；

根据所述依赖任务组信息为所述依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间；

根据所述依赖任务组信息激活多个所述物理主机，并在每个被激活的所述物理主机上划分出多个虚拟机，获取每个被激活的所述物理主机上的每个虚拟机信息；

根据依赖任务组中的每个任务的每个版本的最早开始时间与最晚完成时间、以及每个被激活的所述物理主机上的每个虚拟机信息，将所述依赖任务组中的每个任务的每个版本按照每个被激活的所述物理主机上的任务分布情况在指定的时间段上加载到每个被激活的所述物理主机上的每个虚拟机中；

在每个被激活的所述物理主机上的每个虚拟机中按照指定的时间安排运行被加载的所述依赖任务组中的每个任务的每个版本；

完成依赖任务组的全部任务并返回任务结果；

多个被激活的所述物理主机之间存在传输时延；根据所述依赖任务组信息为所述依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间包括：

对于任一子任务的主版本，其最早开始时间为其多个父任务中每个父任务的完成时间加上所述父任务所在物理主机与子任务所在物理主机之间的传输时延之和中的最大值；

对于任一子任务的副版本，其最早开始时间为其多个父任务中每个父任务的完成时间加上所述父任务所在物理主机与子任务所在物理主机之间的传输时延之和、以及同一任务的主版本任务长度二者的较大值；

其中，一子任务与一父任务为一依赖任务对，所述子任务依赖于所述父任务，所述子任务必须获得所述父任务的执行结果才能执行。

2.根据权利要求1所述的一种虚拟化云中容错任务调度方法，其特征在于：

所述依赖任务组信息包括任务集合、任务间关系集合与任务截止期，所述任务集合记载了所述依赖任务组中每个任务的大小，所述任务间关系集合记载了所述依赖任务组中任意两个任务之间的依赖关系，所述任务截止期为所述依赖任务组的最晚完成时间；

所述物理主机信息包括物理主机集合，所述物理主机集合记载了每个所述物理主机处理能力的大小；

所述虚拟机信息包括每个被激活的所述物理主机上的虚拟机集合，所述虚拟机集合记载了每个所述虚拟机所在的物理主机以及每个所述虚拟机处理能力的大小。

3.根据权利要求2所述的一种虚拟化云中容错任务调度方法，其特征在于，所述使用PB模型为所述依赖任务组中的每个任务建立主版本与副版本，为在所述依赖任务组中依次指定每个任务，并为被指定的任务创建一个主版本与一个副版本，其中，同一个任务的主版本与副版本重复进行相同的工作。

4.根据权利要求3所述的一种虚拟化云中容错任务调度方法，其特征在于，将所述依赖任务组中的每个任务的每个版本按照每个被激活的所述物理主机上的任务分布情况在指定的时间段上加载到每个被激活的所述物理主机上的每个所述虚拟机中，为先将所述依赖任务组中的每个任务的主版本在指定的时间段上加载到每个被激活的所述物理主机上的每个所述虚拟机中，并使得所述依赖任务组中的每个任务的主版本尽量均匀的分布在所有主机上；再将所述依赖任务组中的每个任务的副版本在指定的时间段上加载到每个被激活的所述物理主机上的每个所述虚拟机中并使得所述依赖任务组中的每个任务的副版本尽量集中分布到数台副版本分布数量较多的主机上。

5.根据权利要求4所述的一种虚拟化云中容错任务调度方法，其特征在于，将所述依赖任务组中的每个任务的主版本在指定的时间段上加载到每个被激活的所述物理主机上的每个所述虚拟机中，并使得所述依赖任务组中的每个任务的主版本尽量均匀的分布在所有主机上，包括：

选取一个待调度任务的主版本；

在所述候选主机组中选取一个虚拟机，使得在该虚拟机上所述待调度任务的主版本能够在截止期之前被完成，且所述待调度任务的主版本被完成的时间最早；

若调用资源扩展机制增加计算资源后仍不能完成待调度任务的主版本，则将所述待调度任务的主版本调度到所述待调度任务的主版本被完成的时间最早的虚拟机上，并返回待调度任务的主版本不能在截止期之前完成的提示信息。

6.根据权利要求4所述的一种虚拟化云中容错任务调度方法，其特征在于，将所述依赖任务组中的每个任务的副版本在指定的时间段上加载到每个被激活的所述物理主机上的每个所述虚拟机中并使得所述依赖任务组中的每个任务的副版本尽量集中分布到数台副版本分布数量较多的主机上，包括：

选取一个待调度任务的副版本；

在所述候选主机组中选取一个虚拟机，使得在该虚拟机上所述待调度任务的副版本能够在截止期之前被完成，且所述待调度任务的副版本被完成的时间最早；

若调用资源扩展机制增加计算资源后仍不能完成待调度任务的副版本，则将所述待调度任务的副版本调度到所述待调度任务的副版本被完成的时间最早的虚拟机上，并返回待调度任务的副版本不能在截止期之前完成的提示信息。