网格计算作为一种提供高性能计算、管理和服务的新技术,已经得到了越来越多的关注。而调度是网格计算中基本、关键,也是有挑战性的问题之一,是影响网格计算执行效率的一个关键因素。网格协同设计环境中任务调度同样也是基本、关键的问题,而且由于网格协同设计本身的特点,网格协同设计环境中的任务调度具有特殊性。 资源预留是提高调度效率的一种有效方法。预留资源有利于顺利执行运行时间较长的任务和有Qos要求的任务,可以保证任务在开始执行时获得资源。在网格协同设计过程中,由于任务通常大小不均,其中的某些任务的执行常常成为整个任务执行的关键,而资源预留可以改善这一情况。因此,本文在网格协同设计的任务调度机制中引入了资源预留。
1 网格任务调度模型
网格环境中资源管理结构模型有分层模型、抽象所有者模型、计算市场(经济)模型和混合模型。GMCD框架是以Globus为基础的,而Globus的资源管理结构模型则是层次的。
1.1 网格任务调度的相关组件及功能
在分层的资源管理结构模型中,资源管理与调度是多级的,每个资源有自己的调度子系统,用户只需把作业提交给资源请求代理,而代理后有多少资源提供者,以及该作业分配哪个资源,对于用户来说都是透明的。用户作业在资源请求代理上进行调度,在局部资源管理器上进行二级调度,如果下面存在更多的集群或局域网,则存在三级、四级等多级调度。
在网格任务调度中有两个非常重要的组件,分别是资源请求代理和资源管理器,它们在任务调度过程中分别进行和二级调度。其他与任务调度有关的组件还有网格工作站点以及负责联系的组件。
(1)资源请求代理
它是整个网格的资源管理者,负责接收用户任务,根据其特点发送给域资源管理器,动态监视任务的运行情况,根据需要将结果提交给用户或进行再调度。主要功能有:
①对服务提供方提供注册功能,并对其加入和退出等动作进行控制。
②建立网格资源信息库并周期性地刷新,对全局资源进行统一管理和分配。
③接收用户提交的作业,并根据作业类型和要求形成作业调度参数。
④根据作业调度参数调度作业,分派资源,并随时监视作业的执行情况。
⑤若作业执行有误,则对其进行再调度,保证用户作业的安全运行。
(2)域资源管理器
它是域内资源管理和动态调度的中心,负责本域工作的创建、属性的收集、接收从资源请求代理提交的任务并根据其特点进行处理机的分配。主要功能有:
①监听从本域结点发送来的信息,建立域成员信息资料库并周期性刷新。
②周期性地接收由资源请求代理提交的作业,并判断其可行性,建立本域的任务队列。
③从任务队列中选取作业,根据提交的参数和资源情况合理地分配作业。
④将作业执行情况定时返回给资源请求代理,维持与上级数据库的一致性。
⑤监视各组员执行状况,根据情况进行作业调整(域内调整或再调度)。
⑥确保用户作业的安全运行,将结果通知资源请求代理并直接返还给用户。
(3)网格工作结点
它是任务执行的基本单位,一旦申请加入资源提供方,便由域资源管理器直接调度和由资源请求代理间接调度。主要功能有:
①向上级管理器提出申请,请求加入资源提供方。
②收集本结点的状态和负载信息,并周期性地提交给域资源管理器。
③产生服务进程,随时接收上级管理器提交的任务并执行。
(4)负责联系的组件
①作业提交部分
用户向资源请求代理提交作业任务;资源请求代理根据用户参数将作业转交给域资源管理器;域资源管理器根据各结点负载情况分派作业给合适的资源工作结点,域资源管理器直接将结果返回给用户。
②资源汇报部分
它完成如下任务:网格工作结点向域资源管理器提供各结点的状态和负载情况;域资源管理器将该域的负载信息汇总并送给资源请求代理供查询和管理结点;域资源管理器周期性地刷新资源请求代理中的作业状态;工作结点执行完毕。
1.2 网格任务调度的过程
用户利用提交程序将作业任务和要求的环境属性(如资源类型和数量等)提交给资源请求代理,根据任务性质、通信状况和各资源负载情况进行粗粒度调度,寻求分配方案将作业及参数文件提交给选中的域资源管理器。当任务途中异常中断或执行性能比预期要差时,重新安排其他资源;而当任务完成时,资源请求代理会要求域资源管理器直接将作业结果返还给用户。
2 GMCD中的任务调度机制
由于网格协同设计环境的特殊性,网格协同设计环境中的任务调度模型和通用的网格调度模型相比也具有特殊性。现以GMCD构架为例,讨论网格协同设计中的任务调度机制。
GMCD系统体系结构由底而向可以分为四层,即设计知识单元DKU(Design Knowledge Units)、网格中间件、设计中间件和应用层,如图1所示。
DKU及互联网络组成了GMCD的底层支持结构。DKU是Internet上的具有设计能力的组织或机构,它们在某一类产品或零部件研发上具有先进的设计技术和生产能力。在DKU内部存在设计知识数据库、局域网和设计工具(集)。它们之间通过Internet或专用高速网连通。在设计过程中,各个DKU之间具有平等关系,各自负责所获得任务的运行,相对来说是独立的。
GMCD任务分解分为两层。任务以XML(eXtensible Markup Language)文件形式被提交后,首先会由资源请求代理转交给自称能完成该任务的域,然后在域控制管理器内被首次分解,分解的原则是可执行原则。对于已经进入域控制管理器的任务,应用分解智能体根据知识库内的知识,将其分解为可以被DKU执行的任务。如果被提交的设计任务没有合适的域可以执行,则还要在高层分解之前加入一层手工分解或由资源请求代理分解。域资源管理器和DKU的关系如图2所示。
分解后的任务由域调度器调度到合适的DKU上去执行。GMCD的任务映射分为三个层次。资源请求代理保留了每个域的功能自述副本。然后在域内分解再由域调度器进行二次映射,二次调度的目的是把分解后的子任务映射到合适的DKU上去;在DKU内的调度是第三次映射,这次调度的目的是把解析子任务后得到的底层任务映射到合适的服务器上去。在第二次调度中,由于设计任务的特殊性,一组相似或相关任务通常会在一个时间段内陆续到达。
3 资源预留的引入
资源预留是网格系统中一个十分必要的机制,因为资源预留可以保证任务在开始执行时获得必要的资源,从而提高网格系统的QoS。
网格协同设计任务执行的框架分为三个层次:由底而上依次为资源层、资源管理控制层和应用(用户)层。资源层是可以进行设计的实体DKU或者其他必要的资源,接受资源管理控制层的管理。应用层负责用户任务的提交和结果的反馈。
网格协同设计任务调度系统模型示意图如图3所示。
在图3中,在设计应用层和资源管理器之间省略了一个资源请求代理层。这是因为假定任务已经由资源请求代理指定为由该域完成。当调度系统有预留的需求时,就通过创建预留操作向资源预留请求处理模块提出预留请求。
在该任务调度系统模型中,任务执行流程:用户通过网格门户Portal将任务提交给资源请求代理;资源请求代理将任务分配给可以执行该任务的域,必要时可以先对任务进行分解;在域内任务被分解并被调度到具体的资源上去执行。任务执行的结果由资源逐层向上返回给用户,任务执行的状态监控由资源监控模块负责。
在本文中,分析了网格任务调度模型,基于网格协同设计环境的特殊性,以GMCD为构架,建立了网格协同设计环境中的任务调度模型。
免责声明: 凡注明来源本网的所有作品,均为本网合法拥有版权或有权使用的作品,欢迎转载,注明出处。非本网作品均来自互联网,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。