CN105005506B - 一种虚拟化云中容错资源供给方法 - Google Patents
一种虚拟化云中容错资源供给方法 Download PDFInfo
- Publication number
- CN105005506B CN105005506B CN201510422309.4A CN201510422309A CN105005506B CN 105005506 B CN105005506 B CN 105005506B CN 201510422309 A CN201510422309 A CN 201510422309A CN 105005506 B CN105005506 B CN 105005506B
- Authority
- CN
- China
- Prior art keywords
- task
- virtual machine
- dependence
- resource
- subedition
- 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
- Hardware Redundancy (AREA)
- Stored Programmes (AREA)
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,完成依赖任务组的全部任务并返回任务结果。
其中,依赖任务组信息包括任务集合、任务间关系集合与任务截止期,任务集合记载了依赖任务组中每个任务的大小,任务间关系集合记载了依赖任务组中任意两个任务之间的依赖关系,任务截止期为依赖任务组的最晚完成时间;物理主机信息包括物理主机集合,物理主机集合记载了每个物理主机处理能力的大小;虚拟机信息包括每个被激活的物理主机上的虚拟机集合,虚拟机集合记载了每个虚拟机所在的物理主机以及每个虚拟机处理能力的大小。
并且,使用PB模型为依赖任务组中的每个任务建立主版本与副版本,为在依赖任务组中依次指定每个任务,并为被指定的任务创建一个主版本与一个副版本,其中,同一个任务的主版本与副版本重复进行相同的工作。
并且,多个被激活的物理主机之间存在传输时延;根据依赖任务组信息为依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间包括:
对于任一子任务的主版本,其最早开始时间为其多个父任务中每个父任务的完成时间加上父任务所在物理主机与子任务所在物理主机之间的传输时延之和中的最大值;
对于任一子任务的副版本,其最早开始时间为其多个父任务中每个父任务的完成时间加上父任务所在物理主机与子任务所在物理主机之间的传输时延之和、以及同一任务的主版本任务长度二者的较大值;
对于任一非子任务的主版本,其最早开始时间为该任务的主版本所在物理主机的所在虚拟机为执行该任务的主版本而准备就绪的时间与该任务所在的依赖任务组信息到达时间中的较大值;
对于任一非子任务的副版本,其最早开始时间为该任务的副版本所在物理主机的所在虚拟机为执行该任务的副版本而准备就绪的时间与该任务所在的依赖任务组信息到达时间中的较大值;
对于任一任务的任意版本,其最晚完成时间为该任务的截止时间;
其中,一子任务与一父任务为一依赖任务对,子任务依赖于父任务,子任务必须获得父任务的执行结果才能执行。
同时,根据计算物理主机的负载情况与实时利用情况使用资源扩展机制与资源收缩机制调节系统的资源利用率中,资源扩展机制包括水平扩展与垂直扩展,资源收缩机制包括水平收缩与垂直收缩;其中,水平扩展为通过创建新的虚拟机增加计算资源规模,垂直扩展为将主机的未启用处理能力分配到该主机的虚拟机上,水平收缩为通过关闭虚拟机降低计算资源规模,垂直收缩为降低虚拟机的处理能力。
并且,资源扩展机制按以下方式运作:
将所有活动主机根据剩余处理能力由大到小排序,并依次指定每个主机;
分别访问主机上的每个虚拟机,获得待分配任务在每个虚拟机上的最早开始时间,并根据待分配任务在每个虚拟机上的最早开始时间计算为完成待分配任务每个虚拟机分别需要的处理能力;
根据指定主机的未启用处理能力大小判断将未启用处理能力分配到虚拟机能否是虚拟机的处理能力足够完成待分配任务,若能则使用垂直扩展将未启用处理能力分配到一个可用的虚拟机上并将待分配任务分配到该虚拟机上;
依次指定每台活动主机直到该任务被成功分配或所有活动主机都被指定过,若所有活动主机都被指定过但该任务仍未被成功分配,则使用水平扩展创建一台新的虚拟机并将待分配任务分配到该虚拟机上;
若使用水平扩展无法创建新的虚拟机,则返回任务分配失败信息。
同时,资源收缩机制按以下方式运作:
指定休眠阈值、关闭阈值、第一空闲时长阈值与第二空闲时长阈值;
当有任务的主版本或副版本被调度到虚拟机上时,或当虚拟机上有副版本因为主版本失效而需要执行时,根据第一空闲时长阈值、第二空闲时长阈值与任务长度,更新休眠阈值与关闭阈值;
当虚拟机连续空闲的时常超过休眠阈值时,将虚拟机的处理能力压缩到最小;
当虚拟机连续空闲的时常超过关闭阈值时,关闭该虚拟机并将占用的处理能力返还主机;
当虚拟机被关闭且所在主机的负载情况与实时利用情况处于较低水平时,关闭该主机并将主机上剩余虚拟机迁移到其他主机上。
并且,当有任务的主版本或副版本被调度到虚拟机上时,或当虚拟机上有副版本因为主版本失效而需要执行时,根据第一空闲时长阈值、第二空闲时长阈值与任务长度,更新休眠阈值与关闭阈值包括:
当有任务的主版本或副版本被调度到虚拟机上时,休眠阈值更新为第一空闲时长阈值与任务的主版本长度之和、与旧休眠阈值两者中的较大值,关闭阈值更新为第二空闲时长阈值与任务的主版本长度之和、与旧关闭阈值两者中的较大值;
当虚拟机上有副版本因为主版本失效而需要执行时,休眠阈值更新为第一空闲时长阈值与任务的副版本长度之和、与旧休眠阈值两者中的较大值,关闭阈值更新为第二空闲时长阈值与任务的副版本长度之和、与旧关闭阈值两者中的较大值。
下面根据具体实施例进一步阐述本发明的技术特征。
由于任务到达通常不具有周期性,在本实施例中,我们考虑动态到达的依赖任务。一组依赖任务可以表示为一个有向无环图(Directed Acyclic Graph,下文中简称为DAG)。一个DAG可被定义为G={T,E},其中,T={t1,t2,…,tn}表示实时的非周期任务集合,E表示任务间的关系集合。eij=(ti,tj)表示任务tj依赖于任务ti,即只有tj获得ti的执行结果或者消息才能执行。因此,我们称ti为tj的父任务,tj为ti的子任务。对任一任务ti∈T,P(ti)和C(ti)分别表示任务ti的父任务集合和子任务结合。表示任务ti没有父任务,表示任务ti没有子任务。一个DAG的达到时间和截止期分别表示为a(G)和d(G)。任务ti可以描述成一个三元组ti=(ai,di,si),其中,ai、di和si分别表示任务ti的达到时间、截止期和任务大小。任务ti的截止期di可以通过其所在DAG的截止期d(G)计算得到。任务大小用百万指令数(million instructions,下文中简称为MI)衡量。在PB模型中,对于任一任务ti∈T,存在两个版本,分别表示为主版本和副版本和被分配到不同的主机上以实现容错。和分别表示主版本的开始时间和完成时间。类似地,和分别表示副版本的开始时间和完成时间。和分别表示和的父任务集合,和分别表示和的子任务集合。
虚拟化云可描述为一个物理主机的无限集合H={h1,h2,…}。虽然云中的主机数量是无限的,但活动主机的数量是有限的。集合表示云中活动主机集合,H-Ha表示关闭主机集合。对任一主机hk∈H,其处理能力pk用每秒百万指令数(million instructionsper second,下文中简称为MIPS)衡量。每个主机hk上有多个虚拟机,用集合表示,每个虚拟机vjk∈Vk有不同的处理能力pjk。对于主机hk上的虚拟机,其处理能力满足vjk的就绪时间表示为rjk。
在一个虚拟化云中,一个主机可以有一个或多个虚拟机在其上运行,因此任务被分配到每个虚拟机而非直接分配到某个主机。我们假设,虚拟机的处理能力具有异构性,即虚拟机可以有不同的处理能力。一个任务的主版本和副版本在这些虚拟机上的执行时间可分别用矩阵EP和EB表示,其中元素和分别表示和在虚拟机vjk上的执行时间。我们用和分别表示任务主版本和副版本与虚拟机vjk之间的映射关系:如果被分配到虚拟机vjk上则否则类似地,如果被分配到虚拟机vjk上则否则 和分别表示和所分配到的虚拟机,和则表示和所分配到的主机。因此,意味着 意味着
表示和之间的边,其中X,Y∈{P,B},即可以是也可以是同样,既可以是也可以是对每个边从到的数据或消息传输时间表示为若和具有依赖关系且被分配到同一主机,则此外,令dvij表示任务ti到任务tj的数据或消息传输量,表示主机到的传输速度,可知其中任务tj主版本和副版本最早开始时间可分别计算为:
的最晚完成时间由任务的截止期决定,因此有:
的实际开始时间是被调度后开始执行的时间。可以放置在由和限定的空闲时间槽内。我们的调度目标即找到合适的任务开始时间,尽量接受更多的实时DAG,提高系统的吞吐量。
需要特别指出的是,本发明的技术方案所述的错误为针对主机出错,主机出错导致其他层级如虚拟机和应用的中断运行。错误既可以是暂时的也可以是永久的,但各个错误相互独立,一台主机的出错不会影响其他主机。同时,由于两个主机同时出错的概率很小,因此假设在任一时间,至多一台主机出错。一台主机出错后,主版本在该主机上的任务可在另一个主机出错之前由其副版本成功完成。并且,系统中存在一个出错探测机制,可以提供出错信息,新任务不会被调度到已出错的主机上。系统还采用回收机制,即如果主版本成功完成,那么副版本的执行被中断,所占用的资源被回收。
针对多个主机同时失效的情况,该失效模型可以通过下面两个步骤进行扩展。首先,将云中主机分为若干组;之后,在每个组内采用上述错误模型。可通过在各个组内采用本文所提出的容错机制,以解决多主机失效的情况。
下文将给出采用PB模型实现的容错资源供给算法。
为方便分析,我们首先定义强主版本与弱主版本。
定义1,强主版本:对任意一个任务主版本如果其所在的主机不出错,一定可以执行,则称为强主版本。
图2给出了强主版本的一个例子。如图2所示,ti是tj的父任务,即tj必须接收到ti传来的消息或数据才能开始执行,带箭头的虚线表示从主版本到副版本的消息传递关系及方向。由图2可知,只要所在的主机h3不出错,就能成功执行,可以收到其父任务传来的消或数据。因此,是一个强主版本。
定义2,弱主版本:对任意一个任务主版本如果其所在的主机不出错,也不一定可以执行,则称为弱主版本。
图3给出了弱主版本的一个例子。如图3所示,假设所在的主机h1在完成之前出错,那么将执行。但是由于不能接收到传来的消息或数据,尽管所在的主机不出错,仍不能执行。因此,是一个弱主版本。
根据定义1与定义2,我们有如下命题:
命题1,如果以下三种情况中有任意一种成立,则是强主版本:
(1)
(2)
(3)
否则,是弱主版本。
第一种情况可以直接根据定义1推出。第二种情况可根据图2推出。对于第三种情况,图4与图5给出了两个例子,其中主版本被分配到同一主机,副版本被分配到不同的主机。其中,图4为子任务主版本开始时间晚于父任务副版本的结束时间的情况,图5为子任务主版本开始时间早于父任务副版本的结束时间的情况。
从图4与图5中,我们可以发现,不管是否能够收到的消息或数据,都能收到的消息或数据。根据定义1,若主机h1在完成之前不出错,则一定可以成功执行完成。因此是强主版本。
本实施例提出了一种虚拟化云中实时依赖任务动态容错调度与资源弹性供给策略,被称为FASARD。在FASARD中,当一组依赖任务到达时,该组内的所有任务都会被复制为两个版本,即主版本与副版本。FASARD根据先到先服务(First Come First Service)的规则依次调度各组依赖任务,在调度一个任务时,首先调度该任务的主版本,而后调度其副版本。考虑到一个任务超过截止期并不一定意味着整组任务无法在截止期前完成,当出现一个任务超过截止期时,FASARD尝试调度其子任务让其更早地完成。为了降低算法复杂性,若其子任务也无法在截止期前成功完成,那么系统拒绝该依赖任务组。一旦依赖任务组被拒绝,该任务组内所有已分配的资源都将被收回。
具体地,FASARD的任务调度方法在算法1中以伪代码的形式示出。在算法1中,当一个依赖任务组到达系统时,FASARD首先根据任务组(DAG)的截止期估算各个任务的截止期。当一个任务没有父任务,或者父任务都已被调度时,先调度该任务的主版本,后调度副版本。只有当一个任务的主版本与副版本都被调度到截止期前完成时,该任务才可被视为已成功调度。如果一个任务没有被成功调度,那么系统将重新计算其子任务的最早可能开始时间并使该时间适当提前以消除该任务延时造成的影响。然而,如果其子任务再次超时,则拒绝该依赖任务组,并回收所有已分配的资源。
弹性是云的一个重要特征。FASARD的资源供给算法具有资源供给弹性,会在系统过载时增加计算资源来容纳任务,也会在系统空闲时缩小计算资源规模以提高资源利用率。
一方面,当系统资源不足,无法在现有的虚拟机上放置一个任务时,系统便会调用资源扩展机制,通过扩大现有虚拟机的处理能力或增加新的虚拟机来容纳该任务。对于任务ti,虚拟机的处理能力pr应满足下式:
esti+si/pr+delay<di (8)
其中,esti是任务ti的最早开始时间,可通过公式(1),(2)计算得到,delay指由于资源调整而产生的时间延迟。如果没有虚拟机满足上式,那么资源扩展机制应尝试扩展计算资源。本文所提出的方法主要以垂直扩展与水平扩展两种方式来实现计算资源的扩展。
水平扩展方式通过创建新的虚拟机来增加计算资源规模。它首先尝试在一台活动主机上创建新的虚拟机,若无法找到合适的活动主机,那么将开启一台新的活动主机来容纳该虚拟机。水平扩展方式是一种简单、有效的扩展计算资源规模的方式,然而创建虚拟机、开启新的活动主机会产生较大的延迟,这对截止期较为紧张的任务而言,往往是不可接受的。在先进的虚拟化技术的支持下,现今各种主流云平台,如OpenStack、CloudStack等,均支持虚拟机处理能力的动态调整,这意味着调整处理能力的延迟相当小,甚至可以忽略不计。为充分这种垂直扩展的优势,我们提出的资源扩展机制中也将包含这种方式。算法2列出的是FASARD的资源供给算法的步骤伪代码。
资源扩展机制将首先采用垂直扩展方式。所有活动主机根据剩余处理能力的大小按降序排序。接着,算法将依次探询主机上的虚拟机,计算任务ti在该虚拟机上最早开始时间,并根据公式(8)计算所需要的处理能力,算法第7行检验主机的剩余处理能力是否足够该虚拟机扩展到所需要的处理能力大小。如果垂直扩展是可行的,那么系统将扩展该虚拟机,并将任务调度到该虚拟机上。如果垂直扩展不可行,那么水平扩展方式将创建一台新的虚拟机(见12-22行)。如果无法通过水平扩展方式创建出合适的虚拟机,那么函数返回false值(见24行)。
另一方面,为了提高系统的资源利用率,当计算资源没有被充分利用时,虚拟机应具备降低处理能力、整合收缩到最少数量主机上的能力,而执行FASARD的资源收缩机制能够达到这一目标。该机制由垂直收缩与水平收缩两种方式组成,前者尝试降低虚拟机的处理能力,后者通过关闭虚拟机来收缩资源规模。当一个虚拟机长时间处于空闲状态时,系统首先将降低其处理能力,而后如果仍然处于空闲状态,该虚拟机将被关闭以提高资源利用率。
通过引入垂直收缩方式,虚拟机的处理能力可以在空闲时收缩到最小以降低资源开销,而当系统负载再次繁忙时,又可以通过垂直扩展方式,在短时间内恢复原有的处理能力,以接收新的任务。通过这种方法,系统可以更灵活地适应负载变化,避免频繁地开启或关闭虚拟机。
本文中,我们对每个虚拟机设定两个时间点Tshrink与Tcancel,当达到该时间点时,虚拟机将被降低处理能力或关闭。设定空闲时长阀值Tidle与T′idle,Tidle>T′idle,则Tshrink与Tcancel按下式更新:
当主版本被调到虚拟机上时,
当副版本被调到虚拟机上时, 如果由于对应主版本失效而需要执行,那么
通过上述方式,若Tidle与T′idle时间内,虚拟机上没有执行任务,那么该虚拟机将被降低处理能力或关闭。此外,由于副版本可能被取消执行,在上述方式下,一个副版本可以被调度到Tshrink或Tcancel之后完成甚至开始执行,从而充分利用虚拟机空闲时间段内的计算能力。算法3列出的是FASARD的资源压缩机制的步骤伪代码。
当虚拟机达到时间点Tshrink时,虚拟机的处理能力被降低到最低Plowest以减少资源开销。若达到时间点Tcancel,那么虚拟机将被关闭,如果该虚拟机关闭后宿主机的资源率低于Ulow,那么系统将尝试将剩余的虚拟机迁移到其他主机上(见8-16行),并关闭主机,以进一步降低资源开销(见19行)。
实验证明,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/λ0,1/λ0+2]之间均匀分布。依赖任务组的截止期设定为其中表示该依赖任务组可能的最短执行时间,α符合均匀分布U(1.5,2.5)。依赖任务组按下述步骤生产:首先确定依赖任务组中的任务数量N以及依赖关系的数量U,本文实验中假设U=4N;依赖任务组内各个任务的大小在范围[1×105,2×105]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/λ0从以2为步长,从0增加到10。
图9显示前6种算法由于可以动态调整资源规模,因此任务完成率均高于eFRD。随着1/λ0的增加,前六种算法的完成率均略有增加,这是由于当到达间隔时间较短时,系统负载较重,扩展资源需要主机开机时间、虚拟机创建时间等额外的调整时间,导致大量任务无法在截止前完成而被拒绝。相对应的,当间隔时间边长时,系统有较为充裕的时间进行资源扩展,更多的任务可以在截止期内成功完成。同时,FASARD与NCFASARD有更高的完成率,原因与图6中的类似。从图9还可以看出,由于无法动态扩展资源规模,eFRD的任务完成率较低。
从图10我们可以发现,FASARD始终在前六种算法中保持最低的HAT值,这又一次说明FASARD中所用的各种技术与策略的有效性。当间隔时间变长是,NCFASARD与其他算法之间在资源开销上的差别变得更加明显,这说明缺少虚拟机整合收缩方法会在间隔时间变长时明显导致更多的资源开销。此外,当1/λ0为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 (7)
1.一种虚拟化云中容错资源供给方法,其特征在于,包括:
获取已到达的依赖任务组信息与虚拟化云的物理主机信息;
使用PB模型为所述依赖任务组中的每个任务建立主版本与副版本;
根据所述依赖任务组信息为所述依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间;
根据所述依赖任务组信息激活多个所述物理主机,并在每个被激活的所述物理主机上划分出多个虚拟机,获取每个被激活的所述物理主机上的每个所述虚拟机信息;
根据依赖任务组中的每个任务的每个版本的最早开始时间与最晚完成时间、以及每个被激活的所述物理主机上的每个所述虚拟机信息,将所述依赖任务组中的每个任务的每个版本在指定的时间段上加载到每个被激活的所述物理主机上的每个所述虚拟机中;采用虚拟化云中实时依赖任务动态容错调度与资源弹性供给策略,根据先到先服务的规则依次调度各组依赖任务,在调度一个任务时,首先调度该任务的主版本,而后调度其副版本;当出现一个任务超过截止期时,尝试调度其子任务让其更早地完成;若其子任务也无法在截止期前成功完成,那么系统拒绝该依赖任务组;一旦依赖任务组被拒绝,该任务组内所有已分配的资源都将被收回;
在每个被激活的所述物理主机上的每个所述虚拟机中按照指定的时间安排运行被加载的所述依赖任务组中的每个任务的每个版本,并根据计算物理主机的负载情况与实时利用情况使用资源扩展机制与资源收缩机制调节系统的资源利用率;完成依赖任务组的全部任务并返回任务结果;
所述资源扩展机制按以下方式运作:
将所有活动主机根据剩余处理能力由大到小排序,并依次指定每个主机;
分别访问主机上的每个虚拟机,获得待分配任务在每个虚拟机上的最早开始时间,并根据待分配任务在每个虚拟机上的最早开始时间计算为完成待分配任务每个虚拟机分别需要的处理能力;
根据指定主机的未启用处理能力大小判断将未启用处理能力分配到虚拟机能否使虚拟机的处理能力足够完成待分配任务,若能则使用垂直扩展将未 启用处理能力分配到一个可用的虚拟机上并将待分配任务分配到该虚拟机上;
依次指定每台活动主机直到该任务被成功分配或所有活动主机都被指定过,若所有活动主机都被指定过但该任务仍未被成功分配,则使用水平扩展创建一台新的虚拟机并将待分配任务分配到该虚拟机上;
若使用水平扩展无法创建新的虚拟机,则返回任务分配失败信息;
所述资源收缩机制包括水平收缩与垂直收缩,所述水平收缩为通过关闭虚拟机降低计算资源规模,所述垂直收缩为降低虚拟机的处理能力;当一个虚拟机长时间处于空闲状态时,系统首先将降低其处理能力,而后如果仍然处于空闲状态,该虚拟机将被关闭以提高资源利用率。
2.根据权利要求1所述的一种虚拟化云中容错资源供给方法,其特征在于:
所述依赖任务组信息包括任务集合、任务间关系集合与任务截止期,所述任务集合记载了所述依赖任务组中每个任务的大小,所述任务间关系集合记载了所述依赖任务组中任意两个任务之间的依赖关系,所述任务截止期为所述依赖任务组的最晚完成时间;
所述物理主机信息包括物理主机集合,所述物理主机集合记载了每个所述物理主机处理能力的大小;
所述虚拟机信息包括每个被激活的所述物理主机上的虚拟机集合,所述虚拟机集合记载了每个所述虚拟机所在的物理主机以及每个所述虚拟机处理能力的大小。
3.根据权利要求2所述的一种虚拟化云中容错资源供给方法,其特征在于,所述使用PB模型为所述依赖任务组中的每个任务建立主版本与副版本,为在所述依赖任务组中依次指定每个任务,并为被指定的任务创建一个主版本与一个副版本,其中,所述同一个任务的主版本与副版本重复进行相同的工作。
4.根据权利要求3所述的一种虚拟化云中容错资源供给方法,其特征在于,多个被激活的所述物理主机之间存在传输时延;根据所述依赖任务组信息为所述依赖任务组中的每个任务的每个版本均指定一个最早开始时间与一个最晚完成时间包括:
对于任一子任务的主版本,其最早开始时间为其多个父任务中每个父任 务的完成时间加上所述父任务所在物理主机与子任务所在物理主机之间的传输时延之和中的最大值;
对于任一子任务的副版本,其最早开始时间为其多个父任务中每个父任务的完成时间加上所述父任务所在物理主机与子任务所在物理主机之间的传输时延之和、以及同一任务的主版本任务长度二者的较大值;
对于任一非子任务的主版本,其最早开始时间为该任务的主版本所在物理主机的所在虚拟机为执行该任务的主版本而准备就绪的时间与该任务所在的依赖任务组信息到达时间中的较大值;
对于任一非子任务的副版本,其最早开始时间为该任务的副版本所在物理主机的所在虚拟机为执行该任务的副版本而准备就绪的时间与该任务所在的依赖任务组信息到达时间中的较大值;
对于任一任务的任意版本,其最晚完成时间为该任务的截止时间;
其中,一子任务与一父任务为一依赖任务对,所述子任务依赖于所述父任务,所述子任务必须获得所述父任务的执行结果才能执行。
5.根据权利要求3所述的一种虚拟化云中容错资源供给方法,其特征在于,根据计算物理主机的负载情况与实时利用情况使用资源扩展机制与资源收缩机制调节系统的资源利用率中,所述资源扩展机制包括水平扩展与垂直扩展;其中,所述水平扩展为通过创建新的虚拟机增加计算资源规模,所述垂直扩展为将主机的未启用处理能力分配到该主机的虚拟机上。
6.根据权利要求5所述的一种虚拟化云中容错资源供给方法,其特征在于,所述资源收缩机制按以下方式运作:
指定休眠阈值、关闭阈值、第一空闲时长阈值与第二空闲时长阈值;
当有任务的主版本或副版本被调度到虚拟机上时,或当虚拟机上有副版本因为主版本失效而需要执行时,根据第一空闲时长阈值、第二空闲时长阈值与任务长度,更新休眠阈值与关闭阈值;
当虚拟机连续空闲的时常超过休眠阈值时,将虚拟机的处理能力压缩到最小;
当虚拟机连续空闲的时常超过关闭阈值时,关闭该虚拟机并将占用的处理能力返还主机;
当虚拟机被关闭且所在主机的负载情况与实时利用情况处于较低水平时,关闭该主机并将主机上剩余虚拟机迁移到其他主机上。
7.根据权利要求6所述的一种虚拟化云中容错资源供给方法,其特征在于,当有任务的主版本或副版本被调度到虚拟机上时,或当虚拟机上有副版本因为主版本失效而需要执行时,根据第一空闲时长阈值、第二空闲时长阈值与任务长度,更新休眠阈值与关闭阈值包括:
当有任务的主版本或副版本被调度到虚拟机上时,所述休眠阈值更新为第一空闲时长阈值与任务的主版本长度之和、与旧休眠阈值两者中的较大值,所述关闭阈值更新为第二空闲时长阈值与任务的主版本长度之和、与旧关闭阈值两者中的较大值;
当虚拟机上有副版本因为主版本失效而需要执行时,所述休眠阈值更新为第一空闲时长阈值与任务的副版本长度之和、与旧休眠阈值两者中的较大值,所述关闭阈值更新为第二空闲时长阈值与任务的副版本长度之和、与旧关闭阈值两者中的较大值。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510422309.4A CN105005506B (zh) | 2015-07-17 | 2015-07-17 | 一种虚拟化云中容错资源供给方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510422309.4A CN105005506B (zh) | 2015-07-17 | 2015-07-17 | 一种虚拟化云中容错资源供给方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN105005506A CN105005506A (zh) | 2015-10-28 |
CN105005506B true CN105005506B (zh) | 2017-11-10 |
Family
ID=54378186
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510422309.4A Active CN105005506B (zh) | 2015-07-17 | 2015-07-17 | 一种虚拟化云中容错资源供给方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN105005506B (zh) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105912383A (zh) * | 2016-05-05 | 2016-08-31 | 中国人民解放军国防科学技术大学 | 一种高可靠性的依赖任务调度与资源配置方法 |
CN108241522B (zh) * | 2016-12-27 | 2022-05-17 | 阿里巴巴集团控股有限公司 | 虚拟化环境中的睡眠状态切换方法、装置及电子设备 |
CN108628708A (zh) * | 2017-03-20 | 2018-10-09 | 中兴通讯股份有限公司 | 云计算容错方法及装置 |
CN108628660B (zh) * | 2017-03-24 | 2021-05-18 | 华为技术有限公司 | 一种虚拟机扩缩容方法及虚拟管理设备 |
CN109981310B (zh) * | 2017-12-27 | 2022-02-11 | 杭州海康威视数字技术股份有限公司 | 资源管理方法、装置及存储介质 |
CN110764896A (zh) * | 2018-07-25 | 2020-02-07 | 北京京东金融科技控股有限公司 | 资源分配方法、系统及计算机系统和计算机可读存储介质 |
CN109062673B (zh) * | 2018-11-14 | 2019-04-05 | 中国人民解放军国防科技大学 | 动态容错弹性调度方法 |
CN114428722A (zh) * | 2020-10-29 | 2022-05-03 | 上海阵量智能科技有限公司 | 硬件仿真方法、装置、设备及存储介质 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102799957A (zh) * | 2012-05-30 | 2012-11-28 | 武汉理工大学 | 一种云计算环境下安全感知的科学工作流调度方法 |
WO2014171810A2 (en) * | 2013-04-16 | 2014-10-23 | Mimos Berhad | A system and method of fault tolerant for distributed applications in a virtualized environment |
CN104536806A (zh) * | 2014-12-26 | 2015-04-22 | 东南大学 | 一种云环境下的工作流应用弹性资源供应方法 |
-
2015
- 2015-07-17 CN CN201510422309.4A patent/CN105005506B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102799957A (zh) * | 2012-05-30 | 2012-11-28 | 武汉理工大学 | 一种云计算环境下安全感知的科学工作流调度方法 |
WO2014171810A2 (en) * | 2013-04-16 | 2014-10-23 | Mimos Berhad | A system and method of fault tolerant for distributed applications in a virtualized environment |
CN104536806A (zh) * | 2014-12-26 | 2015-04-22 | 东南大学 | 一种云环境下的工作流应用弹性资源供应方法 |
Non-Patent Citations (1)
Title |
---|
虚拟化云平台中实时任务容错调度算法研究;王吉等;《通信学报》;20141031;第35卷(第10期);第172-180页 * |
Also Published As
Publication number | Publication date |
---|---|
CN105005506A (zh) | 2015-10-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN105005506B (zh) | 一种虚拟化云中容错资源供给方法 | |
CN104951367B (zh) | 一种虚拟化云中容错任务调度方法 | |
Zhong et al. | A cost-efficient container orchestration strategy in kubernetes-based cloud computing infrastructures with heterogeneous resources | |
CN105912406B (zh) | 一种低能耗的独立任务调度与资源配置方法 | |
CN109885389A (zh) | 一种基于容器的并行深度学习调度训练方法及系统 | |
Baruah | Optimal utilization bounds for the fixed-priority scheduling of periodic task systems on identical multiprocessors | |
CN103064746B (zh) | 基于当前credit进行预测调度的处理器资源精确分配方法 | |
CN103646006B (zh) | 一种处理器的调度方法、装置和系统 | |
CN107291550B (zh) | 一种针对迭代应用的Spark平台资源动态分配方法及系统 | |
CN106528270A (zh) | 一种基于OpenStack云平台的虚拟机自动迁移方法及系统 | |
CN104023042B (zh) | 云平台资源调度方法 | |
CN105373434B (zh) | 资源管理系统及方法 | |
CN106201701A (zh) | 一种带任务重复的工作流调度算法 | |
Zhao et al. | A resource minimizing scheduling algorithm with ensuring the deadline and reliability in heterogeneous systems | |
CN101582043A (zh) | 一种异构计算系统动态任务分配方法 | |
CN105912383A (zh) | 一种高可靠性的依赖任务调度与资源配置方法 | |
CN106959895A (zh) | 快速释放线程的资源调度方法和系统 | |
CN110311965A (zh) | 一种云计算环境下的任务调度方法及系统 | |
CN109510852A (zh) | 灰度发布的方法及装置 | |
Soniya et al. | Dynamic fault tolerant scheduling mechanism for real time tasks in cloud computing | |
CN108900343A (zh) | 基于本地存储的云服务器的资源预测和调度方法 | |
CN108415766A (zh) | 一种渲染任务动态调度方法 | |
CN114911613A (zh) | 一种云际计算环境中跨集群资源高可用调度方法及系统 | |
CN105094971B (zh) | 一种云中基于任务后移的容错任务调度方法 | |
CN112559174A (zh) | 一种区块链并行交易处理方法及装置 |
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 |