Basic Offline Server Consolidation

updated: 2019-04-01 01:33

Basic Offline Server Consolidation¶

Synopsis¶

display name: Basic offline consolidation

goal: server_consolidation

Good server consolidation strategy

Consolidation of VMs is essential to achieve energy optimization in cloud environments such as OpenStack. As VMs are spinned up and/or moved over time, it becomes necessary to migrate VMs among servers to lower the costs. However, migration of VMs introduces runtime overheads and consumes extra energy, thus a good server consolidation strategy should carefully plan for migration in order to both minimize energy consumption and comply to the various SLAs.

This algorithm not only minimizes the overall number of used servers, but also minimizes the number of migrations.

It has been developed only for tests. You must have at least 2 physical compute nodes to run it, so you can easily run it on DevStack. It assumes that live migration is possible on your OpenStack cluster.

Requirements¶

Metrics¶

The basic strategy requires the following metrics:

metric	service name	plugins	comment
`compute.node.cpu.percent`	ceilometer	none
`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).
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,
 'disabled_reason': 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. The disabled_reason references the reason why Watcher disables this nova-compute service. The value should be with watcher_ prefix, such as watcher_disabled, watcher_maintaining.

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`).
`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, 'disabled_reason': 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. The disabled_reason references the reason why Watcher disables this nova-compute service. The value should be with watcher_ prefix, such as watcher_disabled, watcher_maintaining.

Planner¶

Default Watcher’s planner:

Weight planner implementation

This implementation builds actions with parents in accordance with weights. Set of actions having a higher weight will be scheduled before the other ones. There are two config options to configure: action_weights and parallelization.

Limitations

This planner requires to have action_weights and parallelization configs tuned well.

Configuration¶

Strategy parameter is:

parameter	type	default Value	description
`migration_attempts`	Number	0	Maximum number of combinations to be tried by the strategy while searching for potential candidates. To remove the limit, set it to 0
`period`	Number	7200	The time interval in seconds for getting statistic aggregation from metric data source

Efficacy Indicator¶

[{'value': 0, 'name': 'released_nodes_ratio', 'unit': '%', 'description': u'Ratio of released compute nodes divided by the total number of enabled compute nodes.'}]

How to use it ?¶

$ openstack optimize audittemplate create \
  at1 server_consolidation --strategy basic

$ openstack optimize audit create -a at1 -p migration_attempts=4

External Links¶

None.