VolumeAffinity - Revision history

Ryan Lane: Text replace - "NOTOC" to ""

2013-02-17T23:30:59Z

Text replace - "__NOTOC__" to ""

Duncan: Antoher typo

2011-10-27T16:38:34Z

Antoher typo

Duncan: typos

2011-10-27T15:56:47Z

typos

Duncan: typo

2011-10-27T15:54:41Z

typo

Duncan at 15:51, 27 October 2011

2011-10-27T15:51:00Z

New page

__NOTOC__
= 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 optimised 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.

For example an example of anti-affinity, if a user wants to create a mirrored pair of volumes for reliability or disaster recovery, then these volumes 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().

← Older revision		Revision as of 23:30, 17 February 2013
Line 1:		Line 1:
−	~~__NOTOC__~~	+
	= Volume Affinity for scheduling =		= Volume Affinity for scheduling =

@@ Line 10: / Line 10: @@
 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 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 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.