<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 25 February 2015 at 16:52, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">jOn Mon, Feb 23, 2015 at 5:07 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
> 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>
> The long and boring thing:<br>
><br>
> In the past few months there's been a fair amount of discussion concerning<br>
> the use of locking queries (ie: SELECT ... FOR UPDATE) in various OpenStack<br>
> projects, especially in connection with the fact that this kind of queries<br>
> is likely to trigger write set certification failures in synchronous db<br>
> replication engines such as MySQL Galera - as pointed out in [1] and<br>
> thoroughly analysed in [2].<br>
> Neutron, in particular, uses this construct often - and the correctness of<br>
> the whole IPAM logic depends on it. On this regard Neutron is also guilty of<br>
> not implementing any sort of retry mechanism. Eugene, Rossella, and others<br>
> have been working towards fixing this issue. Some examples of their work can<br>
> be found at [3] and [4].<br>
><br>
> However, techniques such as "compare and swap" described in [2] can be used<br>
> for implementing non-blocking algorithms which avoid at all the write-set<br>
> certification issue.<br>
> A neutron example of such technique can be found in [5]. However, a bug in<br>
> this process found by Attila [6], and the subsequent gerrit discussion [7],<br>
> raised further questions on locking vs non-blocking solutions.<br>
> At this stage, we know that using database-level locks triggers write-set<br>
> certification failures in synchronous multi master modes. This failures are<br>
> reported as deadlock errors. Such errors can be dealt with retrying the<br>
> transaction. However, this is claimed as not efficient in [2], whereas<br>
> Attila in [7] argues the opposite.<br>
><br>
> As I'm rewriting Neutron's IPAM logic as a part of [8], which heavily relies<br>
> on this construct, I decided to spend some time to put everything to the<br>
> test.<br>
> To this aim I devised 3 algorithms.<br>
><br>
> A-1) The classic one which locks the availability ranges for a subnet until<br>
> allocation is complete, augmented with a simple and brutal retry mechanism<br>
> [9].<br>
<br>
</div></div>So, similar to today's implementation.<br>
<span class=""><br>
> A-2) A wait-free 2 step process, in which the first one creates the IP<br>
> allocation entry, and the second completes it by adjusting availability<br>
> ranges [10]. Primary key violations will trigger retries.<br>
<br>
</span>My summary:  queries RESERVED ip requests and subtracts them from<br>
availability.  Attempts to generate an IP from the resulting set.<br>
Adjust availability in an idempotent way as a post-step.  Does that<br>
sound about right?<br></blockquote><div><br></div><div>Correct. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Seems there are four flavors of this.  Did you compare them?  Which<br>
one did you use to compare with the other two?<br></blockquote><div><br></div><div>There are indeed 4 flavors. Random and sequential, and for each one of them with or without a preliminary range check to verify whether the IP address has already been removed by a concurrent thread and hence skip the process.</div><div><br></div><div>Random allocation works terribly with availability ranges. This is mainly because adjusting them with random allocation in the great majority of cases means doing 1 update + 1 insert query at least, whereas sequential allocation usually results in a single update query.</div><div>The range check before retrying brings improvements in the majority of cases tested in this experimental campaign. However, its effectiveness decreases when the concurrency level is low, so it might not be the best solution.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> A-3) A wait-free, lock-free 3 step process [11], which adopts<br>
> compare-and-swap [2] and the same election process as the bully algorithm<br>
> [12].<br>
<br>
</span>Also, 2 flavors of this one:  random and sequential.  I'll admit I did<br>
not fully grok this implementation.  It looks to me like it would be<br>
inefficient.<br></blockquote><div><br></div><div>It sounds inefficient because we are making very little assumptions on the underlying database. I think its effectiveness can be improved; nevertheless is its complexity that worries me.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Unfortunately neutron does not create IP records for every address in a<br>
> subnet's CIDR - this would be fairly bad for IPv6 networks. Therefore we<br>
> cannot simply apply the simple CAS technique introduced in [2].<br>
<br>
</span>What if it created records for only N addresses and did the same sort<br>
of thing with those?  That would mitigate the issue with IPv6 and<br>
large IPv4 subnets.  If those N are exhausted then we'd have to run a<br>
routine to create more records.  Multiple workers could run that<br>
routine at the same time but I imagine that they would all attempt to<br>
insert the same set of new records and only one would win.  The others<br>
would hit key violations and try to allocate again.<br></blockquote><div><br></div><div>I thought of the same strategy but did not implement it. Nevertheless it might be a good candidate, and we should put it to the test.</div><div>In this case we should test how it scales with subnets where a large amounts of IPs is allocated. We need to ensure select queries are optimized as they might analyse tens of thousands of records or even more.</div><div>The aspect of extending the pool of IPs when the chunk is exhausted is another interesting one. As you note, multiple workers might crash there. In my opinion since this is an unfrequent operation we might find a way to designate a single worker which does this kind of thing. This is something neutron is currently unable to do, but it should not be difficult.</div><div><br></div><div>My intention was to have a chunk of 100 addresses and a minimum spare chunk size of 50 - which would give up to 50 concurrent allocations without issues.. Whenever the amount of free IPs would go below 50, I would trigger a thread that added more address until the number of available one went back up to 100.</div><div><br></div><div>One more thing that we should watch out for are specific IP allocations. It's not hard to reproduce a situation where one allocates  a specific IP and at the same time that IP is being allocated for a chunk.</div><div><br></div><div>Iif you want to add this algorithm I'd be happy to test it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
> I then tested them under arbitrary concurrent load from multiple workers.<br>
> The tests were performed first on a single node backend, and then a 3-node<br>
> mysql Galera cluster, installed and configured using the official<br>
> documentation [13].<br>
> The single-node tests showed, as it might have been expected, that the<br>
> algorithm leveraging db-level locks is way more efficient [14]<br>
> While it's pointless discussing the full results, one important aspect here<br>
> is that with db-level locks are a lot more "gentle" with the database, and<br>
> this result in consistently faster execution times.<br>
> With 20 concurrent threads, every thread completed in about 0.06 seconds<br>
> with db-level locks (A-1). With A-2 it took about 0.45 seconds, and with A-3<br>
> 0.32. With A-2 we saw over 500 queries, a little more than 200 with A-3, and<br>
> just a bit more than 100 with A-1.<br>
> It's worth noting that what makes A-3 faster than A-2 is a random allocation<br>
> strategy which drastically reduces collisions. A-3's performance with<br>
> sequential allocations are much worse (the avg. thread runtime with 20<br>
> concurrent threads is about 0.75 seconds)<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 A-1.<br>
> At this stage I am leaning towards adoption db-level-locks with retries for<br>
> Neutron's IPAM. However, since I never trust myself, I wonder if there is<br>
> something important that I'm neglecting and will hit me down the road.<br>
<br>
</div></div>Wondering if Kilo should just focus on creating the interface which<br>
will allow us to create multiple implementations and swap them out<br>
during the Liberty development cycle.  Hopefully, this could include<br>
even something like your option 2 below.<br>
<br>
I think I would go with the locking solution first because it is most<br>
like what we have today.<br></blockquote><div><br></div><div>Indeed. I realised the way you suggest here is the best for Kilo while implementing those algorithms.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
> 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>
</span>I think we need to look in to these options for Liberty.  I have had<br>
both options on my mind for a while.  I think I lean toward option 2<br>
first and option 1 as a last resort.  What do you think?<br></blockquote><div><br></div><div>Ideally I'd lean towards option 2 as well. The current structure of the code makes me thing we need to settle for option 1, which is decent anyway, especially if the plan around using multimaster clusters as master/slave wrt writes goes ahead. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Thanks for reading through this email.<br>
<br>
</span>You're welcome.  :)<br>
<span class="HOEnZb"><font color="#888888"><br>
Carl<br>
</font></span><div class="HOEnZb"><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>