[openstack-dev] anyone using RabbitMQ with active/active mirrored queues?
Jesse Pretorius
jesse.pretorius at gmail.com
Thu Sep 11 06:50:41 UTC 2014
On 10 September 2014 17:20, Chris Friesen <chris.friesen at windriver.com>
wrote:
> I see that the OpenStack high availability guide is still recommending the
> active/standby method of configuring RabbitMQ.
>
> Has anyone tried using active/active with mirrored queues as recommended
> by the RabbitMQ developers? If so, what problems did you run into?
>
Whoops - finger trouble led my my last email being sent prematurely.
We've been running RabbitMQ 3.1.5 as a high availability cluster in
production for over a year now. Previous versions had some nasty memory
leaks and later versions changed the way authentication was handled and we
haven't gotten to work out the changes to our chef recipes to facilitate
the upgrades yet.
We're still only using one IP address in the OpenStack conf files - this
points to a virtual IP address which floats from one node to the other, so
one may consider it an active-passive cluster in actual usage.
We previously used two nodes configured as single servers and used DRBD and
pacemaker to manage the data partition and failover, but RabbitMQ's queue
mirroring is much less pain to deal with than DRBD.
The only trouble we've had has been when there have been network partitions
for extended periods, but I would think that this is a fairly normal
situation to result in a little pain. In our case it's been simple enough
to just restart the node to get the queues back to a normal running state.
We have seen some issues with the service restarts not working too well
(the service stays running), but that's easy enough to resolve too.
I would recommend that you ask this question on the openstack-perators list
as you'll likely get more feedback.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140911/f58bfb8e/attachment.html>
More information about the OpenStack-dev
mailing list