Queue Manager Clusters: Adding a new, interconnected cluster

Adding a new, interconnected cluster

Scenario

A WebSphere MQ cluster has been set up as described in network into a cluster.
A new cluster called MAILORDER is to be implemented. This cluster will comprise four of the queue managers that are in the CHAINSTORE cluster; CHICAGO, CHIGACO2, SEATTLE, and ATLANTA, and two additional queue managers; HARTFORD and OMAHA. The MAILORDER application will run on the system at Omaha, connected to queue manager OMAHA. It will be driven by the other queue managers in the cluster putting messages on the MORDERQ queue.
The full repositories for the MAILORDER cluster will be maintained on the two queue managers CHICAGO and CHICAGO2.
The network protocol is TCP.

1. Create a namelist of the cluster names

The full repository queue managers at CHICAGO and CHICAGO2 are now going to hold the full repositories for both of the clusters CHAINSTORE and MAILORDER. First, create a namelist containing the names of the clusters. Define the namelist on CHICAGO and CHICAGO2, as follows:
DEFINE NAMELIST(CHAINMAIL)
       DESCR('List of cluster names')
       NAMES(CHAINSTORE, MAILORDER)
2. Alter the two queue-manager definitions

Now alter the two queue-manager definitions at CHICAGO and CHICAGO2. Currently these definitions show that the queue managers hold full repositories for the cluster CHAINSTORE. Change that definition to show that the queue managers hold full repositories for all clusters listed in the CHAINMAIL namelist. To do this, at both CHICAGO and CHICAGO2, specify:
ALTER QMGR REPOS(' ') REPOSNL(CHAINMAIL)
3. Alter the CLUSRCVR channels on CHICAGO and CHICAGO2

The CLUSRCVR channel definitions at CHICAGO and CHICAGO2 show that the channels are available in the cluster CHAINSTORE. You need to change this to show that the channels are available to all clusters listed in the CHAINMAIL namelist. To do this, at CHICAGO, enter the command:
ALTER CHANNEL(TO.CHICAGO) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
At CHICAGO2, enter the command:
ALTER CHANNEL(TO.CHICAGO2) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
4. Alter the CLUSSDR channels on CHICAGO and CHICAGO2

Change the two CLUSSDR channel definitions to add the namelist. At CHICAGO, enter the command:
ALTER CHANNEL(TO.CHICAGO2) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
At CHICAGO2, enter the command:
ALTER CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
5. Create a namelist on SEATTLE and ATLANTA

Because SEATTLE and ATLANTA are going to be members of more than one cluster, create a namelist containing the names of the clusters. Define the namelist on SEATTLE and ATLANTA, as follows:
DEFINE NAMELIST(CHAINMAIL)
       DESCR('List of cluster names')
       NAMES(CHAINSTORE, MAILORDER)
6. Alter the CLUSRCVR channels on SEATTLE and ATLANTA

The CLUSRCVR channel definitions at SEATTLE and ATLANTA show that the channels are available in the cluster CHAINSTORE. Change this to show that the channels are available to all clusters listed in the CHAINMAIL namelist. To do this, at SEATTLE, enter the command:
ALTER CHANNEL(TO.SEATTLE) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
At ATLANTA, enter the command:
ALTER CHANNEL(TO.ATLANTA) CHLTYPE(CLUSRCVR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
7. Alter the CLUSSDR channels on SEATTLE and ATLANTA

Change the two CLUSSDR channel definitions to add the namelist. At SEATTLE, enter the command:
ALTER CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
At ATLANTA, enter the command:
ALTER CHANNEL(TO.CHICAGO2) CHLTYPE(CLUSSDR)
      CLUSTER(' ') CLUSNL(CHAINMAIL)
8. Define CLUSRCVR and CLUSSDR channels on HARTFORD and OMAHA

On the two new queue managers HARTFORD and OMAHA, define cluster-receiver and cluster-sender channels. It doesn't matter in which sequence you do this. At HARTFORD, enter:
DEFINE CHANNEL(TO.HARTFORD) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(HARTFORD.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-receiver channel for HARTFORD')
 
DEFINE CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(CHICAGO.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-sender channel from HARTFORD to repository at CHICAGO')
At OMAHA, enter:
DEFINE CHANNEL(TO.OMAHA) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(OMAHA.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-receiver channel for OMAHA')
 
DEFINE CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(CHICAGO.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-sender channel from OMAHA to repository at CHICAGO')
9. Define the MORDERQ queue on OMAHA

The final step to complete this task is to define the queue MORDERQ on the queue manager OMAHA. To do this, enter:
DEFINE QLOCAL(MORDERQ) CLUSTER(MAILORDER)
The cluster achieved by task 8

The cluster set up by this task is shown in Figure 21.
Now we have two overlapping clusters. The full repositories for both clusters are held at CHICAGO and CHICAGO2. The mailorder application that runs on OMAHA is independent of the inventory application that runs at CHICAGO. However, some of the queue managers that are in the CHAINSTORE cluster are also in the MAILORDER cluster, and so they can send messages to either application. Before carrying out this task to overlap two clusters, be aware of the possibility of queue-name clashes. Suppose that on AMSTERDAM in cluster CHAINSTORE and on OMAHA in cluster MAILORDER, there is a queue called ACCOUNTQ. If you overlap the clusters and then an application on a queue manager that is a member of both clusters, for example SEATTLE, puts a message to the queue ACCOUNTQ, the message can go to either instance of the ACCOUNTQ.
Before starting this task the system administrators of the two clusters must check for queue-name clashes and be sure that they understand the consequences. You might need to rename a queue, or perhaps set up queue aliases before you can proceed.

Extensions to this task

Suppose you decide to merge the MAILORDER cluster with the CHAINSTORE cluster to form one large cluster called CHAINSTORE.
To merge the MAILORDER cluster with the CHAINSTORE cluster, such that CHICAGO and CHICAGO2 hold the full repositories:
Alter the queue manager definitions for CHICAGO and CHICAGO2, removing the REPOSNL attribute, which specifies the namelist (CHAINMAIL), and replacing it with a REPOS attribute specifying the cluster name (CHAINSTORE). For example:
ALTER QMGR(CHICAGO) REPOSNL(' ') REPOS(CHAINSTORE)
On each queue manager in the MAILORDER cluster, alter all the channel definitions and queue definitions to change the value of the CLUSTER attribute from MAILORDER to CHAINSTORE. For example, at HARTFORD, enter:
ALTER CHANNEL(TO.HARTFORD) CLUSTER(CHAINSTORE)
At OMAHA enter:
ALTER QLOCAL(MORDERQ) CLUSTER(CHAINSTORE)
Alter all definitions that specify the cluster namelist CHAINMAIL, that is, the CLUSRCVR and CLUSSDR channel definitions at CHICAGO, CHICAGO2, SEATTLE, and ATLANTA, to specify instead the cluster CHAINSTORE.
From this example, you can see the advantage of using namelists. Instead of altering the queue manager definitions for CHICAGO and CHICAGO2 you can just alter the value of the namelist CHAINMAIL. Similarly, instead of altering the CLUSRCVR and CLUSSDR channel definitions at CHICAGO, CHICAGO2, SEATTLE, and ATLANTA, you can achieve the required result by altering the namelist.

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.