[rabbitmq-discuss] How to use federation with clustering for best HA-behaviour?

Simon MacMullen simon at rabbitmq.com
Thu Jan 17 11:14:14 GMT 2013


On 16/01/13 17:40, Adam Aquilon wrote:
> I'm trying to understand how to achieve the best possible High
> Availability-setup with RabbitMQ. The documentation seems to say
> that I don't need to mirror the queues created by the federation
> plugin, but then I don't get uninterrupted traffic.

Oh, the queues used by federation are not magic - if you need them to 
work in case of node failure in a cluster then they should be mirrored.

> Once I created a policy that included "ha-mode":"all" for federated
> queues, I could crash single cluster nodes with no interruption in
> traffic. Did I misunderstand the documentation or is there something
> else going on here?

No, you understand right. Where in the documentation did it say that? I 
can't see anything obvious but I might be suffering from familiarity 
blindness.

> Background:
>
> Currently, I have six test nodes running on my linux box, arranged
> in three clusters of two nodes each: {n1,n2}, {n3,n4} and {n5,n6}.
>
> The clusters are called "kista", "linkoping" and "lindholmen"
> respectively. They are meant to represent different sites.
> For the details, please see the end of this email which has
> output from rabbitmqadmin.
>
> I've defined separate upstreams and upstream-sets for each one-way
> link between clusters. (Is that the way to do it?)

I see that you are using upstream sets to get redundancy in federation 
links - that's not really what they're intended for (we expect each 
upstream in an upstream set to point to a different cluster), so this 
will lead to message ordering getting broken as both upstreams connect 
to the same queue simultaneously.

However, there's no way at the moment for an upstream to point to 
multiple cluster nodes, with the intention of connecting to exactly one 
of them, so I don't think you have a choice. There should be though; I 
have filed a bug to do this.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware


More information about the rabbitmq-discuss mailing list