Tips & Techniques > Systems Management

WebSphere MQ Clustering Configuration Tips

October 2006 | by Michelle Schlicht

Note: This article is part one of a two-part series. Part two will appear in a future issue of IBM* Systems Magazine, i5 Business Systems edition.

WebSphere* MQ (WMQ) is a robust middleware product that can reliably send messages between applications, regardless of what language the application is written in or what platform the application is housed in. WMQ offers benefits such as assured delivery, powerful development facilities, end-to-end security and reliable file transfer. WMQ 6.0 on the System i* hardware is available for V5R2 and above. The most basic approach to using WMQ is a point-to-point configuration, where two queue managers pass messages through a sender and a receiver channel. This article provides technical tips and techniques regarding WMQ's more sophisticated configurations, including clustering configurations. To learn about the basic concepts on each configuration, refer to the WMQ Information Center (http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp).

Clustering
In situations where more than two queue managers must be able to communicate with each other, a WMQ cluster has several benefits over using multiple point-to-point configurations:

Reduced system administration - With a WMQ cluster, far fewer channels and queues must be defined for the queue managers to communicate with each other.

Increased availability and workload balancing - Because a WMQ cluster can have multiple instances of the same queue, WMQ can distribute workload between multiple queue managers. If a queue manager that contains a queue defined elsewhere in the cluster goes down, the cluster can reroute traffic to the queue manager that's available.

A cluster must be structured in a particular way for the cluster to function properly. Vital to that structure is the concept of full repositories and partial repositories. According to the WMQ Queue Manager Clusters Guide, a full repository is "a queue manager that hosts a complete set of information about every queue manager in the cluster." Partial repositories are "other queue managers in the cluster [that] inquire about the information in the full repositories and build up their own subsets of this information." Hence, a partial repository contains information about itself and other full repositories, and a full repository contains information about all of the queue managers in the cluster.

The WMQ Queue Manager Clusters Guide recommends at least two full repositories in a WMQ cluster. It's possible to create and use a WMQ cluster with only one full repository. However, a WMQ with only one full repository has a single point of failure. The cluster won't function if that full repository goes down. By using multiple full repositories, if one full repository goes down, the other full repositories will seamlessly take over to manage the cluster.

Figure 1 shows an example of information flow in a cluster between full and partial repositories. The partial repository queue managers know about only the queue managers that are full repositories and themselves. In contrast, the full repositories have information about all of the queue managers in the cluster. Full repositories learn about queue managers in the cluster using several different methods:

Directly from the queue manager (e.g., QMGR.B has information about QMGR.E because QMGR.E uses QMGR.B as a full repository)
Other full repositories in the cluster (e.g., QMGR.B knows about QMGR.C because information was exchanged with QMGR.A, and QMGR.A is a full repository for QMGR.C)

WMQ offers benefits such as assured delivery, powerful development facilities, end-to-end security and reliable file transfer.

Next page: >>

Michelle A. Schlicht is a staff software engineer with IBM. Michelle can be reached at schlicht@us.ibm.com.

Tips & Techniques > Systems Management

WebSphere MQ Clustering Configuration Tips

Advertisement

Advertisement