<div>Ok, the advice of central database seems feasible, and we have an discuss about it, but the delay between different region are pullback for this advise, because it is far away between the two region. The slow sync decide only the relatively static business can happen between the different regions.</div><div><br></div><div><div class="gmail_quote"><div>Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>>于2017年2月17日 周五下午1:10写道:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Fri, Feb 17, 2017 at 11:22 AM, Clint Byrum <span class="gmail_msg"><<a href="mailto:clint@fewbar.com" class="gmail_msg" target="_blank">clint@fewbar.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from 王玺源's message of 2017-02-17 14:08:30 +0000:<br class="gmail_msg">
<span class="m_2784512004543579192gmail- gmail_msg">> Hi David:<br class="gmail_msg">
><br class="gmail_msg">
> We have not find the perfect solution to solve the fernet performance<br class="gmail_msg">
> issue, we will try the different crypt strength setting with fernet in<br class="gmail_msg">
> future.<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</span>One important thing: did you try throwing more hardware at Keystone?<br class="gmail_msg">
Keystone instances are almost entirely immutable (the fernet keys<br class="gmail_msg">
are the only mutable part), which makes it pretty easy to scale them<br class="gmail_msg">
horizontally as-needed. Your test has a static 3 nodes, but you didn't<br class="gmail_msg">
include system status, so we don't know if the CPUs were overwhelmed,<br class="gmail_msg">
or how many database nodes you had, what its level of activity was, etc.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">+1</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Several folks in the community have tested token performance using a variety of hardware and configurations. Sharing your specific setup might draw similarities to other environments people have used. If not, then we at least have an environment description that we can use to experience the issues you're seeing first-hand.</div></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_2784512004543579192gmail- gmail_msg"><br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> There are multiple customers have more than 6-region cascade, how to<br class="gmail_msg">
> synchronous keystone data between these region disturbed us a lot. It does<br class="gmail_msg">
> not need to synchronize these data while using pki token, because the pki<br class="gmail_msg">
> token including the roles information.<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</span>The amount of mutable data to synchronize between datacenters with Fernet<br class="gmail_msg">
is the fernet keys. If you set up region-local caches, you should be<br class="gmail_msg">
able to ship queries back to a central database cluster and not have to<br class="gmail_msg">
worry about a painful global database cluster, since you'll only feel<br class="gmail_msg">
the latency of those cross-region queries when your caches are cold.<br class="gmail_msg">
<br class="gmail_msg">
However, I believe work was done to allow local read queries to be sent<br class="gmail_msg">
to local slaves, so you can use traditional MySQL replication if the<br class="gmail_msg">
cold-cache latency is too painful.<br class="gmail_msg">
<br class="gmail_msg">
Replication lag becomes a problem if you get a ton of revocation events,<br class="gmail_msg">
but this lag's consequences are pretty low, with the worst effect being a<br class="gmail_msg">
larger window for stolen, revoked tokens to be used. Caching also keeps<br class="gmail_msg">
that window open longer, so it becomes a game of tuning that window<br class="gmail_msg">
against desired API latency.<br class="gmail_msg">
<span class="m_2784512004543579192gmail- gmail_msg"><br class="gmail_msg"></span></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Good point, Clint. We also merged a patch in Ocata that helped improve token validation performance, which was not proposed as a stable backport: </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://github.com/openstack/keystone/commit/9e84371461831880ce5736e9888c7d9648e3a77b" class="gmail_msg" target="_blank">https://github.com/openstack/keystone/commit/9e84371461831880ce5736e9888c7d9648e3a77b</a></div></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_2784512004543579192gmail- gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> The pki token has been verified that can support such large-scale<br class="gmail_msg">
> production environment, which even the uuid token has performance issue in<br class="gmail_msg">
> too.<br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
</span>As others have said, the other problems stacked on top of the critical<br class="gmail_msg">
security problems in PKI made it very undesirable for the community to<br class="gmail_msg">
support. There is, however, nothing preventing you from maintaining it<br class="gmail_msg">
out of tree, though I'd hope you would instead collaborate with the<br class="gmail_msg">
community to perhaps address those problems and come up with a "PKIv2"<br class="gmail_msg">
provider that has the qualities you want for your scale.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">+1</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Having personally maintained a token provider out-of-tree prior to the refactoring done last release [0], I think the improvements made are extremely beneficial for cases like this. But, again re-iterating what Clint said, I would only suggest that if for some reason we couldn't find a way to get a supported token provider to suit your needs.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">We typically have a session dedicated to performance at the PTG, and I have that tentatively scheduled for Friday morning (11:30 - 12:00) [1]. Otherwise it's usually a topic that comes up during our operator feedback session, which is scheduled for Wednesday afternoon (1:30 - 2:20). Both are going to be in the dedicated keystone room (which I'll be advertising when I know exactly which room that is).</div><div class="gmail_msg"> </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">[0] <a href="https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider" class="gmail_msg" target="_blank">https://review.openstack.org/#/q/status:merged+project:openstack/keystone+branch:master+topic:cleanup-token-provider</a></div><div class="gmail_msg">[1] <a href="https://etherpad.openstack.org/p/keystone-pike-ptg" class="gmail_msg" target="_blank">https://etherpad.openstack.org/p/keystone-pike-ptg</a></div></div></div></div><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="m_2784512004543579192gmail-HOEnZb gmail_msg"><div class="m_2784512004543579192gmail-h5 gmail_msg"><br class="gmail_msg">
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</div></div></blockquote></div></div></div>
__________________________________________________________________________<br class="gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="gmail_msg" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br class="gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="gmail_msg" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class="gmail_msg">
</blockquote></div></div>