On 11/21/2013 10:52 AM, Stephen Gran wrote:
On 21/11/13 15:49, Chris Friesen wrote:
On 11/21/2013 02:58 AM, Soren Hansen wrote:
2013/11/20 Chris Friesen <chris.frie...@windriver.com>:
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
I suspect that a large performance gain could be had by 2 fairly simple
changes:
a) Break the scheduler in two, so that the chunk of code receiving
updates from the compute nodes can't block the chunk of code scheduling
instances.
b) Use a memcache backend instead of SQL for compute resource information.
My fear with keeping data local to a scheduler instance is that local
state destroys scalability.
"a" and "b" are basically what is described in the blueprint above.
Your fear is addressed by having the compute nodes broadcast their
resource information to all scheduler instances.
As I see it, the scheduler could then make a tentative scheduling
decision, attempt to reserve the resources from the compute node (which
would trigger the compute node to send updated resource information in
all the scheduler instances), and assuming it got the requested
resources it could then proceed with bringing up the resource.
Chris
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
