WebSphere Process Server V6.0.2 集群，第 1 部分：了解拓扑

核心提示：引言集群是一项关键技术，可以用于改进 WebSphere Process Server 环境的可用性和可伸缩性，WebSphere Process Server V6.0.2 集群，第 1 部分：了解拓扑，通过集群技术，可以实现以下目标：提高系统的可用性，在本系列的第 2 部分，我们将对各个步骤进行详细说明，即通过提供

引言

集群是一项关键技术，可以用于改进 WebSphere Process Server 环境的可用性和可伸缩性。通过集群技术，可以实现以下目标：

提高系统的可用性，即通过提供冗余 Java™ Virtual Machine (JVM) 进程或硬件组件，确保在发生故障时保持某个级别的服务连续性。

通过提供其他进程和系统来运行事务，从而提供满足额外工作负载可伸缩性的机制。

故障转移和可伸缩性的概念很大程度上都是独立的。正因为如此，您可能会发现确保可伸缩性的拓扑并不能很好地确保可用性，反之亦然。

通过使用 WebSphere Process Server，可以采用很多方法使用集群技术来处理可用性和可伸缩性。

本文是本系列的第一篇文章，将简要介绍一些用于 WebSphere Process Server 集群的拓扑解决方案，并讨论各种方法的优缺点。本系列的第二篇文章将逐步说明如何设置我们所期望的最常采用的 WebSphere Process Server Version 6.0.2 的集群拓扑。

WebSphere Process Server 集群的关键拓朴

从宏观角度而言，每个 WebSphere Process Server 环境都涉及到三个基本层：WebSphere Process Server 应用程序、一个或多个关系数据库和消息基础设施，如图 1 中所示：

图 1. 要集群化的组件

WebSphere Process Server 应用程序包括流程服务器基础结构代码，如 Business Process Choreographer 以及利用流程服务器功能的任何用户应用程序。这些应用程序要求安装和运行 WebSphere Process Server 应用服务器。在概念上，集群 WebSphere Process Server 应用程序与在 WebSphere Application Server V6 环境中的集群普通 J2EE 应用程序没有太大区别。

一个或多个关系数据库。WebSphere Process Server 要求在关系数据库表中存储特定应用程序配置信息和运行时信息。为了保证持久性，下文将要讨论的消息传递基础结构也将使用关系数据库表。用于保证可伸缩性和可用性的集群 RDB 已是一项非常成熟的技术。我们将不会花时间讨论 RDB 集群技术。在本文中，我们将讨论如何设置必要的数据库和模式来支持 WebSphere Process Server 集群。下表显示了在对 WebSphere Process Server 进行集群化时将要处理的四组数据库对象：

“公用数据库” (WPRCSDB)。

Business Process Choreographer 数据库 (BPEDB)。

保存消息所需的 Messaging Databases (Messaging DB)。

公共事件基础设施的数据库对象（Common Event Infrastructure Database，CEI DB），主要在其中存储事件数据。

ESB Mediation Log 数据库 (EsbLogMedDb)，可以在希望记录 ESB 中介处理的每条消息时使用。数据库模式包含单个表。由于此数据与 WebSphere Enterprise Service Bus 产品的功能相关，因此我将不在本文中讨论。

消息传递基础结构。WebSphere Process Server 还要求使用消息传递基础结构。有些消息传递基础结构必须使用 WebSphere Service Integration Bus (SI Bus) 和 WebSphere Default Messaging JMS Provider。在本文中，对于 WebSphere Process Server 基础设施的任何消息传递需求，我们都不考虑使用其他消息传递提供程序。我们假定您将完全依赖于 SI Bus，此时，它是推荐的做法。

集群消息传递基础结构也许是整个关于集群的讨论中最复杂的部分。一般情况下，我们可以这样说，由于我们使用的是 SI Bus，它要求运行 WebSphere Application Server，因此还可以使用 WebSphere 集群技术来集群消息传递基础结构。不过，在选择要采用的拓朴时，需要了解若干注意事项。下面几个部分将讨论其中的一些注意事项。请注意，消息传递基础设施除了集群外，还需要四个 Service Integration Bus (SIBus)。创建集群时我们将需要考虑的 SI Bus 有：

与服务组件体系结构（Service Component Architecture，SCA）支持相关的两个总线（SCA. SYSTEM 和 SCA.APPLICATION 总线）。

用于 Business Process Choreographer 的总线 (BPC SI Bus)。

用于 CEI 异步事件发布的总线。

集群消息传递基础结构

WebSphere SI Bus 除提供其他功能以外，还允许您定义应用程序用于发送或检索消息的“目的地”（如队列或主题）。

为了使这些目的地实际可用，必须指定消息传递基础结构可以运行的应用服务器进程（或进程集群）。可以通过向 SIBus“添加成员”做到这一点。

“成员”可以是单个 Network Deployment 单元服务器，也可以是服务器集群。

在向总线添加成员时，在该成员上还将创建“消息传递引擎”（Messaging Engine，ME）。消息传递引擎是实现消息传递基础结构本身逻辑的应用服务器进程中的组成部分。

在作为 SIBus 的成员添加集群之后，每个集群成员都能够运行消息传递引擎。不过，在任何给定时间仅有一个集群成员拥有活动的消息传递引擎。适用于消息传递引擎的高可用性策略是一种“One-of-N”策略。

集群消息传递引擎时存在两个主要选项：

在作为 SI Bus 的成员添加集群时，会得到一个自动创建的消息传递引擎。刚才已经提到，此操作将创建一个消息传递引擎，该引擎使用“One-of-N”策略实现高可用性，从而激活消息传递引擎的单个实例。

在此情况下，与目的地关联的消息只有一个物理存储库。这种情况可以确保可用性；但是，只有为服务器提供了附加的计算能力（从本质上说，是通过在功能更强大的硬件上配置应用服务器）才能实现可伸缩性。

图 2. 消息传递的活动/备用集群拓朴

多个消息传递引擎同时处于活动状态。将集群添加到 SI Bus（这将创建第一个消息传递引擎）后，另外还可以手动在 SI Bus 的该集群上创建其他消息传递引擎。每个消息传递引擎都将使用“One-of-N”策略进行操作，但由于具有多个引擎，因此现在有多个活动实例。您可以创建自己的高可用性（High Availability，HA）策略，以定义在缺省情况下应在何处运行每个活动实例，从而跨各个集群成员均匀地分布活动引擎。

不过，此解决方案意味着 SI 总线上的目的地是分区的。也就是说，每个 ME 实例控制和使用整个队列的一部分；不再存在用于某个特定目的地的单个物理消息存储库。此类拓朴确实可以确保可伸缩性和一定程度的可用性。不过，在采用此技术前，我们希望您能记住三个注意事项：

由于没有单个消息物理存储单元，要满足保留消息序列之类的需求时，这些拓扑并非总是能满足要求。

消息使用者可能静态绑定到队列的一个特定部分。若是这样，如果特定使用者分区出现问题，可能最终会得到没有人能使用的搁浅消息。

与一次仅有单个活动 ME 的拓扑（非分区）相比，这些拓扑设置和管理更为复杂。

我们建议，仅在验证了消息传递基础设施的确是解决方案的瓶颈的情况下才使用图 3 中所示的拓扑：

图 3. 具有分区队列的活动/活动集群拓朴

您已经了解到集群消息传递引擎的两个基本选项，接下来我们将讨论对于 WebSphere Process Server 应用程序，消息传递引擎可以位于何处。

这也有两个选项：

消息传递引擎与 WebSphere Process Server 应用程序共存。换句话说，消息传递引擎与 WebSphere Process Server 应用程序在同一集群中运行。

消息传递引擎位于自己的集群中，与 WebSphere Process Server 应用程序分离。

这两个选项有四种可能的组合。

消息传递引擎与 WebSphere Process Server 应用程序位于相同的集群中，队列未分区。在这种情况下，在 WebSphere Process Server 应用程序中运行的任何消息驱动的 Bean 都将被强制“绑定”到本地消息传递引擎。这是一个 SI Bus 设计点：如果 MDB 有本地 ME 可用，它将始终连接到此 ME（即使在 ME 处于非活动状态时也是如此）。由于这个原因，只有一个集群将具有 MDB 的活动实例。显然，如果您使用不可中断的（长期运行）业务流程或异步 SCA 调用，这个选项意味着对解决方案的总体可伸缩性有重大的限制。不过，这些拓朴比较简单，易于设置和管理。通常，我们建议除非对以下方面非常确信，否则不要利用此类拓扑：

您将永远不会使用长期运行的流程或异步 SCA 调用。

即使使用长期运行的流程和异步 SCA 调用，也不关心除一个集群成员之外所有其他成员都实际上处于备用状态这一事实。

图 4. 最简单的集群拓扑：活动/备用

此拓朴的设置比较简单，仅需要少量服务器和单个集群。不过，正如我们提到的，它具有一个大缺点，可能会极大地限制此类配置的可伸缩性。

WebSphere Process Server 应用程序和消息引擎位于相同的集群中，但对队列进行分区。

此拓扑是前一拓扑的变体，如图 5 中所示。

图 5. 具有分区队列的活动/活动拓朴

与前一拓朴相比，此拓朴的优点是提供了一个可伸缩的环境，其中多个 MDB 同时处于活动状态（尽管它们在同一队列的不同分区上）。下面让我们分析一下此拓扑选项的优缺点：

通过多个集群成员对消息传递引擎进行了扩展。这是一个优点。

另外，由于 ME 与使用消息的 MDB 位于相同的服务器上，因此尽可能减少了延迟。这也是一个优点。

对目的地进行了分区，使其成为了较难管理的环境，对保存消息序列造成了困难。这是一个缺点。

此解决方案不能保证消息传递引擎的真正故障转移。例如，如果 ME1 在其当前活动的服务器上崩溃，HA Manager 实际上将在没有受到影响的服务器（例如 ME2 处于活动状态的服务器）上激活 ME。不过，任何使用者都无法在该服务器使用它。崩溃时在第一个分区中包含的任何消息都将为“搁浅”状态。

消息传递引擎和 WebSphere Process Server 应用程序位于独立的集群中。我们建议只要实际可行，就采用此拓扑。

无分区队列、活动/备用拓朴。

图 6. 将消息传递引擎隔离在单独的集群中

此拓朴可让您真正实现 WebSphere Process Server 应用程序的可伸缩性，因为它可以同时让多个 MDB 处于活动状态。

此外，由于队列未分区，则对能够在 WebSphere Process Server 集群上运行哪种应用程序没有特别限制。

它还可以让您独立于消息传递引擎优化和配置 WebSphere Process Server 集群。

仅需要注意的一点是消息传递引擎的可伸缩性，只有将其置于功能较为强大的系统上才能实现其可伸缩性。

分区队列、活动/活动拓朴。

图 7. 实现消息传递的最大可伸缩性的队列

此拓朴可以实现完全的可扩展性，并允许单独管理 WebSphere Process Server 集群和 ME 集群。

不过，由于分区目的地的原因，考虑处理消息时保持顺序、工作负载不平衡等问题时，需要记住一些注意事项，具体取决于各个分区的填充方式。设置此类拓朴的任务也非常复杂。

由于复杂性增加，在确定吞吐量的主要限制因素是消息引擎，并对应用程序的限制全面了解的情况下，我们建议采用分区目的地。

对拓扑进行分类

现在已经了解了与 WebSphere Process Server 组件和消息传递引擎相关配置有关的选项，接下来让我们对各种拓扑进行分类。

表 1. 拓扑分类

拓扑名	说明
青铜	此拓扑包括一个运行所有组件的集群： WebSphere Process Server 应用程序 消息引擎（每个 SI Bus 一个） CEI 正如我们说过的，如果您使用长时间运行的业务流程执行语言（Business Process Execution Language，BPEL）或异步 SCA 交互，则此拓扑可能不保证可伸缩性。
白银	此拓扑包括两个独立的集群： 一个集群用于安装 WebSphere Process Server 应用程序和 CEI Event Server。 一个集群用于消息传递引擎。 此拓扑确保 WebSphere Process Server 应用程序和 CEI Event Server 能通过将一定数量的物理服务器分配到其集群中来进行“扩展”。此拓扑是非常适合大部分中小型环境的选择。
黄金	此拓扑引入了专门（本质上是这样）用于运行 CEI Event Server 的第三个集群。 最后得到的是三个集群： 一个集群用于 WebSphere Process Server 应用程序。 一个用于消息传递引擎。 一个用于 CEI Event Server。 当处理量非常大且可伸缩性是一项主要需求时，建议采用此拓扑。通过将 CEI Event Server 和 WebSphere Process Server 应用程序分离，可以确保这两个组件不会争用相同的资源（内存和 CPU）。 此拓扑还能帮助创建集中的事件服务器。可以让此事件服务器处理来自多个源的事件。CEI 集群还能够独立使用自己的一组物理设备。

在本文档中，我们将讨论如何通过设置三个服务器集群来设置黄金拓扑。

集群关系数据库

我们在上文已简要提到，可以通过许多已知和经证实的技术来实现关系数据库平台的高可用性和可伸缩性。我们认为该主题已超出本文讨论的范围。

目标拓朴

对于我们的示例场景，我们采用了具有三个独立集群的黄金拓扑，一个用于 WebSphere Process Server 应用程序，其余两个分别用于消息传递引擎和 CEI Event Server。

对于黄金拓扑，建议的配置包括至少三个系统和一个用于承载数据库的独立计算单元（或计算单元集群）：

一个系统（最小的系统）将专门用于运行 Deployment Manager。将仅在此系统上创建 WebSphere Process Server Deployment Manager 概要。

在其他两个系统上，将各创建一个 WebSphere Process Server 自定义概要并将每个概要添加到 Deployment Manager 计算单元。每个概要均包括一个节点。

将随后创建跨这两个系统的三个集群，如图 8 中所示：

图 8. WebSphere Process Server 的带三个系统的黄金拓扑

作为图 7 中所示的拓扑的变体，可以在其中一个节点上安装 Deployment Manager，但记住这可能会让备份和恢复工作变得更为复杂。

如果具有三个以上的系统，还可以尝试通过为消息传递引擎使用普通 WebSphere Application Server 概要来尽可能减少拓扑的许可需求（消息传递引擎并不需要在 WebSphere Process Server 服务器中运行，可以在安装普通 WebSphere Application Server 的节点上运行）。

图 9. 更为复杂的“黄金”拓扑

图 9 所示的拓扑中我们创建了以下内容：

在 System A 上创建了 WebSphere Process Server Deployment Manager 概要

在 System B 和 System C 上创建了 WebSphere Process Server 自定义概要

在 System D 和 System E 上创建了 WebSphere Application Server 自定义概要

我们随后将四个节点联合到 Deployment Manager，并仅在 System D 和 System E 上配置消息传递引擎。

本文所述的拓扑与我们在图 8 中所看到的拓扑类似。我们所使用的系统并没有那么多，但我们的确创建了一个 WebSphere Process Server Deployment Manager 概要、一个 WebSphere Process Server 自定义概要和一个 WebSphere Application Server 自定义概要。

下面（图 10）对目标拓扑进行了总结：在 ISSW1 上，我们安装了 Deployment Manager 和 WebSphere Process Server 自定义概要。在 ISSW2 上，我们创建了 WebSphere Application Server 自定义概要。

在第三个单元上，我们安装了 DB2® 和拓扑所需的数据库。此拓扑消除了由于创建驻留在单个物理设备上的集群而导致的单个故障点。

图 10. 详细说明部分描述的拓扑

当然，在此示例中，我们使用了“垂直集群”（在相同物理设备上创建集群成员）来说明如何设置此拓扑，在实际环境中，由于物理崩溃时无法确保故障转移，因此几乎从来不会单独使用“垂直集群”。

安装集群（黄金拓扑）的主要步骤

以下列出了安装和配置实现图 10 中所述的拓扑的集群时所涉及的主要步骤。

在所有计算机上安装产品二进制文件和修补程序包。

创建概要。

联合节点。

创建 ME 集群。

使用新 Business Integration Wizard 来创建和配置 SCA 运行时所需的 SI Bus。

创建 WebSphere Process Server 集群。

使用脚本来创建 BPC 数据库。

使用新 Business Integration Wizard 来配置业务流程容器 (Business Process Container) 和人工任务容器 (Human Task Container)。

创建 CEI 集群。

执行 CEI 应用程序的手动安装。

对数据源进行手动更改。

结束语

到目前为止，我们对一些拓扑选项和在规划 WebSphere Process Server 集群时需要考虑的优缺点进行了概略讨论。我们还介绍了一个常用的集群方案（黄金拓扑），并列出了实现此方案所需的步骤。

在本系列的第 2 部分，我们将对各个步骤进行详细说明，向您讲解从如何安装产品到如何配置集群和相关资源的详细操作。