在本系列的前两篇文章中，我们对 TeraGrid 项目进行了简要介绍，介绍了用来维护其网格计算基础设施的基本软件，并解释了在 TeraGrid 计算资源中构建数据网格、从而为大型数据资源提供远程、透明访问能力的动机，以及支持这些的基础设施。
所有这些对于充分利用任何大型网格来说都非常重要。但是网格计算存在的最终目的是支持计算任务在任何资源上的执行。在构建于无数 TeraGrid 站点上的各种开发和部署所取得的成果的基础上，我们可以支持大量基于网格的执行模式和机制。不过，工作仍在继续，因为用来支持下一代工作流的针对底层网格资源的高级需求非常重要，所以相关标准仍在不断开发之中。
现在我们将着重介绍一下作业执行的策略，以及 TeraGrid 用户可以使用的工具，并介绍用户直接用来执行远程作业的基本网格基础设施，以及基于网格的资源选择和调度应用程序间接使用的基本网格基础设施。然后介绍使用网格资源实现大型计算任务所使用的一些方法，以及在 TeraGrid 项目中开发更高级访问和控制机制的动机。我们会随同网格上的作业执行标准的当前发展状态一起，逐一对这些进行介绍，并对很快就会为这个项目提供的工具提供一些建议。
基本基础设施
分布式作业执行基础设施最基本的需求是标准化的远程执行机制（remote execution mechanism）。它允许用户和应用程序根据用户的行为来建立对作业需求和执行指令的标准描述，它们在任何给定时间都在最适合的资源上使用。网格中最常见的远程执行机制是 Globus Gatekeeper 服务器和客户机工具，它是 TeraGrid 上最先部署的 TeraGrid 项目的网格组件之一。
Globus Gatekeeper 和本地调度程序
Globus Grid Resource Allocation Manager（GRAM）框架在用户、网格计算系统、本地资源管理器和调度程序之间提供了一组标准的接口。GRAM 框架通过使用 RSL（Resource Specification Language）来提供这种接口，RSL 提供了一组简单的原语集，例如 executable=/bin/date，从而允许用户指定典型的计算参数，例如所需要的节点和处理器的数量、作业应该运行的时间长度、应该启动的可执行程序等。
然后用户会将这个计算任务的 RSL 描述提交给在给定资源上运行的 Globus Gatekeeper 进程。如果这个 RSL 正确，并且所使用的资源可以满足需求，那么 JobManager 进程就会将这些通用的 RSL 参数转换成一个与本地资源管理器匹配的作业脚本，并将这个脚本作为一个作业与其他本地任务一起提交（参见图 1）。
图 1. 作业提交流程
TeraGrid 环境包括很多站点，每个站点都使用了不同的机器和不同的方法将资源分配给不同的用户。为了尽可能地隐藏这种异构性，TeraGrid 从几年前就开始使用 Globus Toolkit V2 提供的 GRAM 系统。然而，由于 TeraGrid 基础设施被设计用来支持下一代的网格计算工作流，并作为一个完全计费的产品资源集来使用，因此有一些特殊的要求，以便在一个简单的 Globus Gatekeeper 设置所需的一般配置之上操作 TeraGrid 中的资源。这些配置包括要求调度程序支持高级预约，以及要求通过 Globus 系统将记帐信息顺利地集成到作业提交工作流中。
高级预约 是一种用户可以提前预约部分给定资源的机制 —— 在这种情况下，所预约的通常都是计算资源。利用可以支持高级预约的调度程序，用户可以请求特定数量的在某个预先确定的时间段内可用的节点和处理器，使用这些节点和处理器与其他资源进行协调，或者根据需要使用它们执行一些数据处理操作。尽管有很多可用的通用资源管理和调度系统不一定非得支持高级预约，例如 OpenPBS 或 LoadLeveler，但是有很多高级开源调度工具都支持高级预约，例如 Maui Scheduler（请参阅 参考资料）。
所有的主要 TeraGrid 资源都为高级预约功能提供了一定程度的支持。Globus Gatekeeper 在最初设计 RSL 系统时并没有考虑这种提前预约计算资源的能力，因此就在主 JobManagers 上为各种 TeraGrid 资源添加了另外一个 RSL 属性，从而允许用户将之前已经通过调度程序的高级预约系统预约过的一组（新）节点作为目标。
Web 服务和 Globus Gatekeeper
在 Globus Toolkit 和 TeraGrid 使用的传统模型中，某个特定站点希望运行的每个网格服务都是作为一个不同的服务进程实现的。在 Gatekeeper 的实现中，Gatekeeper 服务器所运行的每个任务都会在正在使用的资源上扩展出几个新进程。这种模型的效率很低，因为每次实现新特性或协议时都需要对单一的服务器进行修改，这对于大型的繁忙资源来说是不切实际的。
在网格标准团队正在开发的架构以及 Globus Toolkit 已经实现的架构中，所有网格服务都可以由一个容器来提供，网格功能是使用 SOA（Service-Oriented Architecture）实现的。在新的参考实现规范和 GRAM 模块的实现中，另外一项改进使用了基于 XML 版本的 RSL，它为作业规范提供了更好的标准化、结构化和可扩充能力。
Globus Toolkit V4 就遵循这种新方法，它是下一代 TeraGrid 基础设施的基础。Globus V4 服务的容器服务器是在 TeraGrid 上进行部署和测试的。TeraGrid 项目期望它们可以成为将来网格服务消费者所使用的主要机制 —— 用户和特定的应用程序都根据用户的行为进行操作。本文中提到的所有工具都被认为可以在 TeraGrid 基础设施的新旧部署中等效地工作。
高级作业执行策略和工具
对于最简单的计算任务来说，高级网格接口和技术都是不必要的。例如，如果用户只需要在资源上运行一项任务，那么他只需要理解如何使用本地机制登录系统并发起一项任务即可，这种方法对于执行这种作业来说似乎是最有效的。不过更为常见的是用户会希望执行一些逻辑任务，这些逻辑任务可能会包含一个工作流或其他协同执行模式中的很多实际任务，或者有些用户会希望选择多个资源来让自己的作业尽可能快地运行。
执行模式和高级网格工具
对于更新、更复杂或更大型的科学应用程序的高级执行模型，需要更多的高级网格计算服务来管理这些复杂的工作流。
网格计算技术的第一个用户（也是使用最频繁的用户）就是所谓的参数清扫应用程序（parameter sweep application），其中会有很多相同且相当小的应用程序会多次运行，每次都会使用一组不同的参数。这种应用程序非常适合使用基于自动化网格的模型来执行，因为这会涉及多次单独启动多个任务，但每次任务都与其他任务无关。
另外一种越来越通用的模型是同时使用多个资源，或者为单独某项计算任务累计大量资源，或者将一个非常复杂的任务划分成很多组件，每个组件都可以在一个不同的资源上很好地完成。这种网格计算能力最有趣的一个应用是为远程位置的计算结果提供实时的可视化协作检验。
基于自动化网格作业执行的每种模型都需要 GRAM 系统所提供的这些基础设施上的其他功能，它只会实现将各个作业提交到各个资源的功能。可以提供一个统一的系统，将这些任务提交到多个资源上，并启用多个计算资源来参与一个作业的执行过程，这需要其他软件的一些功能。
对多个网格资源提供访问能力的第一种机制（有很多方法，但这是最简单的）是对用来支持网格计算的众所周知的 Condor 分布式计算工具 Condor-G 的扩展。Condor 和 Condor-G 允许用户构建一组可由单个 Condor 队列管理的资源。这些请求的状态是由 Condor 系统进行跟踪的，用户并不需要手工为所有不同作业检索状态信息。Condor 还为根据 Condor 作业描述中的需求定义来自动选择特定资源提供了 ClassAds 机制。所有的 TeraGrid 站点都可以支持使用 Condor-G 进行远程网格作业提交，而不管它是通过本地系统还是远程 Condor-G 系统进行的。
更复杂的情况包括在一个作业中同时使用多个资源。这种情况不但需要工具从多个资源所在处同时提供资源，而且还需要软件允许通过所设计的（至少是经过调优的）网格和应用程序来使用标准的 MPI（Message Passing Interface），从而充分利用网格机制的优点执行作业。
为此提供的一种最高级的软件包（也是受 TeraGrid 支持的软件包）是 MPICH-G2 库。这个应用程序库使用了流行的 MPI 的开源 MPICH 实现，将其作为通信网络的智能结构化层次中的一层来为任何特定的应用程序调用提供优化通信能力。这个库已经在所有的产品 TeraGrid 平台（包括可视化资源）上经过了测试，它允许用户尽可能有效地执行复杂或非常大的多资源任务。
基于 Web 和 HTTP 的接口
正如前面介绍的那样，Globus Toolkit 和基于网格标准正努力朝着 SOA 的方向发展，并使用容器模型来定义和实现网格标准。
在这种新模型下提供网格服务的最广泛的实现机制是使用 Web 服务容器。实际上，第一个 Globus Toolkit V4 发行版就是以 Web 服务容器为基础的。除了容器的灵活性之外，它对于基于服务的方法的关注也极大地促进了通过基于 Web 的接口（通常称为门户）来提供网格计算的实现。使用网格门户，任何给定的用户都可以获得一个所有可用资源的图形化视图（用于数据存储和计算），通常可以在任何显示资源上配置和启动数据移动和计算任务，所有这些都来自于一个简单的 Web 接口。这些接口也可以配置成根据用户请求而产生更复杂的操作序列。有几个网格门户工具包可以用来简化开发定制门户的过程。
TeraGrid 对于通用和特定于领域的网格门户用法已经给予了很大的支持。整个 TeraGrid 项目都在开发一个 TeraGrid 范围的门户项目，从而允许自己的整个 user base 来使用这种机制访问资源。还有其他几个项目，它们为特定领域中现有或正在开发的科学门户项目中的 TeraGrid 资源提供了集成的访问能力。这些技术的使用可以更广泛地在 user base 中启用网格计算技术，并更加紧密地将 TeraGrid 基础设施继承到外部项目的查看和访问可用资源的方法中。
TeraGrid 中的下一代网格计算
网格计算是正在在生产计算的前端进行广泛的开发，其中实现标准非常重要；目前已经开始向下一代标准前进了。在网格计算中，资源选择和远程作业执行的主题尤其活跃，这是由于它具有广泛的适用性，并且性价比和效率方面得到了重大改进，可以从更有效的资源利用工具中获得这些能力。
另外，现有的工具和标准只提供了少量的服务和信息，因此这显然也是改进的目标之一。在产品网格中，TeraGrid 正在逐渐利用最新的可靠技术，试图在下一代更复杂的网格标准中提供有用的输入，并基于现有基础设施开发一些工具，以前进一步支持网格计算。
Grid Unified Remote
Grid Unified Remote（GUR）项目最初是在 San Diego Supercomputing Center（SDSC）开发的，开发它的目的是为了提供一个简单易用的接口来管理各种基于网格的资源，尤其是在各种资源都期望具有不同作业负载和支持高级特性的情况下，例如用户预约。这个项目提供了将一个作业请求同时提交到多个资源上的机制，以及选择第一个可用资源来运行作业的机制。它还为在多个资源上同时启动多个进程提供了管理工具，从而对在 TeraGrid 上启动大型协作作业的任务进行简化。GUR 软件现在正在 TeraGrid 上非常活跃地进行测试和开发，其目标是在最终包含到标准 TeraGrid 生产软件堆栈中。
Global Grid Forum、OGSA 以及将来的展望
Global Grid Forum（GGF）是为网格计算开发的第一个标准，它为网格服务定义了整体的架构。GGF 非常活跃地参与到了向 SOA 的最初转化过程中，利用 GGF 对将来的标准进行开发对于将来的标准和组件有着巨大的影响。同样，TeraGrid 项目也非常紧密地参与了对 GGF 工作的跟踪和推动。
GGF 正在开发的整体结构被称为 Open Grid Services Architecture（OGSA），它定义了一组可以交互操作的服务，它们可以一起提供一些更高级的功能。GGF 中 OGSA 工作组的主要目标是开发高级标准来支持在网格中进行复杂的资源选择和调度。这包括很多服务，例如远程执行服务，用来管理资源列表的服务，对可用资源列表与等待执行的任务需求列表进行比较的服务。
由于 TeraGrid 在这个方面具有很多经验，我们的用户已经展示了对于这种高级执行环境的需要，说明他们可以通过实现这些高级标准来启用，因此希望随着它们不断的开发和日益健壮，我们可以紧密地参与到网格计算标准中来。
支持TeraGrid
从技术和用户服务的角度来看，支持 TeraGrid 项目的各种用途都是一个重大的挑战，在那些标准、应用程序和使用模式依然在不断更新和变化的环境中更是如此。
相应地，我们已经采取了两种方法来解决这些问题：在开发下一代技术的同时部署产品网格基础设施，并为数据移动和作业执行提供一组基本的服务（该服务是稳定的并且经过严格测试的）。这个项目还在不断追踪其他开发努力所采用的新技术，并维护了至少两种技术设施，因此，边缘用户可以访问这些新软件的开发版本了，而对于网格工作流要求较少的用户可以一直使用稳定的计算基础设施。
随着继续将网格计算作为一种概念和工作技术进行开发，我们已经尝试参与更广泛的标准制定工作中来 —— 通过成功地实现 Globus Project 和其他一些类似的网格项目，例如在欧洲、澳大利亚和亚洲所开展的一些项目。我们还一直试图培养与特定于领域的网格协作者的紧密关系，因为这些努力已经说明科学社区希望采用网格计算。我们所服务的社区的组织性越好，范围越广泛，有效地对整个用户社区提供服务的机会就越大。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
