| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Why should qmgrs use unique channel for each cluster? |
« View previous topic :: View next topic » |
| Author |
Message
|
| bfzhou |
 Posted: Fri Jun 03, 2022 5:21 am Post subject: Why should qmgrs use unique channel for each cluster? |
 |
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
In situations of multiple overlapping clusters, MQ Cluster best practice seems to recommend using unique CLUSSDR-CLUSRCVR pair for each cluster where a qmgr is a member, like TO.FR1.CLST_1, TO.PR3.CLUS_1, etc. But it doesn't say why.
I ask this question because during a cluster consolidation project, where we centralize the full repos of several clusters into a single, dedicated FR-pair, we realize that
1. Only one pair of CLUSSDR-CLUSRCVR is needed on each of the two FRs. which are shared across all clusters through the use of a namelist.
2. On each partial repo, only one manually defined CLUSSDR to one of the 2 FRs and one CLUSRCVR are needed, shared among clusters it is a PR of, through a corresponding cluster namelist.
I do not see such a simplified configuration can cause any confusion or difficulty in operation / administration. For cluster communications between PRs, each automatically created CLUSSDR channel uses a unique cluster xmitQ, suffixed with the destination qmgrname.
As a result, in case of trouble-shooting, message traffic between PRs are clearly separated.
To put it in more concrete terms, let's say we have 5 clusters, CLSTR_1 ~ CLSTR_5, sharing two FRs FR1 and FR2, with manually defined channel pair between them: TO.FR1 and TO.FR2. There are 9 PRs, PR1 ~ PR9, each has one manually defined CLUSSDR TO.FR1 and a manually defined CLUSRCVR TO.PRx.
Let qmgr PR7 be a member of 3 clusters, CLST_1, 3, 5. qmgr PR9 a member of clusters CLST_2, 3, 4. as a result, there is an automatically generated CLUSSDR channel on PR7 TO.PR9, with xmitQ SYSTEM.CLUSTER.TRANSMIT.TO.PR9 for cluster traffic in CLST_3.
This seems to be a clear-cut configuration.
I would like to know if there is any hidden pitfall I have not recognized, which might be a reason behind the best practice recommendation.
thanks a lot for any input. |
|
| Back to top |
|
 |
| hughson |
| Posted: Fri Jun 03, 2022 7:49 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
In my blog post: Naming Convention for MQ objects I say the following about naming cluster channels:-
| MQGem Blog Post wrote: |
| It is best practice to only ever use one cluster per channel name (avoiding the CLUSNL keyword on channels completely). This allows channels to be controlled independently for different clusters, thus ensuring that there is no reliance, or impact shared by clusters just because of a common channel. This best practice allows you to then add the cluster keyword to the channel name which means you have immediate awareness of which cluster is impacted when you see a channel having connectivity issues for example. |
T.Robs' excellent Stack Overflow answer on the same subject says the following about naming cluster channels:-
| T.Rob on StackOverflow wrote: |
| Use names like CLUSNAME.QMNAME. The old wisdom said to use names like TO.QMNAME but if you ever implement overlapping clusters this causes the same channel to be used for multiple clusters. That's bad because you can then never perform maintenance on one cluster without impacting the other. Using CLUSNAME.QMNAME insures that every QMgr has a dedicated CLUSRCVR channel for each cluster in which it participates. |
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| bfzhou |
| Posted: Mon Jun 13, 2022 6:59 am Post subject: |
|
|
Apprentice
Joined: 07 Aug 2003
Posts: 38
Location: Springfield, VA
|
Thank you Morag for sharing the blog posts. That makes avoid sharing of CLUSRCVR channels on partial repository qmgrs a meaningful practice.
For CLUSSDR channels to the two full repository qmgrs, since it is always in an one-to-one relationship, at least from the PR end, it seems to make real sense to share a single CLUSRCVR channel on the FR qmgrs for all clusters - troubleshooting always starts from the sending end.
On PRs, I defined one CLUSRCVR channel for each cluster in the pattern of <TO.QMGR>.<cluster_specifier>.
This seems to be an optimal compromise between simplicity and operational efficiency. I modified our consolidated overlapping clusters in the above manner as an experiment. Will observe for a while to see if any complaint comes up during operational support / trouble-shooting.
Will report back!
thanks much!
Last edited by bfzhou on Wed Jun 15, 2022 11:39 am; edited 1 time in total |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jun 13, 2022 5:49 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| bfzhou wrote: |
| ... it seems to make real sense to share a single CLUSRCVR channel on the FR qmgrs for all clusters ... |
This will work, but from a support / maintenance / troubleshooting / comprehension point of view, our FR qmgrs have separately defined CLUSRCVR for every cluster.
_________________
Glenn |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 13, 2022 6:46 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Creating a CLUSRCVR channel is a one time task that takes only a minute, that serves the lifetime of the cluster. Do yourself a favor - one CLUSRRCVR channel per cluster.
I hope the hesitance isn't due to you having a massive amount of overlapping clusters constantly being added and removed.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| pcelari |
| Posted: Tue Sep 06, 2022 5:59 am Post subject: |
|
|
Chevalier
Joined: 31 Mar 2006
Posts: 411
Location: New York
|
| PeterPotkay wrote: |
| Creating a CLUSRCVR channel is a one time task that takes only a minute, that serves the lifetime of the cluster. Do yourself a favor - one CLUSRRCVR channel per cluster. .... |
You turn out to be absolutely correct. It proves to be a bad idea to consolidate the cluster channels I thought out earlier - had to de-consolidate due to lack of flexibility brought about by that approach. 
_________________
pcelari
-----------------------------------------
- a master of always being a newbie |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
