| Author |
Message
|
| mq_guru |
 Posted: Fri Aug 27, 2004 8:48 am Post subject: Client load balancing ...... |
 |
|
Novice
Joined: 23 Feb 2004
Posts: 13
|
Hi All,
I am running with the current setup.
All these 4 Qmgrs told below are in different OS's.
QM1 and QM2 are part of the Application server environment and all they do is collect the messages and pass it on.
MQ1 and MQ2 are my broker QM's where my msgs will undergo some tranformation.
Currently all these 4 qmgrs are in a cluster where load balancing is happening properly and if MQ1 is down, then all msgs go thru MQ2 and when MQ1 comes up, then all the msgs will flow in RR appraoch.
Problem :
I want to remove the qmgrs QM1 and QM2 which are part of the Application server enviornment and I want to use clients as these Qmgrs are not doing anything other than collecting and passing the msgs to broker QMgrs. After all they are just costing much. If I replace the Qmgrs (QM1 and QM2) with clients, then How can I acheive the following.
1. Client 1 (replacement for QM1) will connect to MQ1 and Client 2 (replacement for QM2) will connect to MQ2.
2.When MQ1 in cluster goes down, then both the clients should point to MQ2 and when MQ1 comes up, then client 1 should come back and connect to MQ1.
Is there any other best way to reduce the Qmgr count so that I can save some money to the client.    |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Aug 27, 2004 9:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You first need to determine if your applications are using XA to perform two-phase commit.
If they are, you cannot reduce your client's costs. 2PC requires a local queue manager, or the transactional client which costs as much as the queue manager.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mq_guru |
| Posted: Fri Aug 27, 2004 9:48 am Post subject: |
|
|
Novice
Joined: 23 Feb 2004
Posts: 13
|
| I don't think they are using the XA. But all they want is... if MQ1 goes down, then the client should point to MQ2 and when MQ1 comes back, then the client should start pointing to MQ1. |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Aug 27, 2004 9:56 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
You should code it in your app (assuming it is in Java)
Try QMGR1 first, if you cannot connect to it connect to the second QMGR. |
|
| Back to top |
|
|
| gunter |
| Posted: Fri Aug 27, 2004 10:18 am Post subject: |
|
|
Partisan
Joined: 21 Jan 2004
Posts: 307
Location: Germany, Frankfurt
|
How about channeltables with two client connection channel? I never tried it but I read about this a few days ago. I can't find the thread.
_________________
Gunter Jeschawitz
IBM Certified System Administrator - Websphere MQ, 5.3 |
|
| Back to top |
|
|
| vennela |
| Posted: Fri Aug 27, 2004 10:23 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| For a Java application, you cannot use a channel table. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Sep 14, 2004 5:55 pm Post subject: Re: Client load balancing ...... |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| mq_guru wrote: |
Hi All,
Currently all these 4 qmgrs are in a cluster where load balancing is happening properly and if MQ1 is down, then all msgs go thru MQ2 and when MQ1 comes up, then all the msgs will flow in RR appraoch.
Problem :
I want to remove the qmgrs QM1 and QM2 which are part of the Application server enviornment and I want to use clients as these Qmgrs are not doing anything other than collecting and passing the msgs to broker QMgrs. After all they are just costing much. If I replace the Qmgrs (QM1 and QM2) with clients, then How can I acheive the following.
1. Client 1 (replacement for QM1) will connect to MQ1 and Client 2 (replacement for QM2) will connect to MQ2.
2.When MQ1 in cluster goes down, then both the clients should point to MQ2 and when MQ1 comes up, then client 1 should come back and connect to MQ1.
Is there any other best way to reduce the Qmgr count so that I can save some money to the client. |
With a Client relationship the application will lose all the advantages of Clustering and you will be limited to distributed MQ functionality.
Ergo if APP1 that is Binding to QM1 is replaced with a Client relationship to MQ1 and APP1 that is Binding to QM2 is replace with a Client relationship with MQ2 thus removing QM1 and QM2 as participants in the Cluster. You may as well not have a Cluster.
Because, the application on the Servers are now using Client mode to connect to MQ2 and MQ1 now instead of Binding Mode to connect to QM1 and QM2 as cluster participants. This eliminates your ability to use MQ as a load balancer/failure redundancy in which case you will have to rely on either the application code to intelligently route traffic around the failing MQ* Manager or the webserver to or some network load balancer.
Applications that use Client relationships to connect to MQManagers (local or remote) can not currently take advantage of the features of Clustering.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Sep 14, 2004 11:52 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| I usually recommend that MQ client programs read a list of their queue managers (from an ini file) and connect to one of them (chosen at random) until successful. That provides load balancing (assuming the list has more than one entry) and if the same logic is used for re-connecting after a failure, then it also provides recovery. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 15, 2004 5:10 am Post subject: Re: Client load balancing ...... |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| csmith28 wrote: |
| Applications that use Client relationships to connect to MQManagers (local or remote) can not currently take advantage of the features of Clustering. |
That's not true. There's no relationship between bindings/client connections and clustering.
If I have an application that is making a client connection to QMGR A, then as always I can only get messages from QMGR A. I can put messages to any queue that is known to QMGR A - this includes cluster queues, remote queues, and local queues. The messages that I put will be load balanced among all the queues that are available following all the same rules (including local queue first and always).
Now, I might want to think about what to do in the case of a cluster, when my client connection goes away. If I've got multiple instances of my application, each making client connections to a different queue manager, then I might NOT want to try and connect to another queue manager if I lose my connection to QMGR A.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Sep 15, 2004 11:27 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
If you use the client channel table method of connecting clients, then the connection can be made to any qmgr in the list.
Define the CLNCONN channels in the usual way, the the QMNAME and CONNAME attribute.
When connecting, set * (or any other wildcard spec) as the qmgr name in MQCONN. The client table is searched for a CLNTCONN chl with a qmgr matching the specified qmgr, and connected to. If the connection fails, the next CLNTCONN chl is used, and so on. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Sep 21, 2004 6:15 pm Post subject: Re: Client load balancing ...... |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| jefflowrey wrote: |
| csmith28 wrote: |
| Applications that use Client relationships to connect to MQManagers (local or remote) can not currently take advantage of the features of Clustering. |
That's not true. There's no relationship between bindings/client connections and clustering.
If I have an application that is making a client connection to QMGR A, then as always I can only get messages from QMGR A. I can put messages to any queue that is known to QMGR A - this includes cluster queues, remote queues, and local queues. The messages that I put will be load balanced among all the queues that are available following all the same rules (including local queue first and always).
Now, I might want to think about what to do in the case of a cluster, when my client connection goes away. If I've got multiple instances of my application, each making client connections to a different queue manager, then I might NOT want to try and connect to another queue manager if I lose my connection to QMGR A. |
Yes, as long as QMGR A is up but, when QMGR A is down what happens? The application that has a "Client" relationship with QMGR A even though it is a member of an MQCluster fails because the "Client" Application is not sending messages to the MQCluster it is sending messages to a member of a Cluster. So you are not in fact taking advantage of the true nature of MQClustering.
An application that uses a client connection to MQ can connect to an MQManager in a Cluster but it can not take advantage of Clustering.
An IBM Rep told me this so if it is indeed false, please do prove me wrong because I have over fifteen Production Applications that currently share one MQManager as remote Clients and I would love to be able to allow them to access a second MQManager in an MQCluster.
I'll do what ever it takes.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Sep 22, 2004 4:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You misunderstand the purpose of MQ clustering.
MQ Clustering is not intended to provide failover.
It is intended to provide workload balancing and redundancy/scalability. You can put another queue manager out there, and put it in a cluster.
You can then run COPIES of your applications that connect to that new queue manager.
This will provide you a better throughput. It also allows you to say "If my client application loses connection to my queue manager, I can close my application, and halt. Or otherwise just sit around and wait until the queue manager comes back up. I can do this, knowing that the work that needs to be done is still being done by other copies of myself on other queue managers".
So, basically, my response to
| Quote: |
Yes, as long as QMGR A is up but, when QMGR A is down what happens? The application that has a "Client" relationship with QMGR A even though it is a member of an MQCluster fails because the "Client" Application is not sending messages to the MQCluster it is sending messages to a member of a Cluster. So you are not in fact taking advantage of the true nature of MQClustering. |
is that you aren't taking advantage of the true nature of clustering if you only have one queue manager hosting any particular queue, not if you are making a client connection.
Again, client vs. server bindings has no relationship to clustering.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Sep 28, 2004 3:24 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| The main purpose of clustering is to relieve the user of the administration involved in setting up and maintaining the channels between many qmgrs. Clustering provides a seamless mechanism to route msgs to the qmgr in a cluster hosting the queue, without the overhead of creating lots of xmit queues and channels. Workload balancing is the icing on the cake as far as that is concerned. |
|
| Back to top |
|
|
|
|
