| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| HA/round-robin question... |
« View previous topic :: View next topic » |
| Author |
Message
|
| John89011 |
 Posted: Wed Mar 10, 2010 11:45 pm Post subject: HA/round-robin question... |
 |
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
Hitting a braing freeze lately so I have a couple of questions so just bare with me please...
Lets's say I have 3 QMs on 3 different servers for the same application (EAST, WEST, NORTH) and name the cluster ABC_CL)
So.. I make EAST and WEST FRs and interconnect the QMs
I first define sender channels manually
ON EAST:
TO.ABC_CL.WEST
TO.ABC_CL.NORTH
ON WEST
TO.ABC_CL.EAST
TO.ABC_CL.NORTH
ON NORTH
TO.ABC_CL.EAST
TO.ABC_CL. WEST
then receivers...
ON EAST
TO.ABC_CL.EAST
ON WEST
TO.ABC_CL.WEST
ON NORTH
TO.ABC_CL.NORTH
Now I have created a 4th QM on a different server let's say SOUTH who will be joining the cluster and will be sending messages to EAST, WEST, NORTH in a round-robin fashion..
I first create a receiver on SOUTH(TO.ABC_CL.SOUTH) and then the sender TO.ABC_CL.EAST
So now EAST and WEST auto define sender channels to SOUTH but NORTH does not. why is that? because NORTH is a PR?
I was hoping that NORTH will also auto define a sender but that was not the case. I had to first define a sender on SOUTH TO.ABC_CL.MTASNORTH for NORTH to then auto define a sender back to SOUTH.
Question number two...
If I want a 5th QM on a 5th server to talk to EAST,WEST,NORTH but via a new cluster (DEF_CL), do I need to/should interconnect EASt,WEST,NORTH again with a new set of channels TO.DEF_CL.EAST,WEST,NORTH etc.. or will the REPOS info be passed via the ABC_CL channels if I just define a repos nl for the FRs to use?
Question number three...
Back to the first setup.. should I interconnect EAST, WEST, NORTH via a seperate channels/cluster (123_CL) so that they don't interfer with SOUTH QM and ABC_CL and have a reposnl(123_CL,ABC_CL,DEF_CL)?
something like this...
EAST
TO.WEST
TO NORTH
TO.EAST(receiver)
WEST
TO.EAST
TO.NORTH
TO WEST(receiver)
NORTH
TO.EAST
TO.WEST
TO.NORTH(receiver)
Thanks! |
|
| Back to top |
|
 |
| exerk |
| Posted: Thu Mar 11, 2010 12:24 am Post subject: Re: HA/round-robin question... |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| John89011 wrote: |
Hitting a braing freeze lately so I have a couple of questions so just bare with me please...
Lets's say I have 3 QMs on 3 different servers for the same application (EAST, WEST, NORTH) and name the cluster ABC_CL)
So.. I make EAST and WEST FRs and interconnect the QMs
I first define sender channels manually
ON EAST:
TO.ABC_CL.WEST
TO.ABC_CL.NORTH
ON WEST
TO.ABC_CL.EAST
TO.ABC_CL.NORTH |
Why did you define CLUSSDR's from FR's to a PR? Explicit CLUSSDR's should only ever be defined to FR's - Re-read the Clustering manual...
| John89011 wrote: |
ON NORTH
TO.ABC_CL.EAST
TO.ABC_CL. WEST |
You define a CLUSSDR to one, and one only, of the FR's of the cluster you are joining the PR to...
| John89011 wrote: |
then receivers...
ON EAST
TO.ABC_CL.EAST
ON WEST
TO.ABC_CL.WEST
ON NORTH
TO.ABC_CL.NORTH |
Correct...
| John89011 wrote: |
Now I have created a 4th QM on a different server let's say SOUTH who will be joining the cluster and will be sending messages to EAST, WEST, NORTH in a round-robin fashion..
I first create a receiver on SOUTH(TO.ABC_CL.SOUTH) and then the sender TO.ABC_CL.EAST
So now EAST and WEST auto define sender channels to SOUTH but NORTH does not. why is that? because NORTH is a PR? |
Correct...
| John89011 wrote: |
| I was hoping that NORTH will also auto define a sender but that was not the case. |
No need to hope, it will but only when it needs to...
| John89011 wrote: |
| I had to first define a sender on SOUTH TO.ABC_CL.MTASNORTH for NORTH to then auto define a sender back to SOUTH. |
No you didn't have to define it (see the previous statement)...
| John89011 wrote: |
Question number two...
If I want a 5th QM on a 5th server to talk to EAST,WEST,NORTH but via a new cluster (DEF_CL), do I need to/should interconnect EASt,WEST,NORTH again with a new set of channels TO.DEF_CL.EAST,WEST,NORTH etc.. or will the REPOS info be passed via the ABC_CL channels if I just define a repos nl for the FRs to use? |
You are totally confused. Please re-read the Clustering manual, especially the part about overlapping clusters...
| John89011 wrote: |
Question number three...
Back to the first setup.. should I interconnect EAST, WEST, NORTH via a seperate channels/cluster (123_CL) so that they don't interfer with SOUTH QM and ABC_CL and have a reposnl(123_CL,ABC_CL,DEF_CL)? |
You've just partially answered your previous question (see previous comment)...
| John89011 wrote: |
something like this...
EAST
TO.WEST
TO NORTH
TO.EAST(receiver)
WEST
TO.EAST
TO.NORTH
TO WEST(receiver)
NORTH
TO.EAST
TO.WEST
TO.NORTH(receiver)
Thanks! |
Again, re-read the clustering manual. Best advice I can give so far is:
1. Scrap what you have done to date, and start again with N, W and E in a simple cluster, then add S - properly.
2. Create an overlapping cluster by applying the knowledge gained from 1. and the Clustering manual.
What I normally tell tyro's about clustering is:
"FR's know all about the cluster, all of the time. PR's know what they need to know about the cluster when they need to know it, but then remember it".
Of course it's a lot more complex than that, but it is a good starting point.
_________________
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 |
|
|
| fjb_saper |
| Posted: Thu Mar 11, 2010 6:44 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
  The cluster manual is your friend. Please do read it 
I noticed that you started your subject with HA.
Please be aware that MQ clustering has nothing to do with HA and is mainly for load distribution 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| John89011 |
| Posted: Fri Mar 12, 2010 5:32 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
I know it's not a "real" HA solution I am planning to implement clustering with all the 15-20 apps we interface with among our three prod servers in three different DC locations. Presently if one of our servers fails or there's some kind of issue and traffic needs to be migrated, I have to notify each of these apps and have them re-point to the available QMs and that's quite a messy and long process, especially when we're talking about production. So, with clustering if one of the QMs fails the other two will pick up the load without manual intervention unless the issue is on the app side and I am looking for load balancing as well. I will pay a visit back to the cluster manual again and scrap the current setup I've created.
I appreciate your guys' input and advice! |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 12, 2010 6:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| John89011 wrote: |
| So, with clustering if one of the QMs fails the other two will pick up the load without manual intervention |
Yes, with some caveats and qualifications. Be sure the client / business understands these, and the possible outcomes before you actually have a problem and they bite you. Then draw a really big diagram and make sure they get it.
I've just dealt with a client that used a WMQ Cluster for failover. They just lost a truckful of money because a lot of important messages didn't get processed. We have a signed piece of paper covering the sensitive parts of our bodies, I've been forbidden to send any emails including the phrase "told you" or any variation of it, and the guy who signed the paper client side is looking as sick as the proverbial parrot.
My 2 cents.
| John89011 wrote: |
| I will pay a visit back to the cluster manual again and scrap the current setup I've created. |
Solid plan. It's a mess and starting again will be much quicker than fixing it. But do not despair and do not give in.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| zonko |
| Posted: Sun Mar 14, 2010 11:00 pm Post subject: |
|
|
Voyager
Joined: 04 Nov 2009
Posts: 78
|
| Quote: |
| with clustering if one of the QMs fails the other two will pick up the load without manual intervention |
It is quite easy for msgs to be pinned to a particular qmgr in the cluster if a cluster channel fails before the end of the batch. The channel attribute BATCHHB is very useful to prevent this happening. |
|
| Back to top |
|
|
| John89011 |
| Posted: Mon Mar 15, 2010 11:04 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
Ok browsed the Manual and started from scratch and it's looking good so far..
Created 3 QMS A,B,C with cluster ABC_CL
made A & B FRs
1. created manual sender channels among A and B
2. created manual receiver channels among A and B
3. created receiver for C and a sender to a FR
all 3 QMS are now interconnected
this is where I still get confused with overlaping..
Introduced D QM to QM A,B,C and created a new cluster ABCD_CL by doing the following:
1. created manual sender channels among A and B
2. created manual receiver channels among A and B
3. created receiver for C and a sender to a FR
4. altered the REPOSNL(ABC_CL,ABCD_CL)
5. created a receiver/sender for D to a FR
All QMs are now connected except D and C
Exerk I now understand your comment "No need to hope, it will but only when it needs to..." after creating queues and started sending messages across, channels were auto defined betweek D and C.
Long story short, I introduced 15 more QMs and created seperate clusters for each QM to A,B,C
So my question still... am I on the right track by interconnecting A,B,C QMs for every new cluster I create or should I be using 1 set of channels and create a NL? If I am reading the cluster manual correctly it states to use a NL.
I tried using a NL and it just auto defined channels to all the clusters listed in NL(as it should) but I'd like to restrict visibilty among the 15 QMs to A,B,C
I believe by sharing channels among clusters by using a NL can make it more difficult dealing with problems.
For example, if I needed to take A out of cluster ABCD_CL temporarily, I would have to change the cluster parameter on both the cluster sender and cluster receiver channels from the namelist to ABC_CL. But those channels will still exist, so if another queue manager starts up the channel, A will respond. But if I have a separate set of channels for each cluster, I can simply stop the ABCD_CL channels. Am I making any sense?
Thanks for your help as always! |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Mar 16, 2010 12:17 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| John89011 wrote: |
Ok browsed the Manual and started from scratch and it's looking good so far..
Created 3 QMS A,B,C with cluster ABC_CL
made A & B FRs
1. created manual sender channels among A and B
2. created manual receiver channels among A and B
3. created receiver for C and a sender to a FR
all 3 QMS are now interconnected |
Excellent!
| John89011 wrote: |
| this is where I still get confused with overlaping.. |
Don't worry, you're in good company 
| John89011 wrote: |
Introduced D QM to QM A,B,C and created a new cluster ABCD_CL by doing the following:
1. created manual sender channels among A and B
2. created manual receiver channels among A and B
3. created receiver for C and a sender to a FR
4. altered the REPOSNL(ABC_CL,ABCD_CL)
5. created a receiver/sender for D to a FR
All QMs are now connected except D and C |
Presumably achieving what you wanted?
| John89011 wrote: |
| Exerk I now understand your comment "No need to hope, it will but only when it needs to..." after creating queues and started sending messages across, channels were auto defined betweek D and C. |
You are now discovering the black art of clustering 
| John89011 wrote: |
| Long story short, I introduced 15 more QMs and created seperate clusters for each QM to A,B,C |
Not a good idea...I worked at one site where they did this, thinking that they were separating their applications by cluster, and it was a mess. Better to create one cluster per usage, e.g. a 'retail' cluster and 'wholesale' cluster, and put in application-authorised QA's to reference cluster queues.
| John89011 wrote: |
| ...should I be using 1 set of channels and create a NL? If I am reading the cluster manual correctly it states to use a NL. |
At the rate you are adding queue managers you'll run out of entries in the namelist, and my preference (note the stress on my) is to use discrete channels per cluster, but it is also my preference to minimise the number of clusters. Slightly modifying my earlier post, namelists should be used for queues and queue managers which host multiple Full Repositories, never for channels (again I stress it is only my preference).
| John89011 wrote: |
| I tried using a NL and it just auto defined channels to all the clusters listed in NL(as it should) but I'd like to restrict visibilty among the 15 QMs to A,B,C |
As you found, working as advertised.
| John89011 wrote: |
| I believe by sharing channels among clusters by using a NL can make it more difficult dealing with problems. |
Good, you've learned this early - a lot of people only find out once they've implemented and are committed to it.
| John89011 wrote: |
| For example, if I needed to take A out of cluster ABCD_CL temporarily, I would have to change the cluster parameter on both the cluster sender and cluster receiver channels from the namelist to ABC_CL. But those channels will still exist, so if another queue manager starts up the channel, A will respond. |
Without a picture I'm not sure 
| John89011 wrote: |
| But if I have a separate set of channels for each cluster, I can simply stop the ABCD_CL channels. Am I making any sense? |
The joy of separate 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 |
|
|
| mqjeff |
| Posted: Tue Mar 16, 2010 3:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The other big issue people tend to run into with overlapping clusters is that they end up with fully overlapped clusters when they thought they were building a gateway setup.
Make a picture of the cluster set up that you want to achieve, paying close attention to what qmgrs you DO NOT WANT to talk to each other. And then make sure that when you build it, that this is true. Also make sure that objects have the visibility that you expect them to. I.e. that you're not seeing CLUSA queues from a qmgr that should only be in CLUSB. |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Mar 16, 2010 8:17 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
[quote="exerk"][quote="John89011"]Ok browsed the Manual and started from scratch and it's looking good so far..
| John89011 wrote: |
| Long story short, I introduced 15 more QMs and created seperate clusters for each QM to A,B,C |
Not a good idea...I worked at one site where they did this, thinking that they were separating their applications by cluster, and it was a mess. Better to create one cluster per usage, e.g. a 'retail' cluster and 'wholesale' cluster, and put in application-authorised QA's to reference cluster queues.
I was thinking of grouping them as both you and the manual suggest it but I can't find a logical way of doing it since all of these 15 apps do 15 totally different things. So I think I'll be stuborn and stay with my setup on this one  |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Mar 16, 2010 8:27 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| mqjeff wrote: |
The other big issue people tend to run into with overlapping clusters is that they end up with fully overlapped clusters when they thought they were building a gateway setup.
Make a picture of the cluster set up that you want to achieve, paying close attention to what qmgrs you DO NOT WANT to talk to each other. And then make sure that when you build it, that this is true. Also make sure that objects have the visibility that you expect them to. I.e. that you're not seeing CLUSA queues from a qmgr that should only be in CLUSB. |
Thanks Jeff! Yes, that's how I usually start, with a picture since it can get quite messy trying to understand it and not to mention trying to explain it to someone
My next step would be to test the heck out of it and break/fix things so that there are not any suprises when implementing it in Prod. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Mar 16, 2010 10:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
What is the business requirement that is leading you down this path of so many overlapping clusters?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Mar 16, 2010 10:38 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Honestly there really is none... I guess it's just my way of thinking, to me it seems a bit more organized and easier to administer. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Mar 17, 2010 12:05 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| John89011 wrote: |
| ...to me it seems a bit more organized and easier to administer... |
So did that other organisation I worked for; one day, one of my colleagues emailed me to tell me that he was in the process of putting a queue manager in its 48th cluster (which set the record. It's been nearly three years now, so I wonder if there is now a zero on the end of that number). The place was a mess, trying to keep a queue manager network diagram was impossible and because of it the occasional error such as defining explicit CLUSSDR's from an FR to a PR occurred - and they wondered why the repository process died on some queue managers.
_________________
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 |
|
|
| John89011 |
| Posted: Wed Mar 17, 2010 11:03 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
Ok, I'll take your advice... I am going to downsize it down to three clusters and see how it looks.. I'll report later on today...
Thanks for all your help guys! |
|
| 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
|
|
|
|
