IBM MQ 7.5 was EOS 30th April 2018.Click EOS notice for more details
Adding a new, interconnected cluster
Add a new cluster that shares some queue managers with
an existing cluster.
Before you begin
Note:
For changes to a cluster to be propagated throughout the cluster,
at least one full repository must always be available. Ensure that
your repositories are available before starting this task.
Before starting this task, check for queue-name clashes and understand
the consequences. You might need to rename a queue, or set up queue
aliases before you can proceed.
A new cluster called MAILORDER is to be implemented.
This cluster comprises four of the queue managers that are in the
CHNSTORE cluster; CHICAGO, CHICAGO2
, SEATTLE, and ATLANTA, and two
additional queue managers; HARTFORD and OMAHA
. The MAILORDER application runs on the system at
Omaha, connected to queue manager OMAHA. It is driven
by the other queue managers in the cluster putting messages on the
MORDERQ queue.
The full repositories for the MAILORDER cluster
are maintained on the two queue managers CHICAGO and
CHICAGO2.
The network protocol is TCP.
About this task
Follow these steps to add a new, interconnected cluster.
Procedure
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 CHNSTORE 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(CHNSTORE, MAILORDER)
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
CHNSTORE. Change that definition to show that the queue
managers hold full repositories for all clusters listed in the
CHAINMAIL namelist. Alter the CHICAGO and
CHICAGO2 queue manager definitions:
ALTER QMGR REPOS(' ') REPOSNL(CHAINMAIL)
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 CHNSTORE. You need to change the cluster-receiver
definition to show that the channels are available to all clusters
listed in the CHAINMAIL namelist. Change the cluster-receiver
definition at CHICAGO:
ALTER CHANNEL(CHNSTORE.CHICAGO) CHLTYPE(CLUSRCVR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
At
CHICAGO2, enter the command:
ALTER CHANNEL(CHNSTORE.CHICAGO2) CHLTYPE(CLUSRCVR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
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(CHNSTORE.CHICAGO2) CHLTYPE(CLUSSDR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
At CHICAGO2, enter the command:
ALTER CHANNEL(CHNSTORE.CHICAGO) CHLTYPE(CLUSSDR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
Create a namelist on SEATTLE and
ATLANTA.
Because SEATTLE and
ATLANTA are going to be members of more than one cluster,
you must 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(CHNSTORE, MAILORDER)
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 CHNSTORE. Change the cluster-receive
channel definitions to show that the channels are available to all
clusters listed in the CHAINMAIL namelist. At
SEATTLE, enter the command:
ALTER CHANNEL(CHNSTORE.SEATTLE) CHLTYPE(CLUSRCVR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
At
ATLANTA, enter the command:
ALTER CHANNEL(CHNSTORE.ATLANTA) CHLTYPE(CLUSRCVR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
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(CHNSTORE.CHICAGO) CHLTYPE(CLUSSDR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
At
ATLANTA, enter the command:
ALTER CHANNEL(CHNSTORE.CHICAGO2) CHLTYPE(CLUSSDR)
CLUSTER(' ') CLUSNL(CHAINMAIL)
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 does not matter in which sequence you make the definitions.
At HARTFORD, enter:
DEFINE CHANNEL(MAILORDER.HARTFORD) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(HARTFORD.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-receiver channel for HARTFORD')
DEFINE CHANNEL(MAILORDER.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(MAILORDER.OMAHA) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(OMAHA.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-receiver channel for OMAHA')
DEFINE CHANNEL(MAILORDER.CHICAGO) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(CHICAGO.CHSTORE.COM) CLUSTER(MAILORDER)
DESCR('Cluster-sender channel from OMAHA to repository at CHICAGO')
Define the MORDERQ queue on OMAHA
.
The final step to complete this task is to define
the queue MORDERQ on the queue manager OMAHA
. At OMAHA, enter:
DEFINE QLOCAL(MORDERQ) CLUSTER(MAILORDER)
Check that the cluster changes have been propagated.
Check that the definitions you created with the previous
steps have been propagated though the cluster. Issue the following
commands on a full repository queue manager:
DIS QCLUSTER (MORDERQ)
DIS CLUSQMGR
Results
The cluster set up by this task is shown in Figure 1.
Now we have two overlapping
clusters. The full repositories for both clusters are held at
CHICAGO and CHICAGO2. The mail order 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 CHNSTORE 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 NEWYORK in cluster
CHNSTORE and on OMAHA in cluster
MAILORDER, there is a queue called ACCOUNTQ
. If you overlap the clusters and then an application on
SEATTLE puts a message to the queue ACCOUNTQ
, the message can go to either instance of the ACCOUNTQ
.
What to do next
Suppose you decide to merge the MAILORDER
cluster with the CHNSTORE cluster to form one large
cluster called CHNSTORE.
To merge the MAILORDER cluster with the
CHNSTORE 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 (CHNSTORE
). For example:
ALTER QMGR(CHICAGO) REPOSNL(' ') REPOS(CHNSTORE)
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 CHNSTORE. For example, at HARTFORD
, enter:
ALTER CHANNEL(MAILORDER.HARTFORD) CLUSTER(CHNSTORE)
At OMAHA enter:
ALTER QLOCAL(MORDERQ) CLUSTER(CHNSTORE)
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 CHNSTORE.
From this example, you can see the advantage of using
namelists. Instead of altering the queue manager definitions for
CHICAGO and CHICAGO2 you can 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.