<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.hoenzb
{mso-style-name:hoenzb;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>CERN do the same…. The memcache functions on keystone are very useful for scaling it up.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'>Tim<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Matt Fischer [mailto:matt@mattfischer.com] <br><b>Sent:</b> 28 September 2015 18:51<br><b>To:</b> Curtis <serverascode@gmail.com><br><b>Cc:</b> openstack-operators@lists.openstack.org; Jonathan Proulx <jon@jonproulx.com><br><b>Subject:</b> Re: [Openstack-operators] Milti-site Keystone & Galera<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Yes. We have a separate DB cluster for global stuff like Keystone & Designate, and a regional cluster for things like nova/neutron etc.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Mon, Sep 28, 2015 at 10:43 AM, Curtis <<a href="mailto:serverascode@gmail.com" target="_blank">serverascode@gmail.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>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.<o:p></o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'><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" 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" 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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br><br><br><o:p></o:p></p></div></div><p class=MsoNormal><span class=hoenzb><span style='color:#888888'>--</span></span><span style='color:#888888'><br><span class=hoenzb>Twitter: @serverascode</span><br><span class=hoenzb>Blog: <a href="http://serverascode.com" target="_blank">serverascode.com</a></span></span><o:p></o:p></p><div><div><p class=MsoNormal><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" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><o:p></o:p></p></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></body></html>