Queue Manager Clustering

Murali Krishna Nookella

Businesses are increasingly becoming aware of the advantages of establishing an intranet or of connecting processors to a LAN. For example, you might connect some AIX processors in the form of an SP2. Processors that are linked in these ways benefit from support from each other and have access to a far wider range of programs and data.

In the same way, WebSphere MQ queue managers can be connected to form a cluster. This facility is available to queue managers on all operating systems.

You can connect the queue managers by using any of the communications protocols that are available on your operating system. That is, TCP or LU6.2 on any operating system, NetBIOS, or SPX on Windows.

Connections on more than one protocol can exist within a cluster. If you try to make a connection to a queue manager by using a protocol that it does not support, the channel does not become active.

One of the first decisions that must be made when setting up a cluster, is to determine the queue managers that are to have a full repository. All other queue managers must have a predefined CLUSSDR channel to one of the full repository queue managers in the cluster.

You might call QM1 the primary repository, and QM4 the secondary, but this relationship is true only from the point of view of QM2. Both full repository QMGRs have equal rights and functions, as to the cluster.The full and partial repositories store queue manager information like the creation of a new queue for 30 days.

To prevent this data from expiring, the queue manager resends information about themselves after 27 days. When data expires, it is not immediately removed; instead it has a grace period of 60 days. If during the grace period, no changes occur then the data is removed. This grace period provides a queue manager that was temporarily out of service at the expiry date the right to rejoin if it does not stay disconnected from the cluster for 90 days. Then, that queue manager no longer is part of the cluster.

You do not need to alter any of your applications if you are going to set up a simple WebSphere MQ cluster. The applications name the target queue on the MQOPEN call as typical and are not concerned about the location of the queue manager.

However, if you set up a cluster in which there are multiple definitions for the same queue , you must review your applications and modify them as necessary.

Additional information — Bind on group is a new feature added in WebSphere MQ V7.1.

Addition of this feature includes two new message flags within the message descriptor of messages:• Last message in group: MQMF_LAST_MSG_IN_GROUP• All other messages in group: MQMF_MSG_IN_GROUP