Clustering: Planning how to configure cluster transmission queues

You are guided through the choices of cluster transmission queues. We can configure one common default queue, separate default queues, or manually defined queues.

Before starting

Review How to choose what type of cluster transmission queue to use.

About this task

We have some choices to make when we are planning how to configure a queue manager to select a cluster transmission queue.

1. What is the default cluster transmission queue for cluster message transfers?
   1. A common cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE.
   2. Separate cluster transmission queues. The queue manager manages the separate cluster transmission queues. It creates them as permanent-dynamic queues from the model queue, SYSTEM.CLUSTER.TRANSMIT.MODEL.QUEUE. It creates one cluster transmission queue for each cluster-sender channel it uses.

2. For the cluster transmission queues that you do decide to create manually, you have a further two choices:
   1. Define a separate transmission queue for each cluster-sender channel that you decide to configure manually. In this case, set the CLCHNAME queue attribute of the transmission queue to the name of a cluster-sender channel. Select the cluster-sender channel that is to transfer messages from this transmission queue.
   2. Combine message traffic for a group of cluster-sender channels onto the same cluster transmission queue; see Figure 1. In this case, set the CLCHNAME queue attribute of each common transmission queue to a generic cluster-sender channel name. A generic cluster-sender channel name is a filter to group cluster-sender channel names. For example, SALES.* groups all cluster-sender channels that have names beginning with SALES.. We can place multiple wildcard characters anywhere in the filter-string. The wildcard character is an asterisk, *. It represents from zero to any number of characters.

Procedure

1. Select the type of default cluster transmission queue to use.
   • Choose a single cluster transmission queue, or separate queues for each cluster connection.

   Leave the default setting or run the MQSC command:

   ALTER QMGR DEFCLXQ(CHANNEL)
   

2. Isolate any message flows that must not share a cluster transmission queue with other flows.
   • See Clustering: Example configuration of multiple cluster transmission queues. In the example the SALES queue, which must be isolated, is a member of the SALES cluster, on SALESRV. To isolate the SALES queue, create a new cluster Q.SALES, make the SALESRV queue manager a member, and modify the SALES queue to belong to Q.SALES.
   • Queue managers that send messages to SALES must also be members of the new cluster. If we use a clustered queue alias and a gateway queue manager, as in the example, in many cases we can limit the changes to making the gateway queue manager a member of the new cluster.
   • However, separating flows from the gateway to the destination does not separate flows to the gateway from the source queue manager. But it sometimes turns out to be sufficient to separate flows from the gateway and not flows to the gateway. If it is not sufficient, then add the source queue manager into the new cluster. If we want messages to travel through the gateway, move the cluster alias to the new cluster and continue to send messages to the cluster alias on the gateway, and not directly to the target queue manager.

   Follow these steps to isolate message flows:

   1. Configure the destinations of the flows so that each target queue is the only queue in a specific cluster, on that queue manager.
   2. Create the cluster-sender and cluster-receiver channels for any new clusters you have created following a systematic naming convention.
      • See Clustering: Special considerations for overlapping clusters.

   3. Define a cluster transmission queue for each isolated destination on every queue manager that sends messages to the target queue.
      • A naming convention for cluster transmission queues is to use the value of the cluster channel name attribute, CLCHNAME, prefixed with XMITQ.

3. Create cluster transmission queues to meet governance or monitoring requirements.
   • Typical governance and monitoring requirements result in a transmission queue per cluster or a transmission queue per queue manager. If you follow the naming convention for cluster channels, ClusterName. QueueManagerName, it is easy to create generic channel names that select a cluster of queue managers, or all the clusters a queue manager is a member of; see Clustering: Example configuration of multiple cluster transmission queues.
   • Extend the naming convention for cluster transmission queues to cater for generic channel names, by replacing the asterisk symbol by a percent sign. For example,

     DEFINE QLOCAL(XMITQ.SALES.%) USAGE(XMITQ) CLCHNAME(SALES.*)
     

• How to choose what type of cluster transmission queue to use
  How to choose between different cluster transmission queue configuration options.
• Clustering: Example configuration of multiple cluster transmission queues
  In this task you apply the steps to plan multiple cluster transmission queues to three overlapping clusters. The requirements are to separate messages flows to one cluster queue, from all other message flows, and to store messages for different clusters on different cluster transmission queues.
• Clustering: Switching cluster transmission queues
  Plan how the changes to the cluster transmission queues of an existing production queue manager are going to be brought into effect.

Parent topic: Clustering: Best practices

Related concepts

• Access control and multiple cluster transmission queues
• Overlapping clusters

Related information

• Work with cluster transmission queues and cluster-sender channels
• Adding a remote queue definition to isolate messages sent from a gateway queue manager
• Adding a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager
• Adding a cluster and a cluster transmit queue to isolate cluster message traffic sent from a gateway queue manager
• Change the default to separate cluster transmission queues to isolate message traffic
• Create two-overlapping clusters with a gateway queue manager
• Configure message paths between clusters