| Author |
Message
|
| Sam Uppu |
 Posted: Fri Feb 06, 2009 1:13 pm Post subject: Can a QMgr, FR for 1 Cluster and a PR for other cluster? |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Here is our environment and design planning to implement: I need your thoughts and best approach to accomplish this.
MQ version 6 and SunOS.
We have 2 QMgrs, QM1 & QM2 in a cluster called CLUS1 and both QM1 & QM2 are full repository for the cluster CLUS1.
There is another cluster called CLUS2 in which there are 3 QMgrs, QM3, QM4 & QM5.
QM3, QM4 are full repositories for the second cluster CLUS2.
Now, the QMgrs QM1 & QM2 in first cluster(CLUS1) need to talk to QMgrs, QM3 & QM4 in second cluster(CLUS2).
Question:
As QM3 & QM4 are already full repositories for CLUS2, is that OK for QM3 & QM4 to participate in CLUS1 as PRs?. Will there be any performance issues?. Any better approach?.
Thanks. |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Feb 06, 2009 2:52 pm Post subject: Re: Can a QMgr, FR for 1 Cluster and a PR for other cluster? |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Sam Uppu wrote: |
Question:
As QM3 & QM4 are already full repositories for CLUS2, is that OK for QM3 & QM4 to participate in CLUS1 as PRs?. Will there be any performance issues?. Any better approach? |
Yes to the first part, no to the second part, and depends on what your requirements are for the third part. Is there an absolute necessity to maintain two separate clusters, or can they be combined?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat Feb 07, 2009 3:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You'll need to keep one eye on topology if the purpose of this is to segrigate the 2 clusters, but it's not a serious issue.
Is there a better way? It depends (as my associate points out) exactly what you're trying to achieve.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Feb 07, 2009 9:00 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Two qmgr attributes are involved in FR vs. PR: repos( ) and reposnl( ).
Repos( ) indicates that this qmgr is a FR for the cluster named in the parentheses). Reposnl ( ) names the clusters that this qmgr will be an FR.
Additionally, object definitions have similar attributes that defines to which clusters, if any, the object will be known.
So, yes, a qmgr can be an FR and a PR.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Feb 09, 2009 6:59 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| bruce2359 wrote: |
Two qmgr attributes are involved in FR vs. PR: repos( ) and reposnl( ).
Repos( ) indicates that this qmgr is a FR for the cluster named in the parentheses). Reposnl ( ) names the clusters that this qmgr will be an FR.
Additionally, object definitions have similar attributes that defines to which clusters, if any, the object will be known.
So, yes, a qmgr can be an FR and a PR. |
Thanks everyone for your valuable suggestions.
One more thing to clarify:
For the QMgrs, QM3 & QM4, I want to use a single receiver channel with the CLUSNL attribute. If we define a single receiver channel for both the clusters, does this affect any of the cluster performance wise or any other reason?.
I will create a Namelist with 2 clusters and provide it in the CLUSNL of receiver channel.
I know it is advisable to use two seperate receiver channels for each cluster, CLUS1 & CLUS2.
We are following a naming standard for our channels what we define. If we define two receiver channels, then we have to name the receiver channels with 2 different names which we need to think of. If there is no impact of using single receiver channel for both QM3 and QM4 by using CLUSNL, we no need to think of new naming standard.
Please let me know the negative sides of using single receiver channel for the QMgrs, QM3 & QM4 which involves in both the clusters, CLUS1 & CLUS2. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Feb 09, 2009 7:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
As regards a naming standard, what is wrong with: TO.QM1.CLUS1 and TO.QM1.CLUS2 - just as an example.
I have seen, first hand, the problems that can be encountered by namelisting cluster channels 
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 09, 2009 7:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| As regards a naming standard, what is wrong with: TO.QM1.CLUS1 and TO.QM1.CLUS2 - just as an example. |
There's a reason IBM use this naming convention in the Cluster manual.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Feb 09, 2009 7:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Vitor wrote: |
| exerk wrote: |
| As regards a naming standard, what is wrong with: TO.QM1.CLUS1 and TO.QM1.CLUS2 - just as an example. |
There's a reason IBM use this naming convention in the Cluster manual. |
Just for a change, I didn't just want to quote the manual at him  - I must be mellowing!
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 09, 2009 7:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| Just for a change, I didn't just want to quote the manual at him |
This from someone with a picture of the infocenter link as a signature. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Feb 09, 2009 8:42 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| exerk wrote: |
As regards a naming standard, what is wrong with: TO.QM1.CLUS1 and TO.QM1.CLUS2 - just as an example.
I have seen, first hand, the problems that can be encountered by namelisting cluster channels |
Can you elaborate a little bit on the problems which we or you encoutered by using namelist in the chanel?. That would help me my management to push towards defining 2 seperate receiver channels.
I dont see anywhere mentioned in the IBM document regarding problems in using namelist.
thanks. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Feb 09, 2009 8:49 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Have a look at the 01/2009 challenge question, there is a great example of something that started off small, which snowballed into a nightmare.
As far as my safe working practices go, I only ever namelist queues or FR's - unless the customer insists of course. Separate cluster channels makes for ease of maintenance, fault finding, and sleep-filled nights.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
