Components of a cluster
Queue managers and repositories
Every cluster should have at least two queue managers holding full repositories of information about the queue managers, queues, and channels in a cluster. These repositories also contain requests from the other queue managers in the cluster for updates to the information.
The other queue managers each hold a partial repository, containing information about the subset of queues and queue managers with which they need to communicate. The queue managers build up their partial repositories by making inquiries when they first need to access another queue or queue manager, and by requesting that thereafter they be notified of any new information concerning that queue or queue manager.
Each queue manager stores its repository information in messages on a queue called SYSTEM.CLUSTER.REPOSITORY.QUEUE. The queue managers exchange repository information in messages on a queue called SYSTEM.CLUSTER.COMMAND.QUEUE.
Each queue manager that joins a cluster defines a cluster-sender (CLUSSDR) channel to one of the repositories. When it does this, it immediately learns which other queue managers in the cluster hold full repositories. From then on the queue manager can request information from any of the repositories. When the queue manager sends out any information about itself, for example when it creates a new queue definition, this information is sent to the chosen repository and also to one other repository (if there is one).
A full repository is updated when the queue manager hosting it receives new information from one of the queue managers that is linked to it. The new information is also sent to another repository, to reduce the risk of it being delayed if a repository queue manager is out of service. Because all the information is sent twice, the repositories have to discard duplicates. Each item of information carries a sequence number, which the repositories use to identify duplicates. All repositories are kept in step with each other by exchanging messages.
Queues
A queue manager that hosts cluster queues must advertise its queues to the cluster. It does this using the DEFINE QLOCAL command with the CLUSTER option, for example:
DEFINE QLOCAL(Q1) CLUSTER(SALES)Once a queue has been advertised, any queue manager in the cluster can put messages to it. To put a message, the queue manager has to find out, from the full repositories, where the queue is hosted. Then it adds some routing information to the message and puts the message on its cluster transmission queue.
Cluster transmission queue
Each cluster queue manager has a cluster transmission queue called SYSTEM.CLUSTER.TRANSMIT.QUEUE. A definition for this queue (and others required for clustering) is created by default on every queue manager except on z/OS where it can be defined using the supplied sample CSQ4INSX.
A queue manager that is part of a cluster can send messages on the cluster transmission queue to any other queue manager that is in the same cluster.
Applications must not write directly to the cluster transmission queue. They write to named queues that resolve to the cluster transmission queue. Similarly, not specify the cluster transmission queue as a named transmission queue in a remote queue definition, or specify it as the queue manager's default transmission queue.
Queue managers can also communicate with other queue managers that are not part of a cluster. To do this, a queue manager must define channels and a transmission queue to the other queue manager, in the same way as in a distributed-queuing environment.
During name resolution, the cluster transmission queue takes precedence over the default transmission queue. When a queue manager that is not part of a cluster puts a message to a remote queue, the default action, if there is no transmission queue with the same name as the destination queue manager, is to use the default transmission queue. When the sending queue manager is part of a cluster, the default action, if there is no transmission queue with the same name as the destination queue manager, is to use SYSTEM.CLUSTER.TRANSMIT.QUEUE, except when the destination queue is not part of the cluster. In short, if the normal resolution takes place, the normal transmission queue is used if the queue is resolved using the full repository, SYSTEM.CLUSTER.TRANSMIT.QUEUE is used.
Cluster channels
The WebSphere MQ Intercommunication book describes how message channels are used in distributed queuing. Within clusters, messages are distributed between cluster queue managers on a special type of channel for which you need cluster-receiver channel definitions and cluster-sender channel definitions.
A cluster-receiver channel definition defines a channel on which a queue manager can receive messages. A queue manager's CLUSRCVR definition enables other queue managers to auto-define their corresponding CLUSSDR channel definitions to that queue manager. First each queue manager must manually define a cluster-sender channel. This definition enables the queue manager to make its initial contact with the cluster. It names the full repository queue manager to which the queue manager preferentially chooses to send cluster information.
The CLUSSDR definitions made on the full repository queue managers are special. All the updates exchanged by the full repositories flow exclusively on these channels. The administrator controls the network of full repositories explicitly. The administrator must make the CLUSSDR definitions on full repository queue managers manually and not leave them to be auto-defined.
Auto-definition of remote queues
A queue manager in a cluster does not need a remote-queue definition for remote queues in the cluster. The cluster queue manager finds the location of a remote queue (from the full repository) and then adds routing information to the message and puts it on the cluster transmission queue. WebSphere MQ automatically creates a definition equivalent to a remote-queue definition so that the message can be sent.
You cannot alter or delete an automatically-created remote-queue definition. However, you can look at it using the DISPLAY QUEUE command with the CLUSINFO attribute. For example:
DISPLAY QUEUE(*) CLUSINFO
Auto-definition of channels
When you use distributed queuing, a queue manager must have a definition for a sender channel before it can send a message to a remote destination.
When a queue manager has joined a cluster by making its initial CLUSSDR and CLUSRCVR definitions, it does not need to make any other definitions for channels to other queue managers in the cluster. WebSphere MQ automatically makes cluster-sender channel definitions when they are needed. When both the cluster-sender end and the cluster-receiver end of a channel are defined, the channel is started. An auto-defined channel remains active until it is no longer needed and is shut down using the normal disconnect-interval rules.
Auto-defined cluster-sender channels take their attributes from those specified in the corresponding cluster-receiver channel definition on the receiving queue manager. Even if there is a manually-defined cluster-sender channel, its attributes are automatically modified to ensure that they match those on the corresponding cluster-receiver definition. Always be aware of this, suppose, for example that you define a CLUSRCVR without specifying a port number in the CONNAME parameter, and manually define a CLUSSDR that does specify a port number. When the auto-defined CLUSSDR replaces the manually defined one, the port number (taken from the CLUSRCVR) becomes blank. The default port number is used and the channel fails.
You cannot modify an auto-defined cluster-sender definition.
You cannot see automatically-defined channels using the DISPLAY CHANNEL command. To see the auto-defined channels use the command DISPLAY CLUSQMGR(qmname). You can also use the command DISPLAY CHSTATUS(channelname) to display the status of the auto-defined CLUSSDR channel corresponding to the CLUSRCVR channel definition you created.
You can enable the WebSphere MQ channel auto-definition exit if you want to write a user exit program to customize a cluster-sender channel or cluster-receiver channel. You might, for example, do this in a cluster environment to:
- Tailor communications definitions, that is, SNA LU 6.2 names
- Add or remove other exits, for example, security exits
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.