[rabbitmq-discuss] Setting up WAN cluster vs using Shovel

Ben Hood 0x6e6562 at gmail.com
Sun Aug 30 10:18:18 BST 2009


On Sat, Aug 29, 2009 at 6:24 PM, Anuj Agarwal<aagarwal at yellowpages.com> wrote:
> We plan to use RabbitMQ in 2 of our data centers. We're thinking of
> setting up a local cluster in each data center and a 'WAN cluster' which
> includes 2 nodes from each data center for applications that need to
> publish msgs that should be retrievable from either data center.
> Private address space is the same across the 2 co-los (same domain) so
> configuring such a cluster is not an issue. Does this solution have
> drawbacks as opposed to using the Shovel addon? This seems much simpler
> to use than Shovel, but are how robust is the cluster against data
> connection hiccups between the nodes?

Interesting. I don't know if anybody has run a Rabbit cluster split
across a WAN, and whilst it can be done, my first thought would be
that there is little sophistication for handling network partitions in
Rabbit. (Having said that, I don't know if running a Rabbit cluster on
EC2 counts as running over a WAN)

One attraction in splitting the cluster to make messages available to
consumers in both data centers is that when a client creates a queue,
it is local to the node that it connected to and hence you could keep
most of your network traffic local because the Rabbit handles the
intra-node communication on a per-message basis, i.e. it will only
ship one copy of a message between nodes even if you have multiple
bound queues.

This obviously leads to the downside of queues not reachable due to
partitioning and hence you will miss messages.

In this scenario, shovel *may* be less afflicted by partitioning due
to the fact that it could just queue up messages in the event of a
split brain and then replay them once coherency has been restored.
However there are probably some downsides to it such as the extra
configuration you'd have to do yourself. Also, I wouldn't say that the
original shovel implementation is of (dare I say) production quality.
Furthermore, I'm not aware of anybody that has actually used it in
anger in a WAN (although maybe there are some adaptations).

Another alternative to both of these schemes is to run Rabbit in one
data center and just have consumers connect over the WAN.



More information about the rabbitmq-discuss mailing list