<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=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
        {font-family:SimSun;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 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";
        color:black;}
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.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 90.0pt 72.0pt 90.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 bgcolor="white" lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">[Joe]: For reliability purpose, I suggest that the keystone client should provide a
 fail-safe design: primary KeyStone server, the second KeyStone server (or even the third KeySont server) . If the primary KeyStone server is out of service, then the KeyStone client will try the second KeyStone server. Different KeyStone client may be configured
 with different primary KeyStone server and the second KeyStone server.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
</span><span lang="EN-US">[Adam]: </span><span lang="EN-US">Makes sense, but that can be handled outside of Keystone using HA and Heartbear and awhole slew of technologies.  Each Keystone server can validate each other's tokens.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">For cross-site KeyStone HA, the backend of HA can leverage MySQL Galera cluster for multisite database synchronous replication to provide high
 availability, but for the KeyStone front-end the API server, it’s web service and accessed through the endpoint address ( name, or domain name, or ip address ) , like http://.... or ip address.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">AFAIK, the HA for web service will usually be done through DNS based geo-load balancer in multi-site scenario. The shortcoming for this HA is that
 the fault recovery ( forward request to the health web service) will take longer time, it's up to the configuration in the DNS system. The other way is to put a load balancer like LVS ahead of KeyStone web services in multi-site. Then either the LVS is put
 in one site(so that KeyStone client only configured with one IP address based endpoint item, but LVS cross-site HA is lack), or in multisite site, and register the multi-LVS’s IP to the DNS or Name server(so that KeyStone client only configured with one Domain
 name or name based endpoint item, same issue just mentioned).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Therefore, I still think that
</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">keystone client with a fail-safe design( primary KeyStone server, the second KeyStone server ) will be a “very high gain but low invest” multisite high availability
 solution. Just like MySQL itself, we know there is some outbound high availability solution (for example, PaceMaker+ColoSync+DRDB), but also there is  Galera like inbound cluster ware.</span><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Best Regards<o:p></o:p></span></p>
<p class="MsoNormal" style="text-align:justify;text-justify:inter-ideograph"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">Chaoyi Huang ( Joe Huang )<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Adam Young [mailto:ayoung@redhat.com]
<br>
<b>Sent:</b> Tuesday, March 17, 2015 10:00 PM<br>
<b>To:</b> openstack-dev@lists.openstack.org<br>
<b>Subject:</b> Re: [openstack-dev] [opnfv-tech-discuss] [Keystone][Multisite] Huge token size<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On 03/17/2015 02:51 AM, joehuang wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">It’s not reality to deploy KeyStone service ( including backend store ) in each site
 if the number, for example, is more than 10.  The reason is that the stored data including data related to revocation need to be replicated to all sites in synchronization manner. Otherwise, the API server might attempt to use the token before it's able to
 be validated in the target site. </span><span lang="EN-US"><o:p></o:p></span></p>
</blockquote>
<p class="MsoNormal"><span lang="EN-US"><br>
Replicating revocati9on data across 10 sites will be tricky, but far better than replicating all of the token data.  Revocations should be relatively rare.<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">When Fernet token is used in multisite scenario, each API request will ask for token
 validation from KeyStone. The cloud will be out of service if KeyStone stop working, therefore KeyStone service need to run in several sites.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><br>
There will be multiple Keystone servers, so each should talk to their local instance.<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:#1F497D">For reliability purpose, I suggest that the keystone client should provide a fail-safe
 design: primary KeyStone server, the second KeyStone server (or even the third KeySont server) . If the primary KeyStone server is out of service, then the KeyStone client will try the second KeyStone server. Different KeyStone client may be configured with
 different primary KeyStone server and the second KeyStone server.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><br>
Makes sense, but that can be handled outside of Keystone using HA and Heartbear and awhole slew of technologies.  Each Keystone server can validate each other's tokens.<o:p></o:p></span></p>
</div>
</body>
</html>