Revision as of 20:14, 15 October 2013

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.

    Modifying the task status, rather than the Volume status, will be an option only available to
    Volume Drivers that indicate that they implement stateless actions (see "capabilities" later
     on this page). Volume Drivers which are stateful can continue to modify the Volume status
     as is currently done.

• Direct Copy

  Current Cinder backup is very inefficient when the Cinder Backend is external to openstack.
  The current code very inefficiently reads the content over the network from the backend target
  and then puts it to the Object Server after optionally compressing it.

  Having the target put the content directly to the Object Server is far more efficient, even if there
  is no compression.

• 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.

   The methods to support continuous/ongoing replication will include snapshot replication. They
    will be optional capabilities which existing Volume Drivers will not have to implement.

• 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 report a lost connection while still trying to retry that
    connection will be considered.

   This should be a capability reported in the "capabilities" section described later on this page.

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 are discussed in Cinder_Backend_Activity_Attributes.