Yes, memcached is a candidate that looks promising. First things first, though. I think we need the abstraction of an ipam interface merged. That will take some more discussion and work on its own.
Carl On May 30, 2014 4:37 PM, "Eugene Nikanorov" <enikano...@mirantis.com> wrote: > > I was thinking it would be a separate process that would communicate over > the RPC channel or something. > memcached? > > Eugene. > > > On Sat, May 31, 2014 at 2:27 AM, Carl Baldwin <c...@ecbaldwin.net> wrote: > >> Eugene, >> >> That was part of the "whole new set of complications" that I >> dismissively waved my hands at. :) >> >> I was thinking it would be a separate process that would communicate >> over the RPC channel or something. More complications come when you >> think about making this process HA, etc. It would mean going over RPC >> to rabbit to get an allocation which would be slow. But the current >> implementation is slow. At least going over RPC is greenthread >> friendly where going to the database doesn't seem to be. >> >> Carl >> >> On Fri, May 30, 2014 at 2:56 PM, Eugene Nikanorov >> <enikano...@mirantis.com> wrote: >> > Hi Carl, >> > >> > The idea of in-memory storage was discussed for similar problem, but >> might >> > not work for multiple server deployment. >> > Some hybrid approach though may be used, I think. >> > >> > Thanks, >> > Eugene. >> > >> > >> > On Fri, May 30, 2014 at 8:53 PM, Carl Baldwin <c...@ecbaldwin.net> >> wrote: >> >> >> >> This is very similar to IPAM... There is a space of possible ids or >> >> addresses that can grow very large. We need to track the allocation >> >> of individual ids or addresses from that space and be able to quickly >> >> come up with a new allocations and recycle old ones. I've had this in >> >> the back of my mind for a week or two now. >> >> >> >> A similar problem came up when the database would get populated with >> >> the entire free space worth of ip addresses to reflect the >> >> availability of all of the individual addresses. With a large space >> >> (like an ip4 /8 or practically any ip6 subnet) this would take a very >> >> long time or never finish. >> >> >> >> Neutron was a little smarter about this. It compressed availability >> >> in to availability ranges in a separate table. This solved the >> >> original problem but is not problem free. It turns out that writing >> >> database operations to manipulate both the allocations table and the >> >> availability table atomically is very difficult and ends up being very >> >> slow and has caused us some grief. The free space also gets >> >> fragmented which degrades performance. This is what led me -- >> >> somewhat reluctantly -- to change how IPs get recycled back in to the >> >> free pool which hasn't been very popular. >> >> >> >> I wonder if we can discuss a good pattern for handling allocations >> >> where the free space can grow very large. We could use the pattern >> >> for the allocation of both IP addresses, VXlan ids, and other similar >> >> resource spaces. >> >> >> >> For IPAM, I have been entertaining the idea of creating an allocation >> >> agent that would manage the availability of IPs in memory rather than >> >> in the database. I hesitate, because that brings up a whole new set >> >> of complications. I'm sure there are other potential solutions that I >> >> haven't yet considered. >> >> >> >> The L3 subteam is currently working on a pluggable IPAM model. Once >> >> the initial framework for this is done, we can more easily play around >> >> with changing the underlying IPAM implementation. >> >> >> >> Thoughts? >> >> >> >> Carl >> >> >> >> On Thu, May 29, 2014 at 4:01 AM, Xurong Yang <ido...@gmail.com> wrote: >> >> > Hi, Folks, >> >> > >> >> > When we configure VXLAN range [1,16M], neutron-server service costs >> long >> >> > time and cpu rate is very high(100%) when initiation. One test base >> on >> >> > postgresql has been verified: more than 1h when VXLAN range is [1, >> 1M]. >> >> > >> >> > So, any good solution about this performance issue? >> >> > >> >> > Thanks, >> >> > Xurong Yang >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > OpenStack-dev mailing list >> >> > OpenStack-dev@lists.openstack.org >> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > >> >> >> >> _______________________________________________ >> >> OpenStack-dev mailing list >> >> OpenStack-dev@lists.openstack.org >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev