| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Plan to Implement clustering ... |
« View previous topic :: View next topic » |
| Author |
Message
|
| tekion |
 Posted: Tue Nov 18, 2003 12:25 pm Post subject: Plan to Implement clustering ... |
 |
|
Newbie
Joined: 18 Nov 2003
Posts: 4
|
| I am currently running MQ5.2, But I am looking into implementing 5.3 to take advantage of clustering. I currently have one mq server at corporate and serveral hundred mq clients in different colocation site. I want to create a cluster with two mq servers which is configure to hold the repository queue (not sure of the term). This should make all queue transparent to the client, I think. What I am not sure of is, will I have to migrate the mq clients on remote colcation to MQ5.3 and configure them to part of the cluster? Any input on how to get this done is apreciated. Thanks. |
|
| Back to top |
|
 |
| yonny |
| Posted: Tue Nov 18, 2003 1:40 pm Post subject: |
|
|
Apprentice
Joined: 08 Jul 2001
Posts: 49
Location: Santo Domingo
|
Athough is a good idea to update to 5.3, It is not indispensable for clustering, because clustering is available in all V5 or later qmgrs. So If you update your servers to mq 5.3, is it posible to use MQ clients from 5.1 to 5.3.
Regards,
Yonny. |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Nov 19, 2003 10:04 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Clustering only works for a Server connections.
Clients still have to 'decide' which queue manager to connect to. There is no 'round robin' for clients.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| RatherBeGolfing |
| Posted: Fri Nov 21, 2003 7:37 am Post subject: |
|
|
Centurion
Joined: 12 Nov 2002
Posts: 118
Location: Syracuse, NY, USA
|
Agree with above comments. I'm running MQServer V5.3 (on W2K) with CSD04 and have clients connecting that are running everything from V5.1 to V5.3.
The way I do it to provide failover for my clients is to build a channel table file with hooks to at least 2 queue managers - they don't have to be full respositories. That way, if I need to take a box down for say MICROSOFT SECURITY PATCHING, then the client will fail over to the other channel and still be able to function. Of course, if you're in a request-reply scenario, you'll need to build reply Qs on all queue managers that the client may connect to.
Just my $.02,
Larry |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Nov 21, 2003 7:44 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You could also have a Virtual IP address that primarily maps to QM1 on Server1, and if that server is unavailable, then it routes future Client connection attempts to QM2 on Server2.
As long as the port #, the channel name and the queues are the same on both QMs, and both QMs are the default QM on their respective boxes, this will work. This helps for apps that will not or cannot (Java) use channel tables.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
