Overlapping WebSphere MQ
clusters Configuration for high availability
(Ref Link: "http://www.ibm.com/developerworks/websphere/library/techarticles/1401_bhat/1401_bhat.html")
Introduction
This sample setup Websphere MQ environment is configured with nine queue managers and three different
clusters. The three clusters are named AMERICA, EUROPE, and INDIA, and each
cluster has two full repositories and one partial repository. Each queue manager
is part of one cluster, and namelists will be used to enable communication
between the three clusters. The diagram and table below summarize the setup:
Figure 1
Table 1
Cluster name
|
Queue manager
|
Receiver channel
|
Full Repos
|
Yes / No
|
port
|
INDIA
|
NEWDELHI
|
TO.NEWDELHI
|
YES
|
1414
|
|
BOMBAY
|
TO.BOMBAY
|
YES
|
1415
|
||
BANGALORE
|
TO.BANGALORE
|
NO
|
1416
|
||
EUROPE
|
LONDON
|
TO.LONDON
|
YES
|
1417
|
|
PARIS
|
TO.PARIS
|
YES
|
1418
|
||
BERLIN
|
TO.BERLIN
|
NO
|
1419
|
||
AMERICA
|
NEWYORK
|
TO.NEWYORK
|
YES
|
1420
|
|
CHICAGO
|
TO.CHICAGO
|
YES
|
1421
|
||
LOSANGELES
|
TO.LOSANGELES
|
NO
|
1422
|
Architecture
for overlapping clusters
The BOMBAY queue manager, which is part of the INDIA cluster,
will be used as a gateway to communicate with the other clusters. The queue
manager will be made part of all three clusters –
AMERICA, EUROPE, and
INDIA:
Figure 2
Terminology
Overlapping
clusters
You can create clusters
that overlap, for various reasons, such as:
·
To let different organizations have their own administration
·
To enable independent applications to be administered separately
·
To create classes of service
Namelists
A namelist is a WebSphere MQ object that contains
a list of other WebSphere MQ objects, such as cluster names, queue names, or
authentication information object names. In a cluster, it can be used to
identify a list of clusters for which the queue manager holds the repositories.
Namelists are used by queue manager clusters to maintain a list of clusters referenced
by more than one WebSphere MQ object. Typically, namelists are used by
applications such as trigger monitors, where they are used to identify a group
of queues.
Queue aliases
A queue alias (QALIAS) definition provides an alias by which a
queue is known to applications. You can create a QALIAS definition on a queue
manager using the DEFINE QALIAS command. For example, the command
DEFINE QALIAS(QA.BOMBAY)
TARGQ(QL.BOMBAY) advertises a queue
called QA.BOMBAY with the target queue QL.BOMBAY. When an application puts a
message on the alias queue, the message is routed to the target queue.
Configuring
overlapping clusters
In order to create overlapping clusters, the queue manager
BOMBAY will be made part of the three clusters AMERICA, EUROPE, and INDIA, and
BOMBAY will serve as the bridge between the three clusters. You start by
creating a namelist on the bridge queue manager, which is then made part of the
three clusters by creating the required cluster sender and receiver channels.
Here are the detailed instructions:
1.
Create a namelist called GLOBAL on the BOMBAY queue manager:
DEFINE NAMELIST (GLOBAL) NAMES ('AMERICA', EUROPE', 'INDIA')
2.
Make the BOMBAY queue manager part of the three clusters by
altering the REPOSNL attribute. To specify that a queue manager holds a full
repository for several clusters, use the attribute REPOSNL(namelist) on the
ALTER QMGR command:
ALTER QMGR REPOS(' ') REPOSNL(GLOBAL)
3.
The TO.BOMBAY clusrcvr channel is a component only in the INDIA
cluster. To make it part of all the three clusters, alter the channel by
specifying the GLOBAL namelist in the CLUSNL attribute. The CLUSNL contains the
name of the namelist that specifies a list of clusters to which the channel
belongs:
ALTER CHANNEL(TO.BOMBAY) CHLTYPE(CLUSRCVR) CLUSTER('') CLUSNL(GATEWAY)
4.
The cluster receiver channel for the BOMBAY queue manager is now
defined and advertised in all three clusters. The next step is to create a
cluster sender channel to the full repositories of the EUROPE and AMERICA
clusters. As a part of the initial setup of the INDIA cluster, the cluster
sender channel from BOMBAY to NEWDELHI already exists. After these sender
channels are created, the BOMBAY queue manager will be able to communicate with
the full repositories of all the three clusters:
DEFINE CHANNEL(TO.LONDON) CHLTYPE(CLUSSDR) CONNAME('localhost(1417)') CLUSTER (EUROPE)
DEFINE CHANNEL(TO.CHICAGO) CHLTYPE(CLUSSDR) CONNAME('localhost(1421)') CLUSTER (AMERICA)
5.
The only remaining step is to enable the full repositories of
the cluster to communicate with the BOMBAY queue manager, which you do by
creating the cluster sender channels from the LONDON and CHICAGO queue managers
to the BOMBAY queue manager:
o On the LONDON queue manager run the
command:
DEFINE CHANNEL(TO.BOMBAY) CHLTYPE(CLUSSDR) CONNAME('localhost(1415)') CLUSTER(EUROPE)
o On the CHICAGO queue manager run the
command:
DEFINE CHANNEL(TO.BOMBAY) CHLTYPE(CLUSSDR) CONNAME('localhost(1415)') CLUSTER(AMERICA)
You have now created the overlapping clusters AMERICA, EUROPE,
and INDIA, with the BOMBAY queue manager acting as a gateway between the three
clusters.
Validating
the setup
To validate the setup, run a display cluster queue manager
command on the BOMBAY queue manager. All of the full repositories from the
three clusters should be visible from the BOMBAY queue manager, and all of the
cluster sender and cluster receiver channels should be in the running state.
Here are the results of running the DIS CLUSQMGR(*) command on the BOMBAY queue
manager:
Figure 3
Sending messages from one cluster to another
Consider a scenario in which one application connecting to a
queue manager in one cluster needs to put a message on a local queue hosted on
a different cluster. An application connecting to the queue manager BANGALORE,
which is part of the INDIA cluster, needs to put a message on a local queue
hosted on the PARIS queue manager, hosted in the EUROPE cluster. You can do
this by creating a queue alias on the gateway queue manager. The table and
graphic below summarize the cluster queue set-up:
Application name
|
Local queue manager
|
Cluster alias queue
name
|
Destination queue
manager
|
Destination queue name
|
APP1
|
BANGALORE
|
QA.BOMBAY.Q1.PARIS
|
PARIS
|
QL.1.PARIS
|
Figure 4
The messages will be routed to the destination queue managers
through the gateway queue manager MARS. The concept of queue manager alias will
be used to route the messages to the destination queue manager. The table above
shows the required queue manager alias on the application queue managers and
the gateway queue manager MARS.
Here are the commands to create the queue manager alias on the
gateway server and the local queue on the PARIS queue manager:
1. Run the following command to create the
queue alias on the BOMBAY queue manager:
DEFINE QA(QA.BOMBAY.PARIS) TARGQ(QL.PARIS) CLUSTER (INDIA) DEFBIND (NOTFIXED)
An application connected to a queue manager in the INDIA cluster
(such as BANGALORE) can now put a message to a queue, which it refers to
QA.BOMBAY.Q1.PARIS, and this message is routed to QL.1.PARIS at the PARIS queue
manager.
2.
When you open a queue, you need to set DEFBIND to either
(NOTFIXED) or (QDEF), because if it is left as the default (OPEN), the queue
manager will resolve the alias definition to the bridge queue manager(BOMBAY)
that hosts it, and the bridge will not forward the message on.
3. On the PARIS queue manager create the local
queue call QL.1.PARIS:
DEFINE QL(QL.1.PARIS ) CLUSTER (EUROPE)
Testing
the setup
You can test the setup using the amsqput application. Create a
separate section called Validation. Connect to the BANGALORE queue manager and
put a message on the QA.BOMBAY.PARIS cluster queue. The message should reach
the destination queue QL.PARIS on the PARIS queue manager. Use the following
the command to run the test:
amqsput QA.BOMBAY.PARIS BANGALORE
Here are the results of
the test:
Figure 5
Conclusion
This article showed you
how to implement overlapping clusters with WebSphere MQ by using namelists. It
also showed you how to test the setup by creating an alias queue on the bridge
queue manager.
Comments
Websphere mq Training in Bangalore