| Author |
Message
|
| mqnomad |
 Posted: Mon May 03, 2010 11:39 am Post subject: MQ Client |
 |
|
Acolyte
Joined: 18 Mar 2010
Posts: 53
|
I hate to post this question because it's quite basic, but I am not really understanding how MQ clients help load balance, if they do. The more I look at manuals and old posts, the worse it gets.
Customer has two data centers (DC). Each DC has a WAS servers using MQ as a JMS provider, then each DC has another box each with a WMQ server - so WAS w/WMQ talks to WMQ box. Each DC WAS app talks to the specific WMQ manager. I am not 100% sure if the WAS boxes have a full WMQ, or just a WMQ client - but let's assume client for now.
Customer wants to change the WAS app so that if no message is coming back from "its" WMQ server, it can connect to the other DC's MQ. Both environments are identical. They want to do this programatically as a way of failover. I know, no comments - they had HA and long story did away with it.
My understanding of CCDT's is that they are generated by creating a client connection channel. These are created in the MQ server box and if necessary copied over to the client box.
So - if you have AMQCHCHL.TAB from two different queue managers -
1. do you move them to separate directories in the client box?
2. do they get concatenated (there is a big no no in my head here)
How exactly do the CCDT's help load balance?
So please be kind - I know how clueless this sounds ... |
|
| Back to top |
|
 |
| mqnomad |
| Posted: Mon May 03, 2010 11:46 am Post subject: |
|
|
Acolyte
Joined: 18 Mar 2010
Posts: 53
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon May 03, 2010 11:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You need to create one CCDT that has CLNTCONNs to both qmgrs in it.
You do not EVER hand-edit CCDTs.
There's no requirement that the qmgr that generates the CCDT know anything about the qmgrs involved other than having the definitions of the CLNTCONNS. |
|
| Back to top |
|
|
| mqnomad |
| Posted: Mon May 03, 2010 12:13 pm Post subject: |
|
|
Acolyte
Joined: 18 Mar 2010
Posts: 53
|
| Re editing CCDT - there is a support pack MO72 that is supposed to help if you need to change the order of the entries - assuming it's ok to use it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon May 03, 2010 12:45 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| My understanding of CCDT's is that they are generated by creating a client connection channel. These are created in the MQ server box and if necessary copied over to the client box. |
True. Many shops create a qmgr whose sole purpose is to generate client-channel tables.
| Quote: |
So - if you have AMQCHCHL.TAB from two different queue managers -
1. do you move them to separate directories in the client box? |
You can do this. Or you can give each client table a different name.
| Quote: |
| 2. do they get concatenated (there is a big no no in my head here) |
No.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Mon May 03, 2010 1:39 pm Post subject: Re: MQ Client |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqnomad wrote: |
...if no message is coming back from "its" WMQ server, ...
|
What does that mean?
| mqnomad wrote: |
How exactly do the CCDT's help load balance?
|
Version 7 MQ Clients using a client channel table can load balance against 2 or more Queue Managers, when the MQ Client issues a call to connect (or reconnect) to a Queue Manager.
Version 6 and older will pick the first available Queue Manager (based on specific and documented rules about which order it will try) from the table, but again, only when the app issue the call to connect (or reconnect) to a Queue Manager.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Tue May 04, 2010 12:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
There is another form of client load-balancing, whereby two or more MQ clients access the same queue(s) on the same queue manager (which can be HA'd).
If getting messages and processing the messages as they get them, the clients can all use the same queue and will automatically load balance over the clients (app servers). It's works very well and you don't get orphaned messages as you can with MQ clustering. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 04, 2010 3:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
With one caveat, zpat. If the q depth is consistently > 0, then yes, you will get load balancing as the clients all do an equal amount of work - everytime one ends its current message processing, it finds another message to satisfy its next MQGET.
But if the messages are arriving slower than the rate that 1 client can process them, you may find that at the end of the day MQ Client #1 did all the work, or 73.45% of the work, or 0% of the work. When MQ Clients are racing for the same message, there is no guarantee that the Queue Manager will dish them out in a load balanced fashion. Its still a good design and you know that each message will get processed immediatley, but the load will not be balanced across the multiple clients pulling from the single queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Tue May 04, 2010 4:21 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Ah, but the clients will get messages as fast as they can process them. So if one server is faster, it will do more work and get more messages.
This is exactly the desired behaviour and something that is very hard to arrange when load-balancing in a "push" mode, rather than a "pull" mode. MQGET with WAIT should be used to avoid inefficient "polling".
The important thing is that the clients handle the message in between the MQGETs rather than just moving it to a file or something like that. In the event that an app server fails, the others can just keep going.
When a client is busy it cannot issue MQGET, so less busy clients will get more messages. I believe that MQ will service multiple outstanding MQGET WAITs on the same queue in the order they were made, but it doesn't matter.
Using syncpoint on the MQGET is desirable so that if one app server fails during message processing, the message is made available again and another app server will pick it up.
This simple but powerful and scalable design has proved invaluable time and time again to me.
I have found it does load-balance over the clients (all things being equal) but the important thing is that it provides fault tolerance and that the queue is serviced at the maximum rate possible under high load. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 04, 2010 5:18 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
| I believe that MQ will service multiple outstanding MQGET WAITs on the same queue in the order they were made, but it doesn't matter. |
My expirience has been that this is not true and at the end of the day you may find one client did a lot more work and the other one got a lot of 2033s all day long, with only occasional successful gets.
When there are no messages on the queue and all the MQ Clients are sitting there with outstanding MQGET with Waits, there is no guarantee that the oldest MQGET will win - MQ makes no guarantee as to which one will get the message. This is always how I have known and did read something like this, but can't find the reference now. Perhaps its changed in MQ 7? Dunno, can't find any doc one way or the other. Maybe PMR time.
You're right, it doesn't matter if all you are concerned about is messages getting processed as fast as possible. That will happen. But if you have 3 MQ Clients that can each process a messge in 1 second and the messages arrive 1 every 10 seconds, you can't count on all 3 MQ Clients having done an equal amount of work at the end of the day.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| zpat |
| Posted: Tue May 04, 2010 6:05 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Sure, but load-balancing is usually a design to provide (a) maximum throughput under load, (b) fault tolerance, and (c) scalability by adding more app servers.
You only get 2033 if the get wait time expires or if no wait is used, my preference is a long get wait time (with a means to shutdown if needed).
The higher the load, the more even the distribution will be, but actual evenness is usually not a requirement (in my experience). |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue May 04, 2010 6:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Absolute load-balancing is seldom a requirement, or even desirable.
When I've seen this requirement implemented, throughput suffered when one of the hardware platforms was upgraded. Not surprisingly, the now potentially faster qmgr received its absolute share of the workload, but was under-utilized.
_________________
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 |
|
|
|
|
