Excerpts from Chris Friesen's message of 2013-11-19 09:29:00 -0800: > On 11/18/2013 06:47 PM, Joshua Harlow wrote: > > An idea related to this, what would need to be done to make the DB have > > the exact state that a compute node is going through (and therefore the > > scheduler would not make unreliable/racey decisions, even when there are > > multiple schedulers). It's not like we are dealing with a system which > > can not know the exact state (as long as the compute nodes are connected > > to the network, and a network partition does not occur). > > How would you synchronize the various schedulers with each other? > Suppose you have multiple scheduler nodes all trying to boot multiple > instances each. > > Even if each at the start of the process each scheduler has a perfect > view of the system, each scheduler would need to have a view of what > every other scheduler is doing in order to not make racy decisions. >
Your question assumes they need to be "in sync" at a granular level. Each scheduler process can own a different set of resources. If they each grab instance requests in a round-robin fashion, then they will fill their resources up in a relatively well balanced way until one scheduler's resources are exhausted. At that time it should bow out of taking new instances. If it can't fit a request in, it should kick the request out for retry on another scheduler. In this way, they only need to be in sync in that they need a way to agree on who owns which resources. A distributed hash table that gets refreshed whenever schedulers come and go would be fine for that. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
