How clusters work
Understand what clusters are and how they work.
A cluster is a network of queue managers that are logically associated in some way. The queue managers in a cluster might be physically remote. For example, they might represent the branches of an international chain store and be physically located in different countries. Each cluster within an enterprise must have a unique name.
Typically a cluster contains queue managers that are logically related in some way and need to share some data or applications. For example you might have one queue manager for each department in your company, managing data and applications specific to that department. You could group all these queue managers into a cluster so that they all feed into the payroll application. Or you might have one queue manager for each branch of your chain store, managing the stock levels and other information for that branch. If you group these queue managers into a cluster, they can all access the same set of sales and purchases applications. The sales and purchases application might be held centrally on the head-office queue manager.
Once you set up a cluster, the queue managers within it can communicate with each other, without you defining extra channel definitions or remote-queue definitions.
You can convert an existing network of queue managers into a cluster or you can establish a cluster as part of setting up a new network.
An IBM® WebSphere® MQ client can connect to a queue manager that is part of a cluster, just as it can connect to any other queue manager.
Clusters can also be used for workload management. For more information, see Using clusters for workload management.
How messages are routed in a cluster
If you are familiar with IBM WebSphere MQ and distributed queuing, think of a cluster as a network of queue managers maintained by a conscientious systems administrator. Whenever you define a cluster queue, the systems administrator automatically creates corresponding remote-queue definitions as needed on the other queue managers.
You do not need to make transmission queue definitions because IBM WebSphere MQ provides a transmission queue on each queue manager in the cluster. This single transmission queue can be used to carry messages to any other queue manager in the cluster. You are not limited to using a single transmission queue. A queue manager can use multiple transmission queues to separate the messages going to each queue manager in a cluster. Typically, a queue manager uses a single cluster transmission queue. You can change the queue manager attribute DEFCLXQ, so that a queue manager uses a different cluster transmission queues for each queue manager in a cluster. You can also define cluster transmission queues manually.
All the queue managers that join a cluster agree to work in this way. They send out information about themselves and about the queues they host, and they receive information about the other members of the cluster.
This information is stored in repositories. Most queue managers retain only the information that they need, that is, information about queues and queue managers with which they need to communicate. Each queue manager keeps the information in a partial repository. Some designated queue managers retain a full repository of all the information about all queue managers in the cluster.
In order to become part of a cluster, a queue manager must have two channels; a cluster-sender channel and a cluster-receiver channel
A cluster-sender channel is a communication channel like a sender channel. You must manually create one cluster-sender channel on a queue manager to connect it to a full repository that is already a member of the cluster.
A cluster-receiver channel is a communication channel like a receiver channel. You must manually create one cluster-receiver channel. The channel acts as the mechanism for the queue manager to receive cluster communications
All other channels that might then be needed for communication between this queue manager and any other member of the cluster is created automatically
Queue managers on platforms that support clusters do not have to be part of a cluster. You can continue to use distributed queuing techniques as well as, or instead of, using clusters.
Example of a cluster
- In this cluster, there are three queue managers,
QM2host repositories of information about all the queue managers and cluster-related objects in the cluster. They are referred to as full repository queue managers. The repositories are represented in the diagram by the shaded cylinders.
QM3host some queues that are accessible to any other queue manager in the cluster. Queues that are accessible to any other queue manager in the cluster are called cluster queues. The cluster queues are represented in the diagram by the shaded queues. Cluster queues are accessible from anywhere in the cluster. IBM WebSphere MQ clustering code ensures that remote queue definitions for cluster queues are created on any queue manager that refers to them.
As with distributed queuing, an application uses the MQPUT call to put a message on a cluster queue at any queue manager in the cluster. An application uses the MQGET call to retrieve messages from a cluster queue only on the queue manager where the queue resides.
- Each queue manager has a manually created definition for the receiving end of a channel called cluster-name.queue-manager on which it can receive messages. On the receiving queue manager, cluster-name.queue-manager is a cluster-receiver channel. A cluster-receiver channel is like a receiver channel used in distributed queuing; it receives messages for the queue manager. In addition, it also receives information about the cluster.
- In Figure 2 each queue manager also has a definition
for the sending end of a channel. It connects to the cluster-receiver
channel of one of the full repository queue managers. On the sending
cluster-name.queue-manageris a cluster-sender channel.
QM3have cluster-sender channels connecting to
CLSTR1.QM2, see dotted line
QM2has a cluster-sender channel connecting to
CLSTR1.QM1, see dotted line
3. A cluster-sender channel is like a sender-channel used in distributed queuing; it sends messages to the receiving queue manager. In addition, it also sends information about the cluster.
Once both the cluster-receiver end and the cluster-sender end of a channel are defined, the channel starts automatically.
What makes clustering work?
Defining a cluster-sender channel on the local queue manager introduces that queue manager to one of the full repository queue managers. The full repository queue manager updates the information in its full repository accordingly. Then it automatically creates a cluster-sender channel back to the original queue manager, and sends that queue manager information about the cluster. Thus a queue manager learns about a cluster and a cluster learns about a queue manager.
Look again at Figure 1.
Suppose that an application connected to queue manager
to send some messages to the queues at
QM2. The first
QM3 must access those queues, it discovers
them by consulting a full repository. The full repository in this
QM2, which is accessed using the sender channel
With the information from the repository, it can automatically create
remote definitions for those queues. If the queues are on
this mechanism still works, because
QM2 is a full
repository. A full repository has a complete record of all the objects
in the cluster. In this latter case,
QM3 would also
automatically create a cluster-sender channel corresponding to the
cluster-receiver channel on
QM1, allowing direct
communication between the two.
CLSTR1.QM3. It also shows the cluster transmission queue,
QM1uses to send its messages. All queue managers in the cluster have a cluster transmission queue, from which they can send messages to any other queue manager in the same cluster.