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 了。
--------------------------------------------------------------------------------
新 闻 技 术 专 题
帮助
全部新闻 业内新闻 java新闻 Linux新闻 ajax新闻 数据库新闻
相关文章:
[1] IBM WebSphere 开发者技术期刊: 在 WebSphere Application Server 中使用 Java Secure Socket Extension
[2] 关于IBM DB2 数据库的使用小技巧小结
[3] 在Windows系统上安装IBM DB2通用数据库企业版
[4] IBM DB2数据库几个应用上的小技巧
[5] Sybase和IBM创造新Linux事务处理纪录
