Difference between revisions of "Nova/CachingScheduler"
< Nova
John Garbutt (talk | contribs) (→Caching Scheduler) |
John Garbutt (talk | contribs) |
||
| Line 4: | Line 4: | ||
== Aims == | == Aims == | ||
| − | + | 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: | ||
| + | * configure with a list of flavors | ||
| + | * in the background, pi | ||
== Configuration == | == Configuration == | ||
| − | + | <nowiki> | |
| + | [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 | ||
| + | </nowiki> | ||
| + | |||
| + | == 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 | ||
Revision as of 16:50, 23 January 2014
This wiki page describes the experimental scheduler that is being suggested here: https://blueprints.launchpad.net/nova/+spec/caching-scheduler
Aims
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:
- configure with a list of flavors
- in the background, pi
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
