与外部进行沟通，第 2 部分: 使用 Condor-G 与 Globus Toolkit 集成网格资源

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

级别： 初级

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

2006 年 3 月 27 日
2007 年 6 月 08 日 更新

“与外部进行沟通，第 1 部分” 展示了如何充分利用 Globus 和 Condor 的功能在异构网格中为作业提交、监视和控制提供一个易于使用的接口。现在，作者将讨论有关使用 Condor classAds 和 matchmaking 的过程。作者使用 Globus 作为资源的管道（其中作业执行管理是由资源管理器控制的，例如 IBM LoadLeveler、Platform LSF 或 PBS），讨论了一种用来将这种功能扩展到 Condor 之外的方法。本文对一些技术进行了讨论，这些技术用来搜集资源管理器信息，并使用一些工具与 Condor 控制管理器进行通信，从而可以使用它们来确定有关何时、何地运行作业的智能决策。

为什么要与 Globus Toolkit 一起使用调度器？

本系列文章的 第 1 部分 讨论了与 Globus Toolkit 一起使用 Condor 的好处，这可以为在一个可能跨越多个管理域的异构网格计算环境中进行作业提交、监视和控制提供一个易于使用的接口。

正如在上一篇文章中介绍的一样，Globus Toolkit 提供了一些服务来支持作业的提交、监视和控制 —— 同时还提供了一个安全基础设施，并为资源的监视、发现和管理提供了一些服务。它是基于开放标准的，并提供了一些构造块来促进网格解决方案的开发和集成。这些构造块提供了网格基础设施的大部分内容。

然而，您需要选择一个调度组件来增强 Globus 的基础设施，并添加一些智能调度策略来最大化作业的吞吐量和资源的使用。调度器可以确定在何时何地运行某个作业，然后与 Globus 进行协调，从而执行相关的认证、文件划分、监视以及对远程执行环境的控制等任务。Condor 可以使用 classAds 和 matchmaking 技术来提供这种调度能力。

回页首

使用 Condor-G 作为 Globus Toolkit 的前端

Condor 用来与 Globus 进行协调的工具称为 Condor-G。Condor-G 使用了 Condor 的作业管理特性，以及 Globus Toolkit 的资源访问特性。Globus Toolkit 提供了认证机制、与远程资源之间的数据传输功能以及远程执行环境。使用 Condor 作为 Globus Toolkit 的前端可以通过提供监视和控制功能，以及通知、容错机制和证书管理功能，来简化对作业的管理。

第 1 部分 介绍了如何使用 Globus 将作业提交到指定的资源上。有些用户在熟悉网格环境并且了解了有关资源及其可用性和使用情况之后，可能会希望将作业提交到某个特定的资源上。作业可能需要访问只在某个特定资源上可以使用的数据或软件。然而，很多用户都会希望自己只需要简单地运行作业，并让调度器来确定在何时何地真正执行作业，同时允许网格中间件来处理与调度和执行管理有关的有效分布式计算问题所带来的复杂性。在这种情况中，我们可以使用 Condor matchmaking，从而允许 matchmaker 选择适当的资源来执行这个作业，然后使用 Globus 与远程资源进行协调。

回页首

网格中的 matchmaking 是什么？

Matchmaking 就是使用 classAds 将作业匹配到资源上。classAd 允许机器广播 “自己所有的资源可以使用了” 这种消息，作业可以广播它们需要的资源。Condor 利用这些作业和资源 classAds，将最适合运行作业的资源与作业的资源需求进行匹配。

回页首

ClassAds

资源 ClassAds

在机器运行作业时，资源 classAds 会广播机器的属性和条件。典型的机器属性包括内存总量、CPU 类型、CPU 时钟速度以及当前的负载。在这台机器上接受并运行作业的条件也可以指定，这样就可以只在机器上没有其他操作时或只在一天中的特定时间来运行作业了。资源的所有者可以控制何时以及如何使用这些资源。所有者也可以为用户或用户组指定特定的优先级。

作业 ClassAds

作业 classAd 指定了作业所需要的机器的类型，以及运行这个作业可以接受的属性的最大值和最小值。例如，作业 classAd 可以指定作业必须在 Linux® 操作系统上运行，而且机器必须是 Intel® 体系结构的，要具有 2 GB 的可用内存和 40 GB 的磁盘空间。Condor 会查看作业的 classAd 和所有机器的 classAds，从而确定最终的匹配可以满足两方的要求。如果有多个资源都可以满足作业的需求，那么我们可以按一个资源 classAd 属性对这些资源进行评级。例如，对于可以满足或超过作业需求的资源，我们可以选择时钟速度最快或具有最多内存的一个。

回页首

广播

在一个 Condor 池中，资源可以周期性地发送一个资源 classAd 给中央管理器（central manager）。中央管理器包括了一个进程，用于搜集池中所有资源的资源 classAds。当提交作业时，另外一个中央管理器进程会查询资源 classAds 集来确定哪个资源可以匹配作业的需求。在使用 Condor-G 时，一旦在作业与资源之间确定一个匹配之后，就通过 Globus 把作业从 Condor 提交到远程资源上。远程资源正在运行的都是 Globus，而不是 Condor 软件。由于 Condor 并没有在远程资源上运行，因此它就没有通过一个资源 classAd 将远程资源属性广播到 Condor 中央管理器上。

为了 matchmaker 能够了解有关远程 Globus 资源的信息，并可以调度作业在这些资源上运行，我们必须通过生成并发送一个代表资源 classAd 而手动将该资源广播到 Condor 上。如果我们构建了 classAd 结构并搜集了填充 classAd 的资源信息，那就可以使用 condor_advertise 命令将这些信息发送给 Condor，这样就可以把这个作业匹配到这个资源上了。

下面让我们来介绍一下如何构建 classAd。

回页首

构建自己的 ClassAd

在生成 classAd 时，我们要指定所添加的类型是 "Machine"，其目标类型是 "Job"。这说明所生成的资源 classAd 应该使用一个 Job classAd 进行匹配。包括机器名，及其位置或 URL。注意，这种格式取决于正在使用的 Globus 的版本。各种版本的 Globus Toolkit 所使用的格式在 第 1 部分 中都进行了介绍。任何说明资源可以接受的作业类型以及需要何时运行这些作业的需求也都应该包含进来。资源所有者可以对资源进行控制，并且可以指定这些作业可以只在夜间没有其他任务时运行，或者只能由特定的用户或用户组来运行。

在 classAd 中包含了一个惟一的序列号。每当一个更新后的 classAd 被发送给 Condor 时这个序列号都必须递增，或者被丢弃。另外，它还应该包含属性 WantAdRevaluate，这样就有多个作业都可以匹配到同一个资源上了。虽然这个属性通常是不包含在 Condor 资源所生成的资源 classAds 中的，但是如果匹配的作业是通过 Globus 提交给资源管理器的 —— 例如 IBM LoadLeveler、Platform LSF 或 PBS，而资源管理器正在管理的是一个资源集群，因为集群可以同时运行多个作业 —— 那么这个属性就是相关的。

清单 1 给出了一个简单的资源 classAd。

                
MyType                = "Machine"
TargetType            = "Job"
Name                  = "condorTest02"
Machine               = "condorTest02"
gatekeeper_url        = "condorTest02/jobmanager-lsf"
Requirements          = True
Rank                  = 0.000000
CurrentRank           = 0.000000
WantAdRevaluate       = True
UpdateSequenceNumber  = 4
CurMatches            = 0

这个资源 classAd 被使用 condor_advertise 命令发送到 Condor 中央管理器。这个过程可以使用一个脚本进行自动实现，这个脚本负责递增序列号，并调用 condor_advertise。这个脚本可以通过 crontab 来周期性地调用。下面这个例子说明了如何使用 condor_advertise 命令来手动将生成的 classAd 发送到中央管理器。–pool 标识了 ad 所发往的中央管理器。中央管理器的名字应该紧跟在这个参数之后。

下面，中央管理器运行在机器 condorTest_1，手动生成的代表 Globus 资源的 classAd 的名字是 testClusterClassAd。

Condor_advertise –pool condorTest_1 UPDATE_STARTD_AD testClusterClassAd

我们还可以在 classAd 中添加另外一些属性来帮助完成 matchmaking 过程。作业可以指定自己需要的资源属性，并按照重要性的次序对属性进行评级。在前面这个 Condor 将作业提交到远程资源管理器的情况中，我们还应该包括另外几个属性，例如指定资源管理器所控制的集群中的节点个数，等待执行的作业个数，以及可用的 CPU 数量。

评级过程然后可以根据等待的作业数量和可用处理器的个数来确定首先使用哪个资源管理器来执行作业。当然，这个过程可能会更加复杂，为了正确预测哪个资源可以首先完成作业的执行，甚至可能需要考虑有关作业和资源的历史信息。

复杂调度和预测是下一篇文章要介绍的主题，现在让我们来了解一下如何使用资源管理器的信息来组装 classAd 结构，matchmaker 可以在需求和评级过程中使用这个结构进行评估。

首先，我们向资源管理器查询希望在资源 classAd 中包含的信息。然后将这个 classAd 发送给 Condor 中央管理器，这样它就可以用来制定智能调度决策了。下面的 Perl 代码使用了 Platform LSF 提供的 bhosts 命令来确定计算节点的个数。这个数字被赋值给变量 Cluster_Nodes，如清单 2 所示。

                
          $nodeCnt = 0;
          @nodeStr = `bhosts`;
          # count up the compute nodes
          foreach $tmpStr (@nodeStr)
          {
             if ($tmpStr =~ /compute/)
             {
                $nodeCnt++;
             }                       
          $nodesTotal = "Cluster_Nodes=" . $nodeCnt;

每个节点上可能有多个 CPU，因此我们还应该列出 CPU 的个数。下面的 Perl 代码使用了 Platform LSF 提供的 lshosts 命令来确定 CPU 的个数。这个数字被赋值给变量 Cluster_CPUS，如清单 3 所示。

                
          $numCpus = 0;
          @list = `lshosts | grep compute`;
          foreach $list (@list)
          {
             @newlist = split(/ +/, $list);
             if ($newlist[4] =~ /2/)
             {
                $numCpus++;
             }
             $numCpus++;
          }                         
          $cpus = "Cluster_CPUS=" . $numCpus;

在确定应该将某个作业调度到什么地方时，我们必须考虑已经在队列中等待资源的作业的数量。下面的 Perl 代码使用了 Platform LSF 提供的 bjobs 命令来确定作业的个数，并将该值赋值给变量 Cluster_Jobs，如清单 4 所示。

                
         $jobs = `bjobs | wc -l`;
         $jobs--;
         $jobCount = "Cluster_Jobs=" . $jobs--;

这几个应该在资源 classAd 中包含的资源管理器示例属性可以附加到用来制定调度决策的相关性的其他信息之后，并被写入到一个临时的 classAd 文件中。我们还需要包括集群名和 URL 来启用用于协调作业控制的通信。我们已经将集群称为 condorTest02。这个集群正在运行一个 Platform LSF 资源管理器，作业可以通过相关的 Globus 容器 URL（标为 gatekeeper_url） 提交给这个资源管理器。其余的以 Cluster_ 为前缀的属性都是使用上面的例子生成的。清单 5 显示了所生成的资源 classAd。

                
MyType = "Machine"
TargetType = "Job"
Name = "condorTest02"
Machine = "condorTest02"
gatekeeper_url = "condorTest02/jobmanager-lsf"
UpdatesSequenced = 9
CurMatches = 0
Requirements = (TARGET.JobUniverse == 9) && (TARGET.JobGridType =?= ``gt2``)
Rank = 0.000000
CurrentRank = 0.000000
OpSys = "LINUX"
Arch = "INTEL"
State = "Unclaimed"
Activity = "Idle"
LoadAvg = 0.000000
Memory = 2048
WantAdRevaluate = True
Cluster_Name = "condorTest02"
Cluster_Nodes = 4
Cluster_CPUS = 8
Cluster_Jobs = 1

使用 condor_advertise 命令并指定其应该发往的池，classAd 可以被发送到 Collector。这样就可以使用这些信息来制定智能调度决策。classAd 应该周期性地进行更新，从而反映资源管理器的状态变化。更新过程可以使用一个脚本自动进行，这个脚本负责递增序列号，并调用 condor_advertise。我们也可以在 crontab 中周期性地调用这个脚本。记住要递增序列号，这样就可以通过 Condor 中央管理器来接受并更新信息。有关如何使用 condor_advertise 命令的信息，请参见清单 2。有关如何将这个命令添加到您的路径中的信息，请参阅 第 1 部分。

现在 Condor 已经具有了有关该资源的信息，我们就可以提交一个作业并请求 Condor matchmaker 选择最合适的资源了。通过 Globus 从 Condor 提交作业需要使用 grid universe 或 Condor-G。通过通知 Condor 说 Globus 作业管理器的 URL 会在 matchmaking 过程中被选中，可以启用 grid universe 中的 matchmaking。Condor 提交描述文件中使用的以下语句允许将在 matchmaking 过程中选择的 URL 用于作业提交过程。

globusscheduler = $$(gatekeeper_url)
requirements    = TARGET.gatekeeper_url =!= UNDEFINED

这将允许 Condor 通过 Globus 来提交作业，将其放到 matchmaker 所选择的网格资源上运行。上面提到的 Globus 调度器 URL 就是从在 matchmaking 过程中为作业选择的资源 classAd 中提取出来的。

在提交描述文件中指定 grid universe 和 gt2 的 grid_type ，从而将这个作业提交到一个运行 Globus Toolkit V2 的远程资源上。grid_type 应该确定您的环境使用的 Globus Toolkit 的版本。对于 Globus Toolkit V3.x，该值应该是 gt3；对于 Globus Toolkit V4.x，该值应该是 gt4 。记住对于资源 classAd 的 URL 部分来说，我们要使用正确的格式， ogsi(ogsa/services/base/gram...) 或 Web-Service(wsrf/services...)。我们将运行与 第 1 部分 中使用的相同的可执行程序（这是一个用来进行环境测试的 Perl 脚本），然后指定输出、错误和日志文件。有关作业需要的 CPU 个数的其他需求应该添加到清单 6 所示的 requirements 行中。

                
executable      = env2test.pl
output          = env2test.$(Cluster).out
error           = env2test.$(Cluster).err
log             = env2test.log
universe        = grid
grid_type       = gt2
globusscheduler = $$(gatekeepr_url)
requirements    = TARGET.gatekeeper_url =!= UNDEFINED
leave_in_queue  = jobstatus == 4
queue

这个作业是使用 condor_submit 命令并指定上面的作业提交描述文件来提交的。清单 7 展示了通过 Condor 来提交作业的情况。

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

回页首

结束语

在本文中，我们介绍了如何从 Platform LSF 中搜集资源管理器信息，并将这些信息作为集群属性包含到一个资源 classAd 中。我们使用了 condor_advertise 命令将 classAd 发送给 Condor 中央管理器。我们在 classAd 中所保存的资源属性可以在提交作业时作为需求指定。这些属性也可以用来对资源进行评级。例如，对于满足作业需求的资源来说，我们要选择使用有最少作业在排队等待的资源。这让我们可以将 matchmaking 过程扩充到 Condor 池范围之外，从而包含其他资源管理器（例如 LoadLeveler、Platform LSF 或 PBS）所管理的集群。

Globus Toolkit 提供了一个网格安全基础设施。通过让这个基础设施增加 Condor 的作业提交、管理和控制等特性，我们可以创建这样一个网格：它可以扩展到 Condor 池之外，而包括很多资源管理器（例如 LoadLeveler、Platform LSF 或 PBS）所控制的资源。

Globus 促进了 Condor 与这些资源管理器的集成。这种方法展示了如何通过 Globus 来统一不同管理域中现有的具有不同资源管理器和调度策略的资源。Condor 可以通过 Grid ASCII Helper Protocol 或 GAHP 服务器与 Globus 进行协调，从而允许对非 Condor 资源使用 Condor 的作业控制特性。

参考资料

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

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

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

关于作者

		Jeff Mausolf 是位于德州奥斯汀的 e-Technology Center 的认证 IT 架构师。他参与了网格计算计划（Grid Computing Initiative）的部分工作，而且曾经参与了很多网格项目。Jeff 还撰写了一本关于开发网格服务的红皮书。现在，他正在德州大学从事计算网格的开发，在今年晚些的某个时候，该网格将成为 Extended TeraGrid Facility（ETF）的组成部分。Jeff 一直在电子商务项目中担任应用程序架构师和软件工程师的工作，其间为很多州政府和机构开发过门户。Jeff 有计算机科学硕士的学位，已经在 IBM 工作了 12 年。在进入 IBM 工作之前，Jeff 从事的是航天工业，先后曾在 Lockheed、Loral 和 Ford AeroSpace 任职，支持与位于德州休斯顿的约翰逊航天中心 NASA 签订的合同。在休斯顿的那段时间，他支持航天飞机工程模拟（Shuttle Engineering Simulation，SES）实验室的太空人训练计划，帮助构建了空间站的组件和训练控制设备，并从事用于航天飞机的 AP101S 通用计算机（GPC）项目。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首