| Clustering | |
Each queue manager in a cluster needs to define only:
- one cluster-receiver channel on which to receive messages
- one cluster-sender channel with which it introduces itself and learns about the cluster
- which own queues it wants to make available to the cluster
You can only GET from a local cluster queue, but you can PUT to any queue in a cluster. If you open a queue to use the MQGET command, the queue manager will only use the local queue.
Each queue manager has a definition for the receiving end of a channel called TO.qmgr on which it can receive messages. This is a cluster-receiver channel. A cluster-receiver channel is similar to a receiver channel used in distributed queuing, but in addition to carrying messages this channel can also carry information about the cluster.
Each queue manager also has a definition for the sending end of a channel, which connects to the cluster-receiver channel of one of the Full Repository (FR) queue managers. This is a cluster-sender channel. A cluster-sender channel is similar to a sender channel used in distributed queuing, but in addition to carrying messages this channel can also carry information about the cluster.
Once both the cluster-receiver end and the cluster-sender end of a channel have been defined, the channel starts automatically.
In any cluster you need to nominate two queue managers to hold full repositories.
The clusters use the publish/subscribe model for internal messaging (and will Subscribe to only 2 FR)
Queue Manager Repository is kept in SYSTEM.CLUSTER.REPOSITORY.QUEUE queue
Cluster information is carried to repositories (whether full or partial) on a local queue called SYSTEM.CLUSTER.COMMAND.QUEUE.
Few Q&A ;
- how many FR ? 2
- DISCINT=0 ? no
- 2 qmgrs just to be FR ? yes, on a separate server
Interesting summary :
#1 Regardless of how many FRs you have, each FR should have a manual CLUSSNDR defined to every other FR.
#2 If every FR has a CLUSSNDR to every other FR, each FR will know about every cluster attribute on every QM in the cluster.
#3 A PR will only ever publish info to 2 FRs. A PR will only ever subscribe to 2 FRs. Period. It doesn't matter how many manual CLUSSNDRs you define on that PR. A PR will only ever send its info (publish) to 2 FRs and will only get updates (subscribe) from 2 FRs.
#4 You should only define one CLUSSNDR to one FR from a PR.
#5 If 2 FRs go down in your cluster, your cluster will be able to send messages just fine. But any changes to cluster definitions become a problem. Any PRs that used both of these down FRs will still function for messaging, but they will not be made aware of any changes in the cluster because both of it's FRs are N/A.
#6 If two of your FRs are down, and you still have other FRs, you could go to your PRs and delete the CLUSSNDR to the down FR, define a CLUSSNDR to an available FR and issue REFRESH CLUSTER(*) REPOS(YES). This would cause your PR to register with an available FR and thus pick up cluster changes.
#7 In a properly designed system the liklihood of 2 FRs being down is next to zero, so the need for more than 2 FRs is next to zero. And even if both FRs are down it doesn't mean your cluster will come to a screeching halt.
Just use 2 FRs.
Problem : stuck message(s) @ Xmit Q(s)!
#2 If every FR has a CLUSSNDR to every other FR, each FR will know about every cluster attribute on every QM in the cluster.
#3 A PR will only ever publish info to 2 FRs. A PR will only ever subscribe to 2 FRs. Period. It doesn't matter how many manual CLUSSNDRs you define on that PR. A PR will only ever send its info (publish) to 2 FRs and will only get updates (subscribe) from 2 FRs.
#4 You should only define one CLUSSNDR to one FR from a PR.
#5 If 2 FRs go down in your cluster, your cluster will be able to send messages just fine. But any changes to cluster definitions become a problem. Any PRs that used both of these down FRs will still function for messaging, but they will not be made aware of any changes in the cluster because both of it's FRs are N/A.
#6 If two of your FRs are down, and you still have other FRs, you could go to your PRs and delete the CLUSSNDR to the down FR, define a CLUSSNDR to an available FR and issue REFRESH CLUSTER(*) REPOS(YES). This would cause your PR to register with an available FR and thus pick up cluster changes.
#7 In a properly designed system the liklihood of 2 FRs being down is next to zero, so the need for more than 2 FRs is next to zero. And even if both FRs are down it doesn't mean your cluster will come to a screeching halt.
Just use 2 FRs.
Problem : stuck message(s) @ Xmit Q(s)!
Comments
Post a Comment