Difference between revisions of "Nova/CachingScheduler"
< Nova
John Garbutt (talk | contribs) (→Configuration) |
John Garbutt (talk | contribs) (→Aims) |
||
Line 2: | Line 2: | ||
https://blueprints.launchpad.net/nova/+spec/caching-scheduler | https://blueprints.launchpad.net/nova/+spec/caching-scheduler | ||
− | == | + | == How it works == |
We can roughly describe scheduling as: | We can roughly describe scheduling as: | ||
Line 9: | Line 9: | ||
The caching scheduler splits this into: | The caching scheduler splits this into: | ||
− | * configure | + | * in the background... |
− | * in the | + | ** admin configure a list of flavors, and how many "slots" for each flavor to reserve |
+ | ** in a periodic task we populate the cache | ||
+ | ** we generate a partial request_spec and run that through the existing filters and weights logic in host manager | ||
+ | ** the save the best hosts, as picked by the filters and weights | ||
+ | ** we try to fill all the request slots, in order | ||
+ | * when a user requests a server... | ||
== Configuration == | == Configuration == |
Revision as of 16:57, 23 January 2014
This wiki page describes the experimental scheduler that is being suggested here: https://blueprints.launchpad.net/nova/+spec/caching-scheduler
How it works
We can roughly describe scheduling as:
- load the current state (expensive, very expensive with current DB call)
- use filters and weights to help pick a host (expensive with lots of hosts)
The caching scheduler splits this into:
- in the background...
- admin configure a list of flavors, and how many "slots" for each flavor to reserve
- in a periodic task we populate the cache
- we generate a partial request_spec and run that through the existing filters and weights logic in host manager
- the save the best hosts, as picked by the filters and weights
- we try to fill all the request slots, in order
- when a user requests a server...
Configuration
[caching_scheduler] # # Options defined in nova.scheduler.caching_scheduler # # Specification of the cache lists, a list of flavor_id. # (multi valued) #cache_list= # Proportion by which to weight number of each flavor. If not # defined, all our evenly weighted (multi valued) #weights= # Number of slots to keep for each flavor with a weight of # one. (floating point value) #factor=1.0 # How often to refresh the cached slots. (integer value) #poll_period=60
Future work
We currently have blueprints to look at:
- Currently this only works with a single scheduler, need to look at either:
- sharing the cache between scheduler, worker populates cache
- locking resources between schedulers (two phase commit), but still have each scheduler with their own cache
- shard hosts so each scheduler deals with a separate list of hosts
- Caching by flavor is probably not always enough, we can look at a more complex cache key, at least including os_type