Cross data center H/A

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Cross data center H/A

SteveO
Anyone using Pacemaker or Pacemaker-like technology to achieve H/A for persistent messages and durable queues across datacenters (and across the WAN)? The thought would be to have a primary data center, but in the event it went down, a backup data center would allow for processing of messages that had not been drained from queues prior to the primary data center going down. Any success/horror stories?
Reply | Threaded
Open this post in threaded view
|

Re: Cross data center H/A

Jerry Kuch
Hi, Steve...

On Thu, Mar 21, 2013 at 8:37 AM, SteveO <[hidden email]> wrote:
Anyone using Pacemaker or Pacemaker-like technology to achieve H/A for
persistent messages and durable queues across datacenters (and across the
WAN)? The thought would be to have a primary data center, but in the event
it went down, a backup data center would allow for processing of messages
that had not been drained from queues prior to the primary data center going
down. Any success/horror stories?

If the notion of Pacemaker use you're thinking is akin to the old style Rabbit active/passive HA, then that's almost surely something you don't want to consider for cross-WAN geographic distribution for disaster recovery and the like since it relies upon not only shared storage (e.g. a SAN) but also on Pacemaker's liveness checks getting fairly timely responses and not doing crazy things when an unexpected uptick in WAN latency occurs.

Indeed, in general, the idea of replicating, bit for bit, everything that's going on in a Rabbit or Rabbit cluster in one DC in another, far off one, is probably something that's going to be harder and more costly to get right than what you really need.

What we do see, with some regularity, is customers using Shovel or Federation to connect DCs in geographically disparate regions, and then passing checkpointing or roll-up information between the primary in one DC and the other, with the rate, granularity and content send chosen carefully with respect to what sort of pick-up/recovery they want to be able to have happen at the second site.

Best regards,
Jerry


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss