级别： 初级 Andrew Humphreys (andrew_humphreys@uk.ibm.com), 知识传播负责人，Software Services for Websphere, IBM Hursley United Kingdom
2004 年 4 月 01 日 项目架构师需要考虑如何在高可用性的配置中包括 WebSphere Business Integration Message Broker 的重要性。本文将描述如何通过结合应用程序设计与基于软件的队列管理器的群集（利用 MQ 群集和在硬件层提供的机器群集）的使用来达到高可用性。
引言
在以业务为主或以任务为主的环境中使用任何软件产品都需要考虑其可用性，可用性是对系统实际完成假定它应该执行的任务的能力的度量（即便是出现系统崩溃、设备故障或环境灾难等异常情况也是如此）。
因此，考虑如何保证 WebSphere Business Integration Message Broker V5实现所遇到的性能和可用性目标是重要的。由于 Message Broker 最通常的实现是作为一个中央集线器，消息传递体系结构中的所有消息都流经这里，所以它是一个潜在的瓶颈和整个 WebSphere MQ Queue Manager网络的一个单独的故障点。
本文将概述一些在高可用性环境中用于实现 WebSphere Business Integration Message Broker V5的选项。
需要考虑的可用性问题
有很多方面都会有助于Message Broker环境的高可用性。例如，请考虑如下一些问题：
- 可靠的硬件
- 共享队列
- 健康监控
- 故障转移群集
- 在线备份
- 双重网络
- 可靠的操作系统
- 在线重新配置
- WebSphere MQ 群集
- 快速重启
- RAID 磁盘
- 崩溃恢复
- 快速启动
- IP 接管
- 文档化的程序
- 实践中的程序
在考虑可用性时所有这些因素都是重要的。
可用性的一般目标是 99.999%的全年可用性。下面是可用性的正式定义：
百分比_可用性 ＝ 正常运行时间/（正常运行时间＋停机时间）* 100
根据这个定义，在任何特定的系统中，要达到 99.999%的全年可用性，该系统每年最多只能有 5.26分钟的停机时间。
停机时间可以分解为：
停机时间＝ 计划停机时间 ＋ 非计划停机时间
这说明，通过避免系统的非计划停机来达到可用性级别会受到一定的限制。一个从来不会崩溃的并且每个季度有30 分钟的停机时间（在每年总共 8,766 小时的时间中有 2小时的停机时间）进行计划维护的系统的全年可用性为：
8,764 小时/8,766 小时 * 100 ＝ 99.977%
换句话说，99.999%可用性是一个非常有挑战性的目标，并且通常需要设立一个单独的项目来分析：
-
硬件和软件配置
。需要考虑磁盘镜像、服务器冗余以及不中断电源。
-
应用程序设计
。开发人员必须设计支持非破坏性版本升级的应用程序。
-
数据中心组织。需要考虑严格的更改控制、全面的测试以及操作支持。
考虑可能出现的一些与服务器有关的故障。其中包括磁盘故障、处理器/内存故障和电源（或电源本身）故障、网络故障等等。还有许多其他可能的方面。
减少与服务器有关的故障的一种方法是安装可能发生故障的组件的多个实例。例如，可以通过不同的磁盘控制器来建立磁盘的镜像。可以安装多个CPU（尽管在一个 SMP机器中仍然只有一个系统内存），可以安装多个电源或后备电源和UPS，而多个网卡和网络连接能够通过不同的路由器进行连接。
除了上述不可预测的因素之外，还有一些其他的原因可能会导致服务器出现故障--例如，服务器运行的软件出错或不当的使用引起的操作错误。在以安全为主的应用程序中通常运行软件的几个不同的实例，这些实例都是使用不同的编译器、在不同的处理器体系结构上甚至使用不同的算法构建的。这种做法对于商业使用来说一般行不通。
给商业用户的最好的建议是，将生产服务器的使用限制在经过完全试验和测试的具有最低配置的软件和操作程序上。即使系统使用了内置的冗余，它也不能够保护服务器避免出现环境问题，这些问题可能影响整个机器、整个房间中的机器或整个办公楼中的机器。
更大范围的保护/备份是必要的--这是灾难恢复的区域，其中运行着与主要生产站点平行运行的远程站点。如果生产站点遇到环境问题，那么操作将转移到远程站点。
上述所有故障（甚至环境故障）的一个普遍问题是它们造成了威胁，这是因为“系统”包含了一些单独的故障点。成功的设计会减少单独故障点的数目。灾难恢复预置能够避免一个站点成为一个单独的故障点。
在一个站点中，内置硬件冗余能够消除服务器中某些类型的单独故障点，但是不能消除全部。
有几种方法能够使可用性最大化，其中一种是创建合作运行关键服务的商用电脑群集。这些群集所指通常称为高可用性（High Availability，HA）群集。群集服务器的使用类似于内置冗余，但是它们处理的是整个服务器而不是其内部组件。群集服务器提供了一种成本效率高的方法来避免站点中的所有硬件的单独故障点。
消息传递和可用性
消息传递软件的可用性需要考虑两种类型的消息，那些已经加入队列的消息（“现有消息”）和那些还没有加入队列的消息（“新消息”）。
图 1. 群集选项定位
图 1显示可达到的可用性等级：
- “Continuous”表示不间断访问消息。
- “Automatic”表示不需要人工监控或干预就能够恢复可用性。这有助于使停机时间最小化。
这些技术包括：
- 底部是不需要特别考虑高可用性的系统。
- 接下来的是故障转移群集，通常称为共享磁盘群集（实例包括 HACMP 和 MSCS）。
- 与故障转移群集重叠的是 WebSphere MQ 群集。
- 顶部是共享队列支持和容错硬件。
图中需要注意的一点是可以使用 Message Broker 的平台，它只是为所有的消息提供 HA 支持的分布式集群（即 MQ 软件群集）和重启/故障转移群集（即硬件集群）的组合。
Message Broker 的高可用性配置
可以通过结合两种不同技术来获得Message Broker 连接器的高可用性和高吞吐量：
- 软件群集，用于提供跨整个集线器的负载平衡和高服务可用性（通过允许集线器中的个别服务器在其他的服务器继续运行和对集线器进行服务请求时变得不可用）。
- 硬件群集（例如 HACMP），用于提供 Message Broker 集线器内的单个服务器的高可用性。
我们推荐 Bank One考虑在它们的消息传递集线器中同时使用这两种技术以获得高的吞吐量和可用性。通过组合 WebSphere MQ群集和 HA（共享磁盘）服务器群集，正在运行出现故障的节点的队列管理器可以把故障转移到健康的节点，然后重新启动，从而使得消息再次可用，这比其他情况要快得多，而且能够进行水平伸缩以使集线器吞吐量最大化。
软件群集
应该考虑由一个“逻辑集线器”组成的网络拓扑，集线器包含多个物理WebSphere MQ Queue Manager，服务 Message Broker中的多个代理，以分散工作负载，进而改进性能和可用性。
逻辑集线器应该由1-n 个运行 Message Broker代理的服务器组成。逻辑集线器中的每个服务器都有 1-n 个WebSphere MQ 队列管理器（1-1映射到该服务器的代理）。下面两种情况都是可能的,第一种情况是为逻辑集线器中的每个代理部署相同的执行组和消息流，以使每个代理能够处理任何类型的消息；第二种情况就是为每个代理定义所部署的不同消息流，以使工作分散在整个逻辑集线器上，也就是说，一些需要立即处理的消息将到达运行在快速服务器上的代理，而需要较慢响应的消息将到达较慢的服务器
1
。
逻辑集线器器中的队列管理器应该是群集的（使用 WebSphere MQ群集），以提供跨集线器中的每个服务器的高可用性和负载平衡。群集外部的应用程序将只把消息放到逻辑 WebSphere MQ Integrator传入队列中。WebSphere MQ 群集将利用 WebSphere MQ群集负载平衡和可用性算法来把消息传播到每个 WebSphere MQ IntegratorBroker 的传入队列的实例中。
WebSphere MQ群集
WebSphere MQ群集简化了管理并允许（消息流量的）工作负载平衡。它们也为新消息提供更高的可用性，这是因为可以把它们放到群集队列的其他实例中。
WebSphere MQ群集应该用来实现水平可伸缩性和工作负载分布。图 2显示了如何组织 WebSphere MQ队列管理器群集来提供工作负载分布。
在图 2 中，APP1和 APP2 是同一应用程序当前正在运行的两个实例。B1 和 B2是两个当前正在运行的代理，它们配置相同。来自应用程序实例APP1 的消息被发送到集线器，地址指向队列“BROKER.REQUESTQ”。该队列已在队列管理器 QMB1和 QMB2 中定义。这两个队列管理器都是同一 MQ群集的成员。需要注意的是队列管理器（QMB1 和 QMB2）位于该群集而不是代理本身中。不能直接地把代理添加到 MQ群集中，因此您必须添加这些代理所使用的队列管理器。
在发送自己的请求消息时，APP1并不知道这些，已经把消息放到它的本地队列管理器中（只是使用队列名称作为目的地）。由于该队列并没有在QMA1本地定义，因此队列管理器将检查它的群集定义以查看该队列是否定义为群集队列。队列管理器有该队列的两个定义，一个定义在 QMB1，而另一个在 QMB2。WebSphere MQ将在执行时通过把消息循环回收（round-robbing）到每个队列，以决定 BROKER.REQUESTQ的两个实例中的哪一个将接收此消息。
在下面的图中，发送了两个请求消息，并且 WebSphere MQ群集将一个消息发送到 QMB1，而将另一个发送到 QMB2。APP1 指定 MY.REPLYQ作为它希望接收应答消息的队列。它可以但不需要是一个群集队列--不过，在本例中请注意，需要把应答消息发送到队列管理器QMA1 中的 MY.REPLYQ。这应该通过在代理中保留和使用由 APP1 放置到MQMD 中的 ReplyToQ 和 ReplyToQMgr 字段来加以管理。
如果在应答消息中没有正确地指定ReplyToQMgr，那么在一个群集中拥有应答队列的多个实例将会引发问题。在这种情况下，APP1需要的应答消息可能发现本身位于消息管理器 QMA2 的 MY.REPLYQ的实例中。如果没有设计 APP1 和 APP2，那么上述情况当然就是真实的，在这种方式下，它们能够处理来自相同应用程序或适配器中的另一实例的应答消息。
对于 MQ系统管理员来说，WebSphere MQ群集存在几个潜在的问题。例如，如果一个队列管理器出现故障，那么即使发送到群集的任何后续消息不会被发送到出现故障的队列管理器，但是已发送到队列管理器但是代理还没有进行处理的任何消息都会被放置到已出现故障的队列管理器中。
为了使 WebSphere MQ 群集在不同的队列管理器的队列间实现负载平衡，需要把从群集外部发送的消息发送到一个“网关”队列管理器中。这将为整个逻辑集线器产生一个单独故障点。因此这个网关队列管理器将需要有非常高的可用性。为了克服这个问题，可以把消息所源于的队列管理器包括在群集中。如果它们所包含的队列的名称没有与群集负载中多个队列管理器内定义的消息代理传入队列的名称一样的，那么还是可以达到负载平衡。
图 2.负载平衡 MQ 群集
在一个正确配置的WebSphere MQ 群集中，托管集群的完整存储库的所有队列管理器都必须通过使用本地定义的群集发送者通道完全地互相连接。当托管集群的完整存储库的WebSphere MQ 队列管理器接收到一个更新时，它会沿着所有本地定义的群集发送者通道来发送该更新，从而把更新传播到其他的完整存储库中。更新
不是沿着自动定义的（auto-defined）群集发送者通道传播的。
除非群集非常大，否则最好不要把两个完整存储库放在一个群集中。这样做会使设置变得复杂，并且起不到什么好的作用。
MQ群集和 WebSphere MQ 应用程序设计
在设计 WebSphere MQ 应用程序时，尽可能地避免消息亲缘关系（message affinity）是重要的。在需要多个消息来构造一个单独的业务事务或必须以特定的顺序来处理消息时会产生消息亲缘性关系。
因为消息亲缘关系会阻碍平行伸缩，所以应该避免。通过使用群集，可以很好地水平伸缩MQ 和 WMQI。然而，由于消息亲缘关系需要通过相同的线程、代理等等来处理消息，所以它们会阻碍成功的伸缩；这就产生了一个瓶颈。虽然在流程或代理的单独实例中进行性能调整是可能的，但是对于能够达到的吞吐量通常存在物理方面的限制。避免亲缘关系使得应用程序能够跨多个节点运行，这样就能够更好地进行伸缩。
例如，考虑一个贮备管理系统，它发出数个记录来构成一个单独的订单；一个头部记录、若干单独的行式项目记录和一个尾部记录。最简单的方法似乎是把每条记录作为一个单独的消息来发送；然而，这将不是一个好的设计，因为它将在消息间产生亲缘关系，也就是说，每条消息需要其他的消息来构成一个单独的业务事务。这可能隐含WMQI，例如，用于 WMQI 决定将把订单发送到何处的路由信息仅包含在头部中。这使 WMQI需要包含用于组合所有消息以确保正确地路由这些消息的逻辑。更好的设计将把所有的订单记录作为一个单独的消息来发送。
另一个可能影响 WMQI 的消息亲缘关系示例是对系统处理消息的顺序有依赖性的地方。例如，考虑一个处理新的顾客并把他们添加到顾客数据库中的系统。设计可能需要单线程处理所有的新顾客，以确保正确地分配顾客编号并且避免在数据库中创建重复的顾客记录。
硬件群集
在其最基本的层中，硬件群集将自动地从一个出现故障的服务器转用另一个服务器，因而使非计划停机时间减到最少。下图显示了一个典型的硬件群集配置。
该图显示了一对群集的服务器，它们都能访问一个共享的磁盘盒，该磁盘盒包含多个物理磁盘。
这样的配置通常称为“共享磁盘群集”，但是它实际上是无共享体系结构，这是因为不能有多个节点同时访问磁盘。另外，它通常拥有多个电源和网络。
图 3. 群集的服务器
通常将物理磁盘组织成 RAID-1或 RAID-5逻辑卷，并且每个服务器将有多个磁盘控制器，它们连接到 RAID 阵列的不同部分（例如子镜像）。
在一个服务器群集中，影响一个节点的故障将引起该节点正在运行的工作“故障转移”到另一个（健康的）服务器中。该图显示一个应用程序实例（在本例中是称为QM1 的队列管理器）从左边的节点故障转移到右边的节点。
群集软件检测到左边的节点有问题--这可能是硬件问题也可能是非硬件问题。于是备用机器将会：
- 接管 IP 地址。
- 接管共享磁盘。
- 启动队列管理器以及相关联的进程（通道、监听器、触发器监控器）。
这通常称为冷备用（cold-standby）；在同一时间内只有一个节点在主动地运行工作负载。这是一种简单但是相对来说成本高的配置。另一个选择是部署活动/活动（active/active）配置，也称为相互接管（mutual takeover）配置，在这种配置中多个节点可以同时运行。
在 WebSphere MQ 的上下文中，将 /var/mqm 下面的特定于队列管理器的目录放置在共享磁盘中，这样就允许不同的节点同时访问这些子目录。这使得多个节点同时执行 WebSphere MQ工作成为可能。活动/活动配置比冷备用配置拥有更高的服务器应用（server-utilization）。在一些平台上，这将是一个设置稍为复杂的配置，但是可以使用WebSphere MQ HA 支持包（诸如 MC63 和 IC61）中的脚本来自动完成配置。
为了将故障时间减到最少，必须训练操作员可靠并有效地执行切换（switch over）。我们强烈推荐您每隔一段时间（每月或每两月）运行切换（switch over）预演。这将确保操作人员了解程序，并且还使得可以在早期检测到生产和系统测试间的配置更改。
结束语
本文讨论了将 WebSphere Business Integration Message Broker 作为高可用性配置包括在内的重要性。
本文还介绍了如何通过结合应用程序设计与基于软件的队列管理器的群集（利用MQ 群集和在硬件层提供的机器群集）的使用来达到高可用性。
高可用性不是一些想要就要想不要就不要的东西。如果需要 MessageBroker 提供级别非常高的可用性，那么项目架构师就必须考虑应用程序的可用性和吞吐量需求，并且进行全面的计划和测试以确保这些目标是可达到的，理解这一点非常重要。
关于作者  | 
| |
Andrew Humphreys
是一名业务集成专家，他作为顾问为 IBM Software Services for
WebSphere 工作。他在设计 WebSphere Business Integration Message Broker
解决方案方面具有非常丰富的经验，并且已经在全世界范围的顾客站点上施展他的这些技能。他是
IBM
顾客、IBM 服务社区以及 Hursley 开发实验室公认的 WebSphere Integration Message Broker
和 WebSphere MQ 解决方案方面的世界级专家。
|
对本文的评价
| 
