Storage capacity balance¶
Synopsis¶
display name: Storage Capacity Balance Strategy
goal: workload_balancing
Storage capacity balance using cinder volume migration
Description
This strategy migrates volumes based on the workload of the cinder pools. It makes decision to migrate a volume whenever a pool’s used utilization % is higher than the specified threshold. The volume to be moved should make the pool close to average workload of all cinder pools.
Requirements
You must have at least 2 cinder volume pools to run this strategy.
Limitations
Volume migration depends on the storage device. It may take a long time.
Spec URL
Requirements¶
Metrics¶
None
Cluster data model¶
Storage cluster data model is 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
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 parameter is:
parameter |
type |
default |
Value description |
---|---|---|---|
|
Number |
80.0 |
Volume threshold for capacity balance |
Efficacy Indicator¶
None
Algorithm¶
For more information on the storage capacity balance strategy please refer to: http://specs.openstack.org/openstack/watcher-specs/specs/queens/implemented/storage-capacity-balance.html
How to use it ?¶
$ openstack optimize audittemplate create \
at1 workload_balancing --strategy storage_capacity_balance
$ openstack optimize audit create -a at1 \
-p volume_threshold=85.0
External Links¶
None