|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ/MB/Datapower Disaster recovery |
« View previous topic :: View next topic » |
Author |
Message
|
given2fly |
Posted: Wed Feb 11, 2015 7:05 pm Post subject: MQ/MB/Datapower Disaster recovery |
|
|
Newbie
Joined: 18 Sep 2014 Posts: 5
|
Hello everyone,
We have been tasked to make our ESB service(Datapower+MQ/MB) resilient. Has anyone ever implemented active queue managers in different geographic locations? I have reached out to IBM but would like to know the thoughts and experiences of this group.
To elaborate, let's assume there's a datacenter on the east and the west coast. Each DC would have a DP/MB/MQ instance which would actively process messages fed to it thru a load balancer. The active instances would also be replicated to the other DC so that when a DC goes down, the other DC would fire up the backup DP/MQ/MB instance.
The other option would be to drop the resiliency requirement and just focus on recovery using a backup DP/MQ/MB environment that will be replicated from the production DC and activated during DR.
Thanks!! |
|
Back to top |
|
 |
Vitor |
Posted: Thu Feb 12, 2015 5:56 am Post subject: Re: MQ/MB/Datapower Disaster recovery |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
given2fly wrote: |
Has anyone ever implemented active queue managers in different geographic locations? |
Yes.
given2fly wrote: |
To elaborate, let's assume there's a datacenter on the east and the west coast. Each DC would have a DP/MB/MQ instance which would actively process messages fed to it thru a load balancer. The active instances would also be replicated to the other DC so that when a DC goes down, the other DC would fire up the backup DP/MQ/MB instance. |
Was there an actual question, or is the question "can you do that?".
Of course you can, as you've probably discovered. The only issues are to ensure your application all reconnect when you switch from one DC to the other, and what to do with any unprocessed messages in the "downed" DC. If a specific application uses persistent messages (for example), there's a possibility that there's a design assumption they don't need to reproduce the message and lack the ability. As the message will be sitting in the downed DC not the now-active one, you need a strategy. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Thu Feb 12, 2015 6:27 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
|
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
|
|
|
|