On Mon, Nov 18, 2013 at 12:14 PM, Jay Pipes <[email protected]> wrote:
> On 11/18/2013 02:35 PM, Mike Spreitzer wrote: > >> There were some concerns expressed at the summit about scheduler >> scalability in Nova, and a little recollection of Boris' proposal to >> keep the needed state in memory. >> > > While it could be possible to do all of the scheduler state in memory, I > think a better (or at least, less cumbersome initially) approach would > be to add some layers of in-memory caching to any existing parts where > the scheduler currently makes a database query. The problem with this is > Phil Day discussed this at the summit and I have finally gotten around to posting a POC of this. https://review.openstack.org/#/c/57053/<https://review.openstack.org/#/c/57053/1/nova/scheduler/host_manager.py> It is very very rough, but gives the general idea. Small scale testing in devstack showed promising initial results. > that you won't be able to scale out the design -- since the scheduler's > cached pieces cannot be shared easily across distributed nodes. This is > where the concept of using cells and a hierarchical "sieve scheduling" > pattern is used, where higher-level cell schedulers can quickly send a > scheduling request to another cell's scheduler based on a small amount > of information that can generally be compared against in-memory things > (like region, availability zone, type of hypervisor, etc...) > > > I also heard one guy say that he thinks Nova does not really need a >> general SQL database, that a NOSQL database with a bit of >> denormalization and/or client-maintained secondary indices could >> suffice. Has that sort of thing been considered before? What is the >> community's level of interest in exploring that? >> > > Good luck. :) I don't think that whomever suggested that a NoSQL > database with a "bit of denormalization" would suffice for Nova realized > the extent to which the sets of data within Nova's database are highly > relational. You will just end up implementing JOIN algorithms in Python > code and make some of the more advanced search queries much slower, IMO. > > Oh, and BTW, Nova's "database" was originally Redis [1] :) > > Best, > -jay > > [1] > https://github.com/openstack/nova/blob/bf6e6e718cdc7488e2da87b21e258c > cc065fe499/nova/datastore.py > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
