![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
现在，有一些网格调度器、资源管理器和任务负载管理系统可以提供传统的批处理队列系统的功能，或者提供从空闲桌面工作站中利用时钟周期的能力。通常来说，一个产品用来解决一个领域的问题。Condor 解决了这两个领域的问题：它通过提供一个可以管理专用计算节点并有效地利用空闲桌面工作站中浪费的时钟周期的工具。本文将通过从较高层次上概要介绍 Condor 从而对 Condor 项目简要进行介绍。本文还会介绍有关 Condor 的背景信息，并简要介绍一些特有的概念，例如 ClassAd 和 matchmaking。另外，本文还会简要介绍 Condor 的进程，之后介绍有关它们提供的服务和特性的技术细节。
Condor 是一个用来管理计算密集型的任务的批处理队列系统。这是通过提供一个 高吞吐量的计算（HTC）环境实现的。HTC 环境在为这些任务提供高吞吐量的同时，可以有效且最好地利用所有的可用资源。它提供了传统的队列和调度功能，以及创新技术，例如资源分类。在典型的使用情景中，用户将任务提交给 Condor，它会对任务进行排队并监视，然后在任务完成时将结果表示出来。历史上提供这种功能的批处理系统使用单个组织所有的专用机器。虽然 Condor 在这种环境中工作得很好，但是它也可以通过利用这些资源空闲时的空闲周期从而有效地管理非专用的资源。有时这称为 时钟周期节余。
Condor 可以通过使用一些特有的特性，例如检查点、任务迁移、远程系统调用和 ClassAd，从而有效地利用非专用资源的能力。下面让我们来看一下这些特有的特性。
检查点 是一个保存程序状态的进程，这样稍后这个程序就可以从这个状态重新开始执行，而且可以在另外一个位置启动。周期性的检查点可以提供一定的容错能力，方法是如果任务失败，就允许这个任务从最近的检查点恢复执行。这对于长时间运行的任务来说尤其有用。检查点可以在程序的关键点处设置，也可以周期性地设置，例如每个小时一次。如果某个任务由于某种原因失效了，那么这个任务就可以从最近的检查点处继续执行，而不会丢失失效前所完成的计算操作。检查点对于进程迁移来说非常重要。检查点可以允许调度程序将任务迁移到一个不同的位置处，而不会丢失已经执行的计算任务。这是使用任务状态的检查点来实现的。例如，一个任务的检查点是在当前机器上生成的，然后在将其迁移到一台新机器上时，它就可以用作这个任务的始点。这样可以让任务有效地从失败的地方进行恢复。当任务执行由于更高优先级的任务需要使用资源来运行而必须被中断时，就可以使用这种形式的抢占式调度。
ClassAd 允许一台机器广播其他机器可以使用的资源，也可以允许任务广播自己想使用的资源。Condor 的 ClassAd 类似于分类新闻广告，其中提交任务的用户可以认为是计算资源的购买者，机器的属主是计算资源的销售者。ClassAd 允许 Condor 对任务资源需求与最适合运行该任务的资源进行匹配。
机器 ClassAd 广播一些机器属性，以及可以接收任务的条件。典型的机器属性包括内存数量、CPU 类型、CPU 时钟速度以及当前的机器负载。接收并运行机器上的任务的条件可以限制为特定的时间量，或者说明任务只能在机器上没有其他操作执行时才可以运行。这些条件也可以定制为特定的用户或组才能访问计算机资源。
任务 ClassAd 是一个任务特定的广播，其中包含了运行任务所需要的机器的类型以及某种属性可以接受的最大值和最小值。例如，任务 ClassAd 可以指定自己必须在 Linux™ 上运行，至少有 2 GB 的可用内存和 40 GB 的磁盘空间。Condor 会检查这些任务 ClassAd 和机器 ClassAd，然后确定可以满足这两种需求的实体。
有一些特定类型的任务非常适合 Condor。Condor 任务必须可以作为一个无人干预的后台任务运行。这种任务应该采用一定的算法来生成大量的自包含的独立任务，并保持这些任务的可移植性（可以在任何地方运行）。当然，这些任务也应该可以检测到错误并平滑地进行响应。
任务的运行时环境必须在任务提交时指定。Condor 将这种环境称为 universe。最常见的 universe 是 standard 和 vanilla universe。可用的 universe 如下：
表 1. Condor Universe
| Universe | 说明 |
| Standard | 支持检查点、迁移和可靠性，但是对于任务有一些限制，例如任务必须链接到 condor 库上 |
| Vanilla | 支持很多服务，但是对任务或任务类型有一些限制 |
| PVM | 用于使用 Parallel Virtual Machine 接口编写的程序 |
| MPI | 用于使用 MPICH 接口编写的程序 |
| Globus | 用于通过 Conder 接口提交 Globus 任务 |
| Java | 用于为 Java™ 虚拟机（JVM™）编写的程序 |
现在让我们开始重点介绍最常见的 universe：standard universe。它对系统调用的处理方式是将远程执行机器重定向回提交机器上。这样可以允许用户在提交任务时就仿佛任务是在本地运行的一样，实际上，任务是以一种对用户透明的方式在远程运行的。用户在提交任务时可以指定本地输入和输出文件。任务通过将对网络上远程机器上的文件输入或输出的系统调用重定向到提交任务的机器上而透明地使用这些本地文件。standard universe 还提供了检查点和已经完成一部分的任务的迁移能力。然而，为了获得 standard universe 所提供的扩展功能，执行程序必须要使用 condor_compile 命令链接到 Condor 库上。对于那些无权访问源代码或对象代码或编译环境的用户来说，将程序重新链接到其他库上可能不是什么好的选择。为了支持这些情况，Condor 提供了 vanilla universe，它可以支持那些不能重新链接到 Condor 库上的任务。注意由于任务没有链接到 Condor 库上，就没有办法设置检查点或迁移任务，因此那些已经部分完成的任务就会丢失之前已经完成的计算操作。这是使用 vanilla universe 的一个缺点。
universe 类型以及所提交的任务的详细信息是在一个提交描述文件中指定的。提交描述文件中指定了可执行文件，所有的输入和输出文件，平台类型，任务状态和完成时的通知机制。它也会指定该任务应该运行多少次循环，并提供一种机制将输入文件映射到每个运行的任务上。任务是使用 condor_submit 命令并指定相关的提交描述文件提交给 Condor 的。然后就可以使用 condor_q 和 condor_status 命令对任务进行监视。当任务完成时，提交者就会了解到该任务的退出状态，同时还有一些统计信息，例如所使用的 CPU 时间，以及输入和输出信息。
当一个任务启动时，Condor 就会在提交该任务的机器上启动一个名为 condor_shadow 的进程。这个 shadow 进程会对远程执行的任务所发出的请求进行响应，从而来访问提交任务的机器上的一些环境。例如，尽管远程任务不是在提交任务的机器上运行的，但是它可以查询提交任务的机器上的环境变量。远程任务也可以从提交任务的机器上读取输入文件，或者向这些机器上输出文件，这使得远程执行过程对于用户来说是透明的。
Condor 有一个资源 池 的概念。池是一组机器或任务的集合。Condor Pool 有一个集中的管理程序和很多其他机器。这个集中的机器会搜集有关资源和任务的信息，然后在资源和任务的资源需求之间进行协商和匹配。这是通过检查资源池中资源的状态进行的，并将任务请求与可以满足任务需求的可用资源之间进行匹配。资源所有者可以保留对资源的控制，并会定义一些策略，这样可以指定何时 Condor 请求可以被接受和处理。资源池中的任何机器都可以是提交机器，也可以配置为用来执行 Condor 任务。
现在角色已经标识清楚了，让我们来介绍一下作为守护进程运行的用来支持 Condor Pool 的一些进程。condor_master 进程会在资源池中的每一台机器上运行。它会阅读配置文件，并判断哪些 condor 进程应该在这台机器上运行。然后启动并监视这些进程。如果有进程崩溃了，这个 master 进程就会通知系统管理员，并将其重新启动。
condor_startd 在那些配置用来执行任务的机器上运行。它实施资源所有者所制定的用来判断任务何时可以运行的策略；还会广播用来匹配任务或任务资源请求的资源的属性。当 condor_startd 准备好执行一个特定的 Condor 任务时，就派生一个 condor_ starter 进程，它会设置执行环境。当执行环境被初始化完之后，就在一台远程机器上启动这个任务，并监视该任务的状态。当任务完成时，condor_starter 就将该任务的状态信息发送回提交任务的机器上，并退出。
condor_schedd 在那些配置用来提交任务的机器上运行，也称为 任务提交 节点。用户将任务提交给调度程序或提交节点上的 schedd 进程。调度程序将所提交的任务保存到任务队列中。它会周期性地广播任务队列中的任务，并申请一些资源来处理这些请求，这是由 matchmaker 指定的。当 condor_schedd 任务队列中的一个任务与某项资源匹配时，就启动 condor_ shadow 来处理与这个任务有关的请求。condor_shadow 在提交任务的机器上运行，并用作与该任务有关的请求的资源管理器。在远程执行机器上运行的任何系统调用都会被重新定向回 condor_ shadow，它会在提交机器上执行系统调用，并将结果发回到执行机器上的远程任务。这样可以允许任务就仿佛是在本地运行一样，并且可以访问本地的文件和变量；实际上，此时它们是在资源池中可以满足该任务请求的任何可用资源上运行的。
condor_collector 负责搜集有关资源池中资源状态的信息。我们讨论过的所有 condor 守护进程会将状态信息和更新信息发送给 collector 进程。其他守护进程也会向 collector 查询信息，例如远程机器的地址。
condor_negotiator 执行匹配操作。它向 condor_collector 查询资源池中资源的状态信息，并查询每个任务队列中具有等待资源的请求的 condor_schedd。negotiator 视图将可用资源与任务需要的这些资源进行匹配，同时保留系统中用户的优先级。一种保留用户优先级的方法是跟踪资源的使用状态并对优先级进行调节。一种典型的策略是用户申请的资源越多，它们必须获得并使用的其他资源的优先级就越低。
在本文中，我们从一个较高的层次上概要介绍了 Condor 项目。现在您应该理解任务 classAd 和机器 classAd 的概念了，以及构成 Condor 系统的各个进程和守护进程。这包括搜集器和协商器，前者搜集资源的信息，后者检查搜集器的资源，并查询调度器守护进程的任务队列对资源请求和可用资源进行匹配。我们已经讨论了 Condor 中支持的各种环境和标准 universe 支持的检查点和迁移技术，但是需要应用程序链接到 Condor 库上。具备这些知识之后，现在您就应该已经对 Condor 项目具有很好的了解了，并且可以理解更高级的内容了。
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
- 这里有关于 Condor 及相关项目的详细信息。
- 在 developerWorks 网格计算专区 中可以找到有关网格计算各个方面的文章。
- 访问 Developer
Bookstore 中的技术书籍的详细列表，包括很多有关网格主题的书籍。
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）的项目。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。