简介

粗略来看，您可能会认为这三种产品都提供了相同的功能。但是它们的功能并不相同。它们的功能并不是相互重叠，而是互为补充。另外，它们的打包方式也不同。实际上，Tivoli® Provisioning Manager 可以按照很多方式进行打包。

下面让我们来逐一介绍这些产品。这是一个不断进化的领域，本文介绍的是它们在 2005 年 2 月时的功能及其相互关系。随着技术的不断成熟，这些产品也会不断发展和变化，从而可以为随需应变的基础设施提供最好的支持。

回页首

IBM Enterprise Workload Manager for Multiplatforms

Enterprise Workload Manager for Multiplatforms 是 IBM Virtualization Engine Suite for Servers 的一部分。您也可以将 Enterprise Workload Manager for Multiplatforms 作为一个单独的产品使用。从战略上来说，它应该负责为任务在基础设施之间的动态路由提供数据。目前，它负责对组件进行监视，并为一个基础设施状态的端到端的视图搜集性能信息。它有两个主要的组件：

• Agents —— 搜集有关组件的信息。运行这些代理的服务器称为托管服务器。
• Domain Manager —— 汇集代理所搜集到的信息。这是所有代理数据的一个集合点，在自己的服务器上运行。

Enterprise Workload Manager for Multiplatforms 代理可以在启用 Application Response Measurement（ARM） V4.0 的服务器上运行，ARM V4.0 包括大部分分布式服务器操作系统。ARM V4.0 在 z/OS® 系统上也受到支持。类似地，Enterprise Workload Manager for Multiplatforms 也可以监视启用 ARM V4.0 的中间件。ARM 标准描述了一种将企业应用程序作为可管理的实体进行集成的通用方法（请参阅 参考资料）。

在多个 Enterprise Workload Manager for Multiplatforms 环境中，HTTP 服务器、应用服务器和数据库服务器必须都启用了 ARM V4.0 来为一个事务的端到端的性能视图搜集一组完整的统计信息。这些 ARM 数据被发送给一个 Domain Manager，然后将其保存在一个 Cloudscape 数据库中保存一个小时。您可以有一个或多个组件没有启用 ARM，仍然可以获取性能信息，但是这不可能是完整的端到端的信息。为了向 Enterprise Workload Manager for Multiplatforms 汇报信息，在应用服务器中运行的应用服务器也必须启用 ARM V4.0。

现在，Enterprise Workload Manager for Multiplatforms 并不会控制策略，也不会决定数据的路由。它为操作提供了一些数据，从而来理解端到端的性能视图。正如您可能期望的一样，此处有一个基于浏览器的界面来显示数据。有一些网络设施，例如路由器和负载均衡器可以使用 Server Application State Protocol （SASP）来检索信息。

图 1 描述了所监视到的一个典型的基于 Web 的事务中的一个端到端的事务到数据库的流程。这个例子使用了 IBM HTTP server、WebSphere® Application Server 和一个 DB2® Universal Database，所有这些都启用了 ARM V4.0。

事务的监视过程如下：

1. Web 请求到达 Web（IBM HTTP）服务器。这会生成一个 ARM 启动事件，本地的 Enterprise Workload Manager for Multiplatforms 代理会对其进行处理。
2. 创建一个惟一的相关令牌，并捕获启动时间。这个相关 ID 会被添加到请求中。
3. 这个请求和相关 ID 以及 Web 服务器的标识一起，被路由到应用服务器上。
4. 当请求到达应用服务器上时，它执行一个 ARM 启动事件，其中带有从 Web 服务器接收到的相关 ID。与 Web 服务器的情况一样，应用实例的启动时间也会被记录下来。当应用程序产生数据库请求时，应用服务器就会将这个相关 ID 附加到请求中，并将自己的服务器标识令牌加入到其中。
5. 请求转到 DB2 Universal Database 服务器上，其中包含了相关 ID 和宿主 WebSphere Application Server 的信息。
6. 当请求到达 DB2 Universal Database 服务器时，数据库服务器使用这个相关 ID 执行一个 ARM 启动事件，并跟踪这个事务的参与者的启动过程。
7. 当 DB2 Universal Database 完成自己在事务中的参与过程时，它就使用这个相关 ID 执行一个 ARM 停止事件。这个事件记录了数据库服务器在事务中的停止时间。
8. 这个请求被返回给应用服务器，其中包括响应和 WebSphere 发送给 DB2 Universal Database 的 Enterprise Workload Manager for Multiplatforms 相关 ID。
9. 应用服务器的应用程序完成处理过程，并准备好将数据返回给用户。当数据离开 WebSphere 时，在 WebSphere 服务器中会执行一个 ARM 停止事件，并记录服务器参与事务的停止时间。
10. 响应被发送给包含相关 ID 的 Web 服务器。
11. Web 服务器执行一个 ARM 停止事件，并记录 Web 服务器参与事务的停止时间。
12. 响应被路由到终端用户。

Enterprise Workload Manager for Multiplatforms Domain Manager 可以使用这些信息，从中可以计算事务的总时间和每个服务器在端到端的事务中起作用的时间。最终，在参与端到端的事务的交换机、路由器、防火墙以及其他网络设施中也可以使用 ARM 所支持的功能。Enterprise Workload Manager for Multiplatforms 要捕获所需要的详细信息，所有级别的操作系统和中间件都必须启用 ARM。在 Cisco Service Modules 中已经可以使用 ARM 支持功能了。

使用为 Enterprise Workload Manager for Multiplatforms 设计的 SASP 协议连接到 Domain Manager，可以检索事务的性能数据，确定哪条路径可以最有效地实现最佳性能路径。毫无疑问，路由器利用这种功能的能力在可以遇见的将来会成为现实。

在稍远的将来，我们可以猜想路由器会使用附加到每个请求中的策略，利用内部的软件和 Enterprise Workload Manager for Multiplatforms 搜集到的数据，来确定每个请求可以使用哪条路径。优先级高的用户，例如 Web 商店中的 VIP 客户，可以获得最佳性能路径；而优先级低的用户，例如 Web 商店中的临时用户，则会获得非最佳性能的路径。在这个范例中，客户和服务提供者之间的服务级别协定（SLA）可以在一定的粒度等级中进行管理。

回页首

IBM Tivoli Provisioning Manager

我们可以将 Tivoli Provisioning Manager 作为一个脚本执行环境。它不会作出策略的决定或平台的选择。它执行一些脚本 —— 称为任务流 —— 来执行特定的功能。它使用自己的脚本语言，其结构类似于 Java™ 语言。您是一个主流用户吗？那就可以将任务流当作是一种类 JCL 的结构。您是一个分布式用户吗？那就可以将任务流当作 shell 或者 Perl 脚本。

随着 2.1 版本的 Tivoli Provisioning Manager 引入了功能强大的高级结构，包括 try-and-catch 块和对 Jython 的支持，后者允许任务流编程者为自动配置服务器（provisioning server）创建复杂的算法。这些任务流可以与硬件级可用的自动配置功能一起工作，例如 IBM Director Remote Deployment Manager（RDM）或 Cluster Systems Manager。Tivoli Provisioning Manager 可以向这些低级的服务发送消息，从而对服务器进行通电或断电操作，或者执行 RDM 和 CSM 中提供的其他功能。

Tivoli Provisioning Manager 任务流可以调用其他任务流，这样可以对对象功能进行抽象，从而为高层调用者隐藏细节内容。例如，您可以运行一个名为 Add_Server 的任务流，它将一个服务器加入集群中。Add_Server 然后会调用底层的任务流来判断使用哪个服务器，如何进行自动配置，以及为了支持服务器和到服务器的网络而需要修改对网络进行的改变。所有这些细节都对用户屏蔽了，因为用户只是想将服务器加入集群中。采用这种技术，任务流编程者可以进行一些操作，而不用了解基础设施的所有操作细节。

Tivoli Provisioning Manager 目前既可以与 Tivoli Intelligent Orchestrator 打包在一起，也可以使用 IBM Virtualization Engine 单独发布。通过这种产品或 Orchestration and Provisioning Automation Libraries（OPAL）可以使用很多基本的任务流。在开始编写自己的任务流之前，请在 OPAL 目录中查找现成的版本。尽管 OPAL 任务流可能需要一些为满足特殊客户需求而定制的任务流，但是这可以为构建基础设施提供一个可信赖的基础。请参阅 参考资料 中搜索 OPAL 目录的内容。

回页首

IBM Tivoli Intelligent Orchestrator

Tivoli Intelligent Orchestrator 负责管理基础设施之间的资源。它对基础设施进行监视，并确定是否有资源应该用来对基础设施进行优化。它可以在三种模式中运行：手工模式、半自动化模式和自动化模式。

在 手工模式 中，服务器环境是以一个刻度盘的形式对用户呈现的，以红色和绿色显示。终端用户可以查看显示的内容，并确定要支持当前的负载需要对哪些资源进行修改。一旦做出决定之后，用户就可能会期望采用一个 Tivoli Provisioning Manager 任务流对这些资源进行管理。

在 半自动化模式 中，用户仍然可以通过查看资源来了解服务器环境的活动。另外，当 Tivoli Intelligent Orchestrator 看到一个特定的应用集群需要更多资源时，就确定哪些变化最有效，并请用户批准进行这些修改操作。用户一旦批准之后，Tivoli Intelligent Orchestrator 就会执行适当的 Tivoli Provisioning Manager 任务流。

在 自动化模式 中，虽然用户仍然可以通过查看资源来了解服务器环境，但是无法通过一些输入信息对这些资源进行管理。当 Tivoli Intelligent Orchestrator 看到一个特定的应用集群需要更多资源时，就确定其他地方是否有可用资源，并使用 Tivoli Provisioning Manager 任务流程将这些资源部署到适当的集群中。

Tivoli Intelligent Orchestrator 可以设置为缺省使用任意一种模式，用户可以为特定的集群设置一种不同的模式。用户具有一定的灵活性使用不同的模式来管理不同的集群，从而允许他们可以习惯于 Tivoli Intelligent Orchestrator 的环境，而不用强制他们完全遵从计算机的习惯。这些模式可以在运行时进行设置和恢复，因此提供了全面的灵活性。

Tivoli Intelligent Orchestrator 也可以与 RDM 和 CSM 进行通信，从而允许它理解新获得的资源何时可以成为可用的。例如，RDM 可以识别出一个新的刀片（blade）何时被加入到刀片中心，Tivoli Provisioning Manager 可以被分配来自动配置这个刀片。

Tivoli Intelligent Orchestrator 根据从集群中的资源所接收到的数据来判断集群的行为。它使用 Objective Analyzer（OA）来判断集群的负载。Tivoli Intelligent Orchestrator 中有一个缺省的 OA，名为 Capacity on Demand，它基于一个 Web 工作负载环境。使用 OA 技术，用户可以对工作负载进行建模，从而判断特定的集群需要哪些资源。OA 为 Tivoli Intelligent Orchestrator 提供了一种手段来理解集群需要多少服务器。Tivoli Intelligent Orchestrator 然后会确定集群的优先级，从而确定资源是否可用于满足集群需求。未用的资源可以自动配置到集群中。如果没有可用资源了，Tivoli Intelligent Orchestrator 就可以决定优先级较低的集群必须放弃一些资源，这样，这些资源就可以被自动配置到优先级较高的集群中。

回页首

综合使用

这三个主要的组件 —— Tivoli Intelligent Orchestrator、Tivoli Provisioning Manager 和 Enterprise Workload Manager for Multiplatforms —— 可以构成随需应变环境的基石。

图 2 显示了这三个组件是如何一起工作的。

它们之间的交互如下：

1. 客户端发送一个请求。
2. 位于 Web 服务器前面的负载均衡器（例如 Cisco 的产品）会通过 Enterprise Workload Manager for Multiplatforms 使用 HTTP 服务器的健康统计信息将任务路由到最健康的 Web 服务器上。
3. 在 HTTP 服务集群中，接收请求的集群负责进行分类，并执行一个 ARM 启动事件。当请求完成时，又会执行一个 ARM 停止事件，并发送回客户机。
4. 中间层的 WebSphere Application Server 在应用程序启动和停止时也会执行启动和停止命令。
5. 在处理请求时，DB2 Universal Database 也会执行启动和停止的 ARM 命令。
6. Enterprise Workload Manager for Multiplatforms Domain Manager 会搜集在事务请求过程中所捕获的所有数据，并将其存储。它会保留一个小时的历史数据。
7. 使用 OA，Tivoli Intelligent Orchestrator 会推动 Enterprise Workload Manager for Multiplatforms 来获取必需的数据，并使用这些数据来计算策略分支的可能性。正常来讲，Tivoli Intelligent Orchestrator 会向 OA 查询分支的可能性，并根据这些可能性进行决策。
8. 当 Tivoli Intelligent Orchestrator 判断自己需要在某一层中添加或减少一个服务器时，就会调用 Tivoli Provisioning Manager 使用预先定义的任务流或脚本对服务器进行修改。

图 3 显示了使用 Tivoli Intelligent Orchestrator 和 Tivoli Provisioning Manager 的一个网格集成例子。

任务流的流程如下：

1. 请求被提交给网格资源管理程序。
2. 网格管理程序决定哪个节点接收任务。
3. 请求被路由到所选择的节点上。
4. 响应被返回给请求者。
5. 在处理网格请求时，Tivoli Intelligent Orchestrator 中的 OA 会连续推动网格管理程序，从而获取性能统计信息，并获取队列的深度来计算分支的可能性。基于这种可能性，Tivoli Intelligent Orchestrator 可以决定是否添加另外一个服务器或删除现有的服务器。
6. 当作出添加或减少服务器的决定时，Tivoli Intelligent Orchestrator 就会调用 Tivoli Provisioning Manager。
7. Tivoli Provisioning Manager 执行一个任务流，它可以是由一个或多个脚本组成的，用来向一个网格环境中添加或减少服务器。

注意：当为 ARM 完全启用商业网格产品时，您就可以开发一个类似于上面介绍过的 Web 基础设施例子的集成网格环境，因为 Enterprise Workload Manager for Multiplatforms 可以分析在这些环境中正在运行哪些任务。

回页首

结束语

我们介绍的每个组件都是整个系统的一个集成部分：

• Enterprise Workload Manager for Multiplatforms 负责搜集数据并为端到端的基础设施中的事务提供数据。这些信息可以使用接口进行访问，其他设备或组件可以使用这些信息来确定每个决策的最佳路径和端到端的事务中的路由点。
• Tivoli Intelligent Orchestrator 可以确保资源被有效地部署到企业中。
• Tivoli Provisioning Manager 执行 Tivoli Intelligent Orchestrator 所安排的部署。使用基于硬件的技术，例如 Director RDM 和 CSM，Tivoli Provisioning Manager 可以管理资源的硬件和软件组件。

将来，这些组件之间的联系会更加紧密。例如，您可能会在 Tivoli Intelligent Orchestrator 中运行一个 Enterprise Workload Manager for Multiplatforms OA，从而帮助确定资源的利用率。Tivoli Intelligent Orchestrator 和 Tivoli Provisioning Manager 会确保所有适当的资源都可以用于请求被路由到的应用程序。Enterprise Workload Manager for Multiplatforms 会通过提供端到端的相关数据来帮助确保服务器和网络设施在随需应变的基础设施中进行优化。这些组件在基础设施进行自主管理的世界中迈出了第一步。

参考资料

• 阅读有关 IBM Virtualization Engine Suite for Servers 和其中所包含的组件的信息。
  
  
• IBM Enterprise Workload Manager 是一个信息丰富的 IBM 红皮书。
  
  
• IBM Enterprise Workload Manager SDK 是一个用来帮助应用程序和中间件中 ARM V4.0 的开发和测试的工具。
  
  
• 下载 Tivoli Intelligent Orchestrator 的演示版本。
  
  
• 阅读更多有关 Tivoli Intelligent Orchestrator 和 Tivoli Provisioning Manager 的信息。
  
  
• 在开始编写自己的工作负载之前，请在 OPAL 目录 中搜索现成的版本。
  
  
• Open Group 负责 ARM 标准 的制定工作，这个标准描述了一种将企业应用程序作为可管理的实体进行集成的通用方法。
  
  

作者简介

Frank De Gilio 从 1985 年开始就一直在 IBM 工作。他曾经从事过 MVS 系统的开发、工具集和中间件的开发，并且参与了在客户机/服务器和 Internet 环境中将 MVS 绑定到工作站上的项目。 1997 年，他加入了 IBM S/390® 新科技中心，在此期间他在 UNIX®、MVS 和 Microsoft® Windows® 应用程序/中间件方面的开发经验成为他向客户展示如何在启用 Web 的环境中使用最新的 OS/390® 技术的关键。目前他在新的 IBM Design Center for On Demand Business 部门工作，向客户展示如何使用最新的随需应变技术来增强自己的基础设施。

Hilon Potter 是 IBM Design Center for On Demand Business 的一名资深架构师和 IT 认证专家。他帮助 IBM 的客户机设计端到端的解决方案已经有十年多的历史了，同时还是一名 SHARE、zSeries® Business Leaders Council 和其他会议的参与者。他还是 IBM Poughkeepsie Technical Vitality Affiliate 的一名成员，在基于 Web 的服务领域拥有几项正在公示和已经正式发布的专利。

为本文评分

评论

回页首

内容

• 简介
• IBM Enterprise Workload Manager for Multiplatforms
• IBM Tivoli Provisioning Manager
• IBM Tivoli Intelligent Orchestrator
• 综合使用
• 结束语
• 参考资料
• 作者简介
• 建议