Selecting queue managers to hold full repositories
In each cluster select at least one, preferably two, or possibly more of the queue managers to hold full repositories. A cluster can work quite adequately with only one full repository but using two improves availability. You interconnect the full repository queue managers by defining cluster-sender channels between them.
Figure 1. A typical 2-repository topology
Figure 1 shows a typical 2-full repository topology. This is the topology used in the cluster shown in Figure 1.
- The most important consideration is that the queue managers chosen to hold full repositories need to be reliable and well managed. For example, it would be far better to choose queue managers on a stable z/OS system than queue managers on a portable personal computer that is frequently disconnected from the network.
- You should also consider the planned outages of the systems hosting your full repositories, and ensure that they do not have coinciding outages.
- You might also consider the location of the queue managers and choose ones that are in a central position geographically or perhaps ones that are located on the same system as a number of other queue managers in the cluster.
- Another consideration might be whether a queue manager already holds the full repositories for other clusters. Having made the decision once, and made the necessary definitions to set up a queue manager as a full repository for one cluster, you might well choose to rely on the same queue manager to hold the full repositories for other clusters of which it is a member.
When a queue manager sends out information about itself or requests information about another queue manager, the information or request is sent to two full repositories. A full repository named on a CLUSSDR definition handles the request whenever possible, but if the chosen full repository is not available another full repository is used. When the first full repository becomes available again it collects the latest new and changed information from the others so that they keep in step.
In very large clusters, containing thousands of queue managers, you might want to have more than two full repositories. Then you might have one of the following topologies. (These are only example topologies)
Figure 2. A hub and spoke arrangement of full repositories
Figure 3. A complex full repository topology
If all the full repository queue managers go out of service at the same time, queue managers continue to work using the information they have in their partial repositories. Clearly they are limited to using the information that they have. New information and requests for updates cannot be processed. When the full repository queue managers reconnect to the network, messages are exchanged to bring all repositories (both full and partial) back up-to-date.
The full repositories republish the publications they receive through the manually-defined CLUSSDR channels, which must point to other full repositories in the cluster. You must make sure that a publication received by any full repository ultimately reaches all the other full repositories. You do this by manually defining CLUSSDR channels between the full repositories. The more interconnection of full repositories you have, the more robust the cluster.
Having only two full repositories is sufficient for all but very exceptional circumstances.
Parent topic:
Designing clusters
qc11230_
Home
