The watcher.decision_engine.strategy.strategies.workload_balance Module¶

[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 or RAM 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” and “memory.resident” 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.

class watcher.decision_engine.strategy.strategies.workload_balance.WorkloadBalance(config, osc=None)[source]¶

Bases: watcher.decision_engine.strategy.strategies.base.WorkloadStabilizationBaseStrategy

[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 or RAM utilization % is higher than the specified threshold. The VM to be moved should make the host close to average workload of all compute nodes.

Requirements

• Hardware: compute node should use the same physical CPUs/RAMs
• Software: Ceilometer component ceilometer-agent-compute running in each compute node, and Ceilometer API can report such telemetry “cpu_util” and “memory.resident” 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

calculate_used_resource(node)[source]¶

Calculate the used vcpus, memory and disk based on VM flavors

choose_instance_to_migrate(hosts, avg_workload, workload_cache)[source]¶

Pick up an active instance instance to migrate from provided hosts

Parameters:	hosts – the array of dict which contains node object avg_workload – the average workload value of all nodes workload_cache – the map contains instance to workload mapping

do_execute()[source]¶

Strategy execution phase

This phase is where you should put the main logic of your strategy.

filter_destination_hosts(hosts, instance_to_migrate, avg_workload, workload_cache)[source]¶

Only return hosts with sufficient available resources

classmethod get_config_opts()[source]¶

classmethod get_display_name()[source]¶

classmethod get_name()[source]¶

classmethod get_schema()[source]¶

classmethod get_translatable_display_name()[source]¶

group_hosts_by_cpu_or_ram_util()[source]¶

Calculate the workloads of each node

try to find out the nodes which have reached threshold and the nodes which are under threshold. and also calculate the average workload value of all nodes. and also generate the instance workload map.

post_execute()[source]¶

Post-execution phase

This can be used to compute the global efficacy

pre_execute()[source]¶

Pre-execution phase

This can be used to fetch some pre-requisites or data.