[rabbitmq-discuss] RabbitMQ Clustering with Federation
Simon MacMullen
simon at rabbitmq.com
Thu Aug 1 16:34:04 BST 2013
On 31/07/2013 5:35PM, Robert Parker wrote:
> I'm having some trouble getting the right architecture configured to
> support rabbitmq federation in a clustered high availability
> environment. Our basic setup is four clusters of two nodes each which
> are separated by a WAN.
>
> "home" is the "home" cluster and "remote1", "remote2" and "remote3" are
> remote clusters. There are a lot of queues being created and published
> to via the API identically on all clusters but I only want to federate
> ONE of the queues, which is called "EventListener" back to the "home"
> cluster from all the "remote" clusters. I want messages published to
> this queue on each remote cluster to be federated to the home cluster to
> be consumed by a separate event listener service that only lives at the
> "home" site.
Just to be clear: you are aware that (currently) it's only *exchanges*
which can be federated, not queues?
> Each cluster is configured with:
<snip>
> We have configured three hardware load balancer VIPs that load balance
> connections on port 5672 between both nodes in each cluster, and have
> configured federation upstreams to use these and also configured our
> application to use these VIPs for queue/exchange creation and for
> publishing messages. Here's our federation config script thats run on
> node1 of the home cluster only:
<snip>
> However I am noticing that the "rabbitmqctl eval
> 'rabbit_federation_status:status()." command only shows federation
> config on node2 of the home cluster despite having been configured on node1:
Federation works by establishing link(s) from the downstream to the
upstream(s). You can define the upstreams on any node in the downstream
cluster (the configuration is cluster-wide) and the cluster will
arbitrarily start the link processes on any node (and will migrate them
around the cluster if nodes go down).
*However*, rabbit_federation_status:status() will only report links that
are running on the local node. This is probably not well documented.
Hmm. Let's fix that.
(The HTTP API exported by rabbitmq_federation_management will report
links on all nodes.)
<snip>
> And I'm noticing that messages published to the queues via the load
> balancer VIPs to the remote clusters are not showing up in the
> "EventListener" queue of the home cluster.
Note that you have federated an exchange called "EventListener", not a
queue. So if you bind a queue to the exchange "EventListener" on home,
and publish to the exchange "EventListener" on remote1/2/3 then you
should see messages turning up in the queue on home. Is that what you're
doing?
> Is this not the right way to set this up?
It sounds like you're basically right, apart from the exchange vs queue
thing.
> Is it possible to configure
> this without using an external load balancer and still achieve high
> availability?
Since 3.1.0, yes. You can specify multiple URIs in a single upstream,
and federation will connect to a randomly chosen one (and keep retrying
different ones if that one goes down). Use something like:
rabbitmqctl set_parameter federation-upstream remote1-upstream
'{"uri":["amqp://remote1-node1","amqp://remote1-node2"],"expires":3600000}'
> If I federate to a single node of a cluster directly,
> what happens if that node goes down?
If you only specify one URI, it will keep retrying until that node comes
back up.
> Do I have to configure redundant
> federation between every node of home cluster to every node of each
> remote cluster?
No - since the config is shared across the cluster. So you can set up
the upstreams on one node of the home cluster, pointing to all nodes of
the remote clusters.
> If I don't use a load balancer VIP to publish to from my
> application, if the single node of the cluster I've configured goes
> down, it wont help me that the other node is still available.
Not sure what you mean here. Hopefully I've explained enough now.
Cheers, Simon
--
Simon MacMullen
RabbitMQ, Pivotal
More information about the rabbitmq-discuss
mailing list