Replicate snapshots from one Cinder backend to another

Registered by Caitlin Bestler

Define methods to enable replication of snapshots between Cinder backends under control of the Volume Driver.

Blueprint information

Status:
Complete
Approver:
John Griffith
Priority:
Undefined
Drafter:
Caitlin Bestler
Direction:
Needs approval
Assignee:
Victor Ordaz
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Sean McGinnis

Related branches

Sprints

Whiteboard

(smcginnis): Marking obsolete as this has been sitting out there for a long time. If this is still needed, please submit a new bp.

Define a volume driver method to optimize replication of a snapshot between two volume
backends controlled by the volume driver.

Why replicate snapshots rather than volumes?

* Snapshots are already quiescent. There is no extra work required to ship a consistent set of bytes
   to the destination. In fact, many volume drivers will implement volume replication by first creating
   a snapshot of the volume.
* Snapshots can be organized in a sequence, and the content of a new snapshot can be
   transferred more efficiently when expressed as a delta from a shared older snapshot.
* When replicating volumes it is frequently desirable to replicate at least the most recent N
   snapshots at the same time.
* Migrating a volume can be done more efficiently by first migrating snapshots, especially
  when the backends support incremental snapshots, while keeping the source volume alive.
  You simply iterate through shorter-duration incremental snapshots before finally quiescing
   the source volume.

Why snapshots rather than backups?

* Snapshots will be in a format chosen by the backend vendor, and hence optimized for that
   environment. Backups are formatted to be stored as a single blob in an object service that
   understands nothing about their structure or meaning.

Default algorithms will be used when replicating snapshots across different volume-drivers,
or when a volume driver feels that there is no optimization for it to perform.

snapshot_replicate (snapshot,source_server,destination_server[,force_full_copy])

   snapshot: the snapshot to be replicated.
   source_Server: the volume server where the snapshot currently is found.
   destination_server: the volume server where the snapshot is to be created.
   force_full_copy: optional parameter that suppresses use of vendor-specific
      options which would optimize the replication based upon prior replication
      of earier snapshots for the same object.

As with the other replicate methods, this method may yield an external-activity.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.