Latest revision as of 23:30, 17 February 2013

Volume Affinity for scheduling

Overview

Related to VolumeTypeScheduler, affinity is the ability to express the relationship between a new volume and other volumes on the system. This relationship may be used by the Volume Type Scheduler to choose the most suitable volume node to create the new volume on, or it may be used by a storage backend to optimise the placement of volume data internally, or both. Any given implementation is free to ignore affinity information, it is advisory only.

Design

Expressing affinity

During volume creation, a volume may express affinity for, or anti-affinity for, one or more existing volumes.

An example of anti-affinity, if a user wants to create a mirrored pair of volumes for reliability or disaster recovery, then these volumes might be created with anti-affinity for each other, expressing to the storage system that these volumes should be stored as independently as possible, e.g. on different storage arrays, on different racks, etc

An example of affinity, if a user is setting up a database server, and is spreading the tables across multiple volumes, then these volumes might be created with affinity to each other, indicating to the storage system that they are likely to be accessed at the same time, allowing the volume creation to be optimised for this sort of access.

VolumeTypes, nova-volume and drivers

Affinity and anti-affinity can be expressed as a set of key-value pairs, and so can use the same interface as VolumeTypeScheduler, so the information will be available to both the scheduler and the driver with no further modifications needed

If the driver wishes affinity to be taken into account by the scheduler, then it can express its existing volume layout via get_volume_stats().