On 10/09/2015 12:25 PM, Alec Hothan (ahothan) wrote:
Still the point from Chris is valid. I guess the main reason openstack is
going with multiple concurrent schedulers is to scale out by distributing the
load between multiple instances of schedulers because 1 instance is too
slow. This discussion is about coordinating the many instances of schedulers
in a way that works and this is actually a difficult problem and will get
worst as the number of variables for instance placement increases (for
example NFV is going to require a lot more than just cpu pinning, huge pages
and numa).
Has anybody looked at why 1 instance is too slow and what it would take to
make 1 scheduler instance work fast enough? This does not preclude the use of
concurrency for finer grain tasks in the background.
Currently we pull data on all (!) of the compute nodes out of the database via a
series of RPC calls, then evaluate the various filters in python code.
I suspect it'd be a lot quicker if each filter was a DB query.
Also, ideally we'd want to query for the most "strict" criteria first, to reduce
the total number of comparisons. For example, if you want to implement the
"affinity" server group policy, you only need to test a single host. If you're
matching against host aggregate metadata, you only need to test against hosts in
matching aggregates.
Chris
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
