Overlapping clusters
Overlapping clusters provide additional administrative capabilities. Use namelists to reduce the number of commands needed to administer overlapping clusters.
We can create clusters that overlap. There are a number of reasons you might define overlapping clusters; for example:- To allow different organizations to have their own administration.
- To allow independent applications to be administered separately.
- To create classes of service.
In Figure 1, the queue manager STF2 is a member of both the clusters. When a queue manager is a member of more than one cluster, we can take advantage of namelists to reduce the number of definitions we need. Namelists contain a list of names, for example, cluster names. We can create a namelist naming the clusters. Specify the namelist on the ALTER QMGR command for STF2 to make it a full repository queue manager for both clusters.
If we have more than one cluster in your network, we must give them different names. If two clusters with the same name are ever merged, it is not possible to separate them again. It is also a good idea to give the clusters and channels different names. They are more easily distinguished when you look at the output from the DISPLAY commands. Queue manager names must be unique within a cluster for it to work correctly.
Defining classes of service
Imagine a university that has a queue manager for each member of staff and each student. Messages between members of staff are to travel on channels with a high priority and high bandwidth. Messages between students are to travel on cheaper, slower channels. We can set up this network using traditional distributed queuing techniques. IBM MQ selects which channels to use by looking at the destination queue name and queue manager name.
To clearly differentiate between the staff and students, you could group their queue managers into two clusters as shown in Figure 1. IBM MQ moves messages to the meetings queue in the staff cluster only over channels that are defined in that cluster. Messages for the gossip queue in the students cluster go over channels defined in that cluster and receive the appropriate class of service.
