Author |
Message
|
J.D |
Posted: Thu Jun 17, 2010 3:21 pm Post subject: Client connections load balancing |
|
|
Voyager
Joined: 18 Dec 2009 Posts: 92 Location: United States
|
We have 5000+ clients, 10 gateway servers and 6 backend servers. Both gateway and backend Servers are in same cluster. If v7.0.1 or later is used on clients and gaetway servers, is round robin load balancing possible if CCDT is used? We want to distribute load even across all the 10 gateway servers. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jun 17, 2010 4:50 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Even under v7, don't clients connect in the order given in the table? I accept that v7 offers auto reconnect but does it change original connection behavior?
So you could manually load balance (and presumably are) but I wasn't aware v7 offered anything in this area.
I wait to be corrected by someone with more exposure to v7 clients.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
exerk |
Posted: Thu Jun 17, 2010 5:06 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
New attributes (CLNTWGHT and AFFINITY) can be used to 'force' a client to connect to a particular server in preference to others, but of course that means multiple copies of the CCDT with different weightings etc. _________________ 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: Thu Jun 17, 2010 5:23 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
exerk wrote: |
New attributes (CLNTWGHT and AFFINITY) can be used to 'force' a client to connect to a particular server in preference to others, but of course that means multiple copies of the CCDT with different weightings etc. |
Well in the good old days (i.e. v6) you needed multiple CCDT to work this kind of situation so you're still ahead of the game. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
J.D |
Posted: Thu Jun 17, 2010 6:00 pm Post subject: |
|
|
Voyager
Joined: 18 Dec 2009 Posts: 92 Location: United States
|
Why multiple CCDT's? I guess we can create SVRCONN and CLNTCONN channels of 10 gateway qmgrs in one single gateway qmgr and pass that CCDT to developers. Correct me if i'm wrong. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Jun 17, 2010 7:06 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
One copy of an MQ 7 Client Channel Table can randomly distribute new connections.
Make the CLNTWGHT equal among all the entries in the table and > 0.
I don't think this behavior will equate to a round robin lad balance technically. But the more clients you have connecting more often, the more likely you are to appear to have a round robin load balance. Either way you can be assured that each client connection will find an available QM to connect to, unless all the QMs are unavailable for new connections at the same time. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
zpat |
Posted: Thu Jun 17, 2010 10:11 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Multiple CCDTs means creating several copies with the order of servers arranged differently and distributing these around the clients so that they each have one CCDT, but the order of servers varies depending which one (e.g. of 10 versions) they have. |
|
Back to top |
|
 |
shashivarungupta |
Posted: Thu Jun 17, 2010 11:30 pm Post subject: |
|
|
 Grand Master
Joined: 24 Feb 2009 Posts: 1343 Location: Floating in space on a round rock.
|
J.D wrote: |
Why multiple CCDT's? I guess we can create SVRCONN and CLNTCONN channels of 10 gateway qmgrs in one single gateway qmgr and pass that CCDT to developers. Correct me if i'm wrong. |
Yes , we can do so and in one CCDT you can mention multiple entries for the connection over the diff. servers. There was one *Catch when you define a CCDT i.e. entries with the same name of the channels would not be updated/only the last entry would be updated (if the channels name is same).
But I haven't yet checked this in mqv7.
And I agree with Vitor that this is interesting post/topic.  _________________ *Life will beat you down, you need to decide to fight back or leave it. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Jun 18, 2010 3:37 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
zpat, as of MQ 7 I don't think there is a need for multiple copies. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
zpat |
Posted: Fri Jun 18, 2010 5:47 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Yes, so I gathered from the earlier debate. Personally I have never used them, but provided one highly available queue manager (ideally a mainframe). |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Jun 18, 2010 5:53 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
We want to distribute load even across all the 10 gateway servers. |
This is a technical solution. What is the business requirement that drives the technical solution? You may want to revisit this requirement. (There is a recent post that had a similar objective.)
As written, I'm presuming that all 10 gateway servers are configured exactly the same, that they will always be configured exactly the same, that they process the exact same workload(s), and that you/your organization is not satisfied with the default load distribution behavior.
What symptom(s) or problem(s) does this requirement address? _________________ 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 |
|
 |
|