On 11/20/2013 10:06 AM, Soren Hansen wrote:
2013/11/18 Mike Spreitzer <mspre...@us.ibm.com>:
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.
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.
I may have said something along those lines. Just to clarify -- since
you started this post by talking about scheduler scalability -- the main
motivation for using a non-SQL backend isn't scheduler scalability, it's
availability and resilience. I just don't accept the failure modes that
MySQL (and derivatives such as Galera) impose.
Has that sort of thing been considered before?
It's been talked about on and off since... well, probably since we
started this project.
What is the community's level of interest in exploring that?
The session on adding a backend using a non-SQL datastore was pretty
well attended.
What about a hybrid solution?
There is data that is only used by the scheduler--for performance
reasons maybe it would make sense to store that information in RAM as
described at
https://blueprints.launchpad.net/nova/+spec/no-db-scheduler
For the rest of the data, perhaps it could be persisted using some
alternate backend.
Chris
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
