<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 10 September 2014 17:20, Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I see that the OpenStack high availability guide is still recommending the active/standby method of configuring RabbitMQ.<br>
<br>
Has anyone tried using active/active with mirrored queues as recommended by the RabbitMQ developers?  If so, what problems did you run into?<br></blockquote><div><br></div><div>Whoops - finger trouble led my my last email being sent prematurely.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I would recommend that you ask this question on the openstack-perators list as you'll likely get more feedback.</div></div></div></div>