Set up a new cluster

 

Scenario

You are setting up a new WebSphere MQ network for a retail store. The store has two branches, one in LONDON and one in Amsterdam. The data and applications for each store are hosted by systems running separate queue managers. The two queue managers are called LONDON and AMSTERDAM.

The inventory application runs on the system in Amsterdam, connected to queue manager AMSTERDAM. The application is driven by the arrival of messages on the RCVINVCQ queue, hosted by AMSTERDAM.

The two queue managers, LONDON and AMSTERDAM, are to be linked in a cluster called INVENTORY.

Both will be able to put messages in the RCVINVCQ.

 

Steps

 

1. Decide on the organization of the cluster and its name

You have decided to link the two queue managers, LONDON and AMSTERDAM, into a cluster. A cluster with only two queue managers offers only marginal benefit over a network that is to use distributed queuing, but is a good way to start and provides scope for future expansion. When you open new branches of your store, you will be able to add the new queue managers to the cluster easily and without any disruption to the existing network.

 

2. Determine which queue managers should hold full repositories

In any cluster you need to nominate at least one queue manager, or preferably two, to hold full repositories. See Selecting queue managers to hold full repositories for more information. In this example there are only two queue managers, LONDON and AMSTERDAM, both of which hold full repositories.

You can perform the remaining steps in any order.

As you proceed through the steps, warning messages might be written to the queue-manager log if you have yet to make some expected definitions. 

+--------------------------------------------------------------------------------+
|Examples of the responses to the commands are shown in a box                    |
|like this after each step in this task.                                         |
|These examples show the responses returned by WebSphere MQ for AIX.             |
|The responses vary on other platforms.                                          |
+--------------------------------------------------------------------------------+

Before proceeding with these steps, make sure that the queue managers are started.

 

3. Alter the queue-manager definitions to add repository definitions

On each queue manager that is to hold a full repository, you need to alter the queue-manager definition, using the ALTER QMGR command and specifying the REPOS attribute: 

ALTER QMGR REPOS(INVENTORY)



+--------------------------------------------------------------------------------+
|     1 : ALTER QMGR REPOS(INVENTORY)                                            |
|AMQ8005: Websphere MQ queue manager changed.                                    |
+--------------------------------------------------------------------------------+

If you just runmqsc and enter the ALTER QMGR command, the local queue manager will be changed.

 

4. Define the CLUSRCVR channels

On every queue manager in a cluster you need to define a cluster-receiver channel on which the queue manager can receive messages. This definition defines the queue manager's connection name and the CLUSTER keyword shows the queue manager's availability to receive messages from other queue managers in the cluster. The queue manager's connection name is stored in the repositories, where other queue managers can refer to it.

On the LONDON queue manager, define: 

DEFINE CHANNEL(TO.LONDON) 
       CHLTYPE(CLUSRCVR) 
       TRPTYPE(TCP)
       CONNAME(LONDON.CHSTORE.COM) 
       CLUSTER(INVENTORY)
       DESCR('TCP Cluster-receiver channel for queue manager LONDON')



+--------------------------------------------------------------------------------+
|     1 : DEFINE CHANNEL(TO.LONDON) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)               |
|         CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)                         |
|         DESCR('TCP Cluster-receiver channel for queue manager LONDON')         |
|AMQ8014: Websphere MQ channel created.                                          |
|07/09/98  12:56:35  No repositories for cluster 'INVENTORY'                     |
+--------------------------------------------------------------------------------+

In this example the channel name is TO.LONDON, and the connection name (CONNAME) is the network address of the machine the queue manager resides on, which is LONDON.CHSTORE.COM. (The network address can be entered either as an alphanumeric DNS hostname, or as a dotted-decimal IP address.) Do not allow the CONNAME to specify a generic name.

On the AMSTERDAM queue manager, define: 

DEFINE CHANNEL(TO.AMSTERDAM) CHLTYPE(CLUSRCVR) TRPTYPE(TCP)
CONNAME(AMSTERDAM.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-receiver channel for queue manager AMSTERDAM')

 

5. Define the CLUSSDR channels

On every queue manager in a cluster you need to define one cluster-sender channel on which the queue manager can send messages to one of the full repository queue managers. In this case there are only two queue managers, both of which hold full repositories. They must each have a CLUSSDR definition that points to the CLUSRCVR channel defined at the other queue manager. Note that the channel names given on the CLUSSDR definitions must match those on the corresponding CLUSRCVR definitions.

On the LONDON queue manager, define: 

DEFINE CHANNEL(TO.AMSTERDAM) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(AMSTERDAM.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from LONDON to repository at AMSTERDAM')



+--------------------------------------------------------------------------------+
|     1 : DEFINE CHANNEL(TO.AMSTERDAM) CHLTYPE(CLUSSDR) TRPTYPE(TCP)               |
|         CONNAME(AMSTERDAM.CHSTORE.COM) CLUSTER(INVENTORY)                        |
|         DESCR('TCP Cluster-sender channel from LONDON to repository at AMSTERDAM'|
|AMQ8014: Websphere MQ channel created.                                          |
|07/09/98  13:00:18    Channel program started.                                  |
+--------------------------------------------------------------------------------+

On the AMSTERDAM queue manager, define: 

DEFINE CHANNEL(TO.LONDON) CHLTYPE(CLUSSDR) TRPTYPE(TCP)
CONNAME(LONDON.CHSTORE.COM) CLUSTER(INVENTORY)
DESCR('TCP Cluster-sender channel from AMSTERDAM to repository at LONDON')

 

6. Define the cluster queue RCVINVCQ

Define the RCVINVCQ queue on the AMSTERDAM queue manager, specifying the CLUSTER keyword. 

DEFINE QLOCAL(RCVINVCQ) CLUSTER(INVENTORY)



+--------------------------------------------------------------------------------+
|     1 : DEFINE QLOCAL(RCVINVCQ) CLUSTER(INVENTORY)                              |
|AMQ8006: Websphere MQ queue created.                                            |
+--------------------------------------------------------------------------------+

The CLUSTER keyword causes the queue to be advertised to the cluster. As soon as the queue is defined it becomes available to the other queue managers in the cluster. They can send messages to it without having to make a remote-queue definition for it.

Now that you have completed all the definitions, if you have not already done so start the channel initiator on WebSphere MQ for z/OS and, on all platforms, start a listener program on each queue manager. The listener program listens for incoming network requests and starts the cluster-receiver channel when it is needed. See Establishing communication in a cluster for more information.

 

The cluster achieved by task 1

The cluster set up by this task looks like this:

Clearly, this is a very small cluster. However, it is useful as a proof of concept. The important thing to understand about this cluster is the scope it offers for future enhancement.

 

Converting an existing network into a cluster

If you are converting an existing network into a cluster like this, in step 6, you need to alter the existing queue definition. You also need to delete the remote queue definition at LONDON for the RCVINVCQ queue. See Converting an existing network into a cluster for an example of this.

 

Verifying task 1

Issue some DISPLAY commands to verify the cluster that you have set up. The responses you see should be similar to those shown in the examples that follow.

From the AMSTERDAM queue manager, issue the command: 

dis clusqmgr(*)



+--------------------------------------------------------------------------------+
|     1 : dis clusqmgr(*)                                                        |
|AMQ8441: Display Cluster Queue Manager details.                                 |
|   CLUSQMGR(AMSTERDAM)             CLUSTER(INVENTORY)                             |
|   CHANNEL(TO.AMSTERDAM)                                                          |
|AMQ8441: Display Cluster Queue Manager details.                                 |
|   CLUSQMGR(LONDON)              CLUSTER(INVENTORY)                             |
|   CHANNEL(TO.LONDON)                                                           |
+--------------------------------------------------------------------------------+

Now issue the corresponding DISPLAY CHANNEL STATUS command: 

dis chstatus(*)



+--------------------------------------------------------------------------------+
|     1 : dis chstatus(*)                                                        |
|AMQ8417: Display Channel Status details.                                        |
|   CHANNEL(TO.AMSTERDAM)           XMITQ( )                                       |
|   CONNAME(9.20.40.24)           CURRENT                                        |
|   CHLTYPE(CLUSRCVR)             STATUS(RUNNING)                                |
|AMQ8417: Display Channel Status details.                                        |
|   CHANNEL(TO.LONDON)            XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)           |
|   CONNAME(9.20.51.25)           CURRENT                                        |
|   CHLTYPE(CLUSSDR)              STATUS(RUNNING)                                |
+--------------------------------------------------------------------------------+

 

Using the cluster set up in task 1

Because the RCVINVCQ queue has been advertised to the cluster there is no need for remote-queue definitions. Applications running on AMSTERDAM and applications running on LONDON can put messages to the RCVINVCQ queue. They can receive responses to their messages by providing a reply-to queue and specifying its name when they put messages.

 

Using sample programs

Test your setup by sending some messages between the two queue managers, using amqsput. In the following example LONDON puts a message to the RCVINVCQ at AMSTERDAM:

  1. On LONDON issue the command:

  2. Type some messages

  3. On NEW YORK issue the command:

  4. You should now see the messages you entered on LONDON

 

Using your own programs

Test your setup by sending some messages between the two queue managers. In the following example LONDON puts a message to the RCVINVCQ at AMSTERDAM and receives a reply on its queue LONDON_reply.

  1. Define a local queue called LONDON_reply

  2. Set the MQOPEN options to MQOO_OUTPUT

  3. Issue the MQOPEN call to open the queue RCVINVCQ

  4. Set the ReplyToQ name in the message descriptor to LONDON_reply

  5. Issue the MQPUT call to put the message

  6. Commit the message

On AMSTERDAM:

  1. Set the MQOPEN options to MQOO_BROWSE

  2. Issue the MQOPEN call to open the queue RCVINVCQ

  3. Issue the MQGET call to get the message from RCVINVCQ

  4. Retrieve the ReplyToQ name from the message descriptor

  5. Put the ReplyToQ name in the ObjectName field of the object descriptor

  6. Set the MQOPEN options to MQOO_OUTPUT

  7. Issue the MQOPEN call to open LONDON_reply at queue manager LONDON

  8. Issue the MQPUT call to put the message to LONDON_reply

On LONDON:

  1. Set the MQOPEN options to MQOO_BROWSE

  2. Issue the MQOPEN call to open the queue LONDON_reply

  3. Issue the MQGET call to get the message from LONDON_reply

Note:
The definition for the local queue LONDON_reply does not need the CLUSTER attribute. AMSTERDAM replies to this queue by explicitly specifying the queue manager name. Another way of doing is to use a temporary dynamic queue. See the WebSphere MQ Application Programming Guide for more information.

 

Converting an existing network into a cluster

If you are converting an existing network into a cluster like this, in step 7, you need to alter the existing queue definition. You also need to delete the remote queue definition at LONDON for the RCVINVCQ queue. See Converting an existing network into a cluster for an example of this.

 

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.