Storage Load balancing

Introduction

Currently CloudStack does not support any type of storage load balancing. It always lists the primary storage and secondary storage in same order and the pick the first one which satisfies the criteria. If user wants to load balance then there is no way for user to tell volume to go to different primary storage or secondary storage.

Purpose

This is the functional specification of the feature ‘Storage Load Balancing'.

References

JIRA Ticket

Unable to render Jira issues macro, execution error.  

Branch

Master

Document History

Glossary

Use case

• User may want to load balance volumes across multiple primary storage and secondary storage
• User may want to load balance volumes according to some criteria like FirstFit, Random etc.

Feature specification

• Support storage load balancing.

Test guidelines

• Volumes/Snapshots created are properly getting load balanced across multiple primary storage.
• Volumes should not be unnecessarily migrated to different storages

Error handling

• All errors at various levels of operations will be logged in management-server.log.

Audit Events

NA

Target users

1. CloudStack Users and Admins.

Design description

In allocators before returning suitable pools/image stores sort the list according to user chosen algorithm given through setting (see section Global Settings Added) and then return appropriate storage pools/image stores. This will only be applied only when there is such choice available and will not change existing logic which makes consideration to reduce data transfer usage.

Limitations

• TODO: update with findings.

Work Flow

User will update the global settings as defined below and then volumes will start getting allocated appropriately.

Global Settings Added

1. vm.pool.allocation.algorithm: This can take one of the following values

           firstfit, random, firstfitleastconsumed

          These values have meaning as follows:

• •  firstfit: Will not sort the available pools and return the list as it is.
  •  random: Available pools will be shuffled an then returned
  •  firstfitleastconsumed: Volume will be allocated to pool which has more space available
  •  default: Pool allocation algorithm will be inferred from vm.allocation.algorithm. This will be the default value and is inline with existing behaviour. This was not working properly due to one bug. 

     2. image.store.allocation.algorithm: This can take one of the following values.

           firstfit, random, firstfitleastconsumed

           These values have meaning as follows:

• •  firstfit: Will not sort the available image stores and return the list as it is.
  •  random: Available pools will be shuffled and then returned. This will be the default value and is inline with existing behaviour. 
  •  firstfitleastconsumed: Volume will be allocated to image store which has more space available

     3. image.store.disable.threshold: Will not use image store when the usage is above this threshold. Default value is 0.9 which is inline with existing behaviour.

API Changes

No changes

DB Changes

No changes

Hypervisors supported

Applicable to All Hypervisors

UI Changes

No changes

Upgrade

N/A

Open Items/Questions

N/A

References

N/A