级别： 初级 Jeff Mausolf (mausolf@us.ibm.com), IT 架构师
2005 年 8 月 11 日 在网格系统中，资源管理器负责对本地资源进行协调和控制。但是对于这些资源管理器，又该如何进行管理呢？在本文中，作者将简要介绍元调度器，元调度器是管理器层次结构中的高级调度器；此外，作者还将介绍元调度器如何在多个资源管理器之间实现工作负载的均衡，并给出了为网格项目选择最佳元调度器的标准。这是 University of Texas 网格项目的另一个组成部分。
从历史上说，各个部门都会为自己的应用程序购买一些平台和资源，以支持峰值需要。为了有效地在这些资源上分配工作负载，通常可以使用资源管理器。工作被提交给资源管理器，后者将根据预先定义的调度策略和当前资源的可用性从整体资源对作业进行调度。
随着时间的流逝，出现了很多散碎的资源。这些资源的特性是有时使用率很低，但偶尔会因为资源不足而被用来处理一些峰值负载。其他部门中也存在类似问题，不同之处是它们的峰值出现的时间和频率可能会有所不同。
如果每个部门都有充足的资源来满足自己的日常负载需要，那会是什么样子？在峰值期间，它们能够自动分配其他资源来满足峰值需要，或者使用企业中其他地方尚未充分使用的资源来补充其当前资源。这样做可以带来更高的总体资源利用率，这是网格计算的目标之一。
这样进行处理时，我们并没有说资源管理器要负责资源管理工作。网格是由很多资源管理器和资源组成的。应如何做才能让这些管理器一起协同工作呢？这就引出了网格元调度器的概念。元调度器可以对这些资源管理器之间的工作负载进行均衡，从而有效地创建一个集群的集群，或者创建一个调度器层次结构。元调度器负责对多个资源管理器之间的通信进行协调，通过业务策略进行操作，并强制采用服务水平协议，从而允许资源管理器在自己管理的本地资源上有效地管理作业。
在本文中，我将给出一个考虑事项的清单，这些事项是为了选择满足您的需求的适当元调度器而对网格项目进行评估时需要考虑的。我还将给出一个用来评估单独的元调度器的问题列表，并讨论有关评估的各个方面的细节。
元调度器在网格中的位置
网格计算的另外一个目标是通过虚拟化使用户脱离复杂性。
许多用户都将作业提交给资源管理器。如果系统中存在多个资源管理器，那么他们就可以登录到任意一个资源管理器中，并查看作业队列来判断作业首先可能在什么地方运行。然后用户可以直接将作业提交给作业队列最短的资源管理器。用户必须在不同的系统中拥有帐号，并且知道如何通过不同的资源管理器来提交、监视和控制作业。
具有元调度器的计算网格可以通过让用户对单一系统进行身份验证，进而以一种统一的方式来提交作业，从而减轻用户的大部分这种负担。系统确定这些作业应该在什么地方运行，以便在最短的时间内完成这些作业，同时遵守业务策略，并维护服务水平协议 (SLA)。
网格允许资源管理器继续对其资源进行管理，并实现了一个元调度器来管理资源管理器的工作负载。根据业务策略和所管理资源的反馈，元调度器可以有效地分配工作负载。用户向元调度器来提交作业，而元调度器可以协调所有的资源管理器来正确理解当前负载、暂存负载（backlog）和队列中作业的优先级。根据这些信息以及对业务策略和 SLA 的理解，元调度器可以作出智能的调度决策。它不但可以对多个资源管理器上的工作负载进行协调，而且还可以对多种类型的资源管理器进行协调，这样就简化了与多个部门的异构资源的集成。
元调度器提供了集中的作业和资源管理，允许用户在不了解每种类型的资源管理器的作业提交语法知识的情况下提交任务。
选择进程视图
对于 UT Grid 项目来说，需要做一些实际的决定来选择最适合的元调度器。下面是影响这些决策的主要标准：
- 我们查看了一些元调度器，并对那些不能很好地与校园集群上运行的资源管理器集成的元调度器不予考虑。
- 我们研究了其他元调度器提供的功能，并选择那些提供了最重要功能的一些元调度器进行评估。
- 这些团队的评估是由一些用例和计算法（需求得到全部满足或部分满足）组成的。
- 对于那些没有完全满足或只有部分满足的需求来说，我们所关注的是使产品完全满足要求需要做出的努力。
清单：选择元调度器
现在您已经知道元调度器是什么，以及它所扮演的角色是什么，接下来让我们看一下在选择元调度器时要考虑的因素。以下 27 个因素被视为产品评估标准。
接下来，我们将列出在评估元调度器时要考虑的一些主要问题，其中包括一些要向生产和管理产品的公司询问的问题。
特定于产品的问题：
- 元调度器要与哪些资源管理器进行集成？例如：支持 Platform LSF。
- 哪些平台受到支持？例如：支持 Linux®。
- 哪些安全机制受到支持？例如：支持 GSI 安全性。
- 要支持检查点和进程迁移吗？
- 要假定一个全局名称空间吗？
- 除了任务调度之外，还要负责对数据进行协调吗？
- 需要提供哪些调度策略？
- 需要提供哪些工具来更新现有的策略或添加客户定制的策略？
- 支持动态策略更新吗？
- 支持并行任务提交还是串行任务提交？
- 支持高级预约吗？
- 支持动态客户机吗？
- 支持动态配置更改吗？
- 提供诊断工具吗？
- 提供资源使用情况的记帐信息吗？
- 支持哪些配置？哪些配置经过了测试？
- 提供可用的文档和培训吗？
- 许可费用是多少？
- 可以使用哪种类型的服务？成本是多少？
- 为用户或管理员各提供哪些类型的接口？
特定于公司的问题：
- 公司已经开展了多长时间的业务？
- 有多少人参与开发、测试和技术支持？
- 这些人的办公地点在何处？
- 他们有客户介绍人吗？如何联系他们？
- 这个产品已经使用了多长时间？
- 安装的基础是什么？
- 发行周期是什么？
现在我们将详细对这些标准进行解释。
标准细节
在接下来的几节中，我们将详细介绍此清单中所列出的所有主题，提供对相关背景的介绍，帮助您理解为什么在为您的项目选择适当的元调度器时，这 27 个问题会成为用来简化决策制定过程的一个工具。
资源管理器支持
流行的资源管理器包括：
- Platform LSF
- PBS Pro 或 OpenPBS
- Sun Grid Engine
- Condor
- IBM LoadLeveler®
如果系统中已经存在资源管理器，那么要考虑的一个重要问题就是元调度器如何才能很好地与正在使用的资源管理器进行集成，以及需要什么级别的集成。元调度器可以无缝地与某些资源管理器进行集成。
在其他一些情况下，如果不允许进行直接集成，那么元调度器可以通过 Globus Alliance 提供的 GRAM（Gobal Resource Allocation Manager）提交给资源管理器。
平台和检查点
有些资源管理器只能支持有限数量的平台。支持有限数量的平台并控制用于该平台的软件堆栈的确有一些好处。对于内核源代码的访问可以允许您对内核进行修改和扩展，这样就可以支持一些高级的特性，例如可以对运行的作业提供检查点功能。
检查点和迁移功能允许保存正在运行的某个任务的状态，这样稍后就可以重新启动这个作业，并且甚至可能在一个完全不同的资源上启动这个作业，而不会丢失早已执行的计算。
有很多资源管理器都提供了检查点和重启功能，这取决于应用程序的类型。例如，MPI 任务的检查点和迁移就比标准作业的检查点更复杂。这可以通过利用内核扩展来对内核进行调整得以实现。
您还应该考虑必须对作业进行哪些修改（如果需要）来支持检查点和迁移特性。有些调度器需要任务重新链接到某个特定的库上来支持检查点和进程迁移的功能。
这个主题还与调度策略有关，因为如果选择的是先发制人的调度策略，那么检查点和进程迁移都非常重要。在先发制人的调度策略中，低优先级作业的运行时间往往很长，这期间可能已经完成了一些非常重要的处理过程。如果支持检查点技术，那么就可以为低优先级的作业设置一个检查点，从而将进程迁移到其他资源上继续进行处理。这样可以为高优先级的任务释放一些资源。如果没有检查点，那么之前所执行的任何计算都可能会丢失。
安全性
在需要单点登录的分布式计算环境中，安全性更加复杂。单点登录使用户只需进行一次身份验证即可，并且用户可以将自己的证书委托给执行任务所需的资源。
一个重要的考虑事项是元调度器要支持哪些安全机制。有些元调度器要依赖于底层的操作系统的安全性。在这种情况下，用户必须在目标资源上具有一个相同用户 ID 和在元调度器中用来进行身份验证的证书。
一种更加高级的方法是支持系统之间的用户 ID（UID）和组 ID（GID）的映射，并允许用户在不同系统上有惟一的 ID。这种 UID/GID 的映射通常都是与另外一种支持用户证书委托的高级特性一起使用的。委托允许他人代表用户执行服务。
考虑一下元调度器是否支持现有的或提议的安全机制以及所需的集成级别。
全局名称空间
元调度器的任务是要对所有可用资源上的工作负载进行平衡。在将作业提交给元调度器时，并不知道执行机器是哪一台。如果该作业要求输入文件，那么元调度器可以不管在何处执行作业，都假定输入数据的路径和可执行路径是相同的吗？
如果所有的资源都连接到一个存储区域网 (SAN) 上或者具有一个全局名称空间，那么就会出现这种情况。然而，如果不是这种情况，那么元调度器可以协调输入数据的不同阶段以及为作业选择的目标资源上的可执行程序吗？
调度策略、度量法和报告
元调度器通常都会定义一些调度策略来平衡工作负载或提供失效共享规则。然而，不同组织之间的策略会有很大区别，常常需要进行定制才能实现组织的业务策略。作业属性，例如优先级、输入数据、CPU 的数量、内存总量、磁盘空间等，可以确定将作业调度到何处执行，但是调度策略常常与作业需求中的成本联系在一起。
例如，需要特定软件许可或大量具有高速连接的 CPU 的作业则需要更加昂贵的资源，并且执行所消耗的资源要比简单程序所消耗的资源多。策略可以实现某种形式的度量法，以后可以用这种度量法对哪些使用昂贵资源的帐号进行收费，或者用来调整以后获得的资源。
元调度器可以支持对资源消耗的跟踪吗？可以捕获重要的使用数据并生成所需要的报告吗？
定制策略
由于通常需要一些定制策略，我们可以考虑新策略是否很容易实现，以及现有的策略是否很容易定制。实现新策略非常简单，就像是在一个 GUI 中定义一条业务规则一样。也许这需要编写一个定制的调度插件，它必须适用于该调度策略所使用的所有作业队列。
定义策略的方法还可以确定元调度器如何处理更改。可以在运行时添加业务规则的更改，但是添加客户开发的调度器插件需要重新启动系统才能使这些更改生效。在大部分环境中，系统重启所引起的不可用都是不希望出现的事情。
动态资源
在可以利用空闲周期的环境中，可以从一个资源管理器中动态添加或删除资源。这也是实现自动配置（provisioning）或协调（orchestration）的地方。
资源管理器可以支持动态添加或删除资源的功能吗？资源管理器需要采用哪些步骤来利用这些额外的资源并将它们用于将来的工作？简单地说，资源管理器如何处理哪些失效或已删除的资源呢？正在失效资源上运行的任务会自动重新提交到另外一个资源上吗？
高级预约
我们已经讨论了作业提交的问题，假设作业应该在可以用最短的时间完成任务的资源上执行。我们还应该考虑高级预约特性的需要。高级预约可以让用户对将来资源的数据和时间进行预约。如果需要使用高级预约的特性，那么元调度器是否应支持高级预约？它可以对正在进行预约的资源的预约进行协调吗？
文档
开发人员指南对于开发 API 来说非常有帮助。其他文档也很重要。供应商是否提供了高品质的安装指南、管理员手册和用户指南？可以利用哪些培训？建议用户和管理员参加哪些培训？
许可
为了制定智能的调度决策，元调度器需要那些来自它所控制的资源的反馈。代理可以实现这种功能，并且通常是在所有管理的资源上运行的。代理将信息发回元调度器，这样元调度器就可以制定智能调度决策。
通常元调度器的许可是根据每个代理进行定价的，但是价格和定价方式可能会有很大的区别，因此要与产品的供应商确认这个问题。
接口
另一个重要考虑事项是所提供的接口。有些任务，例如查看资源状态，比较适合使用一个可视化的 GUI 进行查看；而有些任务使用命令行接口查看可能更适合。元调度器可以同时为用户和管理员支持 GUI 和 CLI 吗？是否提供了 API 来支持编程方式的作业提交、监控和控制呢？
根据实现的不同，可以为此提供 Web 服务接口或 Java™ 技术的 API。元调度器支持您的组织所需要的接口吗？
产品和公司的历史
公司和软件的历史都应该考虑。
对于产品历史来说，这个产品已经使用了多长时间？通常可以使用的是哪个发行版本？该发行版本的更新周期是多长时间？供应商可以提供描述将来发布内容的产品路线（product roadmap）吗？当前产品的安装基础是什么？可以提供一些顾客的建议吗？如果可以，如何与他们联系才能获得第一手的产品和服务信息呢？目前生产过程中使用的配置是什么？它们协调了多少资源，都是哪些类型的资源？它们还可以支持哪些配置？已经测试的其他配置还有哪些？
公司的信息也同样重要。这个公司已经运作了多长时间？他们的经济前景如何？该公司有多少员工参与开发、测试和技术支持？他们有距离开发和承载您的项目的地方比较近的办公室吗？有技术支持的联系人吗？与响应时间、问题确定、隔离、解析或自动调整等方面有关的服务水平协议是怎样的？
结束语
在本文中，我们介绍了元调度器的工作方式，以及评估用于您的项目的元调度器时需要考虑的 27 个标准。比较这些产品的一种简单方法就是创建一个表，每个产品作为一列，所需要的每个特性作为一行。然后遍历每个行，在支持该特性的产品的那一列中放置一个检讫记号。
还要考虑到有不同级别的支持，因此您可能想为每种级别分配一个数字，例如 1 到 5 的数字，其中 1 表示部分支持，而 5 表示全部支持。对每行特性进行评估之后，就可以对列进行统计来计算得分了。
更好的一种方法是为每一行都设置一个权重系数，该系数表示这个特性对组织而言的重要程度。最终，我们会将这个权重系数乘以该行的得分，以表示支持的级别和这种特性对于组织的重要性。
在本系列的下一篇文章中，我们将介绍 Platform Computing 中提供的 Community Scheduler Framework V4.0 Meta-scheduler，这是 GT4 中绑定的一种预览技术。
参考资料
关于作者  | | | Jeff Mausolf 是位于德州奥斯汀的 e-Technology Center 的认证 IT 架构师。他参与了网格计算计划（Grid Computing Initiative）的部分工作，并且参与了很多网格项目。Jeff 还撰写了一本关于开发网格服务的红皮书，现在，他正在德州大学从事计算网格的开发（最近当选为 Extended TeraGrid Facility 的成员）。在于 13 年前加入 IBM 工作之前，他曾在 Lockheed、Loral、Ford Aerospace 和 NASA 任职。在 NASA 的 Johnson Space Center 工作的那段时间，他支持航天飞机工程模拟（Shuttle Engineering Simulation，SES）实验室的太空人训练计划，帮助构建了空间站的组件，并从事了用于航天飞机的 AP101S 通用计算机（GPC）的项目。他拥有计算机科学的硕士学位。 |
对本文的评价
| 
