与外部进行沟通，第 1 部分: Condor-G 与 Globus

文档选项 未显示需要 JavaScript 的文档选项 讨论

级别： 中级

Jeff Mausolf (mausolf@us.ibm.com), IT 架构师, IBM Global Services, Global Technology Center, Grid Computing Initiative

2006 年 2 月 06 日

Globus Toolkit 提供了用来共享分布式资源的基本网格基础设施组件。这个系列文章一共两篇，本文是其中的第一篇。在本文中，Jeff Mausolf 将展示如何在 Globus 中使用 Condor 作业提交组件来提供一种更广泛的解决方案。Condor 是用来管理对计算敏感的作业的批处理队列系统和作业调度器，它是由 Madison 的 University of Wisconsin 开发的。它充分利用了这两种技术的优势，在可能会涉及很多管理域的异构计算环境中为作业提交、监视和控制提供一个易用的接口。

Globus Toolkit —— 网格基础设施的标准

Globus Alliance 开发了 Globus Toolkit，用于在多个管理域之间进行资源共享。Globus Toolkit 提供了很多服务，可以支持异构环境中的作业提交、监视和控制功能。另外，它还提供了一种安全基础设施，并提供了一些服务来实现资源发现、监视和管理的功能。安全基础设施可以简化授权用户对于远程资源的经过身份验证的访问，而资源发现服务则可以根据需要来为作业定位资源。

随着时间的推移，Globus Toolkit 已经成为网格基础设施的事实标准。原因之一是 Globus Toolkit 是基于开放标准的，它为在其上构建其他服务提供了一个坚实的基础。其目标不是要提供一个功能完备的网格，而是要提供一些构造基础来简化网格解决方案的开发和集成。这些构造基础，或者称为 Globus Toolkit 组件，提供了很多网格基础设施。然而，Globus Toolkit 中并没有包括调度组件。调度器的作用就是要制订有关何时何地运行作业的智能决策，从而使作业的吞吐量和对资源的利用率最大化。调度器可以根据作业的需要和资源信息（例如属性、可用性和状态）为作业标识适当的资源。调度器确定何时何地运行作业，然后与 Globus 进行协调，从而在所选定的资源上运行作业并指定相关的任务，例如身份验证、文件分段传输、监视和控制。

在本文中，我们将介绍一下 Globus 的特性，并了解 Madison 的 University of Wisconsin 所开发的 Condor 项目。在这篇文章中，我们将介绍如何使用 Condor 在 Globus 环境中简化与作业提交、监视和控制有关的任务。在本系列的第 2 部分中，我们将介绍如何使用 Condor 的 matchmaking 功能来根据作业需求和资源信息制订智能的调度决策，并充分利用 Globus 所提供的远程资源访问能力将作业提交到 Condor 池之外的资源上。

回页首

使用 Globus Toolkit 提交作业

首先，通过展示一个使用 Globus Toolkit 的简单作业的例子来介绍一下基本的步骤。使用 Globus Toolkit 的作业所涉及的典型步骤包括：

1. 创建作业描述文件
2. 初始化凭证
3. 提交作业
4. 监视作业

作业描述

诸如输出文件或错误文件之类的作业参数可以作为命令行参数提供给 globusrun-ws 命令，或者可以包含在基于 XML 的作业描述文件中。作业描述文件然后可以作为 globusrun-ws 命令的输入使用，这个命令用来提交作业和查询已提交的作业的状态。作业描述文件至少应该指定可执行文件、参数以及将输出或错误重定向到哪里。另外，我们还可以在作业描述文件中设置环境变量，指定要运行的作业的数量，对文件进行分段传输，以及进行必要的清理工作，例如清除对环境的更改。

作业提交的前提条件

用户要提交作业，必须使用有效的凭证进行身份验证。作业可能会需要对用户的凭证进行委托，从而执行远程操作，例如分段传输文件。下面的例子假设已经使用 grid-proxy-init 命令生成了一个有效的代理。然而，凭证也可以与作业请求一起传递，或者上传到 Delegation 服务中。清单 1 展示了使用 grid-proxy-init 命令对代理进行初始化的例子。

                
[globust@gt4-test ~]$ grid-proxy-init
Your identity: /C=US/O=UTAustin/OU=TACC/CN=Globus User/UID=globust
Enter GRID pass phrase for this identity:
Creating proxy .............................................. Done
Your proxy is valid until: Thu Nov 19 23:35:47 2005

批处理模式

尽管在大部分情况下作业都可以使用 globusrun-ws 命令交互式地运行，但是如果能提交一系列批处理作业在后台无人参与地运行，则更适合网格计算的使用模式。这样可以允许用户提交多个可以在不同网格资源上同时运行的作业。由于程序控制权会立即返回给用户，而且用户可能会同时运行多个作业，因此用户必须有一种方法能够查询特定作业的状态，并获取该作业的结果或输出。这是使用一个端点引用（end-point reference）来实现的。端点引用是一个 Web 服务术语，与以前版本的 Toolkit 所引用的作业句柄概念类似。当用户提交一个批处理作业时，他还会提供一个输出文件名。Globus 会将与这个作业有关的端点引用写入到输出文件中。然后用户就可以通过指定一个包含端点引用的文件（这个文件是在提交作业时创建的）来与作业进行交互。在下面这个例子中，作业是在 environment_test.xml 文件中进行描述的。这个作业是以批处理模式提交的，端点引用应该被写入到文件 environment_test_job.epr 中。

                
[mausolf@gt4-test ~]$ globusrun-ws -submit  \
-batch -f environment_test.xml -o environment_test_job.epr
Submitting job...Done.
Job ID: uuid:50d175d0-31cb-11da-834f-000bdb915904
Termination time: 10/01/2005 16:00 GMT

端点引用惟一地标识作业。例如，作业状态可以使用 globusrun-ws 命令加上 –status 参数，后面跟上作业端点引用文件（-job-epr-file）来获得。下面的例子实现对清单 2 中所提交的作业的状态进行查询。

[mausolf@gt4-test ~]$ globusrun-ws -status -job-epr-file environment_test_job.epr
Current job state: Done

Globus Toolkit 允许用户提交多个批处理作业。用户可以对这个系统进行查询，从而获得作业的状态，或者安排在作业完成时向用户发送通知。然而，在与多个作业进行交互时这种方法可能会有些麻烦，因为它需要用户管理与每个作业相关的作业端点引用。如果用户可以将多个作业分组在一起，并将其作为一个单元或单独进行控制，那么多个作业的提交、监视和控制就可以进行简化。这对于系统持续进行作业引用也很有好处，这样用户就会看到一个包含所有作业及其状态或退出状态的清单了。

下面让我们了解一下 Condor 系统，从而看一下它如何帮助管理作业引用并简化作业管理和控制。

回页首

Condor

Condor 是一个用来管理计算敏感作业的批处理队列系统。它提供了上面所介绍的特性，而且能够访问分布式资源来获得更多的计算能力。Condor 通过诸如 classAds 和 matchmaking 之类的创新技术提供了调度功能。与其他批处理队列系统一样，提交给 Condor 的作业应该作为无人参与的后台任务运行。

要从网格环境中获得最大的收益，网格应用程序应该可以被划分成很多独立的任务。与 Globus 有关的作业提交、监视和控制机制在上面都简要进行了介绍。下面让我们来介绍一下 Condor 中的特性。作业可以使用 condor_ submit 命令和对作业的描述以及提交描述文件中的相关需求提交给 Condor。一旦作业被提交之后，可以使用 condor_ q 命令进行监视。condor_q 命令返回队列中所有作业的列表，以及作业的详细信息，例如作业提交的日期和时间、作业状态以及优先级。当作业完成时，用户会收到通知，并得到有关作业执行的统计信息，例如所占用的 CPU 时间或作业的输入和所生成的输出。

Condor 环境

在 Condor 中有很多运行环境可以用来支持不同类型的作业。运行环境被称为 Condor 环境。Condor 环境是在上面提到的提交描述文件中指定的。最通用的作业环境是标准环境。然而，还有一些环境可以支持并行虚拟机（Parallel Virtual Machine）、消息传递接口（Message Passing Interface）、Java® 虚拟机、网格计算，还有一个用于特殊调度场景的环境。本文的重点是关于网格环境的。

回页首

Condor 中的网格计算

在所有的计算资源都运行 Condor 时，Condor 可以提供一个相当广泛的网格计算环境。然而，如果网格是通过加入不同管理域中的几个现有集群来创建的，那么这种方法可能是不可行的。不同的集群可能有一些现有的资源管理器，它们可以对集群的资源进行优化。集群可能在不同的域中，运行具有不同本地调度策略的不同资源管理器。在对部门的集群进行集成来构造网格时通常会出现这种情况。网格通常是由很多不同类型的硬件和软件构成的。Globus Toolkit 提供了一个基础设施来在这些异构分布式资源之间进行资源的共享。下面让我们讨论一下 Condor 如何在这个 Globus 基础设施的基础上提供高级的服务。

Condor 的网格特性是通过使用 Condor 的网格环境来启用的。在使用 Condor 网格环境时，Condor 可以通过 Globus Toolkit 将作业提交到远程网格资源上。Globus Toolkit 提供了网格基础设施，包括分布式和多域环境中的安全性和资源访问。

结合使用 Condor 的特性与 Globus 控制的资源一起进行作业提交、监视和控制就称为 Condor-G。Condor-G 使用 Condor 的作业管理特性，以及 Globus Toolkit 的安全性和资源访问特性。Toolkit 提供了身份验证机制、与远程资源进行数据传输的能力以及远程执行环境。Condor 通过在提供监视和控制功能的同时提供通知、容错和凭证管理功能，从而对作业的提交和管理进行了简化。

Condor 可以帮助在用户作业执行时管理用户的凭证或代理，防止它们在作业运行时过期。Condor 可以在作业完成或失败时通知用户，这样用户就可以执行适当的操作了。Condor-G 还提供了一个容错环境。如果一台机器出现了故障，或者一个作业在某台机器上失败了，那么这个作业就会返回这个队列。Condor 会使用另外一个资源来匹配这个作业，并自动重新提交这个作业。

回页首

Globus 组件

当 Condor 的作业管理部分与 Globus 进行协调时，它就会与 Globus Toolkit 的 GRAM（Grid Resource A location and Management）组件进行交互。GRAM 是由一组 WSRF 兼容的 Web 服务构成的，它们用来帮助用户在网格环境中提交和管理作业。GRAM 可以帮助对需要凭证、可靠执行和协调文件分段传输的作业进行处理。作为本文的一部分提供的例子将使用这个环境，但是要记住，如果需要更广泛的调度和资源管理特性，GRAM 可以集成集群级的资源管理器，例如 Platform LSF 或 PBS，它们专门用来管理复杂的作业执行环境。

要在 Condor-G 中提交一个作业，提交描述文件中必须指定 globus 环境，并标识出 Globus 作业管理器的位置。让我们看一下通过 Condor 将一个作业提交到 Globus 资源上还需要其他什么东西。

我们将讨论一个简单的作业提交例子，它在一个特定的资源上运行一个作业。这个资源使用 GRAM Fork 来执行这个作业，不过它很容易进行扩展，从而可以让 GRAM 与诸如 LSF 和 PBS 之类的资源管理器进行协调。提交描述文件对作业进行了描述，并包含了作业的需求。它指定了可执行文件、环境和 Globus 作业管理器。Globus 作业管理器可以惟一地标识执行作业的资源。下面的提交描述文件会在一个名为 laredo 的 Globus 资源上执行一个环境脚本。它使用了在下面的提交描述文件中指定的输出和日志文件名。记住，在将一个作业提交到 Globus 上之前，必须要使用 grid-proxy-init 命令生成一个网格凭证，从而创建一个用户代理。

清单 3 给出了提交描述文件的内容。这个例子在不同的环境中可以通过修改 globusscheduler 的主机部分来标明您自己环境中的主机。

                
executable = env-test.pl
globusscheduler = laredo.tacc.utexas.edu/jobmanager
universe = globus
output = env2test.out
log = env2test.log
queue

清单 4 给出了可执行脚本文件，这可以在安装了 Perl 的环境中使用。注意 Perl 的位置是在第一行中说明的。

                
#!/usr/bin/env perl
foreach $key (sort keys(%ENV))
{
   print "$key = $ENV{$key}\n"
}
exit 0;

我们将设置环境、生成代理，然后使用 condor_submit 命令来提交作业。首先通过引用 Globus 安装目录中的 etc 目录中的 globus-user-env.csh 文件来初始化 Globus 的环境变量。下面的代码展示了如何使用 csh 来引用 Globus 的环境变量，这假设环境变量 GLOBUS_LOCATION 已经被设置为 Globus 的安装目录。

[globust@bandera ~]$ source $GLOBUS_LOCATION/etc/globus-user-env.csh

环境经过初始化之后，就可以使用 grid-proxy-init 命令初始化凭证代理了。使用 grid-proxy-init 命令的例子请参阅清单 1。

接下来，我们将设置环境变量，并将 Condor 命令添加到 PATH 环境变量中。清单 5 给出了对 Condor 环境变量的初始化方法。

                
setenv CONDOR_CONFIG /usr/local/osg/condor/etc/condor_config
setenv CONDOR_LOCATION /usr/local/osg/condor
setenv PATH "${CONDOR_LOCATION}/bin:${CONDOR_LOCATION}/sbin:${PATH}"

现在我们已经正确配置好了环境，可以使用 condor_submit 命令并指定作业提交描述文件来提交作业了。清单 6 给出了用来提交 env2test 作业描述文件中的作业所使用的 Condor submit 命令。

                
[globust@bandera ~/test]$ condor_submit env2test
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 97.

作业状态可以使用 condor_q 命令进行查询。清单 7 展示了 condor_q 命令的用法，这里假设 Condor 命令已经加入到用户的 PATH 变量中了，如清单 5 所示。

                
[globust@bandera ~/test]$ condor_q
-- Submitter: laredo.tacc.utexas.edu : <129.114.4.66:37791> : laredo.tacc.utexas.edu
 ID      OWNER            SUBMITTED     RUN_TIME ST PRI SIZE CMD                 
  97.0   mausolf         11/21 15:54   0+00:00:00 I  0   0.0  env-test.pl
1 jobs; 1 idle, 0 running, 0 held

当作业完成时，作业提交者就会收到通知，并可以收到与这个作业有关的统计信息。清单 8 给出了作业完成时可以收到的典型通知。

                
Your Condor job 97.0
        /home/mausolf/adiga/shloop/sh_loop 60
has exited normally with status 0.


Submitted at:        Fri Nov 11 14:55:11 2005
Completed at:        Fri Nov 11 15:00:49 2005
Real Time:           0 00:05:38

Virtual Image Size:  3832 Kilobytes

Statistics from last run:
Allocation/Run time:     0 00:01:02
Remote User CPU Time:    0 00:00:00
Remote System CPU Time:  0 00:00:00
Total Remote CPU Time:   0 00:00:00

Statistics totaled from all runs:
Allocation/Run time:     0 00:01:02

Network:
    0.0 B  Run Bytes Received By Job
    0.0 B  Run Bytes Sent By Job

在这个作业输出中指定的作业描述文件应该被重定向到一个文件 env2test.out 中。清单 9 给出了在输出文件中包含的作业的输出。

                
[mausolf@laredo gt2]$ cat env2test.out
GLOBUS_GRAM_JOB_CONTACT = https://laredo.tacc.utexas.edu:33651/31451/1125521652/
GLOBUS_GRAM_MYJOB_CONTACT = URLx-nexus://laredo.tacc.utexas.edu:33652/
GLOBUS_LOCATION = /usr/local/globus/globus-3.0.2
GLOBUS_REMOTE_IO_URL = /home/utexas/staff/mausolf/.globus/.gass_cache/local/md5/  \
94/16b4b0acd4e4cf08172048b4f66095/md5/44/1d0594c2e01d2539b803fa25933426/data
HOME = /home/utexas/staff/mausolf
LOGNAME = mausolf
SCRATCH_DIRECTORY = /home/utexas/staff/mausolf//gram_scratch_ghz3DaEyfh
X509_USER_PROXY = /home/utexas/staff/mausolf/.globus/.gass_cache/local/md5/  \
94/16b4b0acd4e4cf08172048b4f66095/md5/10/54ffd2f4efc0f165bc48d822075bfc/data

Condor 使用了一个 GAHP（Grid ASCII Helper Protocol）服务器与 Globus 进行交互。与 GAHP 服务器有关的详细信息可以在 GridmanagerLog < userid > 文件中看到，这个文件通常是在 /tmp 目录中。下面是 GridmanagerLog.mausolf 中的一部分：

                
8/31 15:54:12 [31443] Using job type Globus for job 97.0
8/31 15:54:12 [31443] (97.0) doEvaluateState called: gmState GM_INIT, globusState 32
…
8/31 15:54:12 [31443] GAHP[31447] <- 'CACHE_PROXY_FROM_FILE 1 /tmp/x509up_u800042'
…
8/31 15:54:12 [31443] (97.0) gm state change: GM_INIT -> GM_START
8/31 15:54:12 [31443] (97.0) gm state change: GM_START -> GM_CLEAR_REQUEST
8/31 15:54:12 [31443] (97.0) gm state change: GM_CLEAR_REQUEST -> GM_UNSUBMITTED
8/31 15:54:12 [31443] (97.0) gm state change: GM_UNSUBMITTED -> GM_SUBMIT
8/31 15:54:17 [31443]    GlobusGramVersion = 3
8/31 15:54:17 [31443] (97.0) gm state change: GM_SUBMIT_COMMIT -> GM_SUBMITTED
8/31 15:54:17 [31443] GAHP[31447] <- 'RESULTS'
8/31 15:54:17 [31443] (97.0) Writing globus submit record to user logfile
8/31 15:54:17 [31443] (97.0) globus state change: STAGE_IN -> ACTIVE
8/31 15:54:17 [31443] (97.0) globus state change: ACTIVE -> DONE
8/31 15:54:17 [31443] (97.0) gm state change: GM_SUBMITTED -> GM_CHECK_OUTPUT
8/31 15:54:18 [31443] (97.0) gm state change: GM_CHECK_OUTPUT -> GM_DONE_SAVE

上面这个例子中的提交描述文件指定了使用 per-Web 服务 GRAM 的 globus 环境。Globus Toolkit 有多个发行版，每个发行版支持一种不同版本的 GRAM 协议。为了支持不同的 GRAM 协议，globus 环境要替换成 Conder V6.7 中的 grid 环境，并添加另外一个参数 grid_type。grid_type 指定了要使用哪个版本的 Globus GRAM 协议。所支持的 grid_type 有 GT2、GT3 或 GT4，这分别对应于 Globus Toolkit 发行版 2、3、4。如果使用 Condor V6.7 或更高的版本，我们不用像上面的例子中那样指定 globus 环境，而是按照下面的方式来指定 grid 环境和 grid_type：

universe = grid
grid_type = gt2

如果使用 GT3，grid-type 应该设置为 gt3，globusscheduler 属性的格式是一个 URL。下面这个例子给出了 Globus Toolkit 3.x 版本的 globusscheduler 属性的格式：

                
globusscheduler = http://<hostname>:<port>/ogsa/services/base/gram/
ForkManagedJobFactoryService

如果使用 GT4，grid_type 应该设置为 gt4，globusscheduler 的格式应该遵循 WSRF 的实现，如下面的例子所示：

globusscheduler = https://hostname[:port]/wsrf/services/ManagedJobFactoryService

我们在上文中简单地提到过，GRAM Fork 提供了一个简单的执行环境，不过 GRAM 可以与诸如 LSF 或 PBS 之类的资源管理器进行集成。为了支持这种功能，我们向描述文件中添加了另外一个参数来说明 Condor 正在向其提交作业的作业管理器的类型。作业管理器可以是 Fork、PBS 或 LSF。下面是 GT4 使用的提交描述文件的例子，其中指定了 Fork 作业管理器。

                
universe = grid
grid_type=gt4
globusscheduler = https://gt4-test:8443/wsrf/services/ManagedJobFactoryService
jobmanager_type=Fork

在上面的提交描述文件中指定的可执行文件可以在 Globus 上直接使用 globusrun-ws 命令运行。

回页首

结束语

使用 Condor-G 的优点是，它可以通过一个直观的界面提供对多个作业的提交和控制功能，提供通知，并管理 Globus 凭证。另外，Condor matchmaking 也可以用来为一个作业选择最合适的资源。

在本系列文章的第 2 部分中，我们将介绍 Condor-G 中的 matchmaking，并将已经讨论的内容综合起来：Globus Toolkit 提供了基本的网格基础设施组件，可以用来共享分布式资源。Condor 作业提交组件可以与 Globus 一起使用，用来提供一种更为广泛的解决方案。我们所讨论的描述和例子应该已经对如何一起使用这些技术提供了一个基本的理解。

在本系列文章的第 2 部分中，我们将详细介绍 Condor 如何使用资源属性来确定作业最适合的资源。在确定适当的资源之后，Condor 就可以与 Globus 进行协调，从而完成与远程执行和管理有关的任务，包括凭证委托、远程访问和文件分段传输。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• “鹰眼看 Condor 项目” 对 Condor 进行了概要介绍。
  
  
• 请参阅 “网格实践: 在网格中实现 SOA 和 Web 服务” 中有关 Globus Toolkit 和 GRAM 组件的概要介绍。
  
  
• 请访问 developerWorks 中国网站 Grid Computing 专区，上面提供了很丰富的信息，可以帮助您开发网格技术。
  
  
• 密切关注 developerWorks 技术活动 和 网络广播。
  
  

• 有关 Globus Toolkit 的最新信息可以在 Globus Alliance 上找到。
  
  

• 参与论坛讨论。
  
  
• 与 developerWorks 网格计算论坛 的其他参与者交流您的想法。
  
  
• developerWorks blogs 上面有很多日常从事相关工作的人员对技术的内幕介绍。

关于作者

		Jeff Mausolf 是位于德州奥斯汀的 IBM Grid Integration Center 的认证 IT 架构师，这是 Global Technology Integration and Management Competency 的一部分；他作为应用程序架构师和软件工程师开发过商业和政府门户。他参与了网格计算计划（Grid Computing Initiative）的工作，而且曾经参与了很多网格项目，包括撰写了一本关于开发网格服务的 IBM 红皮书。在 14 年前进入 IBM 工作之前，Jeff 从事的是航天工业，先后曾在 Lockheed、Loral 和 Ford AeroSpace 任职。在约翰逊航天中心的那段时间，他支持航天飞机工程模拟（Shuttle Engineering Simulation，SES）实验室的太空人训练计划，帮助构建了空间站的组件，并从事用于航天飞机的 AP101S 通用计算机（GPC）项目。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 将您的建议发给我们或者通过参加讨论与其他人分享您的想法.

回页首