Cinder Backend Activities

= Cinder Backend Activities = This is part of the Cinder Enhancements for Replication (and more) using Stateless Snapshots. CERSS

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

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.
 * Continuous/Ongoing Replication

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.