Hi, Steve...<br><br><div class="gmail_quote">On Thu, Mar 21, 2013 at 8:37 AM, SteveO <span dir="ltr"><<a href="mailto:steveolivier22@gmail.com" target="_blank">steveolivier22@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Anyone using Pacemaker or Pacemaker-like technology to achieve H/A for<br>
persistent messages and durable queues across datacenters (and across the<br>
WAN)? The thought would be to have a primary data center, but in the event<br>
it went down, a backup data center would allow for processing of messages<br>
that had not been drained from queues prior to the primary data center going<br>
down. Any success/horror stories?<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Best regards,</div><div>Jerry</div><div><br></div></div>