<div dir="ltr">Thanks Clint.<div><br></div><div>I think you are bringing an interesting and disruptive perspective into this discussion.</div><div>Disruptive because one thing that has not been considered so far in this thread is that perhaps we don't need at all to leverage multi-master capabilities for write operations.</div><div><br></div><div>More comments inline,</div><div>Salvatore<br><div class="gmail_extra"><br><div class="gmail_quote">On 25 February 2015 at 14:40, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Excerpts from Salvatore Orlando's message of 2015-02-23 04:07:38 -0800:<br>
<span class="">> Lazy-Stacker summary:<br>
> I am doing some work on Neutron IPAM code for IP Allocation, and I need to<br>
> found whether it's better to use db locking queries (SELECT ... FOR UPDATE)<br>
> or some sort of non-blocking algorithm.<br>
> Some measures suggest that for this specific problem db-level locking is<br>
> more efficient even when using multi-master DB clusters, which kind of<br>
> counters recent findings by other contributors [2]... but also backs those<br>
> from others [7].<br>
><br>
<br>
</span>Thanks Salvatore, the story and data you produced is quite interesting.<br>
<span class=""><br>
><br>
> With the test on the Galera cluster I was expecting a terrible slowdown in<br>
> A-1 because of deadlocks caused by certification failures. I was extremely<br>
> disappointed that the slowdown I measured however does not make any of the<br>
> other algorithms a viable alternative.<br>
> On the Galera cluster I did not run extensive collections for A-2. Indeed<br>
> primary key violations seem to triggers db deadlock because of failed write<br>
> set certification too (but I have not yet tested this).<br>
> I run tests with 10 threads on each node, for a total of 30 workers. Some<br>
> results are available at [15]. There was indeed a slow down in A-1 (about<br>
> 20%), whereas A-3 performance stayed pretty much constant. Regardless, A-1<br>
> was still at least 3 times faster than A-3.<br>
> As A-3's queries are mostly select (about 75% of them) use of caches might<br>
> make it a lot faster; also the algorithm is probably inefficient and can be<br>
> optimised in several areas. Still, I suspect it can be made faster than<br>
> A-1. At this stage I am leaning towards adoption db-level-locks with<br>
> retries for Neutron's IPAM. However, since I never trust myself, I wonder<br>
> if there is something important that I'm neglecting and will hit me down<br>
> the road.<br>
><br>
<br>
</span>The thing is, nobody should actually be running blindly with writes<br>
being sprayed out to all nodes in a Galera cluster. So A-1 won't slow<br>
down _at all_ if you just use Galera as an ACTIVE/PASSIVE write master.<br>
It won't scale any worse for writes, since all writes go to all nodes<br>
anyway. </blockquote><div><br></div><div><div>If writes are sent to a singe node, obviously there will be no contention at all.</div><div>I think Mike in some other thread mentioned the intention of supporting this scheme as part of the db facade work he's doing.</div><div>On the other hand, as you say in this way you'll be effectively using the DB cluster as ACTIVE/PASSIVE w.r.t writes.</div><div>If the fact that there won't be any performance or scalability penalty is proven, then I think I have no concern about adopting this model. Note that I'm not saying this because I don't trust you, but merely because of my ignorance - I understand that in principle what you say is correct, but since galera replicates through write sets and simply by replying transaction logs, things might be not as obvious, and perhaps I'd look at some data supporting this claim.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">For reads we can very easily start to identify hot-spot reads<br>
that can be sent to all nodes and are tolerant of a few seconds latency.<br></blockquote><div><br></div><div>A few second latency sound rather bad, but obviously we need to put everything into the right context.</div><div>Indeed it seems to me that by "hot-spot" you mean reads which are performed fairly often?</div><div>In your opinion, what would be the caveats in always distributing reads to all nodes?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> In the medium term, there are a few things we might consider for Neutron's<br>
> "built-in IPAM".<br>
> 1) Move the allocation logic out of the driver, thus making IPAM an<br>
> independent service. The API workers will then communicate with the IPAM<br>
> service through a message bus, where IP allocation requests will be<br>
> "naturally serialized"<br>
<br>
</span>This would rely on said message bus guaranteeing ordered delivery. That<br>
is going to scale far worse, and be more complicated to maintain, than<br>
Galera with a few retries on failover.<br></blockquote><div><br></div><div>I suspect this as well, but on the other hand I believe some components adopted by several OpenStack projects adopt exactly this pattern. I have however no data point to make any sort of claim regarding their scalability.</div><div>From an architectural perspective you can make things better by scaling out the RPC server with multiple workers, but then you'd be again at the starting point!</div><div>When I propose stuff on the mailing list I typically do full brain dumps, even the terrible ideas, which are unfortunately occur to me very frequently.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> 2) Use 3-party software as dogpile, zookeeper but even memcached to<br>
> implement distributed coordination. I have nothing against it, and I reckon<br>
> Neutron can only benefit for it (in case you're considering of arguing that<br>
> "it does not scale", please also provide solid arguments to support your<br>
> claim!). Nevertheless, I do believe API request processing should proceed<br>
> undisturbed as much as possible. If processing an API requests requires<br>
> distributed coordination among several components then it probably means<br>
> that an asynchronous paradigm is more suitable for that API request.<br>
><br>
<br>
</span>If we all decide that having a load balancer sending all writes and<br>
reads to one Galera node is not acceptable for some reason, then we<br>
should consider a distributed locking method that might scale better,<br>
like ZK/etcd or the like. But I think just figuring out why we want to<br>
send all writes and reads to all nodes is a better short/medium term<br>
goal.<br></blockquote><div><br></div><div>I think I agree on this point - meaning that I believe at some we need to make an architectural decision regarding whether we want to let distributed coordination to the app layer, or rely on a centralised data source where serialisation can be enforce through transaction properties and constructs such as write intent locks. This discussion alone maybe deserves its own mailing list thread, cross-project spec and summit session. Therefore it might be better to refrain going into this rabbit hole in this thread.</div><div>Looking at the current architecture of several openstack API servers, and in particular the Neutron API server, I feel that leveraging db-level constructs at this stage might be the safest approach from scalability, reliability and maintainability perspectives.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>