网格体系结构综述

网格体系结构综述（共5篇）

网格体系结构综述 篇1

0 引言

20世纪90年代中期, 在电力网的概念中引申出的“网格 (Grid) ”的出现, 被人们称为第三代互联网, 它为人们提供了信息系统建设的全新视角和体系结构理念。网格是利用互联网把分散在不同地理的异构、动态变化的各种资源包括计算资源、存储资源、带宽资源、软件资源、数据资源、信息资源、知识资源等连成一个逻辑整体, 整合成一台超级计算机, 为用户提供一体化信息和应用服务、虚拟组织, 最终实现资源共享和协同工作, 彻底消除资源“孤岛”。

网格体系结构就是关于如何建造网格的技术描述。它给出了网格的基本组成与功能, 描述了网格各组成部分的关系以及它们集成的方式或方法, 刻画了支持网格有效运转的机制。合理的网格体系结构是建立良好网格的核心, 只有建立合理的网格体系结构, 才能够设计和建造好网格系统, 才能够使网格更加高效更加有效地发挥其作用。

1 网格体系结构

现在主流的网格体系结构主要有三个:第一个是Ian Foster等人在早些时候提出的五层沙漏结构;第二个是在以IBM为代表的工业界的影响下, 考虑到Web技术的发展与影响后, Ian Foster等结合五层沙漏结构和Web Service提出的OGSA (开放网格服务体系结构) ;第三个是由Globus联盟、IBM和HP于2004年初共同提出的WSRF (Web服务资源框架) 。

1.1 五层沙漏体系结构

在五层沙漏体系结构中, 最基本的思想就是:以协议为中心的体系结构, 强调协议在网格资源共享和互操作中的地位, 强调服务与API和SDK等的重要性。五层沙漏结构的设计原则是:

(1) 要保持参与的开销最小, 即较少的核心协议, 提供一些核心服务为基础, 类似于OS内核, 以方便移植。

(2) 沙漏结构管辖多种资源, 允许局部控制。

(3) 可用来构建高层的、特定领域的应用服务, 支持广泛的适应性。

(4) “IP hourglass”model。

五层沙漏结构根据该模型中各组成部分与共享资源的距离, 将对共享资源进行操作、管理和使用的功能分散在五个不同的层次, 越向下层越接近于物理的共享资源;越向上层就更加抽象共享资源的表示, 就不需要关心与底层资源相关的具体实现等问题。

五层体系结构由构造层、连接层、资源层、汇聚层和应用层。如图1所示。沙漏形状是这种结构的一个重要的特点。其内在的含义就是各部分协议的数量是不同的, 对于其最核心的部分, 要能够实现上层各种协议向核心协议的映射, 同时实现核心协议向下层各种协议的映射, 核心协议在所有支持网格计算的地点都应该得到支持, 因此核心协议的数量不应该太多, 这样核心协议就形成了协议层次结构中的一个瓶颈。瓶颈是由资源层和连接层共同组成的, 形成了沙漏形状的结构。沙漏核心的思想和微内核的操作系统进行类比, 即操作系统只实现一些关键的基本功能, 而把大量与特定设备有关和与应用有关的部分来完成。

下面对五层的功能特点分别进行简单描述。

(1) 构造层的基本功能就是控制局部的资源, 包括查询机制 (发现资源的结构和状态等信息) 、控制服务质量的资源管理能力等, 并向上提供访问这些资源的接口。

(2) 连接层的基本功能就是实现相互的通信。它定义了核心的通信和认证协议, 用于网格的网络事务处理。通信协议允许在构造层资源之间交换数据, 要求包括传输、路由、命名等功能。

(3) 资源层的主要功能就是实现对单个资源的共享。资源层是建立在连接层的通信和认证协议之上, 定义的协议包括安全初始化、监视、控制单个资源的共享操作、审计以及付费等。

(4) 汇聚层的主要功能是协调多种资源的共享, 它涉及资源的共性, 而不是资源的具体特征。

(5) 应用层是在虚拟组织环境中存在的, 关心的是如何解决不同虚拟组织的具体问题。每一层都定义了协议, 以提供对相关服务的访问, 这些服务包括资源管理、数据存取、资源发现等。

1.2 开放网格服务体系结构 (OGSA)

开放式网格体系结构 (OGSA) 是一种基于网格服务的分布式交互和计算体系结构, 用来确保异构系统间的互操作性, 使不同类型的系统可以相互通信、共享信息。网格技术和Web Service技术是OGSA包括两大关键技术, 它是在五层沙漏结构的基础上, 结合Web Service技术提出来的, 解决了两个重要问题——标准服务接口的定义和协议的识别。

OGSA最基本的思想就是以“服务”为中心, 在OGSA中一切都是服务。在OGSA框架中, 将一切抽象为服务, 包括各种计算资源、存储资源、网络、程序、数据库等等, 简而言之, 一切都是服务。五层模型的目的是要实现对资源的共享;而在OGSA中则要实现的是对服务的共享。

网格技术 (如Globus软件包) 和Web Service是OGSA的两大支撑技术。①Globus是一种基于社团的、开放结构、开放源码的服务的集合, 也是支持网格和网格应用的软件库。学和工程计算领域广泛接受的网格技术解决方案。②Web Service是一种标准的存取网络应用的框架。XML协议相关的工作是Web Service的基础。Web Service中几个比较重要的协议标准是SOAP、WSDL、WS-Inspection、UDDI。

OGSA符合标准的Web Service框架。Web Service解决了发现和激活永久服务的问题, 但是在网格中有大量的临时服务, 因此OGSA对Web Service进行了扩展, 定义了网格服务的概念, 网格服务是一种Web Service, 该服务提供了一组接口, 这些接口的定义明确并且遵守特定的管理, 解决服务发现、动态服务创建、生命周期管理等问题。简单地说, 网格服务=接口/行为+服务数据。图2是网格服务体系结构的简单描述。

OGSA以服务为中心的网格体系结构具有如下优势:

在OGSA中一切都是服务, 通过一组相对统一的核心接口, 所有的网格服务都基于这些接口实现, 可以很容易地构造出具有层次结构的、更高级别的服务, 这些服务可以跨越不同的抽象层次。

网格的虚拟化可以使得将多个逻辑资源实例映射到相同的物理资源上, 在对服务进行组合时不必考虑具体的实现, 可以底层资源组成为基础, 在虚拟组织中进行资源管理。通过网格服务的虚拟化, 可以将通用的服务语义和行为, 无缝地映射到本地平台的基础设施之上。

1.3 Web服务资源框架

Web服务资源框架 (Web Service Resource Framework, WSRF) 提供了一种利用Web服务建模和访问有状态资源的通用开放框架。WSRF标准包括一套平等, 互操作和有标准组件的规范, 使得定义和实现一个Web服务以及整合管理多种服务变得更加简易化。

引入Web服务资源框架的Web服务规范, 它们通过具体的消息交换和相关的XML定义描述了Web服务资源方法。这些规范使得程序员能够声明和实现Web服务与一个或多个具有名称的类型化状态组件之间的关联集, 这些状态组件称为Web服务资源。它们描述了一些定义Web服务资源以及将Web服务资源与Web服务接口的描述相关联的方式。它们还描述了如何使Web服务资源可以通过Web服务接口进行访问, 并且定义了与资源分组和寻址有关的机制。这个框架提供标准化定义的五个独立规范文档之间的相互关系。这五个文档是:Web服务资源特性、Web服务资源生命周期、Web服务可更新引用、Web服务服务组和Web服务基本故障。

WSRF采用了与网格服务完全不同的定义:资源是有状态的, 服务是无状态的。为了充分兼容现有的W e b服务, WSRF使用WSDL 1.1定义OGSI中的各项能力, 避免对扩展工具的要求, 原有的网格服务已经演变成了Web服务和资文档两部分。WSRF推出的目的在于, 定义出一个通用且开放的架构, 利用Web服务对具有状态属性的资源进行存取并包含描述状态属性的机制, 另外也包含如何将机制延伸至Web服务中的方式。

WSRF是一个服务资源的框架, 一个具有五个技术规范的集合, 它们根据特定的Web服务消息交换和相关的XM定义来定义了Web服务资源方法的标准化描述。在表1中结了这些技术规范。

WSRF规范是针对OGSI规范的主要接口和操作而定义的, 它保留了OGSI中规定的所有基本功能, 只是改变了某语法, 并且使用了不同的术语进行表达。表2给出了从OG to WSRF:重构和演化。

WSRF使Web服务体系结构发生了以下两点演化:提供了传输中立机制来定位Web服务;提供获取已发布服务的信息机制集, 具体的信息包括WSDL描述、XML模式定义和使用这项服务的必要信息。

和OGSA的最初核心规范OGSI相比, WSRF具有以下七个方面的优势:

(1) WSRF使用了不同的结构模型一个状态资源和一个Web服务, 更具有表达性, OGSI采用了同一种结构模型化态资源作为一个Web服务 (支持Grid Service Porttype) 。

(2) WSRF更具有表达性, Many services-to-Many Resources, OGSI的模式在WSRF均可以表达。而在中是One-to-One。

(3) 在OGSI中不能使用现有的Web服务工具, WSRF采用了标准XML Schema, 融入Web服务标准, 在目前的开发环境下, 使其实现更为简单。

确了其目标是允许Web服务操作对状态资源进行管理和操纵。

(5) OGSI中的Factory接口提供了较少的可用功能, 在WSRF中定义了更加通用的WS-Resource Factory模式。

(6) OGSI中的通知接口不支持通常事件系统中要求的和现存的面向消息的中间件所支持的各种功能, WSRF中规范弥补了上述的不足, 从广义角度来理解通知机制, 状态改变通知机制正是建立在常规的Web服务的需求之上。

(7) OGSI在一个定义中, 没有清晰的功能划分, 以支持增量的发展;WSRF将OGSI v1.0功能分成一个可合成定义的家族, 明确具体任务中所需的组件, 在WSRF中通过将功能进行分离, 使之简化并拓展了组合的伸缩性。OGSI中太多的“面向对象”, WSRF将服务和服务操作的状态资源明确区分开。

对于WSRF而言, 其规范还需在实践中逐步丰富完善。基于OGSA和WSRF的服务网格平台和规范协议, 将最终成为下一代互联网的基础设施, 所有的应用都将在网格的基础平台上得以实施。当然也有一些非主流网格体系结构, 如基于代理的网格体系结构、基于对象模型的网格体系结构等。

2 结束语

网格体系结构是网格的骨架和灵魂, 是网格技术中最核心的部分。本文通过对三种主流网格体系结构的讲述, 有利于建立一个网格的整体性认识, 有利于更好地把握网格的核心技术和整体特征, 它对设计和开发高效实用的网格系统提供基础。随着时间的推移, 网格体系结构和网格技术会更加成熟和发展。

参考文献

[1]网格体系结构概述.http://www.ibm.com/developerworks/cn/grid/gr-fann.2006.

[2]都志辉, 陈渝, 刘鹏.网格计算[M].北京:清华大学.2002.

[3] (美) Ian Foster, Carl Kesselman The Grid2:Blueprint for a New Computing Infrastructure Morgan Kaufmann.2006.

[4]刘鼎鼎.网格体系结构及其Portal应用研究[J].电子科技大学.2006.1.

[5]桂小林.网格技术导论[M].北京:北京邮电大学出版社.2006.

[6]赵念强, 鞠时光.网格计算及网格体系结构研究综述[J].计算机工程与设计.2006.

[7]Next-generation Grids:requirements and knowledge-based ser-vices Concurrency and[7]Computation:Practice&Experience.2006.

网格资源模型综述 篇2

随着互联网技术的快速发展和广泛应用,对广域分布的资源之间的共享和协同需求不断增加,网格技术已成为近年来分布式技术领域的一个研究热点。网格具有资源分布广、资源间的连接需要通过广域网连接、资源类型和数量巨大,而且要求协同工作等特点。因此,需要对网格计算中的资源建立模型,主要的研究内容包括对网格环境中的计算资源进行有效地描述、组织和管理,使用户可以高效地为计算任务寻找合适的资源。

在资源描述方面,资源描述框架RDF(Resource Description Framework)[1]是W3C推荐的用于描述网络资源元数据的模型。凡是被RDF描述的事物都叫资源,一个RDF文件包含多个资源描述,每个资源描述是由资源、属性值、属性构成的三元组语句构成。RDF具有通用性、智能准确性和独立性等特点,它的通用性使得数据的共享能提供更大的价值。RSL(Resource Specification Language)[2]是Globus用于描述资源的通用的可交换的语言,它提供了一个框架性的语法描述,可用来组成复杂的资源描述。RSL语法的核心是关系,关系由属性名和它的值组成,它提供了在资源请求中可执行元素的名字。在RSL可描述更复杂的资源,而且它的语法提供便利引入并且废除了字符串变量。WSDL(Web Service Description Language)[3]是Web Service发展过程中提出的服务描述语言,并由W3C做了标准化,并且用XML文档来描述。WSDL可以描述复杂的资源,具有良好的可扩展性,技术比较成熟,并且已经是一个工业标准,但在互操作性、可用性、安全性等方面有待完善。

2资源模型和资源发现机制

资源模型的重点是要建立一种不依赖集中控制的、分布式、可扩展、能适应资源动态变化并且定位性能好的资源发现机制,本章主要介绍当前主要的一些资源发现机制。

2.1基于资源路由的发现机制

织女星网格操作系统是中国国家网格系统软件核心部分,作为国内大型网格系统,非常具有典型性。从技术水平上讲,在网格软件体系结构、编程环境、安全、数据管理、资源定位与路由方面具有自己的特色,并已经在中国国家网格中完成安装和部署,成功运行了多个网格应用。

织女星网格采用的是基于资源路由的发现机制[4,5],它用于资源表示的EVP模型包括三个层次:有效资源层(E)、虚拟资源层(V)和物理资源层(P)。资源的最终使用发生在物理层,虚拟层主要解决全局一体的问题,有效层主要解决好用性的问题。有效资源空间采用单用户多资源的模式,虚拟资源空间支持多用户多资源,资源空间支持多用户单资源。由于EVP模型是具有一般性的抽象模型,在应用时需将其具体化。

在用户层中,考虑“通用服务”的原则,网格中部署的资源以及使用这些资源的应用程序在资源的表示方式上可能不尽相同,在用户层部署一个统一的命名空间是难以实现的,因此资源发现机制允许不同的应用使用不同的资源请求表示方式,但这也使得给出一个用户层资源表示的一般视图变得很困难。同时有必要将用户层资源表示与路由器层表示分离,将资源表示转换为一种全局一致的表示方式,用于路由器层。在实际应用中,用户层资源往往是由某种规范来描述的,如RDF和WSDL。如果理解规范的含义,就可以在用户层本地完成对请求描述的转换,并保证转换的结果在传到设备端时仍然是有效的。在织女星网格中,要支持某一特定资源表示方式的虚拟设备提供者,应实现针对该方式的用户层表示到路由器层表示转换的解析器。此解析器,作为该虚拟设备驱动程序的一部分,部署在网格客户端设备。解析器将用户层的资源描述转换成了该类资源状态空间的一个点或子空间,同时避开了远程解析可能造成的瓶颈,有助于提高资源定位的效率。

在路由器层,资源按其提供服务的类型别分类,每类资源都有属于本分类的表示格式。路由器层提供了一个简单的模板规范,利用该规范提供的语法,每类资源可以定义各自的模板,每一个资源在路由器层的信息都是自己所在分类的模板的一个实例。

在物理层上,资源的表示应包含物理访问的位置信息,使用Internet中现有的资源定位方式,如URL和IP地址加端口号的形式可以很好的满足这一需求。提供相同服务的资源,尽管其内部可能是异构的,但都应以统一的服务接口封装,并且以一致的格式向资源路由器报告状态信息。所有的资源提供者和用户都通过连接到某个路由器来加入织女星网格,而通过路由器之间的互联,也可以实现网格的动态扩展,所有的路由器在逻辑上是平等的。为适应网格中结点、资源自主控制和动态变化的特点,资源路由器在运行时,需要有动态改变拓扑的能力。为此,资源路由器上运行了一个包含注册、定时更新、超时探测、注销及相应的应答报文的协议。

2.2超拓扑空间模型

网格资源的超拓扑空间模型(Resource Model Based on Hyper Topology Space,RMHTS)是从超拓扑空间角度审视网格资源模型的内在机理与结构[6],研究如何描述资源、抽象资源以及提供单一系统映像,利用其所提供的聚类方法能够自动实现各种异构资源的统一描述和访问,同时允许资源自由地加入或退出网格环境。

从整体上看, 它是一个超拓扑空间,RMHTS资源模型分为三层,,即:特征信息层、特征处理层和功能层。各层有着不同的组织形式与拓扑结构, 并且进一步可细分为若干亚层。各层功能如下:

(1)特征信息层

含有网格资源的全部信息,这些信息用超结点予以表示,一个结点只表示独立使用的单个资源的相应信息。因此该层实际上是一个信息空间,然而这里的信息不是普通的信息,而是一种特征信息。信息空间能够根据网格的实际情况来构建,包括资源的特征信息和资源间的相互连接。然而,该空间是无序的,没有统一映像,难于使用。因此有必要提出一种特殊有序化的空间形式——超拓扑空间来改变这种随机的空间结构。

(2)特征处理层

特征信息元素的集族——信息空间形成了一个原始的拓扑结构,而在该原始拓扑结构基础上建立起来的第二层拓扑结构,是以信息空间上的所有子集做成的集族而形成的拓扑结构,这就是特征处理层。超拓扑空间使信息空间的内在结构发生质变后的高级组织形式,脱离了原信息空间中各个信息元素或子空间之间毫不相关、互相独立存在的那种初级随机组合形式,而使得整个信息空间内部的元素组成一个统一的有机整体,并使得这个整体内部在高级层次上产生出新的重要性质。在一个信息空间中,如果用超拓扑结构中的某种关系来分解这个空间的话,依据这种关系可以将整个空间划分成若干相关等价关系,而由某个拓扑等价关系所确定的等价类集合所对应的那个空间族,叫做由这个等价关系所定义而产生的商空间。在不同的拓扑等价关系映射下可以产生不同的商空间结构。生成商空间后,会产生新的高阶的空间结构,这种结构会将原来系统中隐藏的特性显露出来。利用这种拓扑相关等价关系,将信息空间进行分解,然后重新组合和排序,就会产生一种新的有序化的拓扑结构形式:按等价类排序后的商空间的拓扑结构形式。这种重新有序化的聚合过程,乘坐信息空间的聚类反应。其规律是:同类自动相聚。

(3)功能层

该层位于模型三层结构的顶层,是各种应用的用户接口,如同网格服务。应用的所有资源需求都可以在这里得到满足。并且这一层提供了统一的服务,屏蔽了资源之间的异构特性。应用执行时,用户不必再考虑资源选择的琐碎细节。一般而言,功能层的最终服务将被聚合为三种:Human(人力)、information(信息)、artificial object(人工事物),从而实现了顶层资源的统一划分。

2.3网格和P2P混合模型

网格和P2P(Peer to Peer)是当前分布式领域的两个研究热点,它们有共同的目标:共享和协同分布在网络中的硬件和软件资源。现阶段的网格系统实现还是以C/S结构为主,资源发现主要是基于集中或分层模型进行,存在单点故障问题,扩展性不强。网格与P2P混合模型可以很好的解决单点故障、资源搜索等问题,同时增强网格的可扩展性[7]。

如图1所示,模型分为网格层和P2P层两层。下层的P2P资源被视为一种虚拟的网格资源,网格服务可以作为下层P2P资源的一个包装器或者作为普通网格服务进入下层P2P网络的一个入口,这样可利用P2P层的资源在网格层映射一个网格服务。总的来说,网格层负责提供服务,并且是调度者和管理者,而P2P层主要作为一个资源池并且在底层提供资源的发现和聚集。

由于OGSA/OGSI和GT3已经成熟,在模型中采用GT3作为网格服务架构平台。对于P2P层,选择使用JXTA开发平台。JXTA是一个具有一组支持P2P应用程序标准的框架,致力于提供一个基本的P2P架构。这个框架包含一套协议,这些协议与语言、平台、网络都是无关的。

网格层主要以网格服务的形式存在,为用户应用程提供访问接口,网格节点之间通过SOAP(Simple Object Access Protocol)协议通信。P2P层主要有结点控制器和网格服务包装器两个模块。结点控制器将一个网格结点映射成P2P层的一个结点,并且这个结点能够和P2P结点共同组建P2P网络,在P2P层映射的所有网格结点使用P2P通信技术。网格服务包装器将P2P的PC资源通过包装虚拟化为一个网格服务,用户可以通过这个虚拟的网格服务接口直接使用P2P资源,这样普通的PC就可以在没有安装网格中间件软件包的情况下为上层提供网格资源,解决了当前情况下普通PC不能安装复杂的网格中间件问题。

混合模型的一种实现方式是在每个自治资源域中运行着一个匹配引擎,各个匹配引擎连接形成P2P覆盖网络,每个节点或用户都通过所在域的匹配引擎来发现整个网格环境中的资源[8],模型框架如图2所示。匹配引擎是运行在自治管理域中某个超级节点上的一种服务,负责本域内以及跨域间的资源发现任务。对于用户发来的每个资源请求,匹配引擎会先从本域内搜索,如果找不到合适的资源,则会将请求转发到最佳邻居匹配引擎上,继续这个搜索过程。通过将匹配引擎组织成P2P网络,分散了资源发现请求,不再需要昂贵的高性能服务器,具有P2P搜索技术所带来的可扩展性、健壮性、负载均衡等优点,提高网格资源发现服务对资源变化和网络结构变化的适应能力,适用于大规模动态自治的网格环境。

2.4基于网格距离的资源模型

Ma等还提出了基于网格距离的资源模型[9],该模型将网格资源分成2类:系统资源和网络资源,网络资源是用来传输数据,除此以外的所有资源统称为系统资源,系统资源为任务实现具体的功能。

系统资源从属于一个节点,一个节点可以向网格提供多个资源。资源可以用系统资源所属节点作为顶点,网络资源作为边的无向图表示其状态。同样,应用可以用其所包含的若干任务作为顶点,两个任务之间的通信需求作为边的无向图表示其状态。在这个模型下,资源的调度就体现为一个从任务图到资源图的映射函数。

基于网格距离的优化算法即是在任务k的候选系统资源集合中选择与任务所在节点间网格距离函数值最小的那一个。实验证明,在资源调度中,网格距离达到了选择距离较近、费用较低的资源,有利于提高整个网格资源调度的性能,在任务的完成上也表现出较好的特性,能够达到调度优化的目的。

3结束语

网格环境中的资源模型与资源发现机制,是一个具有重要理论研究价值和广泛的实际应用背景的课题。它涉及到资源的查找的调度,好的资源模型能够对用户屏蔽资源的位置等物理信息,并且具有较好的定位性能和可扩展性,能够适应网格资源自主控制、动态变化的特点,可以较方便地解决请求转发的负载平衡问题,使得互联网中的管理者、运营者和使用者都能够获益。

参考文献

[1]Resource Description Framework.http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.

[2]The Globus Resource Specification Language RSL v1.0.http://www.globus.org/toolkit/docs/2.4/gram/rsl-spec1.html.

[3]W3C.Web Service Description Language(WSDL)1.1.http://www.w3.org/TR/wsdl.

[4]李伟,徐志伟.一种网格资源空间模型及其应用.计算机研究与发展.2003,40(12):1756-1762

[5]董方鹏,龚奕利,李伟,查礼.网格环境中资源发现机制的研究.计算机研究与发展.2003,40(12):1749-1755

[6]鲁斌.网格资源的超拓扑空间模型.计算机工程与应用.2006(29):133-135,150

[7]左东石,孙龙清.网格与P2P计算混合模型研究.微计算机信息,2006,22(12-3):126-128

[8]刘扬,何华灿.基于匹配引擎覆盖网络的网格资源发现模型.计算机工程,2008,24(2):154-156,180

网格编程方法与环境综述 篇3

当今, 网格[1,2]作为新一代的基础设施已经引起了极为广泛的关注, 关于网格理论方面的研究也越来越丰富, 然而, 对于网格应用的开发却相对滞后。产生这种现象的原因是什么呢?我们认为主要有两个方面:一是由于网格不同于传统的高性能设施, 它具有动态性和异构性, 而多数人对网格的这一特点认识不足;二是不熟悉网格的编程环境及其相关技术。这就使得网格应用的开发成为一件很困难的事, 同时也给网格编程带来了一些独特的挑战, 从很大程度上阻碍了网格技术的普及和发展。

网格是一个集成的计算与资源环境, 或者说一个计算资源池, 也被称为虚拟分布式计算环境, 因此大部分的编程的方法和工具都是从并行分布式环境下移植过来。众所周知, 目前在并行机或分布式集群上设计并行分布式应用都仍然是件很耗时的工作, 而网格本身所固有的动态性和异构性, 这就使得在网格上编程变的更为复杂[3,4]。如果没有良好的编程环境, 网格编程的工作将是相当枯燥和乏味的, 而且容易导致错误。目前的研究只是从不同角度、针对不同问题来探讨网格编程, 欠缺统一、系统和完整的认识, 与实际应用还有较大距离, 大量的问题尚未解决, 大量的新问题尚待发现, 大量的新应用尚待开发。因此, 网格编程的研究对网格的普及具有相当重要的意义的。

本文下面的部分剖析了目前网格编程领域最具代表性的方法和支撑工具项目, 如RPC的中间件 (NetSolve[5,6]和Ninf-G[7,8]) 、Ibis[9]、及基于skeleton的ASSIST[10,11,12,13,14]等等, 并从性能、可移植性、编程语言、扩展性和编程语言等方面对它们做了评价, 文章最后做了总结, 并分析了网格编程的发展趋势和未来的进一步研究方向。

1 网格编程方法和工具

网格编程必须既能支持面向服务的新型应用的开发, 又能集成各种遗留软件、数据和应用系统, 开发出的网格应用还需要能给用户提供灵活方便的工作界面和使用环境。下面将基于抽象的层次介绍目前流行的网格编程的各种方法与支撑工具。

1.1 消息传递方式 (MPI)

MPI (MessagePassingInterface) [15,16]模型, 通常使用c/c++或Fortran加MPI的方式进行网格编程, 主要有两种基于网格的消息传递接口的实现:MPICH-G 2[17,18]和PACX-MPI[19,20]。

MPICH-G 2是基于MPI和Globus[21,22]工具包的实现, 从Globus中获得服务。MPICH-G 2结合了Globus的资源发现、资源分配、运行管理、安全验证等功能, 但它的通信效率更高, 加强了对服务质量的控制, 提供了与MPI完全一致的并行编程界面。使用Globus提供的服务启动和管理远程的进程, 对编程人员隐藏了异构性, 并通过自动选择本地或远程系统间消息传递协议来达到良好的异构通讯性能。

PACX-MPI (Parallel Computer eXtension) 是HLRS的一个基于网格MPI的优化实现的开源项目, 它使用完全独立的通信层来处理完成本地发出内部或外部的MPI调用, 优化了与远程进程间的通信。PACX-MPI被广泛应用于DAMIEN[23], METO-DIS[24]和UNICORE+[25]项目中。

但是消息传递的编程方式并没有提供专门的网格编程语言, 仅仅提供了网格中通信和同步的支持, 程序员仍需使用支撑语言直接去描述任务分解、负载平衡、数据的分布和延迟等问题, 再加上网格资源地理上的分布性等, 这些都会给程序员带来严重的编程负担。

此外, 对追求高性能的用户来说, MPI不能自动进行性能优化, 随着问题规模的增长, 手工优化的难度将逐渐增加, 因此消息传递的编程方式并没有真正解决网格计算的挑战。IanFoster在文献[26]已经指出使用这种“英雄式的行为”方式进行网格编程是困难的, 并且容易导致错误, 不仅编写出来的程序不具有可靠性, 安全性, 是相当脆弱的, 而且开发的成本也相当高, 不适合大型的网格编程。

1.2 网格移动程度通信 (GridRPC)

GridRPC (RemoteProcedureCall) [27,28]是基于C/S结构的远程通信中间件, 使用一些基本的Grid RPCAPI来实现访问远程网格节点上的库和任务并行编程模式[27,28]。NetSolve和Ninf-G是两种已经实现了基于GridRPC的网格计算系统, 无论是在设计方法还是在设计的目的上两者都很相似, 都是面向科学工程计算。

NetSolve是为了解决在集群和分布式环境下的科学计算, 给程序员提供一个简单、友好的编程接口和桌面科学计算的无缝集成, 使其能很容易的访问和获得资源。它的通信模型比较简单:所有计算放都在服务器端进行, 服务器和客户端之间增加了一个代理 (agent) 进行连接, 客户端通过agent向远程请求服务, agent选择服务器, 服务器计算完成后返回给客户端。如图1所示。

NetSolve向用户提供了便于科学数值计算的API接口, 包括系统提供的和自定义的函数库, 所有的接口使用Fortran、C/C++和Matlab等设计与实现。

NetSolve已经成功应用在了集群和分布式环境下的IPARS (Integrated ParallelAccurateReservoir Simulators) 和MCell (MonteCarlosimulatorofcellularmicrophysiology) 等项目上, 目前也正在进行对NSF的PACI和其他的计算科学项目的实现。在其最近GridSolve项目的研究中, 针对网格的动态性特征增加了实现和评价NetSolve中程序的容错和迁移等功能。

Ninf-G是日本科学院的一个开源项目, 建立在Globus工具包之上, 借助Globus提供的GRAM, GASS, GSI, MDS和GlobusI/O等多个服务来完成GridRPC。Ninf-G位于函数库和调用的应用之间, 通过broker调用远程的服务, 允许库的代码运行在一个远程的系统上。当应用程序在本地运行的时候, 无论是库还是应用程序都不需要做任何改动。

调用的过程为: (1) 客户端向MDS请求接口信息和可执行的路径检索, 检索后的数据放在客户端, 这将减少与MDS之间的频繁通信; (2) MDS响应客户端的请求 (3) 使用 (1) 中获得的远程服务器的可执行路径, 客户端通过GRAM与远程可执行的服务器交互。 (4) 远程服务器执行完后通过Globus I/O返回给客户端。如图2所示

在目前的Ninf-G 5版本中, 提供了对其它的网格支持平台 (非GlobusToolkit) 提供支持, 拓展了其应用的范围。

基于GridRPC的这两种方法都是仅限于解决科学计算方面的问题, 对其它方面的API支持有限, 并且大多都需要高性能的服务器。没有对通信进行抽象, 类似于远程求值的方式, 仅提供了无缝的网络解决方案, 很难在作为一种通用的网格编程方法。但是, 基于代理的GridRPC的调用机制是一种解决集中式网格的资源发现和调度的较好解决方式。

1.3 Assist (A SoftwaredevelopmentSystem based onIntegratedSkeletonTechnology)

Skeleton[29,30,31]思想最初来源于M.Cole, 它是将并行中通信和同步进行抽象, 并针对底层的运行平台预实现, 程序员只需根据求解问题, 选用合适的skeleton, 并填入执行实际计算的细节串行代码[32,33]。

ASSIST是Pisa大学的基于skeleton技术的结构化并行编程环境项目, 最初设计用于Linux下的集群环境, 目前已经成功移植到网格环境下, 它包括编程模型及一系列的开发工具组成。编程环境的结构如图3所示:

GAM (GridAbstractMachine) 是从底层的网格平台 (如globus) 中间件上抽象的功能和服务, 网格编程环境建立在GAM之上, 使用GAM提供的功能和服务去进行系统设计, 这样不会因为底层平台的变化而做较大的改变, 并且增加了程序的可移植性。

ASSIST提供了一种ASSIST-CL[34,35]语言, 它由顺序模块 (构件) 、并行模块及这些模块之间交互的模块图组成。顺序模块可以是用C/C++或Fortran语言编写的代码, 并行模块使用parmod的实例来表示, Parmod是ASSIT的核心概念, 它是一个通用的并行模块skeleton, 每个Parmod使用一组虚拟进程 (VP) 组成, 每个虚拟进程根据程序提供的参数代码映射到远程的网格节点上的运行。程序在编译后所有的资源分配、进程管理和通信管理都交给网格执行环境去自动完成。如图4所示

从编程模型角度看, 通过结构重用给程序员提供了高层的抽象, 不需要编写任何单独的与进程分解、映射和调度、通信、同步操作相关的代码, 屏蔽了设计过程中的复杂性和底层变化, 并且写出来的程序具有良好的结构性和可读性。

ASSIST实现了构件与skeleton技术融合, 已经在计算化学[36]、图像处理[37]、生物技术[38]领域实现, 并取得了成功。提供了抽象的并行解决方案和相应的编程语言, 在一定程度上, 简化了程序员的编程难度, 将其并行的复杂性部分留给了编程环境的底层。但是在其提供的parmod很难处理不规则的应用, 并在编程时就必须提供可并行执行的代码, 把实现的部分完全留给了支撑工具, 增加了支撑工具的负担。

目前ASSIST项目正在与欧洲其它的项目 (如GridCoord[39]、CoreGRID[40]、Grid.it[41,42]等) 进行无缝集成。

1.4 网格编程系统 (Ibis)

Ibis是荷兰阿姆斯特丹自由大学一个网格编程系统, 目的是实现了“透明网格”[43,44,45]的概念, 使程序同时达到可移植性、可扩展性和高效性。程序员必须使用Ibis提供的一种编程模型 (RMI[46], GMI[47], RepMI[48]andSatin[49]) 进行编程, 这些编程模型使用IPL提供一组java接口和服务, 这些接口和服务是对底层提供的资源管理和服务的封装。如图5所示

Ibis采用了优化的RMI机制, 使用java语言强调了程序的可移植性。尽量屏蔽底层的异构性, 向高层提供简单而友好的接口。Ibis也存在一些缺点:例如仍然需要程序员去完全控制JAVA的通讯机制 (包括进程分解及相关通信) , 这些机制并不具有很高的抽象;通过编程环境的扩展给用户提供了高层次的编程模式, 但并没有降到开发的难度;虽在编程模型中考虑到了“透明网格”的概念, 但仅仅是对Satin中的“分而治之”负载均衡的调整提供了很有限的支持。

采用中间件编程的方式可能是目前网格编程理想的一种方式, 通过提供一个简单, 一致的集成分布式编程环境 (中间件) 来减轻程序员在设计、编程和管理分布式应用中的负担, 高层次的抽象屏蔽底层复杂、异构的环境, 程序员使用中间件提供的API进行网格编程。这些网格编程的方法、工具和环境还是很难解决网格的的复杂性, 只是针对某一方面提出了解决方案。

2 分析比较

我们从上述介绍的典型研究项目中选取出几项进行了评价对比, 结果见表一。这些标准涉及到编程语言、编程难度、抽象层次、自适应性、性能、使用范围和可扩展性等方面。

3 结束语

目前, 由于网格的快速普及, 很多科研机构和项目[50,51,52]都将网格编程研究工作主要集中在将已有的分布式并行环境下的技术移植到网格环境下, 完全开发全新网格编程方法方面的研究工作还不多, 研究成果也很少。

一个良好的网格编程环境、方法和工具应该具有良好的可移植性、互操作性、适应性和安全性, 以及在不影响性能的情况下具有良好的容错能力, 并且能支持面向服务的新型应用的开发, 还应该有灵活方便的网格用户界面工具和网格使用环境, 这样才能很好的解决目前在网格上开发困难的问题。因此, 从长远观点来看, 仍然需要开发出适应网格的一种全新的网格编程模型和技术。

摘要：网格作为新一代的基础设施已经引起了极为广泛的关注, 但在网格上进行编程仍然是件困难的工作。文中介绍了目前最具代表性的网格编程方法和支撑工具的研究现状, 指出了它们存在的一些不足, 并从多个方面对这些方法和支撑工具进行了比较, 最后给出了网格编程未来的发展趋势和进一步的研究方向。

网格工作流调度研究综述 篇4

网格中集成了大规模、分布和异构的资源,为进行科学研究提供了一个全球性的基础设施[1]。很多科学研究机构,从高性能物理、地球物理学、天文学到生物学,都在利用网格来共享、管理和处理大规模的数据集。为了支持复杂的科学实验研究,需要协作分布的资源诸如计算设备、数据库和科学设备等来共同完成。可以通过引入工作流技术来解决这一问题。

网格工作流[2]可以看作是一组任务的集合,任务之间存在着时序或因果的约束条件,并最终完成一个特定的目标。网格工作流和传统的工作流之间具有很大的差别,如基于虚拟组织的工作方式;网格资源的动态性导致网格的计算和处理能力随时间变化,应用性能估计困难;资源异构以及跨管理域等。

调度是网格工作流中最重要的课题,它不仅仅影响网格工作流的执行成功与否和效率的高低,同时也涉及到网格工作流的资源管理情况。网格工作流的调度不同于一般的任务调度,在调度时不仅要考虑为任务选择一个最佳的资源,还要考虑各个任务之间的时序或因果的约束条件,以及协调各个任务的执行来获取最终的执行结果。目前针对网格工作流调度的研究主要集中于下面几个方面:(1)调度策略和调度算法的研究;(2)具体的网格工作流系统和项目中的调度机制;(3)服务网格下的工作流应用及调度。

1 网格工作流调度的相关知识

1.1 调度的体系结构

网格工作流调度器的架构对于工作流系统的可扩展性、自动组合、服务质量以及性能保证具有重要作用,工作流调度器架构分为集中式、分层式和分布式三种[2]。

在Pegasus[9]系统中采用了集中式架构,这种架构的中央调度器负责生成所有任务的调度计划,它为工作流中所有的任务选择和分配资源;对于分层的调度架构,则由一个中央调度器与多个低级的子工作流调度器组成,中央调度器负责控制工作流的执行,并将子工作流任务分配给低级调度器,中央调度器和子工作流调度器可以使用不同的调度策略。在GridFlow[5,6]系统中,采用了这种体系结构;Triana [4]则采用了分布式调度架构,这种架构存在多个调度器但不存在中央调度器,各调度器相互通信完成工作流任务的执行。

可以看出,集中式调度能够获取工作流中所有任务的信息和所有可用资源的信息,因此能够生成有效的调度方案,但是扩展性差,容易产生单点失败,同时也不能较好地适应网格环境的动态性和分布性;分层的调度架构在一定程度上提高了调度的可扩展性、分布性,但因为存在中央调度器,同样存在单点失效的缺点;分布式调度虽然具有良好的扩展能力,但是难以产生可以考虑全局性能的调度方案。

1.2 资源性能估计

网格系统的资源性能估计分为两类:预测性的和非预测性的。

非预测性的资源性能估计只是使用当前任务和资源的状态信息,而无需考虑历史的信息,该方法又分为启发式方法(基于任务和资源的特征)和概率分布方法(基于对期望任务特征的离线统计分析)。

预测性的方法为了估计状态需要考虑当前和历史的信息(如应用以前的运行周期),又可分为启发式方法、价格模型方法和机器学习方法。GridFlow[5,6]使用了启发式方法来预测的资源性能,通过使用预定义的规则基于网格应用的某些期望的行为来指导资源性能预测:在价格模型的方法中,考虑资源的可用性和资源的需求等市场动态来对资源进行买卖交易;在机器学习的方法中,使用在线和离线的学习方案利用潜在的未知的分布来进行资源性能预测。

启发式或基于统计的技术既可用于预测性也可用于非预测性的资源性能估计。文献[10]提到的Myopic算法则使用了基于统计的技术来预测资源的性能。

1.3 调度策略

网格工作流的调度策略分为静态调度和动态调度两种。

静态调度是在工作流建模时就绑定相应的资源,如果绑定的资源在运行时无法获得则会造成任务的暂停和中断,而在运行环境中如有类似功能的资源也不能得到利用,因此静态调度的方法效率较低,容易造成任务运行的失败。因此采用这种调度策略的应用很少。

动态调度是在建模的时候不绑定具体的资源,而是绑定资源的描述,因此在调度时能够根据运行的实际情况,利用合适的资源来执行任务,效率较高。

在动态调度策略中,根据调度时机的不同,又可以分成全局动态调度和实时动态调度。全局动态调度是指在调度发生时,为工作流的所有任务一一指定好资源,文献[9,11,12,13,17,18,19]都是基于该调度策略进行工作流的调度;而实时动态调度,则是调度发生时,仅为当前的任务选择一个最佳的资源,直至工作流应用的完成。显然,实时的动态调度更加适应网格环境中资源的动态性,但是需要实时地获取资源的信息,为资源的选择提供依据,文献[10]提出了一种实时的调度算法Myopic,但只能调度简单的工作流。Triana[4]系统也提供了简单工作流的实时动态调度策略。

2 工作流调度算法的研究

现在大部分针对工作流应用的调度研究是基于有向无环图DAG(directed acyclic graphs)的调度,即把工作流应用描述成一个有向无环图G=(V,E)。V表示图中的所有节点(node),即工作流中的所有子任务;E表示图中的有向边,代表任务之间控制依赖关系(ControlLink)及数据依赖关系(DataLink)。

基于图的调度是一个NP难问题,很难求得精确解,目前的研究大都是采用一些启发式算法来解决调度问题,如贪心算法、列表调度算法和遗传算法等。

2.1 基于遗传算法的工作流调度

遗传算法是将问题的求解表示成染色体,从而构成一群染色体。将它们置于问题的环境中,根据适者生存的原则,从中选择出适应环境的染色体进行复制,通过交叉、变异产生出新一代更适应环境的染色体群,这样一代一代地不断进化,最后收敛到一个最适合环境的个体上,求得问题的最优解。

遗传算法实际是一个动态规划算法,可很好地解决组合优化问题。借助遗传算法可以为工作流应用中所有任务选择一个满足指定约束条件的资源集。

在文献[9,17,18,19]中,作者分别基于遗传算法进行任务与资源的映射,并通过实验验证了算法的有效性,其中文献[17,19]的作者改进了算法,定义了三种收敛判据,并采用最优保存策略实现了跨代保留,避免了算法存在的过早收敛问题,提高了调度性能,缩短了工作流执行的时间;文献[18]的作者考虑了服务质量约束,在使用遗传算法进行调度的时候,是以任务之间的服务质量约束条件为依据来选择资源的。

2.2 基于HEFT算法的工作流调度

HEFT[10]算法是一种列表调度算法,使用时包括三个步骤:(1)为工作流图中的节点和边赋权值;(2)按权值排序生成一个有序的任务列表;(3)映射,为任务分配资源。

任务节点权值是基于预测任务的执行时间来计算获取的,边的权值则是通过预测资源间数据传输的时间来计算的。在异构的环境中,在不同的资源上同一任务的预测执行时间是不同的,在不同的数据通信链路上预测数据传输时间也是不同的。针对不同的应用环境,有很多近似计算方法(如取算术平均值)来提供不同程度的精确值。

排序阶段是为每一个任务节点设置一个序列值,该值的大小包括当前节点的权值和所有前序节点的执行时间。所有的可用资源根据某种目标函数获取一个性能值,它们以非递增的顺序安排在资源列表中。在映射时,对于每一个任务,将为其分配能够提供最早执行时间的资源。

文献[11,12,13]改进了HEFT算法,其中文献[11]为该算法加入了回退(Backtracking)机制,可以更好地调度执行含有并行子任务的工作流应用,文献[12,13]以不同的方式使得HEFT算法支持预留资源,保证了某些实时性要求高的工作流的执行。

2.3 其他调度策略和算法

并行调度的引入,可以大大缩短工作流的完成时间。并行不仅指工作流中本身存在的并行子任务,还指某一子任务内在的并行性。文献[15]提出了一种预调度的调度策略,考虑了某些子任务内部的并行性,通过将其分解(事先为该类子任务设定了数据依赖点,并预测了该任务的调度时间和完成时间),使其能够与其他子任务并行执行,从而加快了工作流的执行。文献[14]在多集群的应用环境中,提出了一种双层工作流调度方法。AWS(Adaptive Workflow Splitting)算法将用户提交的工作流应用分解成多个子工作流;每个子工作流在分配的集群上采用PFAS(Performance Fluctuation Aware Scheduling) 算法为每一个子工作流中的任务分配最佳的资源。

对于一些实时性要求比较高的工作流应用,可以借助资源预留来保障资源的获取,加快工作流的执行。文献[12]通过对网格资源建模,将网格环境描绘成一个图,图中的节点表示计算资源,边表示网络资源,并通过改进HEFT算法使得支持并行性和资源预留,提出的HEFTSync和HEFTSyncBT算法能够为复杂的网格工作流分配和预留资源;文献[13]基于HEFT算法进行调度,为了支持资源预留,在利用HEFT算法进行资源映射时,不再提供有序的资源列表,并且增加了预留阶段,从而使得调度器可以为每个任务预留资源。

2.4 调度算法的性能分析及小结

遗传算法和HEFT算法的性能比较已在文献[10]中通过实验加以比较。对于平衡性较好、存在大量并行子任务的大型工作流应用,HEFT算法的性能要优于遗传算法。对于大而复杂的工作流,使用遗传算法时,当求解到一定范围时往往会做大量无为的冗余迭代,导致调度时间很长,调度性能不佳。对于平衡性差的工作流应用,遗传算法显示出较好的调度性能,因为它不需要为每个节点和边计算权值。

通过分析可知,现有的调度策略和调度算法存在如下的问题:

(1) 或者是针对某一类工作流的应用来设计的,或者仅仅是理论上提出的设想,或者运行在某一特定的环境中,有很强的针对性。

(2) 强调了算法要适应网格环境中的资源具有异构性和动态性,但在具体算法设计的时候却是假定资源的信息是可以实时获得的,并没有提出一个切实可行的方案来实时获取资源的动态信息。

(3) 资源的分布性、动态性和自治性势必导致工作流执行的不稳定性,针对这一问题,现在还不存在一个实时动态的带有容错机制的调度算法。

3 网格工作流调度系统

当前的网格工作流项目和系统主要有以下几种:

(1) GridFlow系统

GridFlow[5,6]使用的调度体系结构是分层式结构,采用有向无环图DAG来表示工作流,并使用了局部调度决策机制,采用了一种性能驱动的动态调度策略,数据以对等的方式传输。系统采用的容错技术是资源替换,采用分析模型对资源的性能进行估计。

系统包含全局网格工作流管理系统和局部网格子工作流系统。其中全局层提供模拟、执行和监控整个工作流的功能,而每个局部网格处理子工作流的调度和冲突。网格工作流全局管理器用广域网格工作流调度算法(GGWM)得到一个流程中子流程的最佳调度方案;局域网格子过程调度器则负责通过局域网格工作流调度算法(LGSS)解决局部网格资源的冲突问题,得到一个子流程中任务的最佳调度方案。

GridFlow系统引入了OGSA定义的标准和接口,并实现了一个性能预测服务来指导调度,但如何提高系统的安全性以及加强各种服务之间的协作还需进一步研究。

(2) Pegasus系统

在Pegasus[9]中,使用的调度体系结构是集中式结构,采用有向无环图DAG来表示工作流,并同时使用了局部和全局调度决策机制,采用了一种性能驱动的动态调度策略,数据以中间传输的方式传输。系统采用的容错技术是重试,并采用基于历史数据的方式对资源的性能进行估计。

早期的Pegasus系统采用一种静态调度算法来调度执行工作流应用。为了支持实时的动态调度,Pegasus系统增加了一个新的组件-分割器,用来将用户提交的抽象工作流分割成若干个子工作流,子工作流间的依赖关系反映了原工作流中任务之间的依赖关系,调度器按照子工作流间的约束条件依次调度执行。

Pegasus系统借助分割器实现了简单的实时调度,在一定程度上提高了调度性能;但是至今还没有设计出一个科学合理的分割算法及具有容错保障的调度算法。

(3) Triana项目

Triana[4]使用的调度体系结构是分布式结构,采用有向无环图DAG来表示工作流,并采用了一种性能驱动的调度策略,数据以对等的方式传输,其容错机制是采取对工作流中各种属性进行配置,比如重试次数、延迟时间以及可选处理器等,不提供资源性能的估计。

Triana是一个服务工作流管理系统,其利用网格技术开发高级中间件以支持人性化的生物实验。Triana引擎可以为任务动态的发现和绑定服务,它的分配策略分为并行执行和对等执行两种,较好地满足了网格环境中资源的动态性。

综上分析,可以发现:

1) 一些系统或项目没有考虑面向服务的网格架构,因此在以网格服务为核心的网格研究中,一些研究成果已不能适应OGSI的要求。

2) 调度系统中使用的调度策略和调度算法单一,缺乏优化,难以满足网格工作流应用的不同需求。

3) 调度系统中绝大部分没有提供对服务质量Qos的支持,并且只提供了基于性能预测的调度策略。对于日益发展的商业工作流应用,调度器势必要更多地考虑用户的Qos需求,考虑成本和安全问题,因此调度策略也将渐渐转向基于市场驱动和信任驱动的调度策略和调度算法的研究。

4 服务网格环境下的工作流调度问题

随着Web服务技术规范WSRF(Web service resource framework)的出现,网格技术和Web服务技术进一步相融合,以服务为基本构成元素的服务网格已经成为网格构建的主流方向之一。网格工作流作为实现网格中资源协同工作的一项重要技术手段,把网格中多个服务包装成一个更大粒度的服务部署在网格中,供其他服务或上层的应用访问。

基于网格环境的各类应用的差异性、动态性,网络应用软件的集约化不仅极大地增加了对核心功能需求的复杂度,而且对软件的可靠性、可维护性、安全性、可控性等非功能性需求也越来越高;同时,网络环境中同时存在着数量众多、功能相同或相近、服务质量等非功能特性各异的服务。根据服务质量等应用需求动态组合服务,实现应用的“按需服务”机制,实现服务间灵活、动态的协作和调度,需要解决如下几个问题:

(1) 基本服务语义描述问题。如果基本服务之间缺乏共同遵守的语义信息,服务之间不能相互识别,更加不能自动地组合和协作。

(2) 缺乏能够灵活、可扩展的动态服务调度模型。利用该模型可以实时地根据上下文环境、约束条件动态地修改或定义服务调度方案。

(3) 缺乏网格服务工作流的实时动态调度算法。由于网格中资源的不确定性,应用的执行常常会因为某些未知的因素而执行失败,所以要求调度算法要具有相应的容错机制,来保障工作流安全顺利地执行。

(4) 在应用层上对多维Qos 的支持。由于网格环境的动态性和不可预知性,Qos 决定服务的可用性和实用性,需要调度系统能够实现由用户的应用Qos 到服务Qos 的映射需求,并将Qos 作为服务调度的一种动态约束条件。

为实现动态的服务组合,可以考虑为服务添加元数据来增加语义的方法,如文献[20]和文献[24]通过使用本体来解决服务资源的异构性问题,从而不同的网格服务间就可以通过语义上的匹配进行动态组合。

为实现实时动态的调度,可以考虑借助数学模型来预测资源的动态信息,借助机器学习或人工智能的方法规划和指导调度。但它们带来的计算复杂度对调度的影响也需要进一步的研究。

在应用层上对多维Qos的支持,可以借鉴文献[18]提出的服务质量感知的工作流调度思想,为每个成员服务和整个工作流建立服务质量参数评价体系,综合考虑了服务的性能、花费、可靠性、完整性、可提供性和声誉。

5 结束语

随着网格技术的发展,科学领域和商务领域涌现了大量网格应用,这些应用大都需要大量的计算资源和其它资源,而且任务的过程也比较复杂,包含很多时间、空间和资源方面的约束条件。利用一般的处理方法,不但效率低下,而且导致某些应用无法完成,必须通过使用网格工作流来对网格应用进行构建、执行调度、管理监控。另一方面,网格环境中资源的异构性、分布性和动态性使得调度执行难以控制,现有的调度算法和调度系统对于复杂的应用来说过于简单,还不能很好地进行实时动态的调度。针对当前流行的服务网格,分析了在服务网格环境进行工作流应用要解决的问题,并就某些问题提出了解决的方法和思路。

摘要：阐述了工作流调度的基本概念和调度的相关知识,分析了目前流行的网格工作流的调度算法的优缺点,并对当前的网格系统和项目所采用的调度机制,从不同侧面对其进行了比较分析。随着服务网格的日益流行,提出了面向服务网格环境下的服务工作流调度,分析了调度中的关键问题,并给出了解决问题的方法和思路。

煤矿安全应用网格的体系结构研究 篇5

网格是近年来国际上兴起的一种重要的信息技术, 它将网络上的各种资源, 如价钱昂贵的超级计算机、服务器、大规模存储系统、各种工作站、个人PC、可视化设备和贵重的精密仪器设备、各种软件资源和数据库等组织在一个统一的大框架下, 为解决大型复杂科学计算、数据服务和网络信息服务提供一个方便用户使用的虚拟平台, 实现计算资源、存储资源、信息资源、知识资源等的全面共享, 消除信息孤岛和资源孤岛[1]。

目前, 国外许多政府部门、研究机构、跨国公司和著名大学的许多科研人员都在从事网格计算系统的研究, 已经开展了许多研究论坛、实验环境和研究项目, 并得到了产业界的大力支持。国内在网格方面的研究仍处于起步阶段, 已经完成的网格研究项目主要有以中科院为主的国家高性能计算环境NHPCE和以清华大学为主的先进计算基础设施。在煤矿安全应用领域, 国内外尚未有成熟的关于煤矿安全应用网格 (Coal Mine Safety Application Grid, CMSAG) 技术方面的研究和应用。本文以网格技术为核心, 在现有煤矿通信网的基础上构建煤矿安全应用网格体系, 从而实现了煤矿安全应用工作中高性能协同计算和空闲资源的有效共享利用。

1 CMSAG体系结构

1.1 CMSAG研究的目标

基于网格基础平台建立煤矿安全领域多节点资源应用处理平台;利用各个节点的空闲资源和数据处理能力, 提供数据信息服务和分析处理服务以及软件、服务之间的集成;在空间信息资源共享的基础上, 为煤矿安全应用工作提供全面的煤矿安全信息服务以及满足高性能协同计算的迫切要求。

1.2 CMSAG的层次结构

CMSAG的层次结构如图1所示。

CMSAG的体系层次结构中, 下层各种资源层的各种资源由高性能计算机、大规模存储系统、精密仪器设备、各种软件资源和数据库等构成, 可由通用的计算机技术、网络技术来推动该方面的研究, 从而完成目前的硬件、网络基础设施向上扩展。GMSAG网格中间件、GMSAG网格应用开发环境和网格应用开发工具目前尚未形成统一的标准, 可以从头开始研发独立的特定产品;也可使用基于开发源码的产品, 如Globus等。GMSAG计算与评价应用层包括煤矿安全监控管理与安全评价应用层, 根据自身的技术实力、技术要求, 构建煤矿安全应用网格中的功能节点以及系统的集成。

1.3 CMSAG的体系结构

CMSAG在网格核心技术和网格系统软件的支持下, 使信息数据和各种共享资源以流的方式按照需要在各网格节点和组成部分之间流动。CMSAG的体系结构描述系统各部分的构成和相互关系, 结合煤矿安全的应用流程, 参照OGSA体系, 设计为7层结构, 如图2所示。在该体系中, 从获取资源、协同计算、资源组织、数据共享、分析处理、服务集成到顶层的应用, 组成了一个从下至上的多层次总体框架, 各层次之间具有相应的关联, 下层可为上层提供功能和服务, 形成了现场信息数据的采集获取、传输、管理、共享到应用的完整体系[3,4]。

2 构建CMSAG的关键技术

CMSAG的研究涉及到多个学科和各种前沿技术的相互渗透和相互支撑。在煤矿领域, 煤矿企业以不同的矿、局等组织形式分布在不同的地理位置, 在煤矿安全应用过程中需要用到软、硬件资源, 包括数据库、文件和存储设备等, 这种分布式环境对应用网格提出了独特的挑战。本文在现有矿区通信网及煤矿安全监测监控系统的基础上, 结合网格技术, 对构建CMSAG的关键技术进行分析。

2.1 资源管理技术

资源管理是网格计算的核心问题, 它负责组织和管理各种类型的资源, 以实现CMSAG中分布空间资源的共享和闲置计算资源的有效利用。资源管理包括CMSAG中资源的组织、定位、发现、调度、分配、确认、进程创建以及准备所需资源的其它活动。系统管理员根据预先定义好的标准, 通过资源管理软件确保CMSAG中资源的合理分配和使用, 以最终达到资源共享的目的。图3为资源管理体系结构图[5]。

资源管理器支持在1组局部资源上创建和管理进程, 资源请求由一种可扩展的资源描述语言来表示, 并可在组件之间传递。资源代理接收分析应用程序所提交的高层资源请求描述, 并将其转换为更具体的需求描述底层资源描述语言, 然后将这些底层描述语言发送到资源联合分配器。通过资源联合分配器把底层资源描述语言中的任务分为若干部分并分别交给下面的几个资源管理器。资源管理器从资源联合分配器接受任务的底层资源需求, 然后将其翻译为本地资源管理器所使用的“语言”, 从而将任务的执行交由本地资源管理器处理。

2.2 资源调度技术

资源管理是计算网格的关键技术之一, 而CMSAG要实现煤矿中分布空间资源的共享和闲置计算资源的有效利用, 必须研究并应用网格资源调度技术, 以对这些空间资源进行协调。为了完成用户提交的任务以及满足用户提出的要求, 网格任务调度搜索CMSAG中所有可用的资源 (计算资源、存储资源和网络资源) , 找到最合理的资源分配方式和资源调度策略。图4为CMSAG任务调度设计图。当把任务请求传递给动态协同分配代理处理后, 任务请求被分解成多个资源管理器请求, 并且把每个请求都提交给资源管理器处理, 所有请求都成功后, 就达到任务请求同步点, 任务就可以正常执行了。但如果没有达到任务启动同步点, 则无法保证所有需要的资源都已获得。

2. 3 网格安全技术

CMSAG的目标是将Internet上提供煤矿安全信息服务的节点连接在一起, 让所有用户都可以享受这些信息服务。另一方面, 这些站点又分属于不同的煤矿组织机构, 各组织机构可以独立地管理属于自己的网络节点。在实际应用中, CMSAG必须为站点管理者提供访问控制等安全管理机制, 管理者可以自由地决定使用者存取网格资源的时间、地点以及范围。这种机制给使用者一个票据, 用于向资源的所有者证明这台经过授权的机器已经给予它存取许可。当然, 这种权限控制必须是易维护且独立于数据源本身, 同时应该在逻辑上提供不同的安全管理层次和控制权限。

3 CMSAG实际应用示例分析

CMSAG基于网格基础平台建立煤矿安全多节点应用结构, 每个节点能够实现各自区域的数据和分析处理功能, 实现信息服务和协同计算处理的集成, 为用户提供全面的一体化的煤矿安全信息服务应用。下面以实例说明CMSAG在煤矿安全领域的应用:煤矿安全研究机构需要对某矿井做通风网络分析与可靠性定量评价, 在评价过程中, 需要利用该煤矿现场关于矿井各巷道的各种参数和现场抽样测定的数据等, 而且还需要利用煤矿上级管理机构关于该矿井近期的安全评价报告等资料, 定量服务评价机构需要集合各种信息资源和计算环境进行综合计算和评估, 从而提供全面的一体化的煤矿安全信息服务应用。

CMSAG工作流程如图5所示, 研究人员 (或应用程序) 通过CMSAG资源服务和注册中心获取满足应用需求的煤矿安全信息资源, 根据这些信息资源, 用户通过CMSAG应用程序入口, 访问各种空间资源。首先调用区域选址服务获取特定的矿井参数和抽查数据以及存储分布在各煤矿机构的资源信息, 将这些信息汇集在定量评价服务机构, 定量评价服务机构根据这些数据信息, 利用各个机构的空闲计算环境进行高性能协同计算和相关处理, 然后把结果集成和融合, 实现最后的通风网络分析与可靠性定量评价, 将结果返回给用户 (或应用程序) 。

通过该应用示例可以看出, CMSAG可实现煤矿安全领域各种空闲资源的共享集成和有效利用以及高性能协同计算, 提高了煤矿安全管理工作中的安全预测预报速度和精度, 对解决煤矿安全的实际问题具有重要意义。

4 结语

随着煤矿企业网络应用需求的不断增长, 对计算模式提出了新的要求。本文结合网格技术及其在煤矿安全应用领域的实际需求, 提出了CMSAG体系结构, 详细论述了CMSAG在实现过程中的关键技术。CMSAG是在煤矿安全应用体系中引入网格概念的煤矿安全应用信息平台和基础设施, 在CMSAG中, 用户可以通过单一的应用程序入口访问所有煤矿安全的信息数据以及服务资源。实际应用表明, CMSAG实现了对煤矿安全应用工作中分布广泛的计算、数据、设备等空闲可利用资源的高效利用和管理, 提高了煤矿安全管理工作中的安全预测预报速度和精度, 对解决煤矿安全的实际问题具有重要意义。但是, CMSAG的研究还处于初步阶段, 需要在应用网格操作系统、高速处理海量数据及其关键技术等方面作进一步的研究。

摘要：应用网格解决煤矿安全管理工作中的数据密集、计算密集、资源分散、异构等问题, 实现高性能协同计算, 进而提高安全预测预报速度和精度, 已成为煤矿安全管理工作中的关键。文章在现有的煤矿通信网的基础上和参照OGSA体系, 提出并构建了从信息获取、处理到应用的煤矿安全应用网格 (CMSAG) 体系结构。结合行业应用需求, 文章重点研究了CMSAG体系的资源管理、资源调度、网格安全等关键技术, 最后给出了具体应用示例。

关键词：煤矿安全,网格,体系结构,CMSAG

参考文献

[1]都志辉, 陈渝, 刘鹏.网格计算[M].北京:清华大学出版社, 2002.

[2]FOSTER I, KESSELMAN C.网格计算[M].北京:电子工业出版社, 2005.

[3]孙艺珍, 龚尚福.煤矿安全信息网格GIS的系统框架研究[J].西安科技大学学报, 2005 (12) .

[4]徐森, 王建国, 李学文.基于网格的煤矿安全应用网格体系研究[J].计算机仿真, 2005 (12) .

[5]孙士翠, 丁恩杰, 徐秀.煤矿安全网格环境下资源管理与任务调度的研究[J].工矿自动化, 2007 (6) .