Designing clusters

Clusters provide a mechanism for interconnecting queue managers in a way that simplifies both the initial configuration and the ongoing management. Clusters must be carefully designed, to ensure that they function correctly, and that they achieve the required levels of availability and responsiveness.

Before starting

• Distributed queuing and clusters
• Comparison of clustering and distributed queuing
• Components of a cluster

When we are designing your queue manager cluster you have to make some decisions. We must first decide which queue managers in the cluster are to hold the full repositories of cluster information. Any queue manager you create can work in a cluster. We can choose any number of queue managers for this purpose but the ideal number is two. For information about selecting queue managers to hold the full repositories, see How to choose cluster queue managers to hold full repositories.

• Example clusters
• Organizing a cluster
• Cluster naming conventions
• Queue sharing groups and clusters
• Overlapping clusters

What to do next

• Establishing communication in a cluster
• Configure a queue manager cluster
• Routing messages to and from clusters
• Use clusters for workload management

For more information to help you configure the cluster, seeClustering tips.

• Plan how we use multiple cluster transmission queues
  We can explicitly define transmission queues, or have the system generate the transmission queues for you. If you define the transmission queues yourself, you have more control over the queue definitions. On z/OS, you also have more control over the page set where the messages are held.
• Access control and multiple cluster transmission queues
  Choose between three modes of checking when an application puts messages to remote cluster queues. The modes are checking remotely against the cluster queue, checking locally against SYSTEM.CLUSTER.TRANSMIT.QUEUE, or checking against local profiles for the cluster queue, or cluster queue manager.
• Comparison of clustering and distributed queuing
  Compare the components that need to be defined to connect queue managers using distributed queuing and clustering.
• How to choose cluster queue managers to hold full repositories
  In each cluster we must choose at least one, and preferably two queue managers to hold full repositories. Two full repositories are sufficient for all but the most exceptional circumstances. If possible, choose queue managers that are hosted on robust and permanently-connected platforms, that do not have coinciding outages, and that are in a central position geographically. Also consider dedicating systems as full repository hosts, and not using these systems for any other tasks.
• Organizing a cluster
  Select which queue managers to link to which full repository. Consider the performance effect, the queue manager version, and whether multiple CLUSSDR channels are desirable.
• Cluster naming conventions
  Consider naming queue managers in the same cluster using a naming convention that identifies the cluster to which the queue manager belongs. Use a similar naming convention for channel names and extend it to describe the channel characteristics. Do not use a generic connection in defining cluster-receiver channels on z/OS.
• Queue sharing groups and clusters
  Shared queues can be cluster queues and queue managers in a queue sharing group can also be cluster queue managers.
• Overlapping clusters
  Overlapping clusters provide additional administrative capabilities. Use namelists to reduce the number of commands needed to administer overlapping clusters.
• Clustering tips
  We might need to make some changes to the systems or applications before using clustering. There are both similarities and differences from the behavior of distributed queuing.
• How long do the queue manager repositories retain information?
  Queue manager repositories retain information for 30 days. An automatic process efficiently refreshes information that is being used.
• Example clusters
  The first example shows the smallest possible cluster of two queue managers. The second and third examples show two versions of a three queue manager cluster.
• Clustering: Best practices
  Clusters provide a mechanism for interconnecting queue managers. The best practices described in this section are based on testing and feedback from customers.
• Uniform clusters: Planning considerations
  Uniform clusters remove some of the manual steps an administrator has to go through to create and administer a group of independent, interconnected queue managers. They move some client connection logic from the client to the queue manager, where information about levels of application activity can inform decisions at the clients, as to which queue managers they should connect to.

Parent topic: Plan for distributed queues and clusters