Author |
Message
|
trotta |
Posted: Mon Nov 15, 2010 6:10 am Post subject: High Availability on Client-Server connections |
|
|
 Newbie
Joined: 02 Nov 2010 Posts: 7 Location: Brazil
|
There is a project running more than 20 clients. These clients are responsible to push a message into a common inbound queue and pull the response back from a specific outbound queue for each client, once it was processed and put the answer back into the outbound queue by the main system.
As all the clients are running on different platforms and programming languages, all of them are connected to the QManager by using direct SRVCONN channels (one for each of them).
I was wondering about the failover method to be used over these clients. On the top of my head I think I just can come up with a failover method managed by the clients, that's, the client will notice that primary server is down and switch over to the backup server by itself. That method would be developed and managed on the application layer at client's side.
Is there any other effective and efficiency failover method to be used upon client-server embodiment that could avoid extra-code at client's side ?
Thank you, Thiago |
|
Back to top |
|
 |
exerk |
Posted: Mon Nov 15, 2010 6:16 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Take a very, very close look at what WMQ V7.0.1 does with clients  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
zpat |
Posted: Mon Nov 15, 2010 6:26 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Does the backup server have a different IP address or is it HA takeover of the IP address?
-----
There are technical limitations to the WMQ v7 auto-reconnect - it needs to be studied carefully. |
|
Back to top |
|
 |
trotta |
Posted: Mon Nov 15, 2010 6:52 am Post subject: |
|
|
 Newbie
Joined: 02 Nov 2010 Posts: 7 Location: Brazil
|
Backup server has a different IP and it's placed on other location. There is no any network method to takeover the IP. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 15, 2010 7:03 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
trotta wrote: |
Backup server has a different IP and it's placed on other location. There is no any network method to takeover the IP. |
Then your best bet is exerk's suggestion. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
trotta |
Posted: Mon Nov 15, 2010 7:25 am Post subject: |
|
|
 Newbie
Joined: 02 Nov 2010 Posts: 7 Location: Brazil
|
I suspect the QManager is running on version 6.x. I need to confirm that information with MQ Specialists working on the same project to be sure about that.
Anyone could explain me what WMQ v7 does with clients ? I just want to know whether or not there are others methods to cover my concern.
Thanks again.. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 15, 2010 7:30 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
trotta wrote: |
Anyone could explain me what WMQ v7 does with clients ? |
We could, but we'd just be repeating what's in the documentation.
It's not hard to find; this is not only in the Clients manual but also in the What's New for v7, being a new feature for v7
Of course, if you're using v6 this is not especially relevant. Except as another reason to upgrade. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
trotta |
Posted: Mon Nov 15, 2010 7:33 am Post subject: |
|
|
 Newbie
Joined: 02 Nov 2010 Posts: 7 Location: Brazil
|
Alright ! Thank you everyone who has replied that topic so far. If anyone has any further information to bring up to me, it will be appreciated.
Thx  |
|
Back to top |
|
 |
zpat |
Posted: Mon Nov 15, 2010 7:35 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Pre V7 (although it still applies), my advice was that the application should automatically retry any broken/failed connections (RC 2009, 2059 etc) but not more often than every 15 seconds.
You should connect clients to the QM using a DNS alias IP address that can be re-directed to the replacement queue manager. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 15, 2010 7:43 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
zpat wrote: |
Pre V7 (although it still applies), my advice was that the application should automatically retry any broken/failed connections (RC 2009, 2059 etc) but not more often than every 15 seconds.
You should connect clients to the QM using a DNS alias IP address that can be re-directed to the replacement queue manager. |
This of course entirely works but does require some client-side code that the OP was trying to avoid. It also requires the DNS alias to be switched over, which may or may not be less desirable than the client code having a list of IP addresses / DNS names (sourced by any of the many available methods) and automatically retrying them. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zpat |
Posted: Mon Nov 15, 2010 8:09 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Having a list of QM addresses also requires a coding change, unless you can use a CCDT or V7 client to do this.
Most of our apps don't (and can't without a coding change) use a CCDT. |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Nov 15, 2010 9:35 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If you are using JMS switching to CCDT should be done without changing any code. The changes happen in the JNDI layer. Be careful though about multi phase commit implications.... Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
zpat |
Posted: Tue Nov 16, 2010 1:23 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
If you are using JNDI which we don't. |
|
Back to top |
|
 |
|