随着扩展和分布式计算环境的逐渐流行，工作负载的调度正在成为 IT 环境中一个日益重要的组成部分。很多网格计算环境都是由分布式资源上的工作调度来驱动的。但这个原理通常不太好理解。为了更加清晰地理解调度的知识，本文将介绍调度的各个方面的内容以及它们之间的相互关系。 工作负载（作业）调度对于网格计算来说非常重要。虽然这一理论已经存在很长时间了，但是随着网格和扩展计算环境的日益流行，它的重要性也日益突出。 调度程序最终要负责将任务放到网格中的资源上执行。理论上这听起来似乎非常简单，但它却是一个相当复杂的问题。从本质上来说，调度是一个优化问题，原因是在网格中只有有限的资源可以使用，而工作请求的数量可能会远远超出这些资源所能承受的能力。而且，优化可以以多种形式进行。有时在所有网格资源之间的资源利用率非常重要，有时作业的吞吐量则会非常重要。通常，许多组织机构都希望能平衡这些相互竞争的目标。 在本文中，我们将深入介绍构成调度策略及其组件的都有哪些内容。调度通常不好理解，因为调度产品通常都将多种功能集成到了一个称为 调度程序（scheduler） 的包中。因此我们要把调度分拆成它的组成部分来介绍。 术语 “调度程序” 甚至可以认为是有些用词不当，因为人们通常把调度的概念理解为以一种组织良好的形式一起工作的一组功能。 在本系列的上一篇文章中，我们介绍了 IBM® 称为 “工作负载虚拟化” 的内容。我们将对这个概念进行扩展，从而更仔细地理解其各个组件的内容，这些组件合在一起被通常理解作调度。我们并不需要修改工作负载虚拟化的定义；从高层来看，它是由调度程序、工作负载管理程序以及供应组件的交互来定义的。工作负载虚拟化的概念更高级、更抽象。 在本节中，我们将对每个组件以及为执行某个作业而进行的交互进行介绍（参见图 1）。 图 1. 作业执行的生命周期  我曾经提到过人们通常都将调度与诸如 Platform LSF 或 IBM Tivoli® Workload Scheduler 之类的调度程序中的功能混淆在一起。这个组件的名字——调度——可能会产生些混淆，因为图 1 中的很多组件合在一起定义调度的核心。我们可以定义两个类别 —— 计划和编排 —— 但是由于编排对于大型的调度来说是个自引导组件（有些人可能会认为计划是调度的根本元素），因此我们就简单地将其称为 “调度”。 计划所关注的是为执行所有已知工作来构建策略。因此，计划通常就意味着某种形式的先知知识（例如，管理员或用户提前告诉调度程序何时运行什么）。并非所有的调度程序都会进行计划，这就是说它们并不会构建一个策略或表示来说明如何执行任务，而是在运行时实时地进行判断分析。（我们都知道人们喜欢这样。）对于进行计划的调度程序来说，当工作不按照计划进展时（通常都是如此），就需要重新进行计划。 工作的编排（orchestration 或 choreography）是一种基本的能力。当用户提交工作去执行时，必须说明执行这个作业所需要的资源需求（例如，需要在一台至少具有 512MB 内存的 Intel® 机器上运行），如果这个工作有很多步骤，还要指定这些步骤的顺序。每个调度程序都必须可以进行一定量的编排。 资源代理（Resource brokering） 关注的是如何让工作匹配可用资源，或者反之，让资源适应工作，这取决于具体要求。优化（作业吞吐量）也在此处进行。 所有的调度程序都必须进行一定程度的资源代理，这是因为调度程序最终都需要确定作业到底在什么地方完成。复杂的作业调度算法或策略（例如 Platform LSF）通常就用来做这种决策，但有时，它们都会简单地随机选取一个资源来执行作业。 在我们的框图中，我们将把资源代理划分为单独的一类，这是由于随着 元调度（metascheduling）（在不同环境之间的调度）的出现，将其作为单独的一类进行考虑将会很有帮助。 资源管理（Resource management） 主要关注的是对可用资源的库存及其功能的跟踪。资源可以是物理资源，也可以是虚拟资源。对某个资源或一组资源的可用容量的了解通常就称为 容量管理（capacity management）。 资源管理是一个通常在调度产品中嵌入的独特类型。在其核心，此功能可以由注册类产品提供（并与之接口），例如 Globus Toolkit 监视和发现系统（MDS）、配置管理数据库（CMDB），理论上甚至可以用 LDAP。 供应（Provisioning） 是调度系统中一个越来越重要的组件，但它并非调度的核心部分。供应的功能是设置资源并确保它已经准备好接收工作请求。 供应管理（Provisioning management） 可能非常简单，就如同将一个不可用的资源（并将其标识为可用）送到资源管理器；或者它可以意味着在资源上真正安装和配置所需要的软件（例如，操作系统或中间件）。当不能使用可用资源来满足工作请求时，资源代理可以与供应系统进行接口。 工作负载管理（Workload management） 就是在工作运行时对工作进行管理和优化。当优先级更高的工作被请求时，工作负载管理可能会停止或暂停工作（可能会为它设置检查点）——或者，如果工作不是根据服务等级目标来进行的，工作负载管理可能会重新配置环境来进一步优化工作负载的执行。 工作负载管理是调度系统中的另外一个组件，它通常会被集成到目前常见的调度程序中。它可以与资源代理或执行引擎进行接口来提供一些有关在哪里执行任务的指导、提示或技巧。 执行组件非常简单。它负责放置要执行的作业。所有的调度程序都有一个执行组件。其中大部分都使用了双向的工作队列，工作被放入这个队列（通常都是放到队列的尾部，但不总是这样），执行引擎从队列中将其取出来执行。
在介绍调度组件时，我们已经对这个问题的答案给出了一些暗示。大部分调度产品或调度功能很好的产品，例如 WebSphere® Extended Deployment 或 DataSynapse FabricServer，都包含了所有这些组件，只是组件间的功能性有些不同程度的差别。 我们已经接触了其中的一些组件 ，即编排、资源代理、资源管理和执行，它们差不多就组成了调度的核心组件。因此我们可以将至少提供这些组件功能的产品认作是调度程序。 进一步来说，在我们抽象地将这些组件的组合认作是调度时，如果再加上供应管理组件和工作负载管理组件，它们就构成了前一篇文章中 “工作负载虚拟化”的概念。 随着分布式和扩展计算体系结构的逐渐流行，调度的重要性也日益增加。调度能力对于在分布式资源上管理工作来说非常重要。然而，一些组织机构的 IT 环境中现在已经存在着一些调度组件的功能（例如资源管理器和目录）。因此，通常可以将很多组件合并到一个集成包中的调度程序还需要能够与这些已有功能协同工作。 因此我们需要将调度分解成一个个的组成部分。这种概念与我们从应用程序的角度使用面向服务的架构（SOA）所见到的相辅相成。因此我们可以期望此处介绍的每个组件都将会有为方便进行集成而定义的服务接口。 IT 架构中调度组件的集成的重要性也正逐渐增加，但是此处我们是指更广泛的趋势：调度与更复杂的管理功能的集成。为调度而进行的调度正被更高级的解决方案所取代。调度也正被集成到具有业务服务管理、供应、工作负载管理以及其他管理和自动化功能的更大型的解决方案中。 在诸如 WebSphere Extended Deployment 之类（实际上并不一定非要被看作是调度程序）的产品中我们都已经看到了这种集成的趋势，它在一个包里集成了很好的调度功能与复杂的工作负载管理、应用程序供应和至关重要的管理功能。
|
联系客服
