级别： 初级 Karl Lvoff (osipov@us.ibm.com), 软件工程师, IBM
Terrence White (tewhite@us.ibm.com), IT 咨询专家, IBM
2006 年 10 月 19 日 在本系列的关于在集群环境中进行部署的最新部分中，您将回顾关于集群部署的主要 IBM WebSphere® MQ 概念。通过使用这些概念，可以确定本系列的第 13 部分所描述的拓扑结构的伸缩性和工作负载平衡特征。您将以前一篇文章建议的体系结构为基础，来探索实现不同可用性和工作负载平衡属性的拓扑更改。另外，还将回顾与您生产环境相关的高可用性和安全主题。
WebSphere MQ 概念回顾
在下面的部分中，将讨论 WebSphere MQ 服务器所使用的主要组件。如果您熟悉面向消息的中间件，此列表将对核心概念进行简单回顾。有关更加深入的讨论，请访问 WebSphere MQ 资料库（请参阅参考资料）。
- 队列。一个命名目的地，消息可以送到此处。消息将在队列上集聚，等待处理它的程序进行检索。队列管理器上定义的队列称为本地队列。
- 队列管理器。队列驻留在队列管理器中，并由队列管理器进行管理。队列管理器会提供一个 API，以便程序能将消息放到队列上，并可以从队列提取消息。对于其所属的每个队列，队列管理器都包含一个对应的定义。队列管理器也可以包含属于其他队列管理器的队列的定义，此类定义称为远程队列定义。应用程序也可以将以这些远程队列为目标的消息放置在其中。
- 传输队列。一种特殊的本地队列类型，消息将存储在其上，直到成功地将消息传输并存储在远程队列管理器上为止。
- 通道：两个队列管理器间的单向通信链接。其上可以承载以远程独立管理器上的任意数量的队列为目的地的消息。如果您的应用程序要求从远程队列管理器上返回消息，则需要在两个队列管理器之间定义另一个相反方向的通道。
使用中央队列管理器进行部署
在本系列的前一篇文章“在集群环境中进行部署”中，我们讨论了一种部署环境，其中采用了单个 WebSphere MQ 服务器实例承载中央队列管理器和 Business Process Choreographer (BPC) 队列。部署到在 WebSphere Business Integration Server Foundation (Server Foundation) 服务器上运行的环境的应用程序组织成一个集群。集群中的各个服务器通过网络发送和接收消息来与 WebSphere MQ 服务器进行通信。图 1 中是此部署拓扑的一个示例。尽管本文主要讨论 WebSphere MQ 安装在独立物理服务器上的场景，但实际上 WebSphere MQ 可以安装在环境中的其他服务器上。
图 1. 采用中央队列管理器的生产拓扑
图 1 中的拓扑具有 Server Foundation 集群高伸缩性的特征，但仅演示了消息工作负载的部分平衡。通过在各个节点添加更多的 Server Foundation 集群成员，可进行纵向扩展；而通过向集群添加其他 Server Foundation 节点，可实现横向扩展。不过，此方法意味着拓扑并不能实现完全的工作负载平衡，因为添加 Server Foundation 节点将提高对中央队列管理器的吞吐量要求。将传入请求分布到各个集群成员则会增加集群成员与 WebSphere MQ 交换信息时出现争用的可能性。而争用导致的延迟会由于网络通信的开销而进一步加剧。
WebSphere MQ 集群概念
下面的部分介绍 WebSphere MQ 集群的核心概念。在使用分布式队列的传统 WebSphere MQ 网络中，每个队列参数都是独立的。如果一个队列管理器需要将消息发送到另一个队列管理器，它必须定义一个传输队列、一个到远程队列管理器的通道，并为每个希望作为发送消息的目标的队列提供远程队列定义。集群是由采用某种方式进行了逻辑关联且需要共享数据的队列管理器组成的网络。它们直接通过单个网络彼此进行通信，而无需额外的通道定义、远程队列定义或传输通道。采用此方法可简化网络管理。下面让我们详细了解一下其中的相关信息：
- 集群队列管理器。队列管理器是集群的成员。它可以承载队列，并将其公布给集群中的其他队列管理器。集群队列管理器并不一定要承载或公布任何队列。可以直接将消息提交到集群，而仅接收显式地定向到其上的消息。
- 存储库。关于集群队列管理器的信息集合。这些信息包括队列管理器名称、位置、通道、其承载的队列等等。完整的存储库包含关于每个集群管理器的完整信息集，而部分存储库包含此信息的子集。
- 存储库队列管理器。完整存储库所属的集群队列管理器。为了确保可用性，请至少在集群中设置两个存储库队列管理器。其他队列管理器可以采用部分存储库。完整存储库队列管理器接收集群中其他队列管理器发送的消息，并据此更新其存储库。它们还彼此发送消息，以确保各自均包含最新的集群信息。
为了启用工作负载平衡，Server Foundation 集群中的应用服务器使用的所有队列管理器都必须属于相同的 WebSphere MQ 集群。MQ 集群中的每个 WebSphere MQ 服务器都需要以下队列管理器来支持 BPC：
- get。拥有所有 BPC 队列的队列管理器。由流程引擎用于从集群获取消息。
- put。不拥有任何队列的队列管理器。由流程引擎用于向集群发送消息。
另外，还要求参与集群的每个队列管理器具有以下专门用于处理集群信息的通道：
- 集群接收器通道。由队列管理器用于从集群中的其他队列管理器检索信息。其他队列的消息都将以接收器通道的定义指定的连接名作为目标地址。该连接名存储在集群存储库中，以便集群中的任意两个队列管理器都能向彼此发送消息。
- 集群发送器通道。一旦定义后，就由队列管理器用于在集群中通告其成员身份以及集群接收器通道的可用性，以便与集群中的其他队列管理器进行通信。集群发送器通道必须指向承载集群存储库的队列管理器之一。所有将来对集群中的队列和队列管理器的更改都将通过此存储库进行通信。
前面提到的集群存储库是用于跟踪集群中的成员和就任何更改与集群成员通信的机制。在部署中，有些队列管理器被选择用于存储和维护这些存储库。为了避免单点故障，建议选取集群中另一个队列管理器承载辅助存储库。此队列管理器应位于另一个节点上。
设计 WesSphere MQ 集群的另一个关键注意事项是，要确保所有存储库彼此间具有通过集群发送器通道的通信路径。通常，集群可靠性可增加集群中的各个存储库间的互连数量。（注：WebSphere MQ 的集群设计和存储库放置的细微差别不在本文的讨论范围内。）在下一部分中安装和配置的集群拓扑是一种用于组织队列管理器和存储库的常见拓扑。有关如何设计 WebSphere MQ 集群的信息，请参考“WebSphere MQ Queue Managers Clusters manual”。（请参阅参考资料。）
WebSphere MQ 集群的好处
Server Foundation 部署中的集群 WebSphere MQ 服务器有很多优点，包括：
- 通过集群改善工作负载平衡。当消息置于参与集群的队列管理器上的队列时，该消息可由集群中的任何队列管理器进行处理，从而提高各个服务器的利用率。
- 通过本地绑定改善性能。WebSphere MQ 服务器可以安装在与 Server Foundation 相同的物理服务器上。在这种情况下，BPC 所使用的 Java™ Message Service (JMS) 连接可以配置为在 WebSphere Application Server 和 MQ 之间使用通信绑定模式。绑定模式使用 Java Native Interface (JNI) 来直接调用 MQ 应用程序编程接口 (API)，从而避免了网络通信的开销。
- 通过冗余实现高可用性。在生产中，尽管两个应用程序在同一物理服务器上运行有性能优势，但仍然可能不会选择将 WebSphere MQ 和 Server Foundation 服务器安装在相同的物理服务器上。在这种情况下，可以通过为每个 WebSphere MQ 维护独立的物理服务器来实现更高的可用性。
在集群 WebSphere MQ 部署中，每个 MQ 服务器都将承载一对队列管理器，即“get”和“put”。get 队列管理器拥有由 BPC 所定义的一组队列，而 put 队列管理器没有队列，因为它只用于发送消息。由于所有队列都属于同一个集群，当消息到达队列管理器时，WebSphere MQ 将调用工作负载平衡算法来确定应由哪个队列接收此消息。因此，请求是在集群中的队列间共享的。
图 2 显示了一个以 Server Foundation 与集群 WebSphere MQ 部署的交互为核心的示例拓扑。请注意，Server Foundation 节点发送的消息可能会放置在任何属于集群的 put 队列管理器上，而 put 队列管理器将随后在集群中各个 MQ 服务器间进行工作负载平衡。
图 2. 采用队列管理器集群的生产拓扑
不过，有些依赖服务器关联性的应用程序无法获得 MQ 集群的工作负载平衡优势。服务器关联性意味着应用程序上的消息必须按照特定的顺序进行处理，这只有通过单个服务器处理消息才能得到保证。具有服务器关联性的应用程序仍然可以通过将 WebSphere MQ 和 BPC 安装在相同物理服务器上来改善通信性能，如图 2 所示。
安装和配置 WebSphere MQ 集群
接下来的部分将提供逐步的详细说明。
必需安装的软件
- WebSphere MQ V5.3 或更高版本
- WebSphere Business Integration Server Foundation 5.1.1
- WebSphere Application Server Network Deployment 5.1.1（带有 Server Foundation 扩展）
- IBM DB2® Universal Database™ (UDB) 8.1 或更高版本
注：集群中的业务流程必须全部都在 UNIX™ 计算机上运行，或者全部都在 Windows® 计算机上运行。不支持混合使用 UNIX 和 Windows 计算机。此处描述的安装是在 Windows 平台上进行的。在其他平台上安装时，请确保您的系统满足所需的先决条件。和在 Windows 平台上一样，需要在您的平台上安装 Java 消息传递和客户机功能。
安装 WebSphere MQ
本文假定您要将 WebSphere MQ 服务器安装在与 Server Foundation 安装相同的节点上，以通过 BPC 和 WebSphere MQ 间的本地绑定改善性能。如果您计划各自采用不同的服务器，则可以在 Configuring MQ resources for the business process container using the administrative console 部分找到有关如何指定恰当的 BPC 设置的更多信息。（请参阅参考资料。）
配置 WebSphere MQ
createQueues 脚本位于 WBISF_HOME\ProcessChoreographer 目录中。创建 NODE01.BPC.GET 和 NODE01.BPC.PUT，分别作为 BPC get 和 put 队列管理器，并将集群命名为 BPCCLUSTER。清单 1 显示了一个示例。
清单 1. 创建队列管理器
createQueues NODE01.BPC.GET BPCCLUSTER NODE01.BPC.PUT
|
成功执行了此脚本后，请在其他将要承载 WebSphere MQ 的节点上重复相同的步骤。在您的配置中，可以将 NODEXX 替换为在其上安装 WebSphere MQ 的主机名称。在本文中，该配置都使用 NODE01 和 NODE02 进行描述。
使用 MQ Explorer
- 启动 NODE01.BPC.PUT 队列管理器。
- 为 NODE01.BPC.PUT 队列管理器在端口 1414 上创建并启动一个新通道侦听器。
- 将 NODE01.BPC.PUT 配置为 BPCCLUSTER 集群的存储库。
对集群中其他队列管理器重复这些步骤。
为了确保队列管理器对集群可用，必须定义两个额外的通道：一个集群接收器 通道和一个集群发送器 通道。在本文所使用的拓扑中，两个 put 队列管理器的集群发送器通道都指向对方。换句话说，NODE01.BPC.PUT 的集群发送器将指向 NODE02.BPC.PUT，反之亦然。两个节点的发送器通道指向彼此，以交换描述集群事件的消息，如向集群添加新队列等。
通道定义可以通过使用 MQ Explorer 从 NODE01.BPC.PUT 队列管理器下的 Advanced > Channels 文件夹创建。配置了这两个节点后，将看到通道上的图标为绿色，指示正在进行通信。（请参阅图 3。）
图 3. 集群存储库通道
定义了集群存储库后，可以使用 MQ Explorer 向导将每个 WebSphere MQ 服务器上的 get 队列管理器添加到 BPCCLUSTER。从 NODE01.BPC.GET 队列管理器的上下文菜单中调用 Join Cluster 任务，以启动向导并指定以下信息：
- 为通道侦听器指定端口 1415
- 为集群指定 NODE01.BPC.PUT 上的本地存储库
对 NODE02 服务器重复这些步骤，使用 NODE02.BPC.PUT 作为集群存储库。
配置 Business Process Choreographer
在 Business Process Choreographer 安装期间（在第 13 部分进行了说明），计算单元中的每个应用服务器都配置为指向中央队列管理器。为了利用本文前面描述的 WebSphere MQ 集群配置，需要对配置进行修改，以利用集群队列管理器。
从 Server Foundation 集群的管理控制台打开 Resources > WebSphere MQ JMS Providers。选择集群中的一个服务器，然后打开该服务器的 WebSphere MQ Queue Connection Factory 配置。
需要修改为 BPC 配置的两个连接工厂：BPECF 应使用 NODE01.BPC.GET 队列管理器，而 BPECFC 应使用 NODE01.BPC.PUT 队列管理器。这两个连接工厂都还应该更改为使用 BINDINGS 作为传输类型。集群中的每个服务器都需要使用 BPECF 和 BPECFC 连接工厂的恰当设置进行更新。
高可用性和安全注意事项
本文中的拓扑通过将 WebSphere MQ 服务器和 Server Foundation 安装在同一个物理服务器上来以可用性为代价换取性能。如果服务器处理请求时出现故障，则在重新启动服务器之前，队列上的消息处理将不会继续。
在某些应用程序中，服务器重新启动的延迟是不可接受的。为了提高此拓扑的可用性，请考虑在独立的服务器上安装 WebSphere MQ，并采用高可用性解决方案，如 High Availability Cluster Multi-Processing (HACMP) on IBM AIX®。您的 WebSphere MQ 高可用性解决方案至少应能进行以下操作：
- 接管故障服务器的 IP 地址。
- 接管队列管理器用于存储队列文件的共享磁盘。
- 重新启动队列管理器和关联的进程。
对于此拓扑，WebSphere MQ 和 Server Foundation 间的通信使用绑定模式，即 Server Foundation Java 进程和 WebSphere MQ API 间的 JNI 接口。除了获得高性能之外，绑定模式还很安全，因为系统间所有的通信都在 Java 进程中进行。
转而采用高可用性安装意味着 WebSphere MQ 和 Server Foundation 间的通信要通过网络进行。由于绑定模式不适合在此情况下使用，因此需要确保 WebSphere MQ 队列连接工厂配置为使用客户机模式进行通信。为了保证在网络上传输的消息的安全，必须将客户机模式配置为支持 SSL 和 J2C 身份验证别名。（有关高可用性和安全问题的更多信息，请参阅“参考资料”部分。）
总结
在本文中，您了解了 IBM WebSphere MQ 提供的集群选项，以及如何利用集群消息传递来改善工作负载平衡。另外，还了解了在 WebSphere MQ 和其他面向消息的中间件中使用的核心概念和集群技术特定的概念。使用集群技术可提高 IBM WebSphere Business Integration Server Foundation 部署体系结构的整体可伸缩性；不过，如果计划利用 WebSphere MQ 集群来增强体系结构，应同时考虑其带来的好处，以及本文中说明的可用性和安全注意事项。
参考资料 学习
获得产品和技术
- 使用 IBM 试用软件开发您的下一个项目，可直接从 developerWorks 下载这些试用软件。
作者简介  | | | Karl Lvoff 是 IBM Software Group 的 On Demand Incubation and Development Organization 的软件工程师。他所擅长的领域是分布式计算和面向服务的体系结构以及语音应用程序开发和自然语言理解。他在本行业以及大众媒体上发表了一些对话管理主题方面的文章，并举行过这方面的讲座。您可以通过 osipov@us.ibm.com 与 Karl 联系。
|
| | | Terrence White 是 IBM Global Services 的 IT 咨询专家。他目前正在 Service-Oriented Architecture Plus 团队工作，重点是使用流程编排进行 Web 服务和业务流程开发。您可以通过 tewhite@us.ibm.com 与 Terrence 联系。
|
对本文的评价
| 
