<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 26 November 2013 17:51, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">There is no reason to run any OpenStack endpoint -- other than the Neutron L3 agent -- in an active/passive way. The reason is because none of the OpenStack endpoints maintain any state. The backend storage systems used by those endpoints *do* contain state -- but the endpoint services themselves do not.</span></div>
</div></blockquote><div><br></div><div>100% agreed. The only parts of the system that need an active/passive HA setup at this stage is the Neutron L3 Agent. Everything else can be setup active/active.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">My advice would be to continue using Percona XtraDB for your database backend (we use the same in a variety of ways, from intra-deployment-zone clusters to WAN-replicated clusters). That solves your database availability issues, and nicely, we've found PXC to be as easy or easier to administer and keep in sync than normal MySQL replication.</span></div>
</div></blockquote><div><br></div><div>We use normal master/master MySQL replication, but we do have to untwist it from time to time and watch the replication state carefully. For large scale I'd definitely recommend looking at one of the other HA MySQL packaging.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">We use RabbitMQ clustering and have had numerous problems with it, frankly. It's been our pain point from an HA perspective. There are other clustering MQ technologies out there, of course. Frankly, one could write a whole book just about how crappy the MQ clustering "story" is...</span></div>
</div></blockquote><div><br></div><div>Interesting - we haven't had much trouble since implementing HA queues and updating to the latest available RabbitMQ from their website (instead of the Ubuntu package). Prior to the update we had memory leaks and lost messages from time to time.</div>
</div></div></div>