Galera is working great for us. Rabbit mirrored queues is supported as of Grizzly: Nova/Quantum/Cinder .conf rabbit_ha_queues=true rabbit_hosts=control01,control02,control03 Details can be found here: http://docwiki.cisco.com/wiki/COE_Grizzly_Release:_High-Availability_Manual_Installation_Guide Regards, Daneyon Hansen From: Jesse Pretorius <jesse.pretorius at gmail.com<mailto:jesse.pretorius at gmail.com>> Date: Tuesday, June 4, 2013 11:45 AM To: "openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>" <openstack-operators at lists.openstack.org<mailto:openstack-operators at lists.openstack.org>> Subject: Re: [Openstack-operators] HA configuration in OpenStack On 4 June 2013 19:15, Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote: With the exception of Quantum l3-agent :( This is the main sticking point I have with deploying Quantum right now... vs. multihost nova-network. What this means in practical terms for us at AT&T is that we can use our F5s to spread load and manage active/active endpoints for everything (including our DB and MQ) -- except for Quantum. And that means exceptions in the Chef cookbooks. And deploying Pacemaker where we didn't need to deploy it previously. And exceptions in the deployment mean technical debt. And technical debt makes Jay a sad panda. Quite. Although I do see that there are efforts underway to overcome this. I am curious to hear about how everyone is deploying MySQL and RabbitMQ in active/active environments. My experience so far with MySQL in a multi-master configuration, but an active/passive usage, is less than steller. I have to watch the sync like a hawk and implement a ton of monitoring around that to be sure that it's not only actively working, but that the tables on master and slave are actually like-for-like. Without hijacking the thread - any tips? Is Galera clustering really that much better? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20130604/8ba8bb73/attachment.html>