Zone migration

updated: 2020-08-06 08:25

Zone migration

Synopsis

display name: Zone migration

goal: hardware_maintenance

Zone migration using instance and volume migration

This is zone migration strategy to migrate many instances and volumes efficiently with minimum downtime for hardware maintenance.

Requirements

Metrics

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.

Storage cluster data model is also required:

Cinder cluster data model collector

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

Actions

Default Watcher’s actions:

action description
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"
 '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).

Note

Nova API version must be 2.56 or above if destination_node parameter is given.
volume_migrate

Migrates a volume to destination node or type

By using this action, you will be able to migrate cinder volume. Migration type ‘swap’ can only be used for migrating attached volume. Migration type ‘migrate’ can be used for migrating detached volume to the pool of same volume type. Migration type ‘retype’ can be used for changing volume type of detached volume.

The action schema is:

schema = Schema({
    'resource_id': str,  # should be a UUID
    'migration_type': str,  # choices -> "swap", "migrate","retype"
    'destination_node': str,
    'destination_type': str,
})

The resource_id is the UUID of cinder volume to migrate. The destination_node is the destination block storage pool name. (list of available pools are returned by this command: cinder get-pools) which is mandatory for migrating detached volume to the one with same volume type. The destination_type is the destination block storage type name. (list of available types are returned by this command: cinder type-list) which is mandatory for migrating detached volume or swapping attached volume to the one with different volume type.

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 parameters are:

parameter type default Value description
compute_nodes array None Compute nodes to migrate.
storage_pools array None Storage pools to migrate.
parallel_total integer 6 The number of actions to be run in parallel in total.
parallel_per_node integer 2 The number of actions to be run in parallel per compute node.
parallel_per_pool integer 2 The number of actions to be run in parallel per storage pool.
priority object None List prioritizes instances and volumes.
with_attached_volume boolean False False: Instances will migrate after all volumes migrate. True: An instance will migrate after the attached volumes migrate.

The elements of compute_nodes array are:

parameter type default Value description
src_node string None Compute node from which instances migrate(mandatory).
dst_node string None Compute node to which instances migrate.

The elements of storage_pools array are:

parameter type default Value description
src_pool string None Storage pool from which volumes migrate(mandatory).
dst_pool string None Storage pool to which volumes migrate.
src_type string None Source volume type(mandatory).
dst_type string None Destination volume type (mandatory).

The elements of priority object are:

parameter type default Value description
project array None Project names.
compute_node array None Compute node names.
storage_pool array None Storage pool names.
compute enum None Instance attributes. [“vcpu_num”, “mem_size”, “disk_size”, “created_at”]
storage enum None Volume attributes. [“size”, “created_at”]

Efficacy Indicator

[{'value': 0, 'name': 'live_instance_migrate_ratio', 'unit': '%', 'description': u'Ratio of actual live migrated instances to planned live migrate instances.'}, {'value': 0, 'name': 'cold_instance_migrate_ratio', 'unit': '%', 'description': u'Ratio of actual cold migrated instances to planned cold migrate instances.'}, {'value': 0, 'name': 'volume_migrate_ratio', 'unit': '%', 'description': u'Ratio of actual detached volumes migrated to planned detached volumes migrate.'}, {'value': 0, 'name': 'volume_update_ratio', 'unit': '%', 'description': u'Ratio of actual attached volumes migrated to planned attached volumes migrate.'}]

Algorithm

For more information on the zone migration strategy please refer to: http://specs.openstack.org/openstack/watcher-specs/specs/queens/implemented/zone-migration-strategy.html

How to use it ?

$ openstack optimize audittemplate create \
  at1 hardware_maintenance --strategy zone_migration

$ openstack optimize audit create -a at1 \
  -p compute_nodes='[{"src_node": "s01", "dst_node": "d01"}]'
updated: 2020-08-06 08:25
Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.

found an error? report a bug questions?