MQ队列共享组系统故障恢复研究与实现.docVIP

MQ队列共享组系统故障恢复研究与实现 　　摘要：本文研究主机Z/OS系统环境下的中间件Websphere MQ在队列共享组实施方案的基础上，针对系统可能发生的不同状况，设计了在不同故障场景下实现MQ恢复的方法，从而实现高可用性。 　　关键词： 队列共享组 高可用性 恢复 虚拟IP地址 　　中图分类号：TP333 文献标识码：A文章编号：1007-9416（2011）05-0145-02 　　 　　近年来，Websphere MQ主机Z/OS系统用户逐渐增多。主机系统发生故障影响巨大，因此在系统的设计、运行过程中形成一整套高可用性方案，保证系统运行的连续性十分必要。 　　主机系统上有多种MQ系统配置方案，本文基于对主机系统设计经验，设计了一种在并行耦合系统（Parellel Sysplex）环境下的共享队列组（Queue Sharing Group）架构，通过不同场景下的故障恢复措施，供有关系统设计和维护的人员参考，进而形成一整套适合不同环境的MQ故障恢复方案。 　　1、系统设计方案概述 　　根据用户需求差异，可以有多种MQ系统设计方案。最典型的方案是并行耦合系统下的队列共享组设计方案，其总体架构如图1所示。 　　在图1架构下，并行耦合系统中共有四个Z/OS系统成员（Member），ZOS1、 ZOS2、 ZOS3、, ZOS4，每个系统各运行一个队列管理器，即QM01、 QM02、 QM03、 QM04，它们分别连接到本系统上运行的DB2成员，并构成了一个队列共享组QG01。在QG01中， QM01和QM03与应用相关联，但它们与远程队列管理器没有连接通道，因此，这两个队列管理器不启动通道启动程序（Channel Initiator）。 　　远程队列管理器只与网关队列管理器QM02和QM04之间有TCP/IP连接通道，并且在ZOS2和ZOS4实施了动态虚拟IP地址（Dynamic Virtual IP Address），远程队列管理器只要使用这个虚拟IP地址，就可以访问到QM02或QM04。一旦某系统发生故障，通道可以切换到另一个队列管理器上，从而保证系统运行的连续性。 　　远程队列管理器发送到QG01的消息，由QM02或QM04接收到共享队列中，并由连接到QM01和QM03的应用程序均衡处理。 　　2、各种故障场景下系统恢复的实现 　　2.1 运行网关的Z/OS系统发生故障 　　假设作为网关运行的ZOS2或ZOS4发生故障，初始启动状态下，远程队列管理器的共享通道都与QM02相连接。此时ZOS2停止运行，系统作业自动重启功能ARM(Automatic Restart Manager)会将QM02启动到ZOS4上。从队列管理器QM04的启动作业信息中可以看到信息CSQM052I，表明共享通道恢复完成。在QM04的通道启动程序作业中，也可以看到相关的通道被启动，原来与QM02连接的每条通道均产生一条CSQX500I信息，表明通道全部恢复到QM04上，业务继续进行。恢复过程无需人工干预。 　　2.2 TCP/IP发生故障 　　系统运行需要远程连接到QM02上的通道连接正常。如果TCP/IP停止运行，连接异常中断，在QM02上系统显示CSQX208E和CSQX599E等通道故障信息。从QM04上可以看到CSQX500I信息，表明同名的通道在QM04上启动，由QM04接收来自远端的消息，整个过程对业务没有影响。QM02的TCP/IP故障恢复后，并不马上接管QM04的工作，而是成为QM04备份网关。 　　2.3 应用队列管理器发生故障 　　QM01和QM03负责应用处理，两者都正常工作时，由于本地队列为共享队列，因此，与QM01和QM03相连接的应用能够并发、均衡地处理数据。如果QM01停止运行，检查QM03的启动作业信息可以看到CSQE008I信息，说明QM03接收到QM01发生问题的信息，随后可以看到CSQE011I，CSQE013I,CSQE012I, CSQE014I等信息，说明QM01发生故障后，应用Structure自动恢复，QM01的工作由QM03接管，消息继续由与QM03连接的应用处理，此后消息的处理并发度会降低，但是不会停止，直到QM01正常启动，系统继续并行处理共享队列中的消息。 　　2.4 应用系统发生故障 　　在主机系统中，处理队列消息的应用可以是批处理程序或者CICS交易程序。 　　在图1中，有两个应用处理共享队列中的消息。如果系统ZOS1上的应用发生故障，这些应用与QM01的连接将都断开，原来均衡分配在ZOS1和ZOS3上的工作负荷将全部由ZOS3上的应用来承担。在具体的测试中，可以发送一定数量的消息，采用EVERY触发方式。在终止其中一个应用程序后，可以看到无消息