| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster Concept |
« View previous topic :: View next topic » |
| Author |
Message
|
| paul52 |
 Posted: Fri Aug 02, 2002 6:54 pm Post subject: Cluster Concept |
 |
|
Novice
Joined: 01 Jul 2002
Posts: 22
|
Hello Everyone
I am trying understand the cluster concept in Load balancing. Would you please let me know if my thinking regarding cluster load balancing is correct. In next week, I need to do the cluster load balancing DEMO and trying to find the good example. I have four cluster queue manager & the following queues.
1. Cluster QM Name (QM1), Hosted cluster Q(CL-01, CL-02, CL_03)
2. Cluster QM Name (QM2), Hosted cluster Q (CL_02, CL_03, CL_04)
3.Cluster QM Name (QM3), Hosted cluster Q (CL_03, CL_04, CL_05)
4. Cluster QM Name (QM4), Hosted cluster Q (CL_01, CL_03, CL_04)
Scenario:
1.If a program A connected to QM1, Issue MQPUT call to Cluster Queue CL_01.Firt the message will go to cluster queue CL_01 (Which is also local queue to QM1). So the program B MUST connect to QM1 to issue MQGET.
2.If CL_01 is not available in QM1 (QM1 crashed) , QM4 will automatically take over because QM4 has the same instance of CL-01. It will issue MQGET from cluster queue CL_01 as usual
3.In a situation where cluster queue CL_01 hosted by QM1 is overloaded by messages , The message will also be handled by CL_01 hosted by QM4 in round robin fashion. ( IS THIS TRUE, IF NOT HOW THE LOAD BALANCING handled)
Thanks you very much
...paul |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Fri Aug 02, 2002 7:42 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
1.
| Quote: |
| 1.If a program A connected to QM1, Issue MQPUT call to Cluster Queue CL_01.Firt the message will go to cluster queue CL_01 (Which is also local queue to QM1). So the program B MUST connect to QM1 to issue MQGET. |
Correct.
2.
| Quote: |
| .If CL_01 is not available in QM1 (QM1 crashed) , QM4 will automatically take over because QM4 has the same instance of CL-01. |
Correct (assuming the app reconnects to another QM that knows about CL_01).
| Quote: |
| It will issue MQGET from cluster queue CL_01 as usual |
Who is "it"? If you mean an app, then in this case it must be an app connected to QM4.
3.
| Quote: |
| In a situation where cluster queue CL_01 hosted by QM1 is overloaded by messages , The message will also be handled by CL_01 hosted by QM4 in round robin fashion. ( IS THIS TRUE, IF NOT HOW THE LOAD BALANCING handled) |
If an app is connected to QM1 and puts to CL_01, MQ will always try to put the messages to CL_01 on QM1 only. Here is what the Cluster handbook says:
| Quote: |
| The workload management algorithm selects the local queue manager as the destination whenever possible. If there is no instance of the queue on the local queue manager, the algorithm determines which destinations are suitable. |
Note it doesn't say if the local queue is full or inhibited. It just says if it is there, it will try to put to it, and I assume give a bad return code if necessary. In this case it would not send messages to QM4. Can someone else confirm this?
The same would apply to an app connected to QM4 putting to CL_01.
You would only see round robin style work load balancing if an app putting to CL_01 was connected to a QM other than 1 or 4 (QM2, QM3, or if properly set up, a QM from outside the cluster)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jc_squire |
| Posted: Mon Aug 05, 2002 2:33 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
Hi,
When a queue is full it becomes "put-inhibited" and open calls will not fail in order to facilitate gets.
The cluster workload algorithm is called on MQOPEN or MQPUT1 and will resolve to a local queue where possible. If a local queue does not exist a cluster queue is selected based on selection criteria (availability, priority etc). As usual the IBM documentation is open to interpretation and I have not found proof that the selection criteria is applied to local queues the same way it is applied to cluster queues.
I am unable to test this at the moment because I have blown my cluster.
Another important item to look out for is the MQOO_BIND_ON_OPEN - multiple instances of a queue (Q1) reside in a cluster and is resolved at open time (e.g. Q1 on QM1) all messages put to Q1 will be delivered to the same instance of the queue that was resolved at open time (Q1 on QM1). Using MQOO_BIND_NOT_FIXED can be used to override this or leave it as default and modify the queue attribute.
A good scenario for you to use is an application on QM1 putting messages to a queue that exists on QM2 and QM3. The algorithm will then distribute messages evenly across both queues on QM2 and QM3 depending on the MQOO_BIND and workload algorithm selection criteria.
Regards
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| 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
|
|
|
|
