级别： 初级 Jeff Mausolf (mausolf@us.ibm.com), IT 架构师, IBM Global Services, Global Technology Center, Grid Computing Initiative
2006 年 7 月 31 日 IBM® Tivoli® Workload Scheduler LoadLeveler® 是一个在 AIX® 和 Linux® 上使用的高级调度系统。本文对这种产品进行了概要介绍，并展示了在 LoadLeveler 环境中如何提交、监视和控制作业。
简介
IBM Tivoli Workload Scheduler（TWS）LoadLeveler 是一个作业调度系统，开发目标是用来为大型计算作业实现资源利用率和吞吐量的最大化。它最初是为 AIX 开发的，不过现在也可以在 Linux 上运行。TWS LoadLeveler 可以根据优先级、资源需求和资源的可用性对串行或并行的作业进行调度。它可以处理与运行在分布式资源集上的作业相关的管理、执行和记帐。
本文对 TWS LoadLeveler 系统简要进行了介绍，并介绍了与在这种环境中创建和运行作业有关的概念。我们将开发一个简单的作业来阐述如何对作业进行创建、提交和管理。
TWS LoadLeveler 是如何工作的？
TWS LoadLeveler 池是一组负责对资源进行协调从而可以提供高吞吐量计算环境的机器集。我们可以认为它就是一个分布式计算集群，其中包括了调度器、中央管理器和多个计算节点。当用户提交作业时，作业就被加入到作业队列中，而作业队列是由调度器进行管理的。
调度器会为每个作业都分配一个惟一的标识符，并通知中央管理器现在有一个新的作业需要使用资源。
中央管理器会负责寻找可以用来处理这个作业的可用资源。它会对作业需求和可用资源进行检查，看是否这些资源可以满足作业需求，从而为作业找到适当的资源。当中央管理器找到可以满足作业需求的资源时，它就通知调度器。调度器然后会联系所选择的资源，并请求它来运行这个作业。
计算机资源是通过派生一个子进程来运行作业的，这个进程会在作业提交者的用户 ID 之下运行。当作业启动时，计算资源会通知中央管理器这个作业正在运行。当作业完成时，LoadLeveler 就会生成有关作业所消耗的资源的记帐信息。
组成 TWS LoadLeveler 的进程
有很多进程一起协调来提供这种高吞吐量的计算环境。这些进程都是在调度器、中央管理器或计算节点上运行的。下面是对构成 TWS LoadLeveler 环境的进程的一个总结。
Master
master 进程在 TWS LoadLeveler 池中的每台机器上都会运行。它首先读取本地配置信息，然后启动应该在这台机器上启动的其他进程。根据机器是配置成计算节点、调度器还是中央管理器，所启动的进程可能会有所不同。在启动适当的进程之后，master 就开始负责对这些进程进行监视。如果一个进程失败了，master 就试图重新启动它。如果 master 要重新启动某个进程，它会向管理员发送一封有关问题情况的 e-mail，并将与失败进程有关的信息（例如终止状态和日志文件）发送给管理员。
Scheduler
scheduler 负责对作业队列进行管理。它接收用户的请求来运行作业，并为每个新作业都分配一个惟一的标识符。它会通知中央管理器有作业请求出现的情况，并当中央处理器已经为作业找到适当的资源时，scheduler 会派生一个 shadow 进程来处理这个作业。shadow 进程负责对在计算资源上运行的作业进行监视，并在作业完成时通知 scheduler。scheduler 会将这些信息转发给中央管理器。
Shadow
shadow 进程是在中央管理器为作业选择好资源之后由 scheduler 启动的。shadow 进程会与为运行这个作业而选定的计算资源上的 startd 进程进行联系。startd 然后会派生一个 starter 进程来管理作业的执行。shadow 进程需要将可执行文件以及相关的作业信息发送给 starter 进程。当
作业完成时，shadow 就会从 starter 进程接收作业的退出状态，并将其返回给 scheduler，然后退出。
startd
计算节点运行了一个名为 startd 的启动进程。当它从 scheduler 接收到运行作业的请求时，就会派生一个 starter 进程，并对作业和机器上的资源进行监视。startd 会将这些信息转发给中央管理器，这样它就可以在与其他作业进行匹配时被当作一个因素考虑进去。当作业完成时，startd 会搜集有关机器状态和作业所消耗的资源的信息。这些信息会被发送给中央管理器用来进行记帐。
Starter
starter 进程是由 startd 进程派生的，用来运行作业。它与调度机器上的 shadow 进程进行联系，以便获得与这个作业有关的可执行文件和其他相关信息。它通过派生一个子进程来运行作业，这个子进程是在作业提交者的用户 ID 之下运行的，然后它会将正在运行的作业的状态通知给中央管理器。当子进程完成运行作业时，starter 进程会将作业的退出状态返回给 shadow，后者会将这些信息转发给 scheduler 并退出。
中央管理器
中央管理器 了解池中所有的资源信息。它维护了有关作业和机器的状态信息。机器信息包括一个描述可用资源的属性列表。当中央管理器接收到 scheduler 发来的有新作业的通知时，就检查机器的资源属性来确定哪台机器可以满足作业的需求。在找到合适的资源时，中央管理器会将作业状态设置为 pending，并请求 scheduler 在这个资源上运行这个作业。
TWS LoadLeveler 用户视图
现在我们已经基本了解了 TWS LoadLeveler 池中的机器和进程是如何进行协调来提供一个高吞吐量的计算环境的。
TWS LoadLeveler 作业类
TWS LoadLeveler 使用类来对作业在资源上进行调度。作业类 定义了与某种类型的作业有关的特性，例如优先级、运行限制和资源。管理员负责创建作业类并为这些类提供一个有意义的名字，这样用户就可以简单地将自己的作业与适当的作业类进行关联了。TWS LoadLeveler 默认的作业类包括 small、medium、large、very long、parallel 或 interactive。管理员也可以创建其他作业类。
资源属主或管理员可以确定在一台机器上可以运行哪些作业类。他们可以指定机器可以接受的作业类，以及在资源上允许运行的每类作业的个数。下面的例子给出了一个样例配置，它指定了在这台机器上可以运行 8 个 small 作业、5 个 medium 作业 以及两个 large 作业。
CLASS = small(8) medium(5) large(2)
|
TWS LoadLeveler 可消费的资源
与每台机器相关的属性，例如 CPU、内存和磁盘空间，都被认为是可消费的资源。这些资源从以下意义上来说都是可消费的：作业需要使用特定数量的资源，在执行完成之后会将这些资源释放。可消费的资源可以为某台特定的机器指定，或者为整个集群指定。
机器资源 包括诸如 CPU、内存和机器上的可用磁盘空间之类的东西。浮动资源 在集群中的所有机器上都是可用的 —— 例如，浮动软件许可证。管理员可以指定池中的机器和浮动可消费资源。中央管理器可以在将作业与资源进行匹配时对这些资源进行考虑。用户可以在提交作业时指定作业所需要的资源。中央管理器会为作业查找所需要的可消费资源，并检查机器上的可用可消费资源来确定在哪里运行作业。
当作业被调度在一台机器上运行时，中央管理器会将这台机器上的可消费资源减少这个作业所需要的数量。当作业完成时，可消费资源又会增加相同的数量。
TWS LoadLeveler 调度器
TWS LoadLeveler 可以使用不同的调度算法，这取决于需要运行的作业的类型。管理员可以在 TWS LoadLeveler 管理配置文件中选择和指定所使用的调度算法。在 TWS LoadLeveler 中提供了默认调度器、backfill 调度器 和 gang 调度器。
默认调度器
默认调度器 是通过将作业在空闲资源上进行调度来运行作业的。默认调度器可以根据任务负载情况启动作业、挂起作业或恢复作业的执行。在对并行作业进行调度时，节点在变为可用时都会被保留。所保留的节点会一直保持空闲状态，直到有足够的节点可以用来运行这个并行作业。由于这个作业将所保留的节点一直保持空闲状态，直到累积到足够的节点为止，因此在调度大型的并行作业时，这会导致总体利用率很低。
Backfill 调度器
backfill 调度器 负责对大型的并行作业在很多资源上进行调度，然后查找一些较小的作业来填补空闲资源的空白。back-filling 算法会运行那些需要少量资源的短小作业，而较大的作业都要等待有足够的节点来运行。较短的作业只要不会延迟较大作业的启动，就可以在空闲资源上运行。
这个调度器通过对大型作业的计划启动时间与小型作业的 wall_clock_limit 时间进行比较来确定小型作业是否可以运行。如果小型作业可以在大型作业预期的启动时间之前完成，就可以运行。为了使用 backfill 调度器，用户必须为作业设置一个 wall_clock_limit 值，或者系统管理员必须为每个作业类都设置一个 wall_clock_limit 值。
wall_clock_limit 是作业完成所需要的时间的上限。如果作业运行时间长于 wall_clock_time 值，那我们就假设这个作业已经被终止了。虽然这看起来可能非常粗糙，但是却需要对作业的执行时间精确进行计算，这样才能让调度器可以更有效地进行调度。
Gang 调度器
作业的启动时间取决于队列中在这个作业之前还有多少作业，以及正在运行的作业何时完成。长时间运行的作业可能会延迟其他作业的启动。分时算法将处理器时间以很小的时间片分配给作业。gang 调度器 的工作方式与使用上下文切换来支持分时和空间共享的操作系统类似。gang 是一组与作业相关的任务。这些任务在多台机器上被调度用来同时运行，每个任务都接收一定的时间片来执行作业。
开始
作业命令文件
用户可以在作业命令文件中对作业进行描述，然后将这个命令文件提交给 TWS LoadLeveler 来运行这个作业。
下面这个例子通过创建一个简单的命令文件来提交样例作业，从而展示了 TWS LoadLeveler 的特性。命令文件应该包含对作业进行描述、对版本历史和变化进行跟踪的注释。每一行开头的 # 号（#）表示该行是一个注释。如果 # 之后是 @ 符号（@），就表示这是一个关键字。关键字用来指定与作业相关的输入、输出和错误文件，以及作业类。要查看管理员已经定义了哪些类，请使用 llclass 命令。
清单 1. llclass 命令
[loadl@blade31 loadl]$ llclass
Name MaxJobCPU MaxProcCPU Free Max Description
d+hh:mm:ss d+hh:mm:ss Slots Slots
--------------- -------------- -------------- ----- ----- ---------------------
large undefined undefined 2 2
medium undefined undefined 5 5
small undefined undefined 8 8
|
有关作业类的其他信息可以使用 -l 标记进行查看。
清单 2. llclass 命令的参数
[loadl@blade31 loadl]$ llclass -l large
=============== Class large ===============
Name: large
Priority: 0
Exclude_Users: adams
Include_Users:
Exclude_Groups:
Include_Groups: staff
Admin:
NQS_class: F
NQS_submit:
NQS_query:
Max_processors: -1
Maxjobs: -1
Resource_requirement:
Class_comment: large job class for grid integration center cluster
Class_ckpt_dir:
Ckpt_limit: undefined, undefined
Wall_clock_limit: 00:30:00, undefined (1800 seconds, undefined)
Def_wall_clock_limit: 00:30:00, undefined (1800 seconds, undefined)
Job_cpu_limit: undefined, undefined
Cpu_limit: undefined, undefined
Data_limit: undefined, undefined
Core_limit: undefined, undefined
File_limit: undefined, undefined
Stack_limit: undefined, undefined
Rss_limit: undefined, undefined
Nice: 0
Free_slots: 2
Maximum_slots: 2
Execution_factor: 1
Max_total_tasks: -1
Max_proto_instances: 2
Preempt_class:
Start_class:
User default: maxidle(-1) maxqueued(-1) maxjobs(-1) max_total_tasks(-1)
|
下面的命令文件是为一个 small 作业使用的，它将错误重定向到 simple.err 文件中，将输出重定向到 simple.out 文件中，并对作业进行排队。作业会首先进行睡眠，然后显示作业名和主机名。sleep 命令是用来让我们可以在作业完成之前查看作业的状态。
清单 3. 作业命令文件
#
# Simple sample script that will demonstrate submitting jobs to LL
#
# @ class = small
# @ error = simple.err
# @ output = simple.out
# @ queue
#
sleep 60
echo Job $0 is running on `hostname`
|
提交作业
作业是使用 llsubmit 命令来提交的，后面跟上命令文件。
[loadl@blade31 loadl]$ llsubmit simple.cmd
llsubmit: The job "blade31.austin.ibm.com.15" has been submitted.
|
作业状态
一旦作业被提交之后，状态就可以使用 llq 命令进行查看：
清单 4. llq 命令
[loadl@blade31 loadl]$ llq
Id Owner Submitted ST PRI Class Running On
------------------------ ---------- ----------- -- --- ------------ -----------
blade31.15.0 loadl 5/12 14:02 R 50 small blade31
1 job step(s) in queue, 0 waiting, 0 pending, 1 running, 0 held, 0 preempted
|
集群状态
池中所有资源的状态都可以使用 llstatus 命令进行查看。
清单 5. llstatus 命令
[loadl@blade31 loadl]$ llstatus
blade31.austin.ibm.com Avail 1 1 Run 1 2.00 0 i386 Linux2
i386/Linux2 1 machines 1 jobs 1 running
Total Machines 1 machines 1 jobs 1 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 会通知提交者，并以 e-mail 的形式提供作业总结信息。
清单 6. 通知
From loadl@blade31.austin.ibm.com Tue May 16 10:03:53 2006
Date: Tue, 16 May 2006 10:03:53 -0500
From: loadl@blade31.austin.ibm.com
To: mausolf@blade31.austin.ibm.com
Subject: blade31.austin.ibm.com.16
From: LoadLeveler
LoadLeveler Job Step: blade31.austin.ibm.com.16.0
Executable: /home/mausolf/simple.cmd
Executable arguments:
State for machine: blade31.austin.ibm.com
LoadL_starter: The program, simple.cmd, \
exited normally and returned an exit code of 0.
This job step was dispatched to run 1 time(s).
This job step was rejected by Starter 0 time(s).
Submitted at: Tue May 16 09:58:52 2006
Started at: Tue May 16 09:58:53 2006
Exited at: Tue May 16 10:03:53 2006
Real Time: 0 00:05:01
Job Step User Time: 0 00:00:00
Job Step System Time: 0 00:00:00
Total Job Step Time: 0 00:00:00
Starter User Time: 0 00:00:00
Starter System Time: 0 00:00:00
Total Starter Time: 0 00:00:00
|
有些用户可能习惯使用上面展示的命令行接口，而另外一些用户则可能喜欢使用图形用户界面（GUI），系统中也提供了这样一个工具 xloadl。
图 1. xloadl —— 选择作业进行提交
图 2 给出了通过 xload GUI 来查看的作业状态。
图 2. xloadl —— 状态
结束语
在 TWS LoadLeveler 中，中央管理器可以了解池中所有的资源信息。每台机器都会向中央管理器发送有关可用资源的信息。
当用户提交作业时，调度器会将作业放入作业队列中。调度器会与中央管理器进行协调，从而定位可以满足作业需求的资源，然后与所选择的资源进行联系，从而运行作业。用户可以通过命令行或使用 xloadl GUI 将作业提交给 TWS LoadLeveler。TWS LoadLeveler 可以处理与确定应该何时、何地运行作业有关的复杂性（这是为了实现作业吞吐量和资源利用率的最大化）。
TWS LoadLeveler V8.3 可以用于 AIX 和 Linux。
参考资料 学习
获得产品和技术
-
在您的下一个开发项目中采用 IBM 试用版软件，这些软件可以从 developerWorks 上直接下载。
讨论
关于作者  | 
| | Jeff Mausolf 是位于德州奥斯汀的 IBM Grid Integration Center（这是 Global Technology Integration and Management Competency 的一部分）的认证 IT 架构师，他作为应用程序架构师和软件工程师开发过商业和政府门户。他参与了网关计算计划（Grid Computing Initiative）的工作，而且曾经参与了很多网格项目，包括撰写了一本关于开发网格服务的 IBM 红皮书。在 14 年前进入 IBM 工作之前，Jeff 从事的是航天工业，先后曾在 Lockheed、Loral 和 Ford AeroSpace 任职。在约翰逊航天中心的那段时间，他支持航天飞机工程模拟（Shuttle Engineering Simulation，SES）实验室的太空人训练计划，帮助构建了空间站的组件，并从事用于航天飞机的 AP101S 通用计算机（GPC）项目。 |
对本文的评价
| 
