| Author |
Message
|
| mq_pm |
 Posted: Mon Oct 18, 2004 10:06 am Post subject: regarding workload balancing |
 |
|
Centurion
Joined: 27 Aug 2003
Posts: 132
|
Hi,
I have a scenario like this:
2 QMs, QM1 and QM2 with full repositories on two servers. Each server has broker installed with same configuration and same message flow and set. These are in cluster. There is a one more QM3 which is a part of this cluster.
Now the situation is when QM3 puts a message to a cluster queue X which is defined on both server QMs from which the broker message flow picks it up and process it. But when one broker is down say server1 broker, when QM3 puts a message one after the other, to X queue, then it distributes the message to both queues X defined on servers doing work load balancing. But since one broker is down, the message stays on that queue X of QM1 and when message arrives to queue of QM2, it processes it since it is up. So how can i make the all the messages to be processed even though one broker is down. Otherwise having 2 brokers for failover or workload balancing is of no use....Any suggestions please.
Thanks. |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Oct 18, 2004 10:56 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| MQ clustering does not help failover scenarios. It is used for work load balancing. You can achieve this using a hardware failover like HACMP Veritas or Service Gaurd etc. |
|
| Back to top |
|
|
| kirani |
| Posted: Mon Oct 18, 2004 1:41 pm Post subject: |
|
|
Jedi Knight
Joined: 05 Sep 2001
Posts: 3779
Location: Torrance, CA, USA
|
Or write a Cluster workload exit to route messages to Active Broker's queue manager.
_________________
Kiran
IBM Cert. Solution Designer & System Administrator - WBIMB V5
IBM Cert. Solutions Expert - WMQI
IBM Cert. Specialist - WMQI, MQSeries
IBM Cert. Developer - MQSeries
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 18, 2004 2:21 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Or write a script that gets fired when the broker shuts down, that also shuts down the queue manager - or otherwise disables it from the cluster.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Oct 21, 2004 12:34 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
When a CLUSSDR channel stops, if there are any msgs remaining on the cluster xmitq for the channel the msgs are all read and put through the workload balancing algorithm. However, all other things being equal, a channel status of RUNNING is the same, as far as workload balancing is concerned, as INACTIVE, and so the msgs will still be distributed to the inactive qmgr.
You can change this by:
Altering the channel status to STOPPED; this has a lower priority than RUNNING and so the msgs will be rerouted to the RUNNING qmgr
Suspending the inactive qmgr, so that the msgs will be routed to the qmgr joined to the cluster
You can do this after the qmgr has stopped; take whichever action you choose to lower the priority of the inactive qmgr, and then start the CLUSSDR channel. The channel will not start, but in ending and going to RETRYING it will reroute the msgs on the cluster xmitq. RERYING also has a lower priority than RUNNING. After the msgs have been rerouted you can stop the channel again. |
|
| Back to top |
|
|
| mverh |
| Posted: Thu Oct 21, 2004 7:00 am Post subject: |
|
|
Voyager
Joined: 06 Mar 2002
Posts: 97
|
| Quote: |
You can change this by:
Altering the channel status to STOPPED; this has a lower priority than RUNNING and so the msgs will be rerouted to the RUNNING qmgr
Suspending the inactive qmgr, so that the msgs will be routed to the qmgr joined to the cluster
|
Suspending the inactive qmgr will not necessarily result in messages no longer being routed to it. I too thought this would work but my testing proved otherwise. Never really figured out why you would want to issue a suspend, if not this exact reason. In any case stopping the clussdr will work. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Oct 21, 2004 7:51 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
There are several posts on this forum, including one by me, which gives the exact critieria for which qmgr is selected by the workload balancing algorithm.
Suspending a qmgr will not stop a msg going to it if no other destination with a higher priority is available. |
|
| Back to top |
|
|
| mq_pm |
| Posted: Mon Oct 25, 2004 6:29 am Post subject: |
|
|
Centurion
Joined: 27 Aug 2003
Posts: 132
|
Hi,
As I mentioned the scenario of the environment above, I do have a doubt. Since the queue is a cluster defined on both cluster qmgrs, if in the flow, in the output node if I mention only the queue and no Qmgr name, then the message is processed by the active broker. Is there any other way I can do this because we need to mention the Qmgr name and queue name in the flow for the message to go.
I hope my question is clear.
Thanks. |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Oct 25, 2004 7:19 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
There is no way that MQ knows whether the broker is running or not.
Your question is not clear. Because you say:
| Quote: |
| Since the queue is a cluster defined on both cluster qmgrs, if in the flow, in the output node if I mention only the queue and no Qmgr name, then the message is processed by the active broker. |
A message that is put in the queue defined on the output node is not usually processed by broker. That's the node(queue) where the broker puts the message. |
|
| Back to top |
|
|
|
|
