1.   多实例队列管理器高可用架构

实例队列管理器能够在备用服务器上自动地重新启动。如下图所示，WebSphere MQ 安装在两个服务器上，其中一个服务器处于空闲状态。QM1 的一个实例处于活动状态，并且正在一个服务器上运行。QM1 的另一个实例以备用方式在另一个服务器上运行，它不执行任何活动处理，但已准备好在 QM1 的活动实例发生故障时接管活动实例。

QM1 的活动实例在运行期间对共享的队列管理器数据文件夹和日志文件夹进行互斥访问。活动实例发生故障时，QM1 的备用实例将检测到这种情况并变为活动实例。它将以先前活动实例所遗留的状态来接管 QM1 数据和日志，并接受来自客户机和通道的重新连接请求。

多实例队列管理器是高可用性解决方案的组成部分。需要其他一些组件才能构建实用的高可用性解决方案。

• 客户机和通道重新连接功能，用于将 WebSphere MQ连接转移到接管活动队列管理器实例的计算机。
• 高性能共享网络文件系统，此系统正确地管理锁定并防范介质和文件服务器故障。

2.   多实例队列管理器与HA比较

传统HA 集群是包含两台或更多台计算机和资源（如磁盘和网络）的组，这些计算机和资源互相连接在一起并配置为当其中一个发生故障时，高可用性管理器，如 HACMP (UNIX) 或 MSCS (Windows)，将执行故障转移。多实例队列管理器与 HA 集群项比较，有以下差别：

	多实例队列管理器方式	HA集群方式
实现功能	•    集成到 WebSphere MQ 中的基本故障转移支持 •    故障转移速度快于 HA 集群 •    配置和操作简单 •    与 WebSphere MQ 资源管理器集成	•    能够协调多个资源，如应用程序服务器或数据库 •    配置选项更灵活，包括可以包含两个以上节点的集群 •    可以故障转移多次，而不需要操作员干预 •    将队列管理器的 IP 地址接管为故障转移的一部分
局限性	•    需要高可用性且高性能的已联网的存储器 •    网络配置更复杂，因为队列管理器在故障转移时将更改服务 IP 地址 •    出现故障转移时，必须手动重新启动备用实例	•    需要购买附加产品和技能 •    需要可在集群的节点间切换的磁盘 •    HA 集群的配置相对复杂 •    故障转移以往都相当慢 •    如果用于监视资源（如队列管理器）的脚本中存在缺陷，那么可能会发生不需要的故障转移

3.   多实例队列管理器创建和维护

3.1 多实例队列管理器创建

• 在服务器1和服务器2上安装WebSphere MQ、创建mqm 用户和组以及定义/var/mqm；
• 检查并确保两服务器上/etc/passwd 中mqm的uid和gid一致；
• 在服务器1上，将要共享的公共文件夹 /MQHA中创建日志和数据目录。例如：

mkdir /MQHA

mkdir /MQHA/logs

mkdir /MQHA/qmgrs

• 在服务器2上创建文件夹/MQHA，以便安装共享的文件系统。使路径与服务器 1 上的路径相同；例如：

mkdir /MQHA

• 确保 MQHA 目录由用户和组 mqm 拥有并且将该用户或组拥有的访问权设置为rwx；
• 在服务器1上创建队列管理器：

crtmqm -ld /MQHA/logs -md /MQHA/qmgrs -q QM1

• 在服务器1上启动 NFS 守护程序：

/etc/init.d/nfs start

• 在服务器2上安装所导出的文件系统 /MQHA：

mount -t nfs4 -o hard,intr 192.168.217.130:/ /MQHA

• 从服务器 1 复制队列管理器配置详细信息：

dspmqinf -o command QM1

该命令将输出类似以下内容，复制到服务器2：

addmqinf -s QueueManager -v Name=QM1 -v Directory=QM1 \

-v Prefix=/var/mqm  -v DataPath=/MQHA/qmgrs/QM1

• 在服务器2上增加队列管理器配置信息：

addmqinf -s QueueManager -v Name=QM1 -v Directory=QM1 \

-v Prefix=/var/mqm  -v DataPath=/MQHA/qmgrs/QM1

• 使用 -x 参数以任意顺序启动队列管理器实例：strmqm -x QM1，先启动的成为活动队列管理器，后启动的成为备份队列管理器；

3.2 多实例队列管理器维护

• dspmq –x

显示关于队列管理器实例的信息，例如

dspmq -x

QMNAME(QM1) STATUS(作为备用实例运行)

INSTANCE(machine1) MODE(活动)

INSTANCE(machine2) MODE(备用)

• strmqm -x <QM>

在其中一个服务器上使用该命令启动该队列管理器，-x选项允许实例故障转移，本服务器上的队列管理器变为活动实例；然后在其他服务器上使用相同的命令启动备用实例，-x 选项允许实例作为备用实例启动。

• strmqm <QM>

也可以将被配置为在不同服务器上具有多个实例的队列管理器作为单实例队列管理器启动和停止。如果使用不带 -x 选项的 strmqm 命令来启动队列管理器，那么在其他机器上配置的队列管理器的实例会被阻止作为备用实例启动。如果尝试启动另一实例，那么会接收到不允许队列管理器实例作为备用实例运行的响应。无法对备用实例发出不带 -x 选项的 endmqm 命令。

• endmqm -s <QM>

通过对活动实例发出 endmqm -s 命令，还可以将控制权手动切换到备用实例。endmqm -s 命令在不关闭备用实例的情况下将活动实例关闭。队列管理器数据和日志上的互斥访问锁定被释放，并且备用实例接管工作。

• endmqm -x <QM>

如果使用带有 -x 选项的 endmqm 命令来停止备用实例，那么该实例将停止作为备用实例，并且活动实例继续运行。

• endmqm <QM>

如果使用不带 -s 选项的 endmqm 命令来停止多实例队列管理器的活动实例，那么活动实例和备用实例均会停止。

4.   多实例队列管理器架构考虑

通道和客户机重新连接是备用队列管理器实例进入活动状态后进行的消息恢复处理的关键部分。

多实例队列管理器实例安装在具有不同网络地址的服务器上。需要对 WebSphere MQ 通道和客户机（具有所有队列管理器实例的连接信息）进行配置。备用队列管理器实例进行接管时，客户机和通道将自动地重新连接到新网络地址处的新进入活动状态的队列管理器实例。用于 Java 的 WebSphere MQ 类不支持客户机自动重新连接。

多实例队列管理器架构与高可用性环境（如 HACMP）为集群提供虚拟 IP 地址以及将该地址传递到活动服务器的方式不同。WebSphere MQ 重新连接功能不会更改或重新路由 IP 地址。它的工作方式是，使用通道定义和客户机连接中定义的网络地址进行重新连接。

4.1 集群通道

通常，不需要进行附加的配置即可使多实例队列管理器在集群中工作。

如果队列管理器连接至仓储库队列管理器，该仓储库将从该队列管理器上 CLUSRCVR 通道的 CONNAME 中发现该队列管理器的网络地址。对于 TCPIP 而言，如果省略 CONNAME 或者将其配置为空，那么队列管理器将自动设置此参数。备用实例进行接管时，它的 IP 地址将作为 CONNAME 而替换先前活动实例的 IP 地址。

4.2 非集群通道

通道的 CONNAME 属性是逗号分隔的连接名称列表；例如 CONNAME(‘92.46.1.1(1415), 85.42.3.8(2423)’)。系统会按照连接列表中指定的顺序来尝试那些连接，直到成功地建立一个连接为止。如果未能成功建立连接，那么通道将尝试重新连接。

4.3 客户端应用程序

客户机连接可以使用连接列表或队列管理器组来选择备用连接。需要强调，用于 Java 的 WebSphere MQ 类不支持客户机自动重新连接。

队列管理器组是在客户机通道定义表（CCDT）中定义的连接集合。客户机连接通道定义存储在与服务器上运行的队列管理器相关联的客户机通道定义表中。 包含表的文件称为 AMQCLCHL.TAB，并且是一个无法直接编辑的二进制文件。可以使用 DEFINE CHANNEL 命令在表中添加客户机连接通道，使用 ALTER CHANNEL 命令改变表中已有条目的通道的属性。

连接列表是指通道定义中CONNAME以逗号分隔的机器名称列表，按照连接列表中指定的顺序尝试建立连接，直到成功建立为止。如果未成功建立连接，那么通道将启动重试处理过程。

通过配置多个组件，可以使客户机应用程序自动进行重新连接，而不必编写任何其他代码。自动重新连接可以在客户机应用程序中的任意位置自动恢复连接，并且恢复所有用于打开对象的句柄。相反，手动重新连接要求客户机应用程序使用 MQCONN 或 MQCONNX 来重新创建连接并重新打开对象。

自动重新连接具有下列配置要求：

组件	要求	对不符合要求的返回
WebSphere MQ 客户机安装	级别 7.0.1	MQRC_OPTIONS_ERROR
WebSphere MQ 服务器安装	级别 7.0.1	MQRC_OPTIONS_ERROR
通道	SHARECNV > 0	MQRC_ENVIRONMENT_ERROR
应用程序环境	必须线程化	MQRC_ENVIRONMENT_ERROR
MQI	将 MQCONNX 的 MQCNO Option 设置为 MQCNO_RECONNECT 或 MQCNO_RECONNECT_Q_MGR	MQCC_FAILED（在连接中断或者队列管理器结束）

需要注意的是，MQCNO Option 参数仅MQCONNX需要设置，MQCONN不需要设置。另外，MQCNO Option 参数与mqclient.ini 配置文件的 Channels 节中设置 DefRecon 属性配合使用。DefRecon 选项的解释决于 MQCNO_RECONNECT_* 值是否仍在客户机程序中设置以及设置为何值。如果客户机程序使用 MQCONN 进行连接，或使用 MQCONNX 设置 MQCNO_RECONNECT_AS_DEF 选项，那么 DefRecon 设置的重新连接值将会生效。如果程序中没有设置重新连接值，或 DefRecon 选项没有设置重新连接值，那么客户机程序不会自动重新连接。具体情况如下：

DefRecon=NO|YES|QMGR|DISABLED

• NO

除非 MQCONNX 覆盖此选项，否则客户机不会自动重新连接。

• YES

除非 MQCONNX 覆盖此选项，否则客户机将自动重新连接。

• QMGR

除非 MQCONNX 覆盖此选项，否则客户机将自动重新连接，但仅至同一队列管理器。QMGR 选项与 MQCNO_RECONNECT_Q_MGR 的作用相同。

• DISABLED

禁用重新连接，即使客户机程序使用 MQCONNX MQI 调用进行请求。

 

4.4 客户机自动重新连接后

WebSphere MQ 客户机环境会注意故障转移本身，并在重新连接之后通过在客户机中存储某些状态信息以及代表客户机应用程序发出其他 MQI 调用以恢复它的 WebSphere MQ 状态，来恢复尽可能多的上下文。例如，将恢复发生故障时已打开的对象的句柄，并且将打开同名的临时动态队列。但是，有一些更改不可避免，您需要进行设计以处理这些更改。这些更改可以分为 5 类：

• MQI 调用将返回新的或者先前未诊断的错误，直到应用程序恢复一致的新上下文状态为止。
• 非持续性消息可能会丢失。
• 事务将被回滚。
• 在同步点外部使用的 MQGET 或 MQPUT 调用可能被中断，且有可能丢失消息。
• 计时引起的错误（由于在 MQI 调用中长时间等待所致）。

关于丢失的上下文的一些详细信息列示在下列部分中。

• 除非通过 NPMCLASS(HIGH) 选项将非持久消息放入一个队列，并且队列管理器故障未中断“关闭时存储非持久消息”这一选项，否则将废弃那些消息。
• 连接中断时，非持久预订将丢失。在重新连接时，将重新建立非持久预订。考虑使用持久预订。
• 将重新计算获取等待时间间隔；如果超出其限制，那么将返回 MQRC_NO_MSG_AVAILABLE。同样，将重新计算预订到期时间，以给出相同的整体到期时间。
• 浏览游标在队列中的位置将丢失；此位置通常在第一条消息前重新确定。

指定了 MQGMO_BROWSE_MSG_UNDER_CURSOR 或 MQGMO_MSG_UNDER_CURSOR 的 MQGET 调用失败，原因码为 MQRC_NO_MSG_AVAILABLE。

供浏览的已锁定消息将被解锁。

浏览所标记的具有句柄作用域的消息将被取消标记，并可以被再次浏览。

在大多数情况下，将取消标记协同浏览所标记的消息。

• 安全上下文丢失。尝试使用保存的消息上下文（例如，在指定了 MQPMO_PASS_ALL_CONTEXT 的情况下放置消息）失败，原因码为 MQRC_CONTEXT_NOT_AVAILABLE。
• 消息标记丢失。使用消息标记执行的 MQGET 返回原因码 MQRC_NO_MSG_AVAILABLE。

注： 作为消息组成部分的 MsgId 和 CorrelId 在故障转移期间将与消息一起保留下来，因此，使用 MsgId 或 CorrelId 执行的 MQGET 将以预期方式工作。

• 在未落实事务中同步点下的队列上所放置的消息不再可用。
• 以逻辑顺序处理消息或者处理消息组中的消息将导致重新连接后发出返回码 MQRC_RECONNECT_INCOMPATIBLE。
• MQI 调用可能会返回 MQRC_RECONNECT_FAILED，而不是返回目前客户机通常接收的更一般的 MQRC_CONNECTION_BROKEN。
• 如果 WebSphere MQ 客户机收不到队列管理器的响应，那么重新连接成功后将返回 MQRC_CALL_INTERRUPTED，以指示下列操作的成功或失败：

在同步点外部使用 MQPUT 调用来传递持久消息。

在同步点外部使用 MQPUT1 调用来传递持久消息或具有缺省持久性的消息。

使用 MQCMIT 调用落实事务。

• 通道作为新实例重新启动（它们也可能是不同的通道），因此不保留通道出口状态。
• 恢复临时动态队列，以作为恢复可重新连接的客户机（已打开临时动态队列）这一进程的一部分。未在临时动态队列上恢复任何消息，但已打开队列或已记住队列名称的应用程序能够继续进行处理。这存在一种可能性，如果该队列正被应用程序使用而不是创建该队列的应用程序使用，那么它在下一次引用时可能不能快速地恢复。例如，如果客户机会创建作为应答队列的临时动态队列，并通过通道将应答消息放到该队列，那么该队列不可能及时进行恢复。在这种情况下，通道通常可以将应答消息放到死信队列。

以下文章点击率最高