<div dir="ltr">Yes. We have a separate DB cluster for global stuff like Keystone & Designate, and a regional cluster for things like nova/neutron etc.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 10:43 AM, Curtis <span dir="ltr"><<a href="mailto:serverascode@gmail.com" target="_blank">serverascode@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
For organizations with the keystone database shared across regions via<br>
galera, do you just have keystone (and perhaps glance as was<br>
suggested) in its own cluster that is multi-region, and the other<br>
databases in a cluster that is only in one region (ie. just local<br>
their their region)? Or are you giving other services their own<br>
database in the single multi-region cluster and thus replicating all<br>
the databases? Or is there another solution?<br>
<br>
Thanks,<br>
Curtis.<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Sep 8, 2015 at 3:22 PM, Jonathan Proulx <<a href="mailto:jon@jonproulx.com">jon@jonproulx.com</a>> wrote:<br>
> Thanks Jay & Matt,<br>
><br>
> That's basically what I thought, so I'll keep thinking it :)<br>
><br>
> We're not replicating glance DB because images will be stored in<br>
> different local Ceph storage on each side so the images won't be<br>
> directly available.  We thought about moving back to a file back end<br>
> and rsync'ing but RBD gets us lots of fun things we want to keep<br>
> (quick start, copy on write thin cloned ephemeral storage etc...) so<br>
> decided to live with making our users copy images around.<br>
><br>
> -Jon<br>
><br>
><br>
><br>
> On Tue, Sep 8, 2015 at 5:00 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>> On 09/08/2015 04:44 PM, Jonathan Proulx wrote:<br>
>>><br>
>>> Hi All,<br>
>>><br>
>>> I'm pretty close to opening a second region in my cloud at a second<br>
>>> physical location.<br>
>>><br>
>>> The plan so far had been to only share keystone between the regions<br>
>>> (nova, glance, cinder etc would be distinct) and implement this by<br>
>>> using MariaDB with galera replication between sites with each site<br>
>>> having it's own gmcast_segment to minimize the long distance catter<br>
>>> plus a 3rd site with a galera arbitrator for the obvious reason.<br>
>><br>
>><br>
>> I would also strongly consider adding the Glance registry database to the<br>
>> same cross-WAN Galera cluster. At AT&T, we had such a setup for Keystone and<br>
>> Glance registry databases at 10+ deployment zones across 6+ datacenters<br>
>> across the nation. Besides adjusting the latency timeout for the Galera<br>
>> settings, we made no other modifications to our<br>
>> internal-to-an-availability-zone Nova database Galera cluster settings.<br>
>><br>
>> The Keystone and Glance registry databases have a virtually identical read<br>
>> and write data access pattern: small record/row size, small number of<br>
>> INSERTs, virtually no UPDATE and DELETE calls, and heavy SELECT operations<br>
>> on a small data set. This data access pattern is an ideal fit for a<br>
>> WAN-replicated Galera cluster.<br>
>><br>
>>> Today I was warned against using this in a multi writer setup. I'd planned<br>
>>>   on one writer per physical location.<br>
>><br>
>><br>
>> I don't know who warned you about this, but it's not an issue in the real<br>
>> world. We ran in full multi-writer mode, with each deployment zone writing<br>
>> to and reading from its nearest Galera cluster nodes. No issues.<br>
>><br>
>> Best,<br>
>> -jay<br>
>><br>
>>> I had been under the impression this was the 'done thing' for<br>
>>> geographically sepperate regions, was I wrong? Should I replicate just<br>
>>> for DR and always pick a single possible remote write site?<br>
>>><br>
>>> site to site link is 2x10G (different physical paths), short link is<br>
>>> 2.2ms average latency (2.1ms low, 2.5ms high over 250 packets) long<br>
>>> link shouldn't be much longer but isn't yet complete to test.<br>
>>><br>
>>> -Jon<br>
>>><br>
>>> _______________________________________________<br>
>>> OpenStack-operators mailing list<br>
>>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-operators mailing list<br>
>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Twitter: @serverascode<br>
Blog: <a href="http://serverascode.com" rel="noreferrer" target="_blank">serverascode.com</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>