| Author |
Message
|
| leo> |
 Posted: Mon Apr 18, 2011 12:08 pm Post subject: multiple cluster sender channels |
 |
|
Apprentice
Joined: 06 Oct 2004
Posts: 42
|
Hi all,
We have a cluster setup with 2 FRs and 5 PRs. All the PRs connect to the same FR. By using the same FR, have we created a single point of failure, what will happen if the FR that all the PRs connect to becomes unavailable?
From clustering manual and the previous posts, I read that PRs should connect to ONE and only one FR. I am trying to figure out what will happen if I connect a PR to more than 1 FR by defining multiple CLUSSDR channels? Any help or pointers to documentation is appreciated.
Thanks
_________________
IBM Certified System Administrator - Websphere MQ V5.3 |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Apr 18, 2011 12:14 pm Post subject: Re: multiple cluster sender channels |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| leo> wrote: |
Hi all,
We have a cluster setup with 2 FRs and 5 PRs. All the PRs connect to the same FR. By using the same FR, have we created a single point of failure, what will happen if the FR that all the PRs connect to becomes unavailable?
From clustering manual and the previous posts, I read that PRs should connect to ONE and only one FR. I am trying to figure out what will happen if I connect a PR to more than 1 FR by defining multiple CLUSSDR channels? Any help or pointers to documentation is appreciated.
Thanks |
So you followed the documentation and created a single cluster sender.
And you wonder what happens when that one is unavailable.
Have you tried to see what happens? Have you made the FR unavailable?
What did you observe?
Experiment some 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 18, 2011 12:16 pm Post subject: Re: multiple cluster sender channels |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| leo> wrote: |
| We have a cluster setup with 2 FRs and 5 PRs. All the PRs connect to the same FR. By using the same FR, have we created a single point of failure, what will happen if the FR that all the PRs connect to becomes unavailable? |
They'll get the cluster updates from the automatically defined channels that link them to the other FR.
If both FRs go down you'll be unable to alter the cluster configuration though data will continue to flow through the cluster as normal until the timeout period (90 days???) expires. After that any route which has not been used at all in that period will be deleted by the PR. If something tries to use it after that & both FRs are still unavailable then you'll get a cluster resolution error.
But if both FRs are down for 90 days straight you've probably got larger issues. 
| leo> wrote: |
| I am trying to figure out what will happen if I connect a PR to more than 1 FR by defining multiple CLUSSDR channels? |
You'll create a lot of unnecessary work for yourself.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Apr 18, 2011 12:29 pm Post subject: Re: multiple cluster sender channels |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| leo> wrote: |
| I am trying to figure out what will happen if I connect a PR to more than 1 FR by defining multiple CLUSSDR channels? |
One of the benefits of clusters is fewer channels to define.
There is no benefit to having multiple CLUSSDR channels to multiple FRs. If an FR fails, cluster software will create the appropriate clussdr channel the other FR, and it will take over for the failed FR.
_________________
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 |
|
|
| mqjeff |
| Posted: Mon Apr 18, 2011 2:40 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are some advantages to having manually defined clussdr channels to both FRs in terms of availability and stability.
And it doesn't really hurt anything to do so. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 18, 2011 4:57 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| and it doesn't really hurt anything to do so. |
Unnecessary, but harmless.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Apr 19, 2011 2:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqjeff wrote: |
| and it doesn't really hurt anything to do so. |
Unnecessary, but harmless. |
Not *completely* unnecessary, but otherwise harmless. And a small matter if you're properly building your cluster from a script. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Apr 19, 2011 3:39 am Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqjeff wrote: |
| And it doesn't really hurt anything to do so. |
I disagree, just a little. Say you have 100 PRs, all configured like that. One downside is that, if you need to move one of your FRs, you are bound to have to go to all of your PRs and change the definitions shortly after the move. If instead you link each PR to only one FR, you have the potential for halving the number of FRs you need to update.
Given that it isn't needed to have 2 manual CLUSSDRs, I'd say don't do it. IMHO. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Apr 19, 2011 4:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mvic wrote: |
| mqjeff wrote: |
| And it doesn't really hurt anything to do so. |
I disagree, just a little. Say you have 100 PRs, all configured like that. One downside is that, if you need to move one of your FRs, you are bound to have to go to all of your PRs and change the definitions shortly after the move. If instead you link each PR to only one FR, you have the potential for halving the number of FRs you need to update.
Given that it isn't needed to have 2 manual CLUSSDRs, I'd say don't do it. IMHO. |
Right, so, by taking one approach you are ensured that you will always need to run a script on every qmgr in the cluster.
By taking another approach, you have to analyze your entire network and decide which sets of qmgrs that you need to run a script on.
And in the first approach, you are more resilient to unexpected long outages from a single FR. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 19, 2011 4:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
| And in the first approach, you are more resilient to unexpected long outages from a single FR. |
Given that clustering software in a PR (that has lost its FR) will automatically create a clussdr channel to the remaining FR - if one is available - from where does the enhanced resilience arise?
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Apr 19, 2011 4:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| mqjeff wrote: |
| And in the first approach, you are more resilient to unexpected long outages from a single FR. |
Given that clustering software in a PR (that has lost its FR) will automatically create a clussdr channel to the remaining FR - if one is available - from where does the enhanced resilience arise? |
I have forgotten the advantages of having both FRs with manually defined channels - there are some and it is mostly in edge cases.
It may not be with resiliency in case of failure, it may have to do with avoiding synchronization issues. |
|
| Back to top |
|
|
| John89011 |
| Posted: Sat Apr 23, 2011 6:43 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Apr 23, 2011 7:11 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The exact quote is "...full repositories republish the publications they receive through the manually-defined CLUSSDR channels...".
But, it makes no reference to use of a 2nd or 3rd or 4th explicitly defined clussdr channel. It offers no definitive answer to the OP - as to whether, if, and under what circumstances - a 2nd or 3rd or 4th explicitly defined clussdr will be used.
_________________
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 |
|
|
|
|
