Cinder Backend Activities
Revision as of 23:21, 16 September 2013 by Caitlinbestler (talk | contribs) (Optimizing Cinder operations for Storage Appliances)
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.