Available Plugins¶
In this section we present all the plugins that are shipped along with Watcher. If you want to know which plugins your Watcher services have access to, you can use the Guru Meditation Reports to display them.
Goals¶
Strategies¶
dummy
Dummy strategy used for integration testing via Tempest
Description
This strategy does not provide any useful optimization. Indeed, its only purpose is to be used by Tempest tests.
Requirements
<None>
Limitations
Do not use in production.
Spec URL
<None>
outlet_temperature
[PoC] Outlet temperature control using live migration
Description
It is a migration strategy based on the outlet temperature of compute hosts. It generates solutions to move a workload whenever a server’s outlet temperature is higher than the specified threshold.
Requirements
- Hardware: All computer hosts should support IPMI and PTAS technology
- Software: Ceilometer component ceilometer-agent-ipmi running
in each compute host, and Ceilometer API can report such telemetry
hardware.ipmi.node.outlet_temperature
successfully. - You must have at least 2 physical compute hosts to run this strategy.
Limitations
- This is a proof of concept that is not meant to be used in production
- We cannot forecast how many servers should be migrated. This is the reason why we only plan a single virtual machine migration at a time. So it’s better to use this algorithm with CONTINUOUS audits.
- It assume that live migrations are possible
Spec URL
vm_workload_consolidation
VM Workload Consolidation Strategy.
Description
A load consolidation strategy based on heuristic first-fit algorithm which focuses on measured CPU utilization and tries to minimize hosts which have too much or too little load respecting resource capacity constraints.
This strategy produces a solution resulting in more efficient utilization of cluster resources using following four phases:
- Offload phase - handling over-utilized resources
- Consolidation phase - handling under-utilized resources
- Solution optimization - reducing number of migrations
- Disability of unused hypervisors
A capacity coefficients (cc) might be used to adjust optimization thresholds. Different resources may require different coefficient values as well as setting up different coefficient values in both phases may lead to to more efficient consolidation in the end. If the cc equals 1 the full resource capacity may be used, cc values lower than 1 will lead to resource under utilization and values higher than 1 will lead to resource overbooking. e.g. If targeted utilization is 80 percent of hypervisor capacity, the coefficient in the consolidation phase will be 0.8, but may any lower value in the offloading phase. The lower it gets the cluster will appear more released (distributed) for the following consolidation phase.
As this strategy laverages VM live migration to move the load from one hypervisor to another, this feature needs to be set up correctly on all hypervisors within the cluster. This strategy assumes it is possible to live migrate any VM from an active hypervisor to any other active hypervisor.
Requirements
- You must have at least 2 physical compute nodes to run this strategy.
Limitations
<None>
Spec URL
basic
Basic offline consolidation using live migration
Description
This is server consolidation algorithm which not only minimizes the overall number of used servers, but also minimizes the number of migrations.
Requirements
- You must have at least 2 physical compute nodes to run this strategy.
Limitations
- It has been developed only for tests.
- It assumes that the virtual machine and the compute node are on the same private network.
- It assume that live migrations are possible
Spec URL
<None>
workload_stabilization
Workload Stabilization control using live migration
Description
This is workload stabilization strategy based on standard deviation algorithm. The goal is to determine if there is an overload in a cluster and respond to it by migrating VMs to stabilize the cluster.
Requirements
- Software: Ceilometer component ceilometer-compute running
in each compute host, and Ceilometer API can report such telemetries
memory.resident
andcpu_util
successfully. - You must have at least 2 physical compute nodes to run this strategy.
Limitations
- It assume that live migrations are possible
- Load on the system is sufficiently stable.
Spec URL
https://review.openstack.org/#/c/286153/
workload_balance
[PoC]Workload balance using live migration
Description
It is a migration strategy based on the VM workload of physical servers. It generates solutions to move a workload whenever a server’s CPU utilization % is higher than the specified threshold. The VM to be moved should make the host close to average workload of all hypervisors.
Requirements
- Hardware: compute node should use the same physical CPUs
- Software: Ceilometer component ceilometer-agent-compute running in each compute node, and Ceilometer API can report such telemetry “cpu_util” successfully.
- You must have at least 2 physical compute nodes to run this strategy
Limitations
- This is a proof of concept that is not meant to be used in production
- We cannot forecast how many servers should be migrated. This is the reason why we only plan a single virtual machine migration at a time. So it’s better to use this algorithm with CONTINUOUS audits.
- It assume that live migrations are possible
uniform_airflow
[PoC]Uniform Airflow using live migration
Description
It is a migration strategy based on the Airflow of physical servers. It generates solutions to move vm whenever a server’s Airflow is higher than the specified threshold.
Requirements
- Hardware: compute node with NodeManager3.0 support
- Software: Ceilometer component ceilometer-agent-compute running in each compute node, and Ceilometer API can report such telemetry “airflow, system power, inlet temperature” successfully.
- You must have at least 2 physical compute nodes to run this strategy
Limitations
- This is a proof of concept that is not meant to be used in production
- We cannot forecast how many servers should be migrated. This is the reason why we only plan a single virtual machine migration at a time. So it’s better to use this algorithm with CONTINUOUS audits.
- It assume that live migrations are possible
Actions¶
migrate
Migrates a server to a destination nova-compute host
This action will allow you to migrate a server to another compute destination host. Migration type ‘live’ can only be used for migrating active VMs. Migration type ‘cold’ can be used for migrating non-active VMs as well active VMs, which will be shut down while migrating.
The action schema is:
schema = Schema({
'resource_id': str, # should be a UUID
'migration_type': str, # choices -> "live", "cold"
'dst_hypervisor': str,
'src_hypervisor': str,
})
The resource_id is the UUID of the server to migrate.
The src_hypervisor and dst_hypervisor parameters are respectively the
source and the destination compute hostname (list of available compute
hosts is returned by this command: nova service-list --binary
nova-compute
).
sleep
Makes the executor of the action plan wait for a given duration
The action schema is:
schema = Schema({
'duration': float,
})
The duration is expressed in seconds.
change_nova_service_state
Disables or enables the nova-compute service, deployed on a host
By using this action, you will be able to update the state of a nova-compute service. A disabled nova-compute service can not be selected by the nova scheduler for future deployment of server.
The action schema is:
schema = Schema({
'resource_id': str,
'state': str,
})
The resource_id references a nova-compute service name (list of available
nova-compute services is returned by this command: nova service-list
--binary nova-compute
).
The state value should either be ONLINE or OFFLINE.
nop
logs a message
The action schema is:
schema = Schema({
'message': str,
})
The message is the actual message that will be logged.
Workflow Engines¶
taskflow
Taskflow as a workflow engine for Watcher
Full documentation on taskflow at http://docs.openstack.org/developer/taskflow/
Planners¶
default
Default planner implementation
This implementation comes with basic rules with a set of action types that
are weighted. An action having a lower weight will be scheduled before the
other ones. The set of action types can be specified by ‘weights’ in the
watcher.conf
. You need to associate a different weight to all available
actions into the configuration file, otherwise you will get an error when
the new action will be referenced in the solution produced by a strategy.