摘  要： 分析了己有的调度机制和常用的任务调度算法，并在此基础上设计了资源评价模型。将资源评价模型加入调度系统中，资源信息由评价模块进行分析和评价，并提供给任务调度器，实现资源和任务的优化匹配，提高了服务质量（QoS）。
关键词： 云计算；资源评价；模型

　近几年来，随着云计算技术的广泛应用以及电子商务、网络社区、搜索服务等互联网应用的快速发展，人们对网络服务和计算服务的需求迅速增加，对服务质量的要求也在不断提高。在传统的商业模式下，用户为了获取某项服务，需要不断升级硬件设备，本地安装软件、配置程序等。而如今，云计算作为一种新的计算模式，使得用户可以通过任何电子终端或网络浏览器，随时随地按照需要获取服务，而不必考虑基础设施的架构、维护以及服务的实现细节等。云计算正逐渐被商品化，人们付出一定的费用来获取所需的服务[1]，与水、电、煤气及电话服务等类似。由于这种商业特性，用户服务质量的保障受到各大云服务提供商的重视，因而任务调度与资源分配问题也显得格外重要。在己有的任务调度系统中，任务调度模块与资源信息收集模块往往紧密耦合，任务调度的选择对象为所有节点的全部资源信息。任务调度器需要对收集到的所有节点的各类资源信息进行整理，并与任务进行匹配，以选择最适宜的节点进行调度，对资源的评价功能多是集中在中心调度器中。在资源大规模性及动态性强的云计算环境下，这种机制给中心任务调度器带来了很大的压力，影响调度效率，并且对任务执行效率、资源收费策略及系统利用率等缺乏综合考虑。
针对上述特点，作者设计了资源评价模型，并将资源评价模型加入到调度系统中，资源信息由评价模块进行分析和评价，将评价结果提供给任务调度器，实现资源和任务的优化匹配，提高了服务质量（QoS）。
1 模型体系结构
　本模型基于Linux系统的分布式平台上实现，采用无中心分布式管理模式，通过各节点的相互监控实现服务和节点故障的检测，并通过协商进行故障服务的接管。本模型设计结合资源评价的分布式调度模型，不存在中心评价与调度节点，各节点的地位作用是对等的，节点间需相互协商以完成资源评价与任务调度。每个节点都针对任务信息进行本地资源评价，并与其他候选调度节点进行比较及综合评价，找到最优节点，以决定是否将任务由本节点执行。
　模型体系结构如图1所示，具体描述如下：
　（1）节点首先发现任务，作为任务源节点，将任务信息以广播的形式发布在组群中，发起协商。
　（2）组群内所有节点收到协商邀请，收集本地资源信息，针对任务需求进行本地资源评价，从而获得任务分配到该节点的性能评估值，并将本地评估值在组群内广播。
　（3）各参与协商节点收集其他参与节点的本地评价信息，并根据任务调度目标，对包括本节点在内的所有候选调度节点进行综合评价，选出评估值最优的节点；若最优节点为本节点，则将任务在本地执行，否则，放弃本次协商。

2 模型功能与模块划分
2.1 系统功能模块
　本实验室已有的基于Linux的分布式平台，主要提供容错及故障接管功能，通过核心态心跳检测机制进行节点间的监控，接管故障节点，重启失效任务，如图2所示。资源监控模块负责对系统计算资源、存储资源、网络资源以及负载信息的收集；任务监控模块负责对任务的监控，以及对新任务的获取；心跳检测模块是系统进行故障监测的核心模块，它实现在系统核心态，通过定时发布心跳信息进行节点间的相互监控；用户模块接收用户输入参数，以及向用户显示系统状态等；中心控制模块是系统的核心模块，负责系统各模块间的消息传递，根据资源信息、任务信息、用户信息以及故障信息进行任务调度和故障接管等。

　本文重点描述资源评价模型（即处于中心控制模块中），结合任务信息、资源信息及节点故障信息对各节点执行任务的适宜程度进行评估，将评估结果提供给任务调度子模块，作为任务调度的依据。
2.2 评价模块及消息流程
　本模型是针对任务调度的资源评价模型，其核心功能是资源评价，包括本地评价和综合评价。根据功能对资源评价模块进行划分，如图3所示。

　系统采用分布式架构，每个节点都包含相同的模块，采用消息驱动机制。消息包括4种：（1）MSG_TASK表示新任务消息；（2）MSG_HELP表示失效任务接管信息；（3）MSG_ASSESS表示本地评价信息；（4）MSG_FITNESS表示最终评价结果。
　根据消息类型及其携带的不同参数，确定消息的处理方式。消息传递流程如图4所示。任务信息由心跳检测模块通过MSG_HELP消息或任务监控模块通过MSG_TASK消息发布，分别表示失效任务接管和新任务调度。消息形式为（task_id，task_infor），表示任务标识号和任务信息。评价模块收到任务信息，设置该task_id的ITIMER_REAL定时器；本地评价模块执行Self_assess（），并将评价信息通过消息MSG_ASSESS（task_id，node_id，assessment）发送；综合评价模块处理接收到的所有节点的MSG_ASSESS消息，将该评价信息加入到候选节点列表candidate_list中；在定时器到了指定时间后执行Final_ssess（），对包括本节点在内的所有节点进行综合评价；并发送最终评价结果MSG_RESULT（tasKid，result），同时忽略此后收到的该task_id的MSG_ASSESS。主要结构如下。
　receive（message）；
　switch（message.msg--type）
　{  //根据消息类型判断
　Ease MSG_TASK：
　Ease MSG_HELP：
　Sef_assess（）；  //本地评价
　Send_assess（）；  //发送本地评价信息
　Case MSG_ASSESS：
　Addto_candidate_list（）；  //将节点加入候选节点列表
　Final_assess（）；  //综合评价
　Send_result（）；  //发送最终评价结果
　Case MSG_RESULT：
　sched_task（）； //调度模块根据评价结果执行任务调度
　}

2.3 任务信息参数化
　该子模块负责把任务信息进行抽象，得到评价所需的参数化任务描述，需输出的信息包括任务的客观属性和用户的QoS需求。对于任务客观属性信息，可通过任务长度、数据文件大小等抽象出任务对各类资源的需求量Rq以及限制条件。
　任务主观描述信息建立在对用户QoS需求的分析上，而用户往往只能提供定性的需求信息，模型无法将其作为参数直接使用。然而要求用户提供定量的QoS描述不适合云计算这种面向服务的商业计算模式。因此，本模型需要考虑将QoS参数由定性转化为定量描述，本文运用云理论模型[2-3]将用户QoS描述参数化，作为评价模型输入的定量值。
2.4 资源信息参数化
　资源信息参数化主要对本节点资源的属性信息进行抽象和整理。资源信息由资源监控模块提供，包括所有与任务执行性能、时间及费用等相关的因素，可分为静态属性和动态属性信息。资源的静态信息指节点的硬件信息，如计算速度、内存大小、数据存储容量及网络带宽等。资源动态信息需要定时收集，其中包括CPU队列长度、内存使用率、硬盘利用率、网络负载及延迟等。
　本实验室对资源动态监控方面的研究主要实现在基于Linux系统的平台上，使用shell命令虚拟内存统计（vmstat）可以对系统的CPU利用率、虚拟内存使用情况及进程进行监视，统计系统的整体使用情况；此外，使用iostat命令还可以监视磁盘及I/O使用情况。资源的整体状态是动态变化的，上述信息需定时统计，为资源的分析评价提供依据。将收集到的资源信息保存在文件nodeinfor.txt中，并定时更新。
针对本文分布式环境的特点，采用招投标模型的方法进行价格制定和服务协商。任务源节点首先发布招标信息；资源提供者通过对本地资源的评估，提供资源信息和报价，进行投标；使用者根据一定的评价策略选择最适合的资源。
2.5 故障率检测
　系统采用心跳机制实现节点间相互监控，通过定时发送心跳消息检测其他节点的状态，记录各节点的故障信息，从而得到各节点的故障率。本实验室在心跳机制方面己进行了相关研究，为提高心跳检测的实时性，一方面，减少心跳包发送的延迟，将心跳协议实现在Linux系统内核态，使得心跳包的发送不受系统协议栈和应用层任务切换的影响[4-5]；另一方面，减少心跳包传输的延迟，设计并实现了基于实时以太网的心跳协议，通过硬实时通信协议TTEP（Time-Triggered Ethernet Protocol）来保证心跳协议数据包传输的实时性，避免了以太网中数据包拥塞导致的心跳包传输延迟，提高检测的准确率[6]。
2.6 本地评价与综合评价
　本地评价和综合评价是资源评价模块的核心。本地评价模块负责处理MSG_HELP以及MSG_TASK消息，形式为（task_id，task_infor），并执行self_assess（）。结合参数化的资源信息及task_infor计算本地评价值，将消息MSG_ASSESS（task_id，node_id，assessment）进行广播。
　消息MSG_ASSESS由综合评价模块处理，将该节点及其评价信息加入候选节点列表candidate_list中，数据结构为：
struct candidate_list{
int task_id；  //任务标识
struct assess_node list[MAXNODENUM]；
//参与评价的节点列表
}
struct assess_node{  //参与评价的节点信息
int node_id；  //节点标识
double load；  //节点负载
double exe_time；  //节点估计完成时间
double cost；   //所需费用
double stability；   //节点可靠性
}
　为了保证及时评价和调度，责任节点在发布任务信息时设置定时器，给定一个时间间隔。该计数随着实际时间而减少，当时间间隔减为0时，综合评价器执行final_assess（），对候选节点列表中的节点进行综合评价。本模型采用ITIMER_REAL定时器，如下所示：
void init_time（）{  //定时器初始化
struct itimerval value；
value.it_value.tv_sec=1；  //设定执行任务的时间间隔
value.it_value.tv_usec=0；
value.it_interval=value.it_value；  //设定初始时间计数
setitimer（ITIMER_REAL，&value，NULL）；  
//设置计时器ITIMER_REAL
}
void init_sigaction（void）{  //建立信号处理机制
struct sigaction tact；
tact.sa_handler=final_assess；  
//收到信号后执行综合评价函数
tact.sa_flags=0；
sigemptyset（&tact.sa_mask）；  //初始化信号集
sigaction（SIGALRM，&tact，NULL）；
//建立信号处理机制
}
　在发布任务信息时调用ini_time（）函数将定时器初始化，规定时间间隔后定时器发送SIGALRM信号，综合评价函数final_assess（）被触发执行。
　本文对资源评价模型的体系结构进行了详细描述，并介绍了其中的功能和模块划分，以及对每个模块中所采用的关键问题和技术进行了描述并给出了解决办法。资源评价模型主要用于对独立任务的调度，尚存在一些不足和需要改进地方，在以后的研究中将作进一步探讨并改进。
参考文献
[1] RAJKUMAR B， CHEE S Y， VENUGOPALA S， et al.Cloud computing and emerging IT platforms： vision， hype，and reality for delivering computing as the 5th utility[J].Future Generation Computer Systems，2009，25（6）：599-616.
[2] 尹国定，卫红.云计算-实现概念计算的方法[J].东南大学学报，2003，33（4）：502-506.
[3] 胡亮，胡德斌，孙叶萌，等.计算网格中经济模型的应用策略[J].吉林大学学报，2009，47（2）：306-311.
[4] Wang Zhanjie， Li Xiao. A new real-time heartbeat failure detector[C]. 4th International Conference on Wireless Communications， Networking and Mobile Computing， 2008：1-3.
[5] Wang Zhanjie， He Kai， Wang Hailong. A safety-critical peal-time network protocol[C]. 2008 IEEE International Conference on Granular Computing，2008：312-315.
[6] Wang Zhanjie， Chen Wen， Wang Hailong. Improvement on real-time capability of heartbeat mechanism[C]. International Conference on Advanced Measurement and Test， 2010：938-942.