IBM TWS LoadLeveler 使用 Globus Toolkit 交叉网格域

TWS LoadLeveler 是 IBM 开发的一个作业调度系统，用于为大型计算作业实现资源利用率和吞吐量的最大化。它最初是为 AIX 开发的，不过现在也可以在 Linux 上运行。本文说明了如何使用 Globus Toolkit 从外部管理域启用对 TWS LoadLeveler 特性和资源的访问。Globus Toolkit 允许用户通过 Globus 客户机与 TWS LoadLeveler 进行交互。其他的调度系统也可以使用 Globus 基础设施与远程 TWS LoadLeveler 集群协调工作。

TWS LoadLeveler 概述

TWS LoadLeveler 管理一群或一组机器，以提供一个高吞吐量的计算环境。用户向 TWS LoadLeveler 提交作业，而它会将作业请求与可用资源匹配，使作业吞吐量和资源利用率最大化。它会对作业需求和可用资源进行检查，看哪些资源可以满足作业需求，从而为作业找到适当的资源。TWS LoadLeveler 根据优先级、资源需求和资源的可用性对作业进行调度。它可以处理与运行在分布式资源集上的作业相关的管理、执行和记帐。

Globus 概述

Globus Toolkit 是一个开放源码的软件项目，它为开发分布式计算系统提供 Web 服务组件。它提供支持向远程资源提交作业的服务。Globus Toolkit 不提供的是根据定义的一套策略为作业进行资源匹配的调度程序。您需要一个调度程序，它可以在一组资源中控制作业的执行管理。调度程序要考虑资源属性和可用性，并利用这些信息，根据作业需求、当前资源约束和定义的调度策略，做出为作业匹配适当资源的智能的决定。

Globus Toolkit 与一些提供这种功能性的网格调度程序集成。这些调度程序包括 Platform Load Sharing Facility（LSF）、Portable Batch System（PBS）和 TWS LoadLeveler。应用程序可以使用 Globus 的 Grid Resource and Allocation Manager（GRAM）服务以一种标准格式与这些调度程序通信。

Globus GRAM

Globus 的 GRAM 服务使跨管理域的虚拟组织的作业提交、监视、管理和控制更容易。GRAM 提供了一套 WSRF 兼容的 Web 服务，来帮助用户在分布式计算环境中提交和管理作业。GRAM 帮助管理用于作业提交的凭证、监视作业进展和控制作业的执行。GRAM 服务为协调不同的调度系统提供了一种标准的方法，专门优化在复杂环境中的作业执行管理。

GRAM 调度程序

网格是通常是分布式的资源的集合。这些资源由一个资源管理程序或者调度程序 控制。这个调度程序优化资源的使用，以在定义的调度策略下高效地执行网格作业。有很多类型的调度程序可用，包括 LSF、PBS 和 TWS LoadLeveler。GRAM 把标准作业描述翻译成这些调度程序可以执行的命令。

集成 Globus 和 TWS LoadLeveler

本文中，我们主要关注 Globus Toolkit V4 (GT4) 与 TWS LoadLeveler 的集成。这种集成允许用户使用 GT4 客户机在远程 TWS LoadLeveler 集群中提交、监视和控制作业。这里提供的示例使用了 TWS LoadLeveler Linux distribution V3.3.2 和 Globus Toolkit V4.0.2。TWS LoadLeveler-GT4 包中包含了支持 GT4 和 TWS LoadLeveler 的集成的工具，这个包随 TWS LoadLeveler V3.3.x 一起分发。

注意：LoadLeveler 已经被增加到 Tivoli Workload Scheduler 产品的 Tivoli 家族中。Tivoli Workload Scheduler 用于调度分布式系统上的工作负载。它可以与 Tivoli Workload Scheduler for z/OS?0?3 一起使用，来管理 IBM zSeries?0?3 主机上的工作负载。LoadLeveler 已作为 Tivoli Workload Scheduler LoadLeveler 加入该套件。

为了集成 TWS LoadLeveler 与 GT4，GT4 应该已经安装并且运行。最新的版本在 Globus.org 上。GT4 的安装和配置在 GT4 管理指南中有详细说明，该指南也在 Globus.org 上。

在尝试集成 GT4 与 TWS LoadLeveler 之前，必须先安装和配置 TWS LoadLeveler V3.3.x。AIX 5L 和 Linux（RHEL 或者 SuSE）支持 TWS LoadLeveler。名为 “Workload Management with LoadLeveler” 的 IBM 红皮书详细描述了 TWS LoadLeveler，包括安装和配置过程。

下面概述的过程假设已经安装并正确配置了 TWS LoadLeveler V3.3.x 和 GT4。作为 Globus Toolkit 安装和配置的一部分，环境变量 $GLOBUS_LOCATION 被定义来反映 Globus 安装目录。为了 Globus Toolkit 的正常运行必须设置这个环境变量，而且与 TWS LoadLeveler 的集成也需要这个环境变量。GT4 TWS LoadLeveler 集成组件位于 TWS LoadLeveler 发行版的 lib 目录下一个名为 llgrid.tar 的文件中。对于 Linux 系统，路径为 /opt/ibmll/LoadL/full/lib。

准备开始，将 llgrid.tar 归档文件的内容解压到一个目录。如下所示，我们使用 /tmp。

$ cd /tmp

$ tar xvf /opt/ibmll/LoadL/full/lib/llgrid.tar

解压 tar 文件的内容将在文件 globus-loadleveler.conf 所在的位置创建并填充一个 gt4 目录。这个文件为 Scheduler Event Generator（SEG）设置变量 log_path。SEG 使用 Job State Monitor（JSM）监控调度程序，并将作业状态更改报告回 Managed Job Service。因为调度程序有多种实现，所以每一个资源管理程序或者调度程序类型都有一个 SEG。LSF 和 PBS 的 SEG 随 Globus Toolkit 一起发布。TWS LoadLeveler 的 SEG 包含在 TWS LoadLeveler 发行版中，即上一步解压的 llgrid.tar 文件中。该归档文件为 AIX 和 Linux 包含 SEG 的二进制发行版。因为提供了 SEG 源代码，所以可以为其他平台编译 SEG。文件 globus-loadleveler.conf 中的变量 log_path 指出 SEG 日志文件的位置。默认位置是 /var/llglobus/globus-loadleveler.log。

把该位置改为 $GLOBUS_LOCATION/etc/globus-loadleveler.log，如下所示。

[globus@blade31 etc]$ cat globus-loadleveler.conf 

log_path=/usr/local/globus-4.0.2/etc/globus-loadleveler.log

这表明日志文件在 $GLOBUS_LOCATION/var 目录下，其他的 Globus 容器日志文件也在这个目录下。文件 globus-loadleveler.log 将包含作业标识符和状态信息。清单 1 显示了文件 globus-loadleveler.log 的内容示例。

清单 1. 示例 globus-loadleveler.conf 文件

[globus@blade31 var]$ cat globus-loadleveler.log 

001;1149181338;blade31.austin.ibm.com.44.0;2;0
001;1149181338;blade31.austin.ibm.com.44.0;8;0
001;1149181541;blade31.austin.ibm.com.45.0;2;0
001;1149181543;blade31.austin.ibm.com.45.0;4;0
001;1149186611;blade31.austin.ibm.com.46.0;2;0
001;1149186611;blade31.austin.ibm.com.46.0;8;0
001;1149188055;blade31.austin.ibm.com.47.0;2;0
001;1149188055;blade31.austin.ibm.com.47.0;8;0

文件 globus-loadleveler.conf 是惟一一个必须为集成而更新的文件。在相同的 gt4 目录下有一个部署脚本会将集成文件复制到适当的位置。运行部署脚本并且提供启动 Globus 容器的用户名。这个用户一般是 globus，如清单 2 所示。

清单 2. 部署集成文件

[root@blade31 gt4]# ./deploy.sh globus 

Installing Loadleveler scheduler files...

Installing filesystem mapping config file...

Installing SEG library for Linux...

Creating log file for Loadleveler scheduler \
at /usr/local/globus-4.0.2/var/globus-loadleveler.log...

DONE

检查下列文件在 $GLOBUS_LOCATION 识别的 Globus 安装目录下，来验证部署脚本是否成功复制了必要的文件，见清单 3。

清单 3. 验证集成文件

$GLOBUS_LOCATION/lib/perl/Globus/GRAM/JobManager/loadleveler.pm

$GLOBUS_LOCATION/etc/gram-service/globus_gram_fs_map_config.xml

$GLOBUS_LOCATION/etc/gram-service-Loadleveler/jndi-config.xml

$GLOBUS_LOCATION/etc/grid-services/jobmanager-loadleveler

$GLOBUS_LOCATION/etc/globus-loadleveler.conf

$GLOBUS_LOCATION/libexec/globus-scheduler-provider-loadleveler

一旦验证了部署的正确性，就要重启 Globus 容器，即用 $GLOBUS_LOCATION/sbin/globus-stop-container 或者 $GLOBUS_LOCATION/sbin/globus-stop-container-detached 停止容器，然后用 $GLOBUS_LOCATION/sbin/globus-start-container 或者 $GLOBUS_LOCATION/sbin/globus-start-container-detached 启动容器。

祝贺！您已经完成 GT4 TWS LoadLeveler 的集成。

GRAM 作业提交

可以使用应用程序编程接口 (API) 或者使用命令行工具程序化地向 Globus 提交作业。使用命令 globusrun-ws 提交、监视和控制作业。可以指定信息作为 globusrun-ws 的命令行选项，或者可以在基于 XML 的作业描述文件中包含信息。命令 globusrun-ws 是同步的，所以当提交作业的时候不能返回控制。相反，它通过显示作业状态提供反馈信息。根据状态信息，用户可以使用 Ctrl+C 取消作业。

GRAM 作业提交的必备条件

用户要提交作业，必须通过身份验证，拥有有效的凭证。作业可能需要指派用户具有执行远程操作（比如划分文件）的凭证。以下示例假设已经使用命令 grid-proxy-init 生成了一个有效代理。但是，凭证也可以与作业请求一起传递或者上载到 Delegation 服务。清单 4 举例说明了使用命令 grid-proxy-init 生成一个有效代理。

清单 4. 创建网格代理

[globus@blade31 globus]$ grid-proxy-init

Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA-\
blade31.austin.ibm.com/OU=austin.ibm.com/CN=globus

Enter GRID pass phrase for this identity:

Creating proxy ........................................ Done

Your proxy is valid until: Fri Jun  2 23:29:43 2006

通过从 Globus 提交作业，以及请求它在 TWS LoadLeveler 资源上运行，来验证集成可以正确工作。这项工作通过使用命令 globusrun-ws 加上命令行选项 FactoryType 来完成。Globus 使用作业工厂服务来创建代表 WSRF 资源的作业实例。GRAM 与之交互的每一个调度程序都具有一个单独的工厂服务。我们可以调用 TWS LoadLeveler 工厂服务来创建和提交作业。清单 5 举例说明了提交一个运行 date 命令的作业。命令行选项 -c 指定运行命令 /bin/date，而命令行选项 -Ft 指出将会使用 FactoryType Loadleveler。

清单 5. 通过 Globus 提交 LoadLeveler 作业

[globus@blade31 globus]$ globusrun-ws -submit -Ft Loadleveler -c /bin/date

Submitting job...Done.

Job ID: uuid:2cf0e45c-f255-11da-903b-00096b00c5f8

Termination time: 06/03/2006 16:31 GMT

        Current job state: Active

        Current job state: CleanUp

        Current job state: Done

        Destroying job...Done.

这个示例示范如何使用命令 globusrun-ws 加上命令行选项 -c 来运行命令。我提到过，信息可以指定为命令行选项，或者可以包含在基于 XML 的作业描述文件中。我们来创建一个 XML 作业描述文件，它询问 TWS LoadLeveler 集群的状态。这个作业描述文件名为 llstatus.xml。它将识别可执行文件、输出结果和错误文件。清单 6 显示了文件 llstatus.xml 的内容。

清单 6. TWS LoadLeveler 状态作业描述文件

<job>
  <executable>/opt/ibmll/LoadL/full/bin/llstatus</executable>
  <directory>/home/globus/test</directory>
  <stdout>/home/globus/test/llstatus.out</stdout>
  <stderr>/home/globus/test/llstatus.err</stderr>
  <queue>small</queue>
</job>

我们不是使用命令行选项 -c 来提交命令，而是使用作业命令行选项 -f 来提交该作业，该选项表示我们提供一个作业描述文件。命令行选项 -f 后面跟着作业描述文件名。清单 7 举例说明了作业提交。

清单 7. 通过 Globus 询问 TWS LoadLeveler 状态

[globus@blade31 test]$ globusrun-ws -submit -f /home/globus/test/llstatus.xml

Submitting job...Done.

Job ID: uuid:71100226-f18d-11da-8895-00096b00c5f8

Termination time: 06/02/2006 16:41 GMTSubmitting job...Done.

Current job state: Active

Current job state: CleanUp

Current job state: Done

Destroying job...Done.

我们来看一下这个作业的输出结果。输出结果位于我们通过作业描述文件中的 stdout 标记识别的文件中。清单 8 显示了输出文件 llstatus.out 的内容。

清单 8. TWS LoadLeveler 状态输出结果

Name                      Schedd  InQ Act Startd Run LdAvg Idle Arch      OpSys

blade31.austin.ibm.com    Avail     0   0 Idle     0 0.00     8 i386      Linux2   

i386/Linux2                 1 machines      0  jobs      0  running

Total Machines              1 machines      0  jobs      0  running

The Central Manager is defined on blade31.austin.ibm.com

The BACKFILL scheduler is in use

All machines on the machine_list are present.

现在，我们使用 TWS LoadLeveler 命令 llsubmit 来提交 TWS LoadLeveler 作业，但是我们使用一个标准作业描述文件、通过 Globus 来完成。下面的示例使用命令 globusrun-ws 和一个 XML 文件，该文件将可执行文件识别为 TWS LoadLeveler 命令 llsubmit，将参数识别为我们想要运行的 TWS LoadLeveler 作业。我们将运行这个与名为 job1.cmd 的 TWS LoadLeveler 发行版打包在一起的示例作业。除了我们可以使用 Globus 客户机从任何地方提交该作业之外，这完全等价于使用 llsubmit /home/loadl/job1.cmd 向 TWS LoadLeveler 集群提交作业。清单 9 显示了作业描述文件的内容。

清单 9. TWS LoadLeveler 提交作业描述文件

<job>
    <executable</opt/ibmll/LoadL/full/bin/llsubmit</executable>
    <argument>/home/loadl/job1.cmd</argument>
    <stdin>/dev/null</stdin>
    <stdout>/home/globus/test/llsubmit.out</stdout>
    <stderr>/home/globus/test/llsubmit.err</stderr>
    <queue>small</queue>
</job>

我们将使用命令 globusrun-ws 向 Globus 提交这个作业描述文件，如清单 10 所示。

清单 10. Globus 作业向 TWS LoadLeveler 提交作业

[globus@blade31 test]$ globusrun-ws -submit -f /home/globus/test/llsubmit.xml 

Submitting job...Done.

Job ID: uuid:616a751a-f190-11da-80bf-00096b00c5f8

Termination time: 06/02/2006 17:02 GMT

Current job state: Active

Current job state: CleanUp

Current job state: Done

Destroying job...Done.

Globus 作业描述文件中指定的输出文件将包含执行命令 llsubmit、向 TWS LoadLeveler 提交作业所产生的输出结果。llsubmit 的输出结果如下所示。

[globus@blade31 test]$ cat llsubmit.out

llsubmit: The job "blade31.austin.ibm.com.42" has been submitted.

清单 11 显示了上一步中提交的 TWS LoadLeveler 作业。这是利用 TWS LoadLeveler 分布的作业示例。

清单 11. TWS LoadLeveler 作业

#!/bin/sh
#
# Sample script to show basic function of LoadLeveler
# - since no "executable" is specified, this file "job1.cmd" will be used as
#   the executable
#
# @ class   = small
# @ error   = job3.$(Host).$(Cluster).$(Process).err
# @ output  = job3.$(Host).$(Cluster).$(Process).out
# @ queue   = small

echo The name of this job is $0
echo
echo This job is running on `hostname`
echo
echo This job is running from `pwd`
echo 
echo These ids are logged onto the system:
who
echo

清单 12 显示了 TWS LoadLeveler 示例作业的输出结果。

清单 12. TWS LoadLeveler 作业的输出结果

[globus@blade31 test]$ cat job3.blade31.42.0.out 

The name of this job is /home/loadl/execute/blade31.austin.ibm.com.42.0/job1.cmd

This job is running on blade31.austin.ibm.com

This job is running from /home/globus/test

These ids are logged onto the system:

root     pts/1        Jun  2 08:37 (sig-9-76-105-85.mts.ibm.com)
root     pts/2        Jun  2 11:21 (sig-9-76-105-85.mts.ibm.com)

现在，不是使用 Globus 来提交使用 TWS LoadLeveler 特定作业脚本的 TWS LoadLeveler 作业，我们将向 Globus 提交一个标准作业描述，并且指定 TWS LoadLeveler 的 FactoryType。Globus 将标准作业描述文件映射到适当的 TWS LoadLeveler 命令，以提交并运行作业。清单 13 显示了标准作业描述文件。

清单 13. 针对 Globus 的标准作业描述文件

<job>
  <executable>/home/globus/test/env-test.pl</executable>
  <directory>/home/globus/test</directory>
  <stdout>/home/globus/test/gt4LLtest1.out</stdout>
  <stderr>/home/globus/test/gt4LLtest1.err</stderr>
  <queue>small</queue>
</job>

清单 14 显示了我们如何使用命令 globusrun-ws 提交标准作业描述文件，并使用 FactoryType 命令行选项 -Ft 指定它应该由 TWS LoadLeveler 来运行。

清单 14. 向 LoadLeveler Factory 提交 Globus 作业描述

[globus@blade31 test]$ globusrun-ws -submit \
-Ft Loadleveler -f /home/globus/test/gt4LLtest1.xml 

Submitting job...Done.

Job ID: uuid:5fa04758-f4ad-11da-954b-00096b00c5f8

Termination time: 06/06/2006 16:07 GMT

Current job state: Active

Current job state: CleanUp

Current job state: Done

Destroying job...Done.

该作业的输出结果被定向到由作业描述文件中的 stdout 标记指定的文件。清单 15 显示了输出文件的内容。

清单 15. Globus 作业的输出结果

[globus@blade31 test]$ cat gt4LLtest1.out

GLOBUS_GRAM_JOB_HANDLE = \
https://9.3.42.41:8443/wsrf/services/ManagedExecutableJobService \
                                               ?5fa04758-f4ad-11da-954b-00096b00c5f8
GLOBUS_LOCATION = /usr/local/globus-4.0.2
GLOBUS_LOG_FILE = /usr/local/globus-4.0.2/var/globus-loadleveler.log
HOME = /home/globus
HOSTNAME = blade31.austin.ibm.com
JAVA_HOME = /usr/java/jdk1.5.0_06/jre
LOADLBATCH = yes
LOADL_ACTIVE = 3.3.2.0
LOADL_COMM_DIR = /tmp
LOADL_JOB_NAME = blade31.austin.ibm.com.77
LOADL_PID = 14626
LOADL_PROCESSOR_LIST = blade31.austin.ibm.com 
LOADL_STARTD_PORT = 9611
LOADL_STEP_CLASS = small
LOADL_STEP_COMMAND = /home/globus/.globus/5fa04758-f4ad-\
11da-954b-00096b00c5f8/scheduler_loadleveler_job_script
LOADL_STEP_ERR = /home/globus/test/gt4LLtest1.err
LOADL_STEP_ID = blade31.austin.ibm.com.77.0
LOADL_STEP_INITDIR = /home/globus/test
LOADL_STEP_OUT = /home/globus/test/gt4LLtest1.out
LOADL_STEP_OWNER = globus
LOADL_STEP_TYPE = SERIAL
LOGIN = globus
LOGNAME = globus
USER = globus
X509_CERT_DIR = /etc/grid-security/certificates

上面的示例使用命令行选项 -FactoryType 来指定我们向 Globus 提交的作业应该由 TWS LoadLeveler 管理。这也可以使用 ResourceID 标记表达在作业描述文件中，如清单 16 所示。

清单 16. 在 Globus 作业描述中指定资源

<job>
    <factoryEndpoint xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job" 
     xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
        <wsa:Address>
            https://blade31.austin.ibm.com:8443/wsrf/services/ManagedJobFactoryService
        </wsa:Address>
        <wsa:ReferenceProperties>
            <gram:ResourceID>Loadleveler</gram:ResourceID>
        </wsa:ReferenceProperties>
    </factoryEndpoint>
    <executable>/home/globus/test/env-test.pl</executable>
    <stdin>/dev/null</stdin>
    <stdout>/home/globus/test/gt4LLtest2.out</stdout>
    <stderr>/home/globus/test/gt4LLtest2.err</stderr>
</job>

除了使用同步模式以外，还可以用批处理模式使用命令 globusrun-ws 来提交后台作业。要使用批处理模式，用户需要向 Managed Job 资源指定一个文件，GRAM 应该将 Job End-Point-Reference (EPR) 存储在该文件中。然后，用户可以在随后的与该作业相关的命令中指定该作业 EPR。在清单 18 显示的示例中，我们将提交一个作业，并通过使用命令行选项 -batch 指定它应该在后台运行。我们还提供另一个命令行选项 ?? -o，来指定 job EPR 写入到的输出文件。因为控制立刻返回到用户，所以用户可以在作业运行的时候执行其他工作。通过使用命令 globusrun-ws 加命令行选项 -status 并指定 -job-epr-file（它识别与作业相关联的 Managed Job 对象），可以获得后台作业的状态。

清单 17. 在 Globus 作业描述中指定资源

[globus@blade31 test]$ globusrun-ws -submit \
-batch -f /home/globus/test/gt4LLtest2.xml -o jobEPR

Submitting job...Done.

Job ID: uuid:28e9f988-f4ae-11da-8013-00096b00c5f8

Termination time: 06/06/2006 16:13 GMT

通过使用命令 globusrun-ws 加命令行选项 -status，后跟 -job-epr-file 或 -j 命令行选项，并指定作业提交时所提供的作业 EPR 文件的名称，可以获得作业状态。下面的代码显示了使用命令 globusrun-ws 的格式，用于获得提交的作业（其中作业 EPR 存储在文件 jobEPR 中）的状态。

[globus@blade31 test]$ globusrun-ws -status -j jobEPR

Current job state: Done

现在我们向 Globus 提交一个长期运行的作业，并从 Globus 和 TWS LoadLeveler 端检查状态。清单 19 显示了文件 gt4LLtest3，为了让我们能够看到它处于运行状态，该文件运行一个将会睡眠几分钟的脚本。

清单 19. 长期运行作业的作业描述

<job>
    <factoryEndpoint xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job" 
     xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
        <wsa:Address>
            https://blade31.austin.ibm.com:8443/wsrf/services/ManagedJobFactoryService
        </wsa:Address>
        <wsa:ReferenceProperties>
            <gram:ResourceID>Loadleveler</gram:ResourceID>
        </wsa:ReferenceProperties>
    </factoryEndpoint>
    <executable>/home/globus/test/sh_loop3.csh</executable>
    <stdin>/dev/null</stdin>
    <stdout>/home/globus/test/gt4LLtest3.out</stdout>
    <stderr>/home/globus/test/gt4LLtest3.err</stderr>
</job>

清单 20 显示了我们如何以批处理模式向 Globus 提交这个作业描述文件，并请求放置在文件 gt4LLtest3.epr 中的作业 EPR。

清单 20. 提交批处理作业

[globus@blade31 test]$ globusrun-ws \
-submit -batch -f /home/globus/test/gt4LLtest3.xml -o gt4LLtest3.epr

Submitting job...Done.

Job ID: uuid:8f1ae93c-f4d2-11da-8fd6-00096b00c5f8

Termination time: 06/06/2006 20:33 GMT

使用命令 globusrun-ws 加命令行选项 -status 和 -j，后跟作业 EPR 文件的名称，可通过 Globus 获得作业状态。

[globus@blade31 test]$ globusrun-ws -status -j gt4LLtest3.epr

Current job state: Active

如果 Globus 显示作业状态是活跃的，我们应该能够使用命令 llq 看到它运行在 TWS LoadLeveler 集群上。

清单 21. 批处理作业的 TWS LoadLeveler 状态

[globus@blade31 test]$ llq
Id                       Owner      Submitted   ST PRI Class        Running On 
------------------------ ---------- ----------- -- --- ------------ -----------
blade31.83.0             globus      6/5  15:33 R  50  small        blade31

1 job step(s) in queue, 0 waiting, 0 pending, 1 running, 0 held, 0 preempted

当这个作业完成后，作业提交者会通过电子邮件得到通知。电子邮件包含与该作业相关的详细信息，包括运行作业所消耗的资源。

清单 22 显示了为我们的长期运行作业指定为可执行文件的脚本。

清单 22. 我们的长期运行作业脚本

[globus@blade31 test]$ cat sh_loop3.csh
#!/bin/csh
set i = 1
set t = 123
while ($i <= $t)
        echo -n $i " " >> /tmp/sh_loop.out
        /bin/sleep 1
        @ i = $i + 1
end
echo "" >> /tmp/sh_loop.out
echo "Normal End-of-Job-sh_loop" >> /tmp/sh_loop.out
echo "" >> /tmp/sh_loop.out
echo `date` >> /tmp/sh_loop.out
echo "" >> /tmp/sh_loop.out

清单 23 显示了长期运行作业脚本的输出结果。

清单 23. 作业输出结果

[globus@blade31 test]$ cat /tmp/sh_loop.out

1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22 23  
24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  
45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  
66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83  84  85  86  
87  88  89  90  91  92  93  94  95  96  97  98  99  100  101  102  103  104  105  
106  107  108  109  110  111  112  113  114  115  116  117  118  119  120  121  122  123  

Normal End-of-Job-sh_loop

Mon Jun 5 15:35:39 CDT 2006

这些示例说明了一个提交给 Globus 的标准的基于 XML 的作业描述文件。Globus JobManager 把这个标准作业描述翻译成特定于调度程序的作业命令。我们仅仅示范了可用作业描述属性的一个小子集。表 1 列出了附加的作业描述属性以及它们映射到的相应 TWS LoadLeveler 关键字。

表 1. 模型能级

RSL 属性	命令文件关键字
`directory`	`initialdir`
`stdin`	`input`
`stdout`	`output`
`stderr`	`error`
`count`	`total_tasks`
`environment`	`environment`
`maxTime`	`wall_clock_limit`
`maxWallTime`	`wall_clock_limit`
`maxCpuTime`	`cpu_limit`
`jobType`	`job_type`
`queue`	`class`
`hostCount`	`node`

对于串行作业，这些属性足够描述作业了。并行作业需要附加属性。附加属性可以使用以 GBLL_ 打头的环境变量来表示。当指定环境变量 GBLL_ 时，TWS LoadLeveler JobManager 会创建相应的 LoadLeveler 作业命令文件关键字。表 2 列出了环境变量 GBLL_ 和相应的 TWS LoadLeveler 作业命令文件关键字。

表 2. GBLL 环境变量与相应的命令文件关键字

GBLL 环境变量	作业命令文件关键字
`GBLL_COMMENT`	`comment`
`GBLL_BLOCKING`	`blocking`
`GBLL_TASK_GEOMETRY`	`task_geometry`
`GBLL_REQUIREMENTS`	`requirements`
`GBLL_PREFERENCES`	`preferences`
`GBLL_MIN_PROCESSORS`	`min_processors`
`GBLL_MAX_PROCESSORS`	`max_processors`
`GBLL_TASKS_PER_NODE`	`tasks_per_node`
`GBLL_NETWORK_MPI`	`network.mpi`
`GBLL_NETWORK_LAPI`	`network.lapi`
`GBLL_NETWORK_MPI_LAPI`	`network.mpi_lapi`
`GBLL_NETWORK_PVM`	`network.pvm`
`GBLL_RESTART`	restart

结束语

我描述了集成 Globus Toolkit 与 TWS LoadLeveler 的过程，并提供了验证集成正确性的示例。您现在应该对 Globus Toolkit 和 TWS LoadLeveler 有了一个基本的了解，可以尝试进行这种集成了。现在您可以一起使用这些工具来扩充 TWS LoadLeveler 集群的域，或者使用 Globus 作为管道与其他调度系统结合使用 LoadLeveler 了。