在 WebSphere Message Broker V7 中配置和管理多实例代理,实现高可用性

本文介绍 WebSphere Message Broker V7 中的一个新特性 — 多实例代理,该特性帮助您配置高可用性环境。该特性基于 WebSphere MQ V7.0.1 中的多实例队列管理器,该管理器提供驻留在多个独立物理服务器上的多个队列管理器实例,从而提供高度可用的配置。在 WebSphere MQ 中,这个多实例队列管理器的配置寄宿在共享网络存储器上,这样,当活动队列管理器出现故障时,另一个实例自动继承停止的队列管理器的配置并变为活动实例。类似地,在 Message Broker V7 中,代理的配置寄宿在网络存储器上,以支持高可用性功能。

Ashwin Gupta, 技术销售专家, IBM

Ashwin Gupta 的照片Ashwin Gupta 担任 IBM(印度)高级软件工程师有 5 年时间了。他的专业技术涵盖 IBM 中间件产品组合,包括 WebSphere Message Broker、WebSphere MQ、WebSphere MQ FTE、WebSphere eXtreme Scale 和 WebSphere Transformation Extender。目前,他是 Worldwide WebSphere Business Partners Team 的技术销售专家,从事各种 WebSphere 产品的 Business Partner Technical Enablement 工作。



Rahul Gupta, IT 顾问专家, IBM

Rahul Gupta 的照片Rahul Gupta 担任 IBM(印度)的 WebSphere Message Broker Consultant 已经有 5 年时间了。目前,他担任美国 IBM 零售商客户的 IBM 中间件产品技术顾问职务。



Venkatesh Murugan, 技术服务专业人员, IBM

Venkatesh Murugan 的照片Venkatesh Nainar Murugan 是一位技术服务专业人员,担任 IBM(印度)的 WebSphere MQ 和 WebSphere Message Broker 专家有一年半时间了。目前,他从事各个平台上的 WebSphere MQ 和 WebSphere Message Broker 的管理和支持工作。此前,他从事这些产品的设计、开发和测试工作。



2011 年 2 月 23 日

简介

本文介绍 IBM® WebSphere® Message Broker(以下称为 Message Broker)中的新的强大功能,用于处理故障转移和提供高可用性(High Availability,HA)。它将帮助您创建和配置多实例队列管理器和代理。本文还将逐步描述开发和测试 Message Broker HA 环境的过程。本文的目标读者包括设计 SOA 解决方案且需要实现 HA ESB 解决方案的高级 IT 架构师和 IT 专家。

要理解 Message Broker V7 的多实例代理特性(以下称为 MI 代理),必须首先理解多实例队列管理(以下称为 MI 队列管理器)的工作方式。本文首先概述 MI 队列管理器实例的概念以及管理它们的任务,然后演示如何在多个实例之间切换。之后描述 MI 代理的概念,包括 MI 代理的设置,以及如何配置和测试它们,以实现高可用性。

多实例队列管理器

术语 “MI 队列管理器” 指共享队列管理器数据和日志的活动和备用队列管理器实例的结合。MI 队列管理器在一个服务器上保持一个活动实例,在另一个服务器上保持一个备用实例,以便在活动实例失败时自动接管,从而保护应用程序免受队列管理器进程失败的影响。复制队列管理器实例是提高队列管理器进程可用性的一种有效方法。

运行本文示例的系统使用 WebSphere MQ 和 Message Broker,包含三个运行 Red Hat Enterprise Linux 5.0 的服务器。图 1 展示了这三个服务器上的 MI 队列管理器和 MI 代理组件的概况。

图 1. MI 队列管理器和 MI 代理组件概览
MI 队列管理器和 MI 代理组件概览

这三个服务器是:

wmbmi1.in.ibm.com
托管 MI 队列管理器 IBMESBQM 的主活动实例和 MI 代理 IBMESBBRK 的主活动实例。
wmbmi2.in.ibm.com
托管 MI 队列管理器 IBMESBMQ 的备用实例副本和 MI 代理 IBMESBBRK 的备用实例副本。
wmbmi3.in.ibm.com
通过 NFS V4 托管共享网络文件系统 /mqha。

尽管在不同的服务器上运行备用实例和托管共享文件系统并不是强制的,但建议防止队列管理器由于硬件问题而出现故障。在本例中,WebSphere MQ 安装在两个服务器上:wmbmi1.in.ibm.com 上安装 MI 主队列管理器,wmbmi2.in.ibm.com 上安装 MI 备用队列管理器。如图 1 所示,IBMESBQM 的活动实例在 wmbmi1.in.ibm.com 上运行;另一个实例作为备用实例在 wmbmi2.in.ibm.com 上运行,不执行活动处理,准备在活动实例失败时接管。

下面介绍管理这些 MI 队列管理器的任务。

配置网络文件系统

MI 队列管理器使用网络文件系统(Networked File System,NFS)来管理队列管理器实例。队列管理器结合使用文件系统锁和共享队列管理器数据和日志来自动化故障转移。在 V7.0.1 之前,WebSphere MQ 不支持网络存储器作为共享文件系统被访问。如果队列管理器数据位于共享网络存储器上,必须确保该数据不会被同时运行的另一个队列管理器实例访问。这种情况在 WebSphere MQ V7.0.1 中得到了改善:队列管理器可以获取读/写锁,对它们的数据提供访问权;在任一时刻,都只允许一个队列管理器实例锁定数据,从而消除了脏读取。

在配置 NFS 之前,需要确保用户的用户 ID(uid)和组 ID(gid)对于 MI 队列管理器实例驻留的所有服务器 — 本例中是 wmbmi1.in.ibm.com、wmbmi2.in.ibm.com 和 wmbmi3.in.ibm.com — 都相同。在 Linux 和 UNIX 系统上,用于运行 WebSphere MQ 和 WebSphere Message Broker 命令的 uid 必须同时是 mqbrkrs 组和 mqm 组的一个成员,mqbrkrs 和 mqm 组的 UNIX gids 必须在所有系统上相同。另外,还应该确保 uid 及其对应 gid 在所有系统上相同,且是创建第一个队列管理器实例的 uid。在 Linux 和 UNIX 环境中更改 uids 和 gids 要特别小心,因为这样做会影响系统上的文件的权限级别。更改一个 uid 或 gid 将导致此前由该用户拥有的所有文件的所有权更改为表示该文件的以前所有者的实际整数。管理员必须确保受影响的文件和目录的所有权能够得到手动恢复。

在本例中,用户 mqm 管理 MI 队列管理器和 MI 代理。使用清单 1 中的命令来匹配 /etc/passwd 中的 mqm 用户的 uid 和 gid,然后在需要更改这些值时重启系统:

清单 1. 在所有成员服务器上匹配 mqm 用户的 uid 和 gid
[mqm@wmbmi1.in.ibm.com]$ cat /etc/passwd | grep mqm
mqm:x:500:501:MQSeries User:/home/mqm:/bin/bash
[mqm@wmbmi2.in.ibm.com]$ cat /etc/passwd | grep mqm
mqm:x:500:501:MQSeries User:/home/mqm:/bin/bash
[mqm@wmbmi3.in.ibm.com]$ cat /etc/passwd | grep mqm
mqm:x:500:501:MQSeries User:/home/mqm:/bin/bash

另外,您还需将 mqm 组的 uid 和 gid 设置为在所有系统上一致。在公共共享文件夹 /mqha 中创建日志和数据目录。确保 mqha 目录由用户和组 mqm 拥有,且用户和组的访问权限设置为 rwx。清单 2 中的命令,在 wmbmi3.in.ibm.com 上作为根执行,将实现以下目的:

清单 2. 创建和设置共享文件夹 /mqha 下的目录的所有权
[root@wmbmi3.in.ibm.com]$ mkdir -p /mqha/WMQ/IBMESBQM/data
[root@wmbmi3.in.ibm.com]$ mkdir -p /mqha/WMQ/IBMESBQM/logs
[root@wmbmi3.in.ibm.com]$ mkdir -p /mqha/WMB/IBMESBBRK
[root@wmbmi3.in.ibm.com]$ chown -R mqm:mqm /mqha
[root@wmbmi3.in.ibm.com]$ chmod -R ug+rwx /mqha

下面,需要在 wmbmi3.in.ibm.com 上配置 NFS 服务器,然后在同一台机器上启动它。将清单 3 中的代码片段添加到 /etc/exports 文件,它应该在 wmbmi3.in.ibm.com 上作为根执行:

清单 3. 配置 NFS 服务器
/mqha *(rw,fsid=0,no_wdelay,sync)

作为根用户在 wmbmi3.in.ibm.com 上执行清单 4 中的命令,启动 NFS 服务器:

清单 4. 启动 NFS 服务器
/etc/init.d/nfs start

如果 NFS 服务器正在运行,使用清单 5 中的命令刷新它:

清单 5. 刷新 NFS 服务器
exportfs -ra

现在,wmbmi3.in.ibm.com 上的共享目录 /mqha 应该被挂载到 wmbmi1.in.ibm.com 和 wmbmi2.in.ibm.com 上。使用清单 6 中的命令检查这两个实例托管服务器上是否可以看到 /mqha 共享目录:

清单 6. 验证 /mqha 已挂载
showmount –e wmbmi3.in.ibm.com

如果清单 6 中的命令的输出是否定的,那么您需要从那两个实例托管服务器挂载这个共享文件夹。作为根用户在这两个服务器上执行清单 7 中的命令,挂载导出的文件系统:

清单 7. 挂载导出的文件系统
mount -t nfs4 -o hard,intr wmbmi3.in.ibm.com:/ /mqha

并不是所有的网络文件系统的锁定协议都是健壮的,一个文件系统可能针对性能而不是数据完整性得到配置。必须运行 amqmfsck 命令来测试,您的网络文件系统能否恰当控制对队列管理器数据和日志的访问:

  • 在每个系统上运行不带任何选项的 amqmfsck 来检查基本锁定。
  • 在这两个 WebSphere MQ 系统上同时运行带 -c 选项的 amqmfsck 命令,测试对这个目录的并发写入。
  • 在这两个 WebSphere MQ 系统上同时运行带 -w 选项的 amqmfsck 命令,测试并发等待和释放这个目录上的锁。

为使用 WebSphere MQ 可靠地工作,共享文件系统必须提供:

  • 数据写入完整性
  • 有保障的文件独占访问
  • 失败时释放锁

如果文件系统没有提供这些特性,那么当 MI 队列管理器配置中使用这个共享文件系统时,队列管理器数据和日志有可能会损坏。目前,NFS V4 提供上述所有特性,因此本例中使用这个文件系统。

创建一个多实例队列管理器

首先在第一个服务器 wmbmi1.in.ibm.com 上创建 MI 队列管理器。作为 mqm 用户登录并执行清单 8 中的命令:

清单 8. 创建一个队列管理器
crtmqm -md /mqha/WMQ/IBMESBQM/data -ld /mqha/WMQ/IBMESBQM/logs IBMESBQM

这个队列管理器创建后,使用清单 9 中的命令显示它的属性:

清单 9. 显示队列管理器的属性
[mqm@wmbmi1.in.ibm.com]$ dspmqinf -o command IBMESBQM

addmqinf -s QueueManager -v Name=IBMESBQM -v Directory=IBMESBQM -v Prefix=/var/mqm –v 
DataPath=/mqha/WMQ/IBMESBQM/data/IBMESBQM

在 mqm 用户的控制台中复制 dspmqinf 的输出并将其粘贴到 wmbmi2.in.ibm.com 的命令行上,如清单 10 所示:

清单 10. 配置 wmbmi2.in.ibm.com
[mqm@wmbmi2.in.ibm.com]$ addmqinf -s QueueManager  -v Name=IBMESBQM
-v Directory=IBMESBQM -v Prefix=/var/mqm -v DataPath=/mqha/WMQ/IBMESBQM/data/IBMESBQM

WebSphere MQ configuration information added.

现在,在这两个服务器上运行 dspmq 命令,显示每个服务器上的队列管理器。结果应该类似于清单 11:

清单 11. 显示两个服务器上的队列管理器
[mqm@wmbmi1.in.ibm.com]$ dspmq
QMNAME(IBMESBQM)                                          STATUS(Ended immediately)

[mqm@wmbmi2.in.ibm.com]$ dspmq
QMNAME(IBMESBQM)                                          STATUS(Ended immediately)

MI 队列管理器 IBMESBQM 现在已经在 wmbmi1.in.ibm.com 和 wmbmi2.in.ibm.com 这两个服务器上创建。

启动和停止多实例队列管理器

以多实例模式启动队列管理器和启动常规队列管理器一样简单。要以任何顺序启动多个队列管理器,执行带有 -x 参数的 strmqm 命令,如清单 12 所示:

清单 12. 以多实例模式启动队列管理器
[mqm@wmbmi1.in.ibm.com]$ strmqm -x IBMESBQM
WebSphere MQ queue manager 'IBMESBQM' starting.
5 log records accessed on queue manager 'IBMESBQM' during the log replay phase.
Log replay for queue manager 'IBMESBQM' complete.
Transaction manager state recovered for queue manager 'IBMESBQM'.
WebSphere MQ queue manager 'IBMESBQM' started.

[mqm@wmbmi2.in.ibm.com]$ strmqm -x IBMESBQM
WebSphere MQ queue manager 'IBMESBQM' starting.
A standby instance of queue manager 'IBMESBQM' has been started. The active
instance is running elsewhere.

这个队列管理器首先在 wmbmi1.in.ibm.com 上启动,然后在 wmbmi2.in.ibm.com 上启动。因此,IBMESBQM 在 wmbmi1 上启动一个活动实例,处理所有请求,而 wmbmi2 上的实例作为一个备用实例,随时准备在活动实例失败时接管。活动实例被授予对队列管理器数据和日志的独占访问权;如果备用实例被授予独占访问权,那么它就变为活动实例。

而且,您总是可以将使用不同服务器上的多个实例配置的一个队列管理器作为一个单实例队列管理器启动。如果使用 strmqm 命令(不带 -x 选项)启动队列管理器,那么在其他机器上配置的队列管理器实例将不能作为备用实例启动。如果用户企图启动另一个实例,将收到一个响应,表明该队列管理器实例不允许作为备用实例运行。

只有以下两个队列管理器实例可以同时运行:活动实例和备用实例。如果这两个实例同时启动,WebSphere MQ 不能控制哪个实例作为活动实例;这由 NFS 服务器决定。首先获得队列管理器数据的独占访问权的实例将成为活动实例。

现在,队列管理器已经启动,可以创建和启动队列管理器侦听器,以便应用程序连接到活动队列管理器 IBMESBQM,如清单 13 所示。清单 13 中的所有管理命令都在活动队列管理器上执行:

清单 13. 创建和启动队列管理器侦听器
[mqm@wmbmi1.in.ibm.com]$ runmqsc IBMESBQM

5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.

Starting MQSC for queue manager IBMESBQM.

define listener(IBMESBLISTENER) trptype(tcp) port(1414) control(qmgr)

     1 : define listener(IBMESBLISTENER) trptype(tcp) port(1414) control(qmgr)

AMQ8626: WebSphere MQ listener created.
START LISTENER(IBMESBLISTENER)

     2 : START LISTENER(IBMESBLISTENER)

AMQ8021: Request to start WebSphere MQ Listener accepted.

有两种方法可以停止已经启动的 MI 队列管理器。第一种方法是使用带 -s 选项的 endmqm 命令来切换活动和备用实例。如果在活动实例上运行 endmqm -s IBMESBQM 命令,则手动将控制权切换到备用实例。endmqm -s 命令关闭活动实例,但不会关闭备用实例。队列管理器数据和日志上的独占访问权锁释放,备用队列管理器接管。

第二种方法是同时停止队列管理器的活动和备用实例。如果在队列管理器的活动实例上执行 endmqm IBMESBQM 命令 — 您将注意到,没有 -s 选项 — 将同时停止活动和备用实例。

如果您正在运行多个队列管理器实例,您认为没有必要这样做,那么您可以执行带 -x 选项的 endmqm 命令,选择只停止备用实例。备用实例将不再充当备用实例,但活动实例仍将继续运行。

删除多实例队列管理器

要删除一个队列管理器的多个实例,首先需要从其他备用队列管理器服务器删除它的引用。在拥有队列管理器定义的所有服务器上运行 rmvmqinf 命令,如清单 14 所示:

清单 14. 删除一个队列管理器的多个引用
rmvmqinf IBMESBQM

下面,必须删除所有活动队列管理器服务器上的队列管理器。运行 dltmqm 命令(如清单 15 所示),删除在其他服务器上定义了实例的队列管理器。

清单 15. 删除一个队列管理器的多个引用
dltmqm IBMESBQM

不需要在创建这个队列管理器的服务器上运行这个命令;可以在定义了这个队列管理器的任何服务器上运行这个命令。也可以通过在两个服务器上运行 dltmqm IBMESBQM 命令来删除 MI 队列管理器。

多实例队列管理器运行时文件系统组织

图 2 展示了 MI 队列管理器 /mqha 文件系统的层级。队列管理器特有的对象和活动日志存储在以下位置:

图 2. MI 队列管理器文件系统的层级
MI 队列管理器文件系统的层级

管理多实例队列管理器

WebSphere MQ Explorer 不能在本地运行多个 MI 队列管理器实例。必须将 WebSphere MQ Explorer 配置为远程管理多个 MI 队列管理器。选择 Queue Managers => Add Remote Queue Manager 菜单项,添加一个 MI 队列管理器的多个连接,如图 3 所示:

图 3. WebSphere MQ Explorer Navigator
WebSphere MQ Explorer Navigator

Add Queue Manager 向导出现。提供队列管理器名称并选择适当的连接方法,如图 4 所示。

图 4. Add Queue Manager 向导
Add Queue Manager 向导

完成选择后单击 Next

下面,您需要提供活动和备用队列管理器的连接细节,指示 WebSphere MQ Explorer 在故障转移时自动重新连接活动队列管理器。图 4 演示了如何正确输入这个信息:

图 5. 在 Add Queue Manager 向导上设置一个 MI 队列管理器
在 Add Queue Manager 向导上设置一个 MI 队列管理器

如果不需要其他客户端配置,则单击 Finish。WebSphere MQ Explorer 现在将连接到活动队列管理器实例,如图 6 所示。记住,在这个样例配置中,活动队列管理器驻留在服务器 wmbmi1.in.ibm.com 上:

图 6. MQ Explorer Navigator 中已连接的活动队列管理器
MQ Explorer Navigator 中已连接的活动队列管理器

下一个逻辑步骤是通过执行一个受控的 BIMESBQM 队列管理器故障转移来验证这个自动重新连接功能。

多实例队列管理器之间的故障转移

您应该在一个受控的环境中执行一个 MI 队列管理器 IBMESBQM 故障转移测试。(在本文后面,当 MI 代理实现后,您还将看到针对一个网络或电源故障的结果的更严格的测试。)要实现受控的故障转移,可以停止活动队列管理器,然后查看备用队列管理器是否能够获取 /mqha 文件系统上的一个锁并变为活动队列管理器。

在运行命令来停止 MI 队列管理器的活动实例之前,重要的是要先识别正在运行活动实例的服务器。为此,运行带 -x 标志的 dspmq 命令。在清单 16 中,您可以看到,在我们的样例设置中,队列管理器 IBMESBQM 在 wmbmi1.in.ibm.com 上作为活动队列管理器运行,在 wmbmi2.in.ibm.com 上作为备用队列管理器运行:

清单 16. 识别活动实例的位置
[mqm@wmbmi1.in.ibm.com$ dspmq -x

    QMNAME(IBMESBQM)                                          STATUS(Running)
    INSTANCE(wmbmi1.in.ibm.com) MODE(Active)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Standby)

[mqm@wmbmi2.in.ibm.com]$ dspmq -x

    QMNAME(IBMESBQM)                                          STATUS(Running as standby)
    INSTANCE(wmbmi1.in.ibm.com) MODE(Active)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Standby)

现在您已经知道活动队列管理器的运行位置,可以运行 endmqm -s IBMESBQM 命令来停止 wmbmi1.in.ibm.com 上的活动队列管理器,如清单 17 所示:

清单 17. 停止活动队列管理器
[mqm@wmbmi1.in.ibm.com]$ endmqm -s IBMESBQM
Quiesce request accepted. The queue manager will stop when all outstanding work
is complete, permitting switchover to a standby instance.

[mqm@wmbmi1.in.ibm.com]$ dspmq -x

QMNAME(IBMESBQM)                                          STATUS(Running elsewhere)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Active)

[mqm@wmbmi2.in.ibm.com]$ dspmq -x

QMNAME(IBMESBQM)                                          STATUS(Running)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Active)

在清单 17 中,可以看到,队列管理器 IBMESBQM 已在 wmbmi1.in.ibm.com 上停止,现在作为活动队列管理器在 wmbmi2.in.ibm.com 上运行。这样,这个测试显示 IBMESBQM 从第一个服务器故障转移到第二个服务器。WebSphere MQ Explorer 也显示了这个事实,它自动重新连接到现在正在 wmbmi2.in.ibm.com 上运行的活动队列管理器实例,如图 7 所示:

图 7. 故障转移之后的自动重新连接
WebSphere MQ Explorer 显示在故障转移之后自动重新连接

现在只有一个队列管理器实例正在运行,如果出现问题,将不会再有任何故障转移。因此,为恢复备用队列管理器,应该在 wmbmi1.in.ibm.com 上执行 strmqm -x IBMESBQM 命令。这将确保队列管理器 IBMESBQM 在 wmbmi2.in.ibm.com 上积极运行,在 wmbmi1.in.ibm.com 上消极运行。要测试从 wmbmi2.in.ibm.com 到 wmbmi1.in.ibm.com 能够正确进行故障转移,并将配置恢复到原始状态,只需重复本节中的步骤。

多代理实例

Message Broker 的 MI 代理特性以两种方式用于 WebSphere MQ。每个代理实例都嵌入到一个 WebSphere MQ 服务中,以便当队列管理器切换到备用系统时,代理自动在备用节点上启动。这个特性在 Message Broker V7.0.0.1 (Fix Pack 1) 中提供。

可以通过在 mqsicreatebrokermqsiaddbrokerinstance 命令上使用一个 -d 选项来配置 MI 代理。如果要创建 WebSphere MQ 服务,则该选项的值为 defined;要移除服务,选项值为 undefined。 当您第一次使用这个选项创建代理实例时,队列管理器已经启动,然后创建 WebSphere MQ 服务,以便只有在队列管理器停止和重新启动之后,该服务才会启动代理。这种情况只在创建代理时出现。此后,WebSphere MQ 服务将取得控制权。

另一种方式是,备用代理可以以一种半初始化状态持续运行,等待关联的备用队列管理器和共享代理配置变为可用。

在本节中,您将使用此前设置的 MI 队列管理器 IBMESBQM,在样例系统上创建 MI 代理 IBMESBBRK。为此,您需要使用相同的用户(mqm),使这个用户成为 mqbrkrs 组的一个成员。确保 mqbrkrs 的 gid 在所有服务器上保持一致。下面是管理 MI 代理的任务:

创建多实例代理

要以多实例模式配置 Message Broker,必须执行三组动作:

  1. 在 NFS 服务器上创建一个共享工作路径目录
  2. 创建一个 WebSphere MQ MI 队列管理器
  3. 创建一个 MI 代理

在上一节中,您配置了一个共享工作路径并设置了一个 MI 队列管理器,因此您可以继续第三步。首先,您需要验证正在运行活动队列管理器的服务器,方法是运行 dspmq -x 命令。在我们的设置中,活动队列管理器正在 wmbmi1.in.ibm.com 上运行,因此应该在这个服务器上创建活动代理实例。用于创建代理的命令是 mqsicreatebroker,它的实现和样例系统的输出如清单 18 所示:

清单 18. 创建一个代理
[mqm@wmbmi1.in.ibm.com]$ mqsicreatebroker IBMESBBRK -q IBMESBQM -e /mqha/WMB/IBMESBBRK

AMQ8110: WebSphere MQ queue manager already exists.
The setmqaut command completed successfully.
The setmqaut command completed successfully.
BIP8071I: Successful command completion.

创建这个代理的活动实例之后,运行 mqsiaddbrokerinstance 命令,在 wmbmi2.in.ibm.com 上创建备用实例:

清单 19. 创建代理的备用实例
mqsiaddbrokerinstance IBMESBBRK -e /mqha/WMB/IBMESBBRK

mqsiaddbrokerinstance 命令用于在安装了 Message Broker 的 UNIX/Linux 或 Windows 服务器上创建一个 MI 代理。mqsiaddbrokerinstance 命令用于在需要多实例支持的其他服务器上添加一个代理实例。该命令假定用户已经使用 mqsicreatebroker 命令在初始服务器上创建了一个支持多实例的代理。这条命令的语法在不同的操作系统上不同:

  • Windows:mqsiaddbrokerinstance <brokerName> -e <sharedWorkPath> -w <Workpath> -i <serviceUserid> -a <servicePassword>
  • UNIX/Linux:mqsiaddbrokerinstance <brokerName> -e <sharedWorkPath> -w <Workpath>

这里,-w 选项在两个平台上都是可选的。它标识将运行这个代理实例的服务器上的一个目录,特定于该代理实例的工作文件应该本地存储在这个目录中。在 Linux 和 UNIX 系统中,用于运行这个命令的 uid 必须同时是 mqbrkrs 和 mqm 组的成员。另外,mqbrkrs 的 uid 和 gid 必须在所有系统上一致。清单 20 展示了 mqsiaddbrokerinstance 命令在 wmbmi2.in.ibm.com 上的输出:

清单 20. mqsiaddbrokerinstance 的输出
[mqm@wmbmi2.in.ibm.com]$ mqsiaddbrokerinstance IBMESBBRK -e /mqha/WMB/IBMESBBRK

AMQ7272: WebSphere MQ configuration information already exists.
BIP8071I: Successful command completion.

启动和停止多实例代理

现在,代理 IBMESBBRK 的实例副本已经在这两个服务器上创建,下一步就是启动那些实例。根据对应的队列管理器 IBMESBQM 的实例的状态,一个副本将作为活动实例运行,另一个副本作为备用实例。在这两个服务器上运行 mqsistart 命令,启动代理,如清单 21 所示:

清单 21. 启动代理实例
[mqm@wmbmi1.in.ibm.com]$ mqsistart IBMESBBRK

BIP8096I: Successful command initiation. Check the system log to ensure that the component
started without problems and that it continues to run without problems.

[mqm@wmbmi2.in.ibm.com]$ mqsistart IBMESBBRK

BIP8236I: A standby instance of Broker IBMESBBRK has been started against the standby
queue manager IBMESBQM. The active broker instance and active queue manager instance
are running elsewhere. The multi-instance broker has started in standby mode. The broker
will not become active until the current active broker instance and active queue manager
instance end, or are stopped.  No action required.

代理 IBMESBBRK 在 wmbmi1.in.ibm.com 上作为活动代理启动,在 wmbmi2.in.ibm.com 以备用模式启动。作为活动和备用实例运行的代理进程将在下面介绍,首先,您需要运行 mqsicreateexecutiongroup IBMESBBRK -e IBMESBEG 命令,在 wmbmi1.in.ibm.com 上的活动代理上创建一个执行组:

清单 22. 创建一个执行组
[mqm@wmbmi1.in.ibm.com]$ mqsicreateexecutiongroup IBMESBBRK -e IBMESBEG

BIP1124I: Creating execution group 'IBMESBEG' on broker 'IBMESBBRK'...
BIP1117I: The execution group was created successfully.
The broker has initialized the execution group.
BIP8071I: Successful command completion.

[mqm@wmbmi1.in.ibm.com]$ ps -eaf | grep –I IBMESBEG

mqm        364 32622 17 20:00 ?        00:00:07 DataFlowEngine 
       IBMESBBRK 9a38eebe-2701-0000-0080-ad888bea8d47 IBMESBEG

执行组在创建后将自动启动。要验证这一点,可以运行 ps 命令,并对 IBMESBEG 字符串(这是执行组名称)执行一个 grep 操作。现在,代理和 DataFlowEngine 已经在活动实例上启动,可以检查在活动和备用实例上运行的进程。在活动节点上,您将发现以下代理进程正在运行:

  • bipservice
  • bipbroker
  • biphttplistener
  • 在每个代理上创建的每个执行组都有一个 DataFlowEngine 进程

在备用节点上,您将发现以下代理进程正在运行:

  • bipservice (in standby mode)
  • bipbroker (in standby mode)

清单 23 展示了样例系统的细节:

清单 23. 在活动和备用节点上运行的进程
[mqm@wmbmi1.in.ibm.com]$ ps -eaf | grep IBMESBBRK

mqm      364        32622       1 20:00 ?        00:00:07 
        DataFlowEngine IBMESBBRK 9a38eebe-2701-0000-0080-ad888bea8d47 IBMESBEG
mqm      32617    1               0 19:56 ?        00:00:00 bipservice IBMESBBRK
mqm      32622     32617      0 19:56 ?        00:00:02 bipbroker IBMESBBRK
mqm      32665     32622      0 19:56 ?        00:00:01 biphttplistener IBMESBBRK

[mqm@wmbmi2.in.ibm.com]$ ps -eaf | grep IBMESBBRK

mqm      31916     1              0 20:04 ?        00:00:00 bipservice IBMESBBRK
mqm      31921     31916      0 20:04 ?        00:00:00 bipbroker IBMESBBRK

了解如何停止 MI 代理很重要。要终止一个 MI 代理或代理实例,运行 mqsistop 命令,并加上代理名称。执行这个命令时不会发生切换,只会停止正在运行的代理。要停止代理的活动和备用实例,必须在两个服务器上分别运行这个命令。

删除多实例代理

尽管此时您不会在您的简单系统上删除 MI 代理,但了解如何删除这些 MI 组件很重要。MI 代理及其关联实例的删除顺序很重要,删除过程中的每一步都需要使用正确的命令。下面是如何删除 MI 代理的概述,这里使用样例设置:

  1. 在活动节点上停止 MI 代理 IBMESBBRK。
  2. 在备用节点上停止 MI 代理 IBMESBBRK。
  3. 在备用节点上使用 mqsiremovebrokerinstance IBMESBBRK 命令移除代理实例 IBMESBBRK。
  4. 在活动节点上使用 mqsideletebroker IBMESBBRK 命令移除代理 IBMESBBRK。

多实例代理运行时文件系统组织

图 8 展示了 MI 代理/mqha 文件系统的层级。这个代理的组件和注册表特有数据存储在以下位置:

图 8. 一个 MI 代理文件系统的层级
一个 MI 代理文件系统的层级

备份和恢复多实例代理

备份和恢复 MI 代理不需要特殊技术。可以用标准方法执行备份和恢复任务,在活动实例上运行清单 24 中的命令:

清单 24. 备份和恢复一个代理
mqsibackupbroker  IBMESBBRK -d /backup/WMB

mqsirestorebroker IBMESBBRK -d /backup/WMB  -a <archive file name>

mqisbackupbroker 命令检测一个 MI 代理,并从该代理的共享工作路径备份注册表和配置。类似地,mqsirestorebroker 将注册表和配置恢复到代理的共享工作路径。对代理的活动实例执行备份命令。执行恢复命令时,停止正在恢复的代理与之共享存档数据的所有代理(活动和备用实例)。如果在一个相关代理处于活动状态时运行这个命令,结果可能难以预料。

多实例代理之间的故障转移切换

开始本节之前,您应该理解故障转移 在 MI 代理上下文中的确切含义。当一个队列管理器由于某种原因而出现故障时,将会导致关联代理失败;Message Broker 然后将切换到备用实例。那时,此前活动的代理实例将自己设置为备用模式,备用实例变为活动实例。MI 代理依赖 MI 队列管理器的状态。

我们来看看两个故障转移场景:一个受控切换,一个由于电源或网络故障导致的失控切换。

一个多实例代理的受控切换

受控切换测试首先显示 wmbmi1.in.ibm.com 上的 MI 代理的状态,确认它是活动的。为此,运行清单 25 中的命令,您应该能看到与清单 25 类似的输出:

清单 25. 显示 wmbmi1.in.ibm.com 上的 IBMESBBRK 的状态
[mqm@wmbmi1 .in.ibm.com]$ mqsilist
                                
BIP1295I: Broker 'IBMESBBRK' is a multi-instance broker running in active mode on 
multi-instance queue manager 'IBMESBQM'.
BIP8071I: Successful command completion

下面,对队列管理器执行相同的操作,如清单 26 所示:

清单 26. 显示 wmbmi1.in.ibm.com 上的 IBMESBQM 的状态
[mqm@wmbmi1 ~]$ dspmq –m IBMESBQM  –x

QMNAME(IBMESBQM) STATUS(Running)  INSTANCE(wmbmi1.in.ibm.com) MODE(Active)
INSTANCE(wmbmi2.in.ibm.com) MODE(Standby)

现在切换到备用服务器 wmbmi2.in.ibm.com,执行相同的命令。您应该能看到清单 27 和 28 中显示的结果,表明那里的队列管理器和代理实例是备用实例。

清单 27. 显示 wmbmi2.in.ibm.com 上的 IBMESBBRK 的状态
[mqm@wmbmi2 .in.ibm.com]$ mqsilist

BIP1294I: Broker 'IBMESBBRK' is a multi-instance broker running in standby mode on 
multi-instance queue manager 'IBMESBQM'. More information will be available when the
broker instance is active. 
BIP8071I: Successful command completion.
清单 28. 显示 wmbmi2.in.ibm.com 上的 IBMESBQM 的状态
[mqm@wmbmi2.in.ibm.com]$ dspmq –m IBMESBQM  –x

QMNAME(IBMESBQM) STATUS(Running as standby) INSTANCE(wmbmi2.in.ibm.com)  
MODE(Standby) INSTANCE(wmbmi1.in.ibm.com)  MODE(Active)

下面,返回 wmbmi1.in.ibm.com,停止 IBMESBQM 的活动实例,如清单 29 所示:

清单 29. 停止 IBMESBQM 的活动实例
[mqm@wmbmi1 ~]$ endmqm -s IBMESBQM

Quiesce request accepted. The queue manager will stop when all outstanding work is 
complete, permitting switchover to a standby instance.

现在显示它的状态,如清单 30 所示。输出应该表明以前的备用实例现在成为活动实例:

清单 30. 确认 IBMESBQM 已经在 wmbmi1.in.ibm.com 上停止
[mqm@wmbmi1.in.ibm.com]$ dspmq -m IBMESBQM –x 

QMNAME(IBMESBQM) STATUS(Running elsewhere) INSTANCE(wmbmi2.in.ibm.com)  MODE(Active)

运行清单 31 中的命令,列示代理 IBMESBBRK 的状态。您将看到,它也在 wmbmi1.in.ibm.com 停止运行了。

清单 31. 确认 IBMESBBRK 已经在 wmbmi1.in.ibm.com 上停止了
[mqm@wmbmi1.in.ibm.com]$ mqsilist

BIP1292I: The multi-instance Broker 'IBMESBBRK' on multi-instance queue manager 'IBMESBQM'
has stopped.
BIP8071I: Successful command completion.

现在再次切换回 wmbmi2.in.ibm.com。运行清单 32 中的命令,确认 IBMESBQM 的实例已经变为活动状态:

清单 32. 确认 wmbmi2.in.ibm.com 上的 IBMESBQM 已经变为活动状态
[mqm@wmbmi2.in.ibm.com]$ dspmq -m IBMESBQM –x 

QMNAME(IBMESBQM) STATUS(Running) INSTANCE(wmbmi2.in.ibm.com)  MODE(Active)

最后,运行清单 33 中的命令,确认 wmbmi2.in.ibm.com 上的 IBMESBBRK 也变为活动状态。

清单 33. 确认 wmbmi2.in.ibm.com 上的 IBMESBBRK 处于活动状态
[mqm@wmbmi2 ~]$ mqsilist

BIP1295I: Broker 'IBMESBBRK' is a multi-instance broker running in active mode on 
multi-instance queue manager 'IBMESBQM'.
BIP8071I: Successful command completion.

由于 IBMESBQM 和 IBMESBBRK 在 wmbmi2.in.ibm.com 上处于活动状态,因此从一个服务器到另一个服务器的切换已经完成。

由于电源或网络故障导致的失控故障转移

在上一节中,您看到在一个受控环境中,如何从一个服务器到另一个服务器进行故障转移。但是,当一个服务器的处理被意外终止,或者当它意外从网络断开时,将会发生什么情况呢?Message Broker 的高可用性特性能够应对这种场景。为执行这个故障转移测试,使用在代理 IBMESBBRK 上的执行组 IBMESBEG 中处理的消息流来创建一个实时场景。创建并部署一个拥有以下节点的、非常简单的消息流(见图 9):

  • MQInput Node (IBMESB_IN)
  • Compute Node (Copy Message)
  • MQOutput Node (IBMESB_OUT)
图 9. 消息流
消息流图表

输入和输出队列(IBMESBQM_IN 和 IBMESBQM_OUT)的持久性属性设置为 persistent,表示在这些队列上到达的所有消息都将被持久化。这将避免故障转移过程中出现任何消息损失。

在本节中,您将看到,客户端连接通过故障转移得以保持。这个客户端将把消息放在队列管理器 IBMESBQM 的输入队列 IBMESBQM_IN 上。

amqsphac 是 WebSphere MQ 附带的一个随时可用的样例程序,可用于检查消息流与队列管理器的连接状态。它不断将消息放置到输入队列上,并通知您放置操作的状态。也可以使用这个样例程序来检查连接状态。清单 34 显示了这个程序的调用结果,调用时间在 wmbmi1.in.ibm.com 由于电源或网络故障而停用之前的较早一段时间内。这个程序持续运行,直到 wmbmi2.in.ibm.com 接管发生故障的服务器。

清单 34. amqsphac 输出显示故障转移正在发生
[mqm@wmbmi2.in.ibm.com]$ amqsphac  IBMESBQM_IN  IBMESBQM

Sample AMQSPHAC start
target queue is IBMESBQM_IN
message <Message 1>
// Client application is well connected here
// and successfully putting message to Input Queue
message <Message 2>
message <Message 3>
message <Message 4>
message <Message 5>
message <Message 6>
message <Message 7>
message <Message 8>
message <Message 9>
message <Message 10>
message <Message 11>
message <Message 12>
message <Message 13>
message <Message 14>
message <Message 15>
// wmbmi1 server has gone down here and the connection of client is lost
20:41:53 : EVENT : Connection Reconnecting (Delay: 168ms)    
20:41:54 : EVENT : Connection Reconnecting (Delay: 1220ms)
20:41:55 : EVENT : Connection Reconnecting (Delay: 2324ms)
20:41:57 : EVENT : Connection Reconnecting (Delay: 4494ms)
20:42:02 : EVENT : Connection Reconnecting (Delay: 8731ms)
20:42:10 : EVENT : Connection Reconnecting (Delay: 19732ms)
// wmbmi2 server has gained the control here and has become active.
20:42:31 : EVENT : Connection Reconnected
//   Client Connection  to Queue Manager  is re-established
message <Message 16>
//   Client application is successfully putting the messages again
message <Message 17>
message <Message 18>
message <Message 19>
message <Message 20>

我们的网络故障测试(断开连接 wmbmi1.in.ibm.com 的网络电缆)得到了清单 34 中的结果。wmbmi2.in.ibm.com 上的备用队列管理器 IBMESBQM 变为活动队列管理器,IBMESBBRK 成为活动代理,整个过程不到两分钟。然后,客户端自动重新连接到活动队列管理器。amqsphac 客户端生成了 20 条消息,它们都被复制消息流处理并放置到 IBMESB_OUT 队列中。输出如下:

清单 35. 输出展示故障转移成功
 [mqm@wmbmi2.in.ibm.com]$ dspmq –m IBMESBQM  -x

QMNAME(IBMESBQM)                                          STATUS(Running)
    INSTANCE(wmbmi2.in.ibm.com) MODE(Active)

[mqm@wmbmi2.in.ibm.com]$ echo "DISPLAY QLOCAL(IBMESBQM_OUT) CURDEPTH" | runmqsc IBMESBQM

5724-H72 (C) Copyright IBM Corp. 1994, 2009.  ALL RIGHTS RESERVED.
Starting MQSC for queue manager IBMESBQM.
     1 : DISPLAY QLOCAL(IBMESBQM_OUT) CURDEPTH
AMQ8409: Display Queue details.
   QUEUE(IBMESBQM_OUT)                     TYPE(QLOCAL)
   CURDEPTH(20)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.

Message Broker Explorer 的一个局限性

目前,使用 WebSphere Message Broker Explorer 来检查一个 MI 代理的备用实例有一个局限性。尽管可以在 WebSphere MQ Explorer 上列示并查看一个 MI 队列管理器的所有实例,并在故障转移发生时将 Explorer 连接切换到备用队列管理器,但在故障转移情况下,不能在 WebSphere Message Broker Explorer 上列示或查看一个 MI 代理的备用实例。

总结全文,展望未来

本文简述了 MI 队列管理器和 MI 代理的概念和基本架构,解释了如何创建、配置、管理和测试这些 MI 组件以获得高可用性。这里描述的系统包含一个活动代理或队列管理器实例和一个备用实例。这代表了设计高可用性消息传递解决方案的一个主动-被动 架构。还有另一种名为 “主动-主动场景” 的 HA 架构,其中,多组 MI 队列管理器和代理覆盖在一个 WebSphere MQ 集群上。我的下一篇文章将详细介绍这种新的 HA 场景。

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=628455
ArticleTitle=在 WebSphere Message Broker V7 中配置和管理多实例代理,实现高可用性
publish-date=02232011