Jump to: navigation, search

Cinder Backend Activities

Revision as of 20:08, 17 September 2013 by Caitlinbestler (talk | contribs) (Cinder Backend Activities)

Cinder Backend Activities

The Cinder Volume Driver enables storage vendors to adapt Cinder to their specific storage solution by implementing specific actions (such as Create Volume, Snapshot, Clone Snapshot, Backup, Restore, etc.) on the terms that are most efficient for that storage target.

This is especially important when the storage solution the customer has selected is a Storage Appliance, rather than merely using DAS in the Openstack host.

The first round implementation achieves a lot of freedom for the appliance backends, but the interface still imposes several performance penalties:

  • The Volume State
  Backend progress is indicated by updating the 'state' attribute of the Volume object.
  The Volume is placed in a "backing up", or "replicating" state. The Volume Driver interface
  allows the target to remain in use while backup-up/replicating/whatever when it can do so
  safely. For example, storage appliances with efficient snapshot mechanisms will generally
  take a snapshot, backup the snapshot and then delete the snapshot. The volume can remain
  active without impeding use by the compute node that has attached it.
   While that is good, the Volume is still blocked from taking other control plane actions. You
   cannot initiate another backup until the first one is complete. This would also mean that you
   could not re-launch the user, or reassign the volume to a different VM until the operation
   completed.
    The proposals that will be presented will allow the Volume Driver to report progress through
    a taskflow status variable, rather than Volume status variable.
  • Continuous/Ongoing Replication
  Setting up an ongoing replication relationship between a master and one or more slaves is
  an efficient way of providing a hot standby of a volume on another server.
  One specific mechanism that will be proposed is to allow replication of a snapshot from one
  backend target to another target managed by the same Volume Manager. This can be optimized
  to take advantage of available vendor enhancements such as incremental snapshots.
  • Durability across connection loss
  A Volume Driver can recover from a connection loss. But doing so automatically might not be the
  optimum response as that it might delay diagnosis of a network problem unrelated to the actual
  target device.
   A mechanism to allow the volume driver to support a lost connection while still trying to retry that
    connection will be considered.


Volume Driver Capabilities


To properly utilize Volume Driver abilities, the taskflow code will need to be able to read a list of Volume Driver attributes that document these capabilities. These attributes would include:

  • Stateless Activities: list of methods which the Volume Driver can perform without needing to modify the Volume state.
  • Snapshot Replication: Snapshots can be replicated from one target to another within the same Volume Driver family.
  • Backup Compression Techniques: list of compression algorithms that the Volume Driver can apply when taking a Backup.
  • Handle Scope: What is the scope of a backend activity handle?
  * Connection-specific.
  * User specific.
  * Unrestricted