Jump to: navigation, search

Difference between revisions of "Nova/InstanceLevelSnapshots"

(Nova Instance-Level Snapshots)
(Nova Instance-Level Snapshots)
Line 1: Line 1:
= Nova Instance-Level Snapshots =
 
  
In a nutshell, we want the ability to take a snapshot of a running instance along with all attached volumes as a single psuedo-atomic operation.  This gives the user a filesystem-consistent snapshot (with qemu-assisted) or application-consistent snapshot (with guest-assisted) of all local storage accessible to a particular virtual machine at that time.
+
== Instance-Level Snapshots ==
  
== Current Behaviour ==
+
Openstack should have the ability to take a snapshot of a running instance that includes all of its attached volumes. A coordinated snapshot of multiple volumes for backup purposes. The snapshot operation should occur while the instance is in a paused and quiesced state so that each snapshot is both consistent within itself and with respect to its sibling snapshots.
  
Today a user can request a snapshot of a VM and that snapshot will contain only the contents of the rool volume.  Both image-backed and volume-backed root volumes are supported.  For image-backed instances, the resulting snapshot will be contained by glance as an available image.  For volume-backed instances, the resulting snapshot is contained by cinder as an available volume.  At snapshot-time, any additional attached volumes must be snapshotted separately, leaving no option to capture them all at once.
+
=== Existing Behaviour ===
  
== Desired Behaviour ==
+
There are two snapshot operations that exist in Openstack at the moment.
  
A way to indicate to create_image() that all attached volume should be included in a snapshot.
+
# A user can create an image of a running instance using the <code>createImage</code> API call. This will create a &quot;template&quot; that can be used to spin up new instances from and is referred to by Glance, regardless of where it's stored. This operation will only capture the contents of the root volume.
 +
# A user can create a snapshot of an attached volume through Cinder. This snapshot is a new volume that can be managed just as any other Cinder volume.
  
== Proposed Changes ==
 
  
The entry point to the Nova API for this feature is create_image().  This method will be modified to look for an additional aoption 'all_volumes'.  If this option is presen and is set to True, then create_image() will ensure that a snapshot request is issued for all attached volumes.  The resulting snapshot will be a combination of the root volume snapshot along with additional cinder volume snapshots.  These snapshots will be named in such a way to make correlation by the user an easy operation.  The naming scheme will be covered later in this document.
+
The user must choose between one of these two, thus I propose adding functionality that allows a user to create a snapshot that includes both the root volume and all attached cinder volumes in a single pseudo-atomic operation.
  
The all_volumes flag will be passed to the compute_api, either snapshot() for image-backed instances or snapshot_volume_backed() for volume-backed instances.  Regardless of the different snapshot implementations, the modified logic will be similar to the following pseudocode:
+
=== Timeline ===
  
  * volumes = get_all_attached_volumes()
+
Maybe Icehouse 3 dependent on required libvirt changes. Libvirt may need to expose additional operations for this feature to be properly supported. See below for further details.
  * freeze_instance()
 
  * snapshot_root_volume()
 
  * for volume in volumes:
 
        snapshot_volume(volume, clever_name)            [volume_api.create_snapshot() via cinder]
 
  * thaw_instance()
 
  * collect metadata for response
 
  * return response
 
  
== Missing Pieces ==
+
=== API Changes ===
  
The primary missing piece is freeze/thaw.
+
There are two obvious choices:
  
  * Does this functionality exist currently?
+
# Foo
  * If so, can we use it similarily to what is described above?
+
# Bar
  * What other pieces are missing?
 
  
== Todo ==
 
  
  * Cinder volume naming scheme for snapshot correlation
+
The entry point to the Nova API for this feature is create_image(). This method will be modified to look for an additional aoption 'all_volumes'. If this option is presen and is set to True, then create_image() will ensure that a snapshot request is issued for all attached volumes. The resulting snapshot will be a combination of the root volume snapshot along with additional cinder volume snapshots. These snapshots will be named in such a way to make correlation by the user an easy operation. The naming scheme will be covered later in this document.
  
== Resolved Questions ==
+
The all_volumes flag will be passed to the compute_api, either snapshot() for image-backed instances or snapshot_volume_backed() for volume-backed instances.
  
  * Instead of snapshotting the instance, could we get away with *only* the attached volumes?
+
=== Snapshot Consistency ===
I don't see any reason that a user would want all attached volumes without the root volume. If a need does arise for this behaviour, it can be added without too much trouble.
+
 
 +
We should be able to support crash-consistent snapshots without too many requirements on libvirt by simply pausing the VM, requesting snapshots, and resuming. A stretch-goal would be to quiesce the instance to provide filesystem-consistent snapshots. The end goal is to use guest-assisted snapshots for application-consistent snapshots across all volumes.

Revision as of 23:02, 20 December 2013

Instance-Level Snapshots

Openstack should have the ability to take a snapshot of a running instance that includes all of its attached volumes. A coordinated snapshot of multiple volumes for backup purposes. The snapshot operation should occur while the instance is in a paused and quiesced state so that each snapshot is both consistent within itself and with respect to its sibling snapshots.

Existing Behaviour

There are two snapshot operations that exist in Openstack at the moment.

  1. A user can create an image of a running instance using the createImage API call. This will create a "template" that can be used to spin up new instances from and is referred to by Glance, regardless of where it's stored. This operation will only capture the contents of the root volume.
  2. A user can create a snapshot of an attached volume through Cinder. This snapshot is a new volume that can be managed just as any other Cinder volume.


The user must choose between one of these two, thus I propose adding functionality that allows a user to create a snapshot that includes both the root volume and all attached cinder volumes in a single pseudo-atomic operation.

Timeline

Maybe Icehouse 3 dependent on required libvirt changes. Libvirt may need to expose additional operations for this feature to be properly supported. See below for further details.

API Changes

There are two obvious choices:

  1. Foo
  2. Bar


The entry point to the Nova API for this feature is create_image(). This method will be modified to look for an additional aoption 'all_volumes'. If this option is presen and is set to True, then create_image() will ensure that a snapshot request is issued for all attached volumes. The resulting snapshot will be a combination of the root volume snapshot along with additional cinder volume snapshots. These snapshots will be named in such a way to make correlation by the user an easy operation. The naming scheme will be covered later in this document.

The all_volumes flag will be passed to the compute_api, either snapshot() for image-backed instances or snapshot_volume_backed() for volume-backed instances.

Snapshot Consistency

We should be able to support crash-consistent snapshots without too many requirements on libvirt by simply pausing the VM, requesting snapshots, and resuming. A stretch-goal would be to quiesce the instance to provide filesystem-consistent snapshots. The end goal is to use guest-assisted snapshots for application-consistent snapshots across all volumes.