Open Stack

On 06/04/2013 01:45 PM, Jesse Pretorius wrote:
> 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.

Hopefully sooner than later :)

> 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?

We use Galera for some things, yes, and it works quite well.

Here's my advice:

* DO use Galera for Identity and Image databases
* DO share Identity and Image database cluster across regions/zones (WAN 
replication actually works very well for this low-write, heavy-read data 
access pattern)
* DO use a separate Galera cluster for Compute, Volume, Dashboard, and 
Network databases in each region/zone
* do NOT use Galera for metering data. Galera is great for light to 
medium write to read ratios. It is NOT a good idea to put archival-type 
data like meters/events data into Galera and replicate it all over the 
place when there are so many writers and very few readers. MySQL's 
standard replication works just great for this kind of data access pattern.
* do NOT use the SQL driver for Keystone tokens. Use the memcache driver.
* do NOT use the SQL driver for Keystone catalog. Use the templated 
catalog driver.

All the best,
-jay