Workload Balance Migration Strategy

Synopsis

display name: workload_balance

goal: workload_balancing

[PoC]Workload balance using live migration

Description

This strategy migrates a VM based on the VM workload of the hosts. It makes decision to migrate a workload whenever a host’s CPU utilization % is higher than the specified threshold. The VM to be moved should make the host close to average workload of all hosts nodes.

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.

Requirements

None.

Metrics

The workload_balance strategy requires the following metrics:

metric service name plugins comment
cpu_util ceilometer none  

Cluster data model

Default Watcher’s Compute cluster data model:

Nova cluster data model collector

The Nova cluster data model collector creates an in-memory representation of the resources exposed by the compute service.

Actions

Default Watcher’s actions:

action description
migration

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"
 'destination_node': str,
 'source_node': str,
})

The resource_id is the UUID of the server to migrate. The source_node and destination_node 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).

Planner

Default Watcher’s planner:

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.

Configuration

Strategy parameters are:

parameter type default Value description
threshold Number 25.0 Workload threshold for migration
period Number 300 Aggregate time period of ceilometer

Efficacy Indicator

None

Algorithm

For more information on the Workload Balance Migration Strategy please refer to: https://specs.openstack.org/openstack/watcher-specs/specs/mitaka/implemented/workload-balance-migration-strategy.html

How to use it ?

$ openstack optimize audittemplate create \
  at1 workload_balancing --strategy workload_balance

$ openstack optimize audit create -a at1 -p threshold=26.0 \
        -p period=310