级别： 初级 Frank J. De Gilio (degilio@us.ibm.com), 高级复杂解决方案架构师
2004 年 10 月 01 日 网格资源管理器负责管理请求方请求可用网格引擎所带来的工作负载。在请求的任务多于可用引擎的处理能力时，应该如何进行处理呢？通常，这种情况会导致任务进行排队，并等待更长时间才能被处理。如果网格资源管理器可以请求外部实体，从而增加引擎资源，情况又会怎样呢？如果一个企业内部有多个网格，而这个外部实体可以判断哪个网格最需要资源，那么又该如何处理呢？本文将采用一个示例基础设施，讨论如何管理网格环境中添加和减少的资源。
简介
随需应变业务环境处理能力的最大障碍是什么？最大障碍并不是技术。电子商务业界已经给出了很多快速革新技术来支持新需求的例子。最大的障碍实际上是策略。就其本身而言，随需应变业务是一种与策略无关的模型：它只是检查自己需要哪些资源，从而确保能够最有效地使用企业的所有资源。然而企业却具有严格的策略。由于这两种模型恰好截然相反：一个是与策略无关的随需应变业务环境，另外一个却是具有严格策略的企业，因此我们需要采用一些技术来鼓励这些企业“王国”进行资源共享。随着网格计算从纯粹的科学和数学应用向更实用模型的转化，在这些环境中，我们必须适当地采用一些技术来平衡服务器的正确使用。
在本文中，我们将给出几个例子，这些例子是从 IBM Design Center for On Demand Business 为一家金融机构提供的设计工作中提取出来的。虽然这些例子中使用的模型是基于贸易方面的网格工作负载的，但是在我们见过的很多不同业务中，这个模型非常具有代表性。
对于这家金融机构，我们使用了 IBM Tivoli Intelligent Orchestrator (TIO) 软件，因为它可以使组织能够根据环境的需要，在处理环境中添加或减少服务器。通常是在基于 Web 的环境中广泛采用 TIO，以确保最充分地使用分布各地的服务器。这已经通过对服务器 CPU 的使用率以及该服务器在网络中的使用率的分析得以实现。如果还可以使用 TIO 来调节网格中的服务器，那么 TIO 将成为在多个异构环境中管理服务器的强大工具。突然之间，服务器成为多个部门间共享的日用品，囤积部门服务器资源的情况已经成为了历史。本文给出了将 TIO 产品从传统的基于 Web 的领域转换到感知多个领域的一种方法。
业务问题
企业会不断寻求管理硬件、软件和管理资源的最佳方法。通常，新的应用会配置一些新服务器。为了确保这些服务器可以如我们所愿地进行处理，规划者通常会过高地估计负载情况，从而确保随着应用使用的增加，系统可以有足够的增长空间。如果对负载估计过低，就会导致性能方面出现问题。但如果对负载的估计过高，则是对资源的浪费。由于现在典型的策略都不鼓励共享资源，因此这些浪费的资源永远得不到利用。困扰 CIO 和 IT 组织的一个问题是，永远都不能用这些浪费的资源来处理那些渴求资源的应用程序。有些用户可能不得不忍受性能极差的应用程序，同时却让那些性能良好的资源闲置不用。
解决方案
目前，同时出现了几种解决上述问题的技术：有效的 Web 服务的出现，用于 Web 服务的 J2EE 基础设施的激增，以及网格计算允许有效地在各种环境中开发应用程序组件的能力。应用程序对平台和基础设施的依赖型越来越小，更注重于解决业务问题。这样就为网格在应用模型中的应用铺平了道路。在多个网格竞争相同资源或共享非网格环境资源的环境中，我们需要借助网格外部的一些信息，来确保正确部署服务器。在对这家金融机构进行的部署工作中，我们使用 IBM Tivoli Intelligent Orchestrator (TIO) 来满足这种要求。TIO 还提供了跟踪服务器环境部署的能力，这样，用户就可以知道服务器是怎样部署的，以及服务器部署是为哪个用户进行的。简而言之，TIO 提供了一种消除策略和技术障碍的框架，这可能代表了企业随需应变业务的发展方向。
在为这家金融机构所做的工作中，我们可以将 Tivoli Intelligent Orchestrator 和 DataSynapse GridServer 组合使用。现在让我们先简要地介绍一下这两种产品，这样您就可以对如何一起使用这两种工具有个基本的概念。
关于 DataSynapse GridServer
DataSynapse GridServer 是一种网格计算的应用环境。它为基于分布式计算的工作负载提供了一种组件体系结构。GridServer 对外提供自适应的非确定性负载平衡、动态调度和作业-任务范例。GridServer 包含三个基本组件：
- Director —— 该组件是网格的基本联系点。它是客户端的主要联系点，知道整个环境中所有代理（broker）的信息，以及这些代理都在管理哪些应用。当客户端与指导者（director）协商任务时，指导者就推荐客户端与适当的代理（与应用相关的）进行协商。
- Broker —— 该组件将对任务进行调度，将其发给网格中的引擎。它接收来自客户机的请求，并向正在该环境中执行的引擎提供作业任务。
- Engine —— 引擎是执行所请求任务的组件。
当在服务器上启动引擎时，它将与代理进行联系，告知自己已经可用。在初始化阶段，它将搜索所有可用的更新信息。一旦向代理注册之后，就可以用该例程接收任务了。引擎通常都有一个主代理，其自身就被连接到这个代理上；但是它们可以根据网格环境的需要，从一个代理转移到另外一个代理上。可以通过 Web 界面对这种环境进行管理，Web 界面可以提供精细的视图，或者对执行环境进行控制；也可以通过 Web 服务接口对这种环境进行管理。总之，DataSynapse GridServer 是网格计算中一个非常灵活的轻量级的基础设施。
关于 Tivoli Intelligent Orchestrator
TIO 有两个主要的组件：Provisioning Manager 和 Orchestrator。这两个组件共享一个数据中心模型（Data Center Model，DCM），其中包含了与服务器和网络环境有关的数据。关于网络设备的类型、这些设备与服务器之间的网络连接、服务器的一些细节和相关软件栈（software stack）的信息提供了数据中心控制的具体说明。
Tivoli Provisioning Manager (TPM)
TPM 是创建管理如何配置服务器所采用的规则的一个框架。使用 TPM 工具集，用户可以创建工作流，定义设置服务器的步骤。工作流采用“类 Java 技术”的语义，可以将预定义的 Java 插件组织在一起执行配置任务，对服务器和 TPM 域中的网络设备进行配置。除了已经提供的 Java 插件之外，用户还可以创建自己的 Java 插件，在工作流中执行其他任务。在大多数情况下，没这个必要，因为 TPM 已经提供了用于服务器通信、群集管理（例如 IBM Direct 和 Cluster Server Manager）和网络设备的插件。
由于工作流可以调用其他的工作流，因此每个工作流都专注于一项特定的任务。在工作流中采用有效的模块化可以创建结构精巧、重用性好的部署构造。
清单 1给出了一个向 DataSynapse Grid 添加一台服务器的工作流。
注意，TPM 的流程结构非常精巧，可以让工作流程捕捉到部署过程中的错误，并试图恢复。虽然 TPM 在这里是与 TIO 一起介绍的，但实际上也可以单独使用它。
Tivoli Orchestrator
Orchestrator 组件使用 TPM 来部署 DCM 中的资源，以确保能够满足服务水平协议（Service Level Agreement，SLA）的要求。Orchestrator 从服务器和网络设备中获取数据，它使用一种称为目标分析（Objective Analyzer，OA）的技术来判断在这种环境中，服务器上的应用程序是如何影响特定任务的 SLA 特性的。SLA 对服务器提供者和消费者之间的操作特性定义了一项协议。例如，SLA 可以为某一个查询定义响应时间。（所有对数据库 A 的查询都必须在 1 秒钟或者更短的时间内返回）。通常，SLA 的作用是用来定义服务消费者对服务提供者的所有主要需求。
除了要理解服务器对特定任务的影响之外，Orchestrator 还必须确保特定任务所使用的服务器上的应用程序对整个数据中心都是可用的。这样，特定的任务可能需要其他资源，从而使运行更快；但另一方面，如果有更重要的任务请求了这些资源，那么这些任务就可能得不到这些资源。
Orchestrator 并不是局限于某一台服务器的上下文来管理任务负载，它要确保有足够的服务器可用，从而满足通常为该任务设置的 SLA 要求，正确理解这一点非常重要。换句话说，Orchestrator 并不负责挑选由哪台服务器来执行某项任务，它的责任是确保有足够的服务器可供已经调度的任务使用。
在网格中应用 TIO
Orchestrator 中附带的 OA 特性是基于随需应变容量（Capacity on Demand）模型的，它非常适合 Web 任务，但不适合网格工作负载。随需应变容量模型从网络设备接收到的信息中提取有关服务器的 CPU 数据，从而作出一些预测。这种“事务型”的请求响应就是 Web 的特性之一，因此这种模型可以非常有效地处理任务。而网格工作负载具有无序性的特性，这使得网格很容易完全消耗所有可用服务器的 CPU，从而使传统的随需应变容量模型在网格环境中变得无效。
TIO 的目标分析特性
每个 OA 都会生成一个“异常概率”，它定义了产生 SLA 异常的可能性。这种可能性是基于当然的任务和该任务可用的资源来判定的。如果“异常概率”足够高，那么 Orchestrator 就会询问 OA 为什么会产生这种影响而需要添加服务器，然后再确定一个优化服务器的分配方案，提供给任务服务。
要在网格中正确地实现这项功能，就需要了解 DataSynapse GridServer 为 OA 提供的信息，OA 用这些信息来判断需要什么样的工作负载要求。经过一些实验之后，DataSynapse 可以向 OA 提供队列深度、执行每项任务所需的时间，以及评测当前任务负载的方法。
在网格中应用 OA
我们还要确定存在为了正确管理网格工作负载而进行正确分类的需要。例如，这家金融机构就有两种基本的任务：一种是突发式的，另外一种是平稳式的。突发式任务的环境中有很多用户，它们会向网格提交很多计算任务，任务之间的运行时间都是不确定的。平稳式任务则是一致地提交计算任务，这些任务都是可以预测的，可以统一进行管理。突发式任务表现的是主动型用户任务的情况，而平稳式任务表现的是批处理任务的情况。
TIO 提供了利用 OA 构建复杂规则集的能力，用它来定义为了确保不破坏 SLA 的要求，需要在何时添加服务器。通过这种方式的处理，每个 OA 都不会太过复杂，这些 OA 也可以在多个特性类似的环境中重用。对于网格来说，我们要创建一个 QA 来负责延缓将服务器从网格中移出的过程。这样可以确保不会过早地从处理突发式任务的网格中删除服务器。即使网格中已经没有任务存在了，这个 QA 也可以确保在有新任务来临时，这些服务器还没有被删除。这样还可以消除网格中服务器分配的波动问题。
网格协调 —— 在网格中添加或删除服务器
目前，网格正日益成为 IT 环境的主流，其有效内涵取决于确定应该为特定的任务使用多少资源的能力。由于网格环境中对服务器的离散使用是可以跟踪的，因此这些资源的所有者可以判断自己的服务器对整个企业的贡献。这样，所有者就可以对外单独进行收费，或者与网格社区共同分担费用。尽管在网格环境中采用传统的 CPU 净化方式是可行的，但从本质上来说，这样做寄生性很强。更多地控制环境中服务器的使用，不但对资源使用者有益，而且对资源提供者也有益。由于服务器的所有者可以从使用资源的用户那里受益，因此，他们会更主动地共享平时不使用的处理周期。
参考资料
关于作者  | 
| | Frank 自 1985 年起就一直就职于 IBM 公司。他曾经从事过 MVS 系统、工具和中间件的开发，还曾经在客户机/服务器和 Internet 环境中将 MVS 移植到工作站上。Frank 于 1997 年加入了 IBM S/390 新科技中心，他在 UNIX、MVS 和 Windows 应用程序/中间件开发方面有丰富的经验，这些经验成为他为用户展示在基于 Web 的环境中的最新 OS/390 技术的关键。现在，他在 IBM 的 Design Center for On Demand Business 部门工作，为用户展示如何使用最新的随需应变技术来加强自己的基础设施。 |
对本文的评价
| 
