Fix formatting problem in README
This patch also includes minor updates. Change-Id: I5e8d52a12d6dd1bddeadacab3a66126decf358db Fixes bug 1455696
This commit is contained in:
Xinyuan Huang
parent
8c2b140f56
commit
3aae5eda0a
220
README.rst
220
README.rst
|
|
@ -6,134 +6,144 @@ A new OpenStack Nova scheduler driver based on constraints-based optimization
|
|||
solvers.
|
||||
|
||||
* Free software: Apache license
|
||||
* Source: http://git.openstack.org/cgit/stackforge/nova-solver-scheduler
|
||||
* Bugs: https://bugs.launchpad.net/nova-solver-scheduler
|
||||
* Blueprints: https://blueprints.launchpad.net/nova-solver-scheduler
|
||||
* Source: https://git.openstack.org/openstack/nova-solver-scheduler
|
||||
* Bugs: https://bugs.launchpad.net/nova-solver-scheduler
|
||||
|
||||
## Overview
|
||||
Overview
|
||||
--------
|
||||
|
||||
Solver Scheduler is an OpenStack Nova scheduler driver that provides smart, efficient, and optimization based compute resource scheduling in Nova. It is a pluggable scheduler driver, that can leverage existing constraint solvers available in open source such as PULP, CVXOPT, Google OR-TOOLS, etc. It can be easily extended to add complex constraint models for various use cases, and to solve complex scheduling problems with pulggable solving frameworks.
|
||||
Solver Scheduler is an OpenStack Nova scheduler driver that provides smart, efficient, and optimization based compute resource scheduling in Nova. It is a pluggable scheduler driver, that can leverage existing constraint solvers available in open source such as PULP, CVXOPT, Google OR-TOOLS, etc. It can be easily extended to add complex constraint models for various use cases, and to solve complex scheduling problems with pulggable solving frameworks.
|
||||
|
||||
## From filter-scheduler to solver-scheduler
|
||||
From filter-scheduler to solver-scheduler
|
||||
-----------------------------------------
|
||||
|
||||
The nova-solver-scheduler works in a similar (but different) way as Nova's default filter-scheduler. It is designed to have the following 3-layer pluggable architecture, compared with filter-scheduler's 2-layer architecture.
|
||||
The nova-solver-scheduler works in a similar (but different) way as Nova's default filter-scheduler. It is designed to have the following 3-layer pluggable architecture, compared with filter-scheduler's 2-layer architecture.
|
||||
|
||||
* Filter-scheduler architecture
|
||||
- Scheduler driver: FilterScheduler. This is a driver that realizes the filter based scheduling functionalities. It is plugged into Nova scheduler service, and configured by the second layer plug-in's, which are known as weighers and filters.
|
||||
- Configurable plug-ins: Weights/Filters. They are the configuration units that defines the behaviour of the filter-scheduler, where filters decide which hosts are available for user requested instance, and weights are then used to sort filtered hosts to find a best one to place the instance.
|
||||
* Filter-scheduler architecture
|
||||
|
||||
* Solver-scheduler architecture
|
||||
- Scheduler driver: SolverScheduler. This is a driver that realizes constraint optimization based scheduling functionalities. It sits in parellel with FilterScheduler and can be used as an (advanced) alternative. It uses pluggable opeimization solver modules to solve scheduling problems.
|
||||
- Solver drivers. The solver drivers are pluggavle optimization solvers that solve scheduling problems defined by its lower layer plug-in's, which are costs/constraints. The pluggable solvers provide more flexibility for complex scheduling scenarios as well as the ability to give more optimimal scheduling solutions.
|
||||
- Configurable plug-ins: Costs/Constraints. Similar as weights/filters in the filter-scheduler. The constraints define the hard restrictions of hosts that cannot be violated, and the costs define the soft objectives that the scheduler should tend to achieve. Scheduler solver will give an overall optimized solution for the placement of all requested instances in each single instance creation request. The costs/constraints can be plugged and configured in a similar way as weights/filters in Nova's default filter scheduler.
|
||||
* Scheduler driver: FilterScheduler. This is a driver that realizes the filter based scheduling functionalities. It is plugged into Nova scheduler service, and configured by the second layer plug-in's, which are known as weighers and filters.
|
||||
* Configurable plug-ins: Weights/Filters. They are the configuration units that defines the behaviour of the filter-scheduler, where filters decide which hosts are available for user requested instance, and weights are then used to sort filtered hosts to find a best one to place the instance.
|
||||
|
||||
* Solver-scheduler architecture
|
||||
|
||||
* Scheduler driver: SolverScheduler. This is a driver that realizes constraint optimization based scheduling functionalities. It sits in parellel with FilterScheduler and can be used as an (advanced) alternative. It uses pluggable opeimization solver modules to solve scheduling problems.
|
||||
* Solver drivers. The solver drivers are pluggavle optimization solvers that solve scheduling problems defined by its lower layer plug-in's, which are costs/constraints. The pluggable solvers provide more flexibility for complex scheduling scenarios as well as the ability to give more optimimal scheduling solutions.
|
||||
* Configurable plug-ins: Costs/Constraints. Similar as weights/filters in the filter-scheduler. The constraints define the hard restrictions of hosts that cannot be violated, and the costs define the soft objectives that the scheduler should tend to achieve. Scheduler solver will give an overall optimized solution for the placement of all requested instances in each single instance creation request. The costs/constraints can be plugged and configured in a similar way as weights/filters in Nova's default filter scheduler.
|
||||
|
||||
While it appears to the user that the solver scheduler with costs/constraints provides similar functionalities as filter scheduler with weights/filters, solver scheduler can be more efficient in large scale high amount scheduling problems (e.g. placing 500 instances in a 1000 node cluster in a single request), the scheduling solution from the solver scheduler is also more optimal compared with that from filter scheduler due to its more flexible designs.
|
||||
|
||||
## Basic configurations
|
||||
Basic configurations
|
||||
--------------------
|
||||
|
||||
In order to enable nova-solver-scheduler, we need to have the following minimal configurations in the "[default]" section of nova.conf. Please overwrite the config options' values if the option keys already exist in the configuration file.
|
||||
```
|
||||
[DEFAULT]
|
||||
... (other options)
|
||||
scheduler_driver=nova_solverscheduler.scheduler.solver_scheduler.ConstraintSolverScheduler
|
||||
scheduler_host_manager=nova_solverscheduler.scheduler.solver_scheduler_host_manager.SolverSchedulerHostManager
|
||||
```
|
||||
In order to enable nova-solver-scheduler, we need to have the following minimal configurations in the "[default]" section of nova.conf. Please overwrite the config options' values if the option keys already exist in the configuration file.
|
||||
|
||||
## Solvers
|
||||
::
|
||||
|
||||
We provide 2 solvers that can plug-in-and-solve the scheduling problems by satisfying all the configured constraints: FastSolver (default), and PulpSolver. The FastSolver runs a fast algorithm that can solve large scale scheduling requests efficiently while giving optimal solutions. The PulpSolver translates the scheduling problems into standard LP (Linear Programming) problems, and invokes a 3rd party LP solver interface (coinor.pulp >= 1.0.4) to solve the scheduling problems. While PulpSolver might be more flexible for complex constraints (which might happen in the future), it works slower than the FastSolver especially in large scale scheduling problems.
|
||||
We recommend using FastSolver at the current stage, as it covers all (currently) known constraint requirements, and scales better.
|
||||
The following option in the "[solver_scheduler]" section of nova config should be used to specify which solver to use. Please add a new section title called "[solver_scheduler]" if it (probably) doesn't already exist in the nova config file.
|
||||
[DEFAULT]
|
||||
# ... (other options)
|
||||
scheduler_driver=nova_solverscheduler.scheduler.solver_scheduler.ConstraintSolverScheduler
|
||||
scheduler_host_manager=nova_solverscheduler.scheduler.solver_scheduler_host_manager.SolverSchedulerHostManager
|
||||
|
||||
```
|
||||
[solver_scheduler]
|
||||
scheduler_host_solver=nova_solverscheduler.scheduler.solvers.fast_solver.FastSolver
|
||||
```
|
||||
Solvers
|
||||
-------
|
||||
|
||||
## Costs and Constraints
|
||||
We provide 2 solvers that can plug-in-and-solve the scheduling problems by satisfying all the configured constraints: FastSolver (default), and PulpSolver. The FastSolver runs a fast algorithm that can solve large scale scheduling requests efficiently while giving optimal solutions. The PulpSolver translates the scheduling problems into standard LP (Linear Programming) problems, and invokes a 3rd party LP solver interface (coinor.pulp >= 1.0.4) to solve the scheduling problems. While PulpSolver might be more flexible for complex constraints (which might happen in the future), it works slower than the FastSolver especially in large scale scheduling problems.
|
||||
|
||||
### Configuring which costs/constraints to use
|
||||
We recommend using FastSolver at the current stage, as it covers all (currently) known constraint requirements, and scales better.
|
||||
The following option in the "[solver_scheduler]" section of nova config should be used to specify which solver to use. Please add a new section title called "[solver_scheduler]" if it (probably) doesn't already exist in the nova config file.
|
||||
|
||||
Solver-scheduler uses "costs" and "constraints" to configure the behaviour of scheduler. They can be set in a similar way as "weights" and "filters" in the filter-scheduler.
|
||||
::
|
||||
|
||||
Here is an example for setting which "costs" to use, pleas put these options in the "[solver_scheduler]" section of nova config, each "cost" has a multiplier associated with it to specify its weight in the scheduler decision:
|
||||
```
|
||||
[solver_scheduler]
|
||||
... (other options)
|
||||
scheduler_solver_costs=RamCost,AffinityCost,AntiAffinityCost
|
||||
ram_cost_multiplier=1.0
|
||||
affinity_cost_multiplier=2.0
|
||||
anti_affinity_cost_multiplier=0.5
|
||||
```
|
||||
[solver_scheduler]
|
||||
scheduler_host_solver=nova_solverscheduler.scheduler.solvers.fast_solver.FastSolver
|
||||
|
||||
**Notes**
|
||||
Tips about the cost multipliers' values:
|
||||
Costs and Constraints
|
||||
---------------------
|
||||
|
||||
Cost class | Multiplier
|
||||
---------- | ----------
|
||||
RamCost | \> 0: the scheduler will tend to balance the usage of RAM. The higher the value, the more weight the cost will get in scheduler's decision.<br>\< 0: the scheduler will tend to stack the RAM usage. The higher the *absolute* value, the more weight the cost will get in scheduler's decision.<br>= 0: the cost will be ignored.
|
||||
MetricsCost | \> 0: The higher the value, the more weight the cost will get in scheduler's decision.<br>\< 0: Not recommended. Might not make the cost meaningful.<br>= 0: the cost will be ignored.
|
||||
Configuring which costs/constraints to use
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The followings is an example of how to set which "constraints" to be used by the solver-scheduler.
|
||||
```
|
||||
[solver_scheduler]
|
||||
... (other options)
|
||||
scheduler_solver_constraints=ActiveHostsConstraint,RamConstraint,NumInstancesConstraint
|
||||
```
|
||||
Solver-scheduler uses "costs" and "constraints" to configure the behaviour of scheduler. They can be set in a similar way as "weights" and "filters" in the filter-scheduler.
|
||||
|
||||
In the following section we will discuss the detailed cost and constraint classes.
|
||||
Here is an example for setting which "costs" to use, pleas put these options in the "[solver_scheduler]" section of nova config, each "cost" has a multiplier associated with it to specify its weight in the scheduler decision:
|
||||
|
||||
### Transition from filter-scheduler to solver-scheduler
|
||||
::
|
||||
|
||||
The table below lists supported constraints and their counterparts in filter scheduler. Those costs and constraints can be used in the same way as the weights/filters in the filter scheduler except the above option-setting. Please refer to [OpenStack Configuration Reference](http://docs.openstack.org/icehouse/config-reference/content/section_compute-scheduler.html) for detailed explanation of available weights and filters and their usage instructions.
|
||||
[solver_scheduler]
|
||||
# ... (other options)
|
||||
scheduler_solver_costs=RamCost,AffinityCost,AntiAffinityCost
|
||||
ram_cost_multiplier=1.0
|
||||
affinity_cost_multiplier=2.0
|
||||
anti_affinity_cost_multiplier=0.5
|
||||
|
||||
Weight | Cost
|
||||
------ | ----
|
||||
MetricsWeigher | MetricsCost
|
||||
RAMWeigher | RamCost
|
||||
The followings is an example of how to set which "constraints" to be used by the solver-scheduler.
|
||||
|
||||
Filter | Constraint
|
||||
------ | ----------
|
||||
AggregateCoreFilter | AggregateVcpuConstraint
|
||||
AggregateDiskFilter | AggregateDiskConstraint
|
||||
AggregateImagePropertiesIsolation | AggregateImagePropertiesIsolationConstraint
|
||||
AggregateInstanceExtraSpecsFilter | AggregateInstanceExtraSpecsConstraint
|
||||
AggregateMultiTenancyIsolation | AggregateMultiTenancyIsolationConstraint
|
||||
AggregateRamFilter | AggregateRamConstraint
|
||||
AggregateTypeAffinityFilter | AggregateTypeAffinityConstraint
|
||||
AllHostsFilter | NoConstraint
|
||||
AvailabilityZoneFilter | AvailabilityZoneConstraint
|
||||
ComputeCapabilitiesFilter | ComputeCapabilitiesConstraint
|
||||
ComputeFilter | ActiveHostsConstraint
|
||||
CoreFilter | VcpuConstraint
|
||||
DifferentHostFilter | DifferentHostConstraint
|
||||
DiskFilter | DiskConstraint
|
||||
ImagePropertiesFilter | ImagePropertiesConstraint
|
||||
IsolatedHostsFilter | IsolatedHostsConstraint
|
||||
IoOpsFilter | IoOpsConstraint
|
||||
JsonFilter | JsonConstraint
|
||||
MetricsFilter | MetricsConstraint
|
||||
NumInstancesFilter | NumInstancesConstraint
|
||||
PciPassthroughFilter | PciPassthroughConstraint
|
||||
RamFilter | RamConstraint
|
||||
RetryFilter | RetryConstraint
|
||||
SameHostFilter | SameHostConstraint
|
||||
ServerGroupAffinityFilter | ServerGroupAffinityConstraint
|
||||
ServerGroupAntiAffinityFilter | ServerGroupAntiAffinityConstraint
|
||||
SimpleCIDRAffinityFilter | SimpleCidrAffinityConstraint
|
||||
TrustedFilter | TrustedHostsConstraint
|
||||
TypeAffinityFilter | TypeAffinityConstraint
|
||||
::
|
||||
|
||||
**Notes**
|
||||
Some of the above constraints directly invoke their filter counterparts to check host availability, others (in the following list) are implemented with improved logic that may result in more optimal placement decisions for multi-instance requests:
|
||||
- DiskConstraint
|
||||
- AggregateDiskConstraint (inherited from DiskConstraint)
|
||||
- RamConstraint
|
||||
- AggregateRamConstraint (inherited from RamConstraint)
|
||||
- VcpuConstraint
|
||||
- AggregateVcpuConstraint (inherited from VcpuConstraint)
|
||||
- IoOpsConstraint
|
||||
- NumInstancesConstraint
|
||||
- PciPassthroughConstraint
|
||||
- ServerGroupAffinityConstraint
|
||||
- ServerGroupAntiAffinityConstraint
|
||||
[solver_scheduler]
|
||||
# ... (other options)
|
||||
scheduler_solver_constraints=ActiveHostsConstraint,RamConstraint,NumInstancesConstraint
|
||||
|
||||
In the following section we will discuss the detailed cost and constraint classes.
|
||||
|
||||
Transition from filter-scheduler to solver-scheduler
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The table below lists supported constraints and their counterparts in filter scheduler. Those costs and constraints can be used in the same way as the weights/filters in the filter scheduler except the above option-setting. Please refer to [OpenStack Configuration Reference](http://docs.openstack.org/icehouse/config-reference/content/section_compute-scheduler.html) for detailed explanation of available weights and filters and their usage instructions.
|
||||
|
||||
================ ============
|
||||
Weight Cost
|
||||
================ ============
|
||||
MetricsWeigher MetricsCost
|
||||
RAMWeigher RamCost
|
||||
================ ============
|
||||
|
||||
================================================ ================================================
|
||||
Filter Constraint
|
||||
================================================ ================================================
|
||||
AggregateCoreFilter AggregateVcpuConstraint
|
||||
AggregateDiskFilter AggregateDiskConstraint
|
||||
AggregateImagePropertiesIsolation AggregateImagePropertiesIsolationConstraint
|
||||
AggregateInstanceExtraSpecsFilter AggregateInstanceExtraSpecsConstraint
|
||||
AggregateMultiTenancyIsolation AggregateMultiTenancyIsolationConstraint
|
||||
AggregateRamFilter AggregateRamConstraint
|
||||
AggregateTypeAffinityFilter AggregateTypeAffinityConstraint
|
||||
AllHostsFilter NoConstraint
|
||||
AvailabilityZoneFilter AvailabilityZoneConstraint
|
||||
ComputeCapabilitiesFilter ComputeCapabilitiesConstraint
|
||||
ComputeFilter ActiveHostsConstraint
|
||||
CoreFilter VcpuConstraint
|
||||
DifferentHostFilter DifferentHostConstraint
|
||||
DiskFilter DiskConstraint
|
||||
ImagePropertiesFilter ImagePropertiesConstraint
|
||||
IsolatedHostsFilter IsolatedHostsConstraint
|
||||
IoOpsFilter IoOpsConstraint
|
||||
JsonFilter JsonConstraint
|
||||
MetricsFilter MetricsConstraint
|
||||
NumInstancesFilter NumInstancesConstraint
|
||||
PciPassthroughFilter PciPassthroughConstraint
|
||||
RamFilter RamConstraint
|
||||
RetryFilter RetryConstraint
|
||||
SameHostFilter SameHostConstraint
|
||||
ServerGroupAffinityFilter ServerGroupAffinityConstraint
|
||||
ServerGroupAntiAffinityFilter ServerGroupAntiAffinityConstraint
|
||||
SimpleCIDRAffinityFilter SimpleCidrAffinityConstraint
|
||||
TrustedFilter TrustedHostsConstraint
|
||||
TypeAffinityFilter TypeAffinityConstraint
|
||||
================================================ ================================================
|
||||
|
||||
**Notes**
|
||||
|
||||
Some of the above constraints directly invoke their filter counterparts to check host availability, others (in the following list) are implemented with improved logic that may result in more optimal placement decisions for multi-instance requests:
|
||||
|
||||
* DiskConstraint
|
||||
* AggregateDiskConstraint (inherited from DiskConstraint)
|
||||
* RamConstraint
|
||||
* AggregateRamConstraint (inherited from RamConstraint)
|
||||
* VcpuConstraint
|
||||
* AggregateVcpuConstraint (inherited from VcpuConstraint)
|
||||
* IoOpsConstraint
|
||||
* NumInstancesConstraint
|
||||
* PciPassthroughConstraint
|
||||
* ServerGroupAffinityConstraint
|
||||
* ServerGroupAntiAffinityConstraint
|
||||
|
|
|
|||
Loading…
Reference in New Issue