Jump to: navigation, search

Difference between revisions of "LocalStorageVolume"

 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
+
{{OldDesignPage}}
 +
 
 
----------
 
----------
  
 
* '''Launchpad Cinder blueprint''':  [https://blueprints.launchpad.net/cinder/+spec/local-storage-volume  local-storage-volume]
 
* '''Launchpad Cinder blueprint''':  [https://blueprints.launchpad.net/cinder/+spec/local-storage-volume  local-storage-volume]
 
* '''Created''': 19 September 2012
 
* '''Created''': 19 September 2012
* '''Last updated''': 19 September 2012
+
* '''Last updated''': 09 October 2012
* '''Drafter''': [https://launchpad.net/~zrzhit Rongze Zhu]
+
* '''Drafter''': [https://launchpad.net/~zrzhit Rongze Zhu] [https://launchpad.net/~freedomhui Hui Cheng]
* '''Contributors''': [https://launchpad.net/~zrzhit Rongze Zhu]
+
* '''Contributor''': [https://launchpad.net/~zrzhit Rongze Zhu] [https://launchpad.net/~freedomhui Hui Cheng]
  
<<[[TableOfContents]]()>>
+
__TOC__
  
 
== Glossary ==
 
== Glossary ==
Line 20: Line 21:
 
== Summary ==
 
== Summary ==
  
The goal of this blueprint is to implement a driver for cinder. This will allow to create volume in local storage and back up point-in-time snapshots of your data to Swift for durable recovery. This snapshots are incremental backups, meaning that only the blocks on the volume that have changed since your last snapshot will be saved.  
+
The goal of this blueprint is to implement a plugin for cinder. This will allow to create volume in local storage and back up point-in-time snapshots of your data to Swift for durable recovery. This snapshots are incremental backups, meaning that only the blocks on the volume that have changed since your last snapshot will be saved.  
  
 
Even though the snapshots are saved incrementally, when you delete a snapshot, only the data not needed for any other snapshot is removed. So regardless of which prior snapshots have been deleted, all active snapshots will contain all the information needed to restore the volume. In addition, the time to restore the volume is the same for all snapshots, offering the restore time of full backups with the space savings of incremental.
 
Even though the snapshots are saved incrementally, when you delete a snapshot, only the data not needed for any other snapshot is removed. So regardless of which prior snapshots have been deleted, all active snapshots will contain all the information needed to restore the volume. In addition, the time to restore the volume is the same for all snapshots, offering the restore time of full backups with the space savings of incremental.
  
 
All in a word, our solutions is local storage + qcow2 image + dependent snapshot + swift. This is like [http://wiki.cloudstack.org/display/RelOps/Local+storage+for+data+volumes  cloudstack:local storage for data volumes], but we have incremental snapshot than cloundstack.
 
All in a word, our solutions is local storage + qcow2 image + dependent snapshot + swift. This is like [http://wiki.cloudstack.org/display/RelOps/Local+storage+for+data+volumes  cloudstack:local storage for data volumes], but we have incremental snapshot than cloundstack.
 +
 +
The name of the plugin is '''''island'''''.
  
 
== Rationale ==
 
== Rationale ==
Line 33: Line 36:
 
* cost reduction from using inexpensive local disks
 
* cost reduction from using inexpensive local disks
 
* raid 10 in local storage have a better reliability.
 
* raid 10 in local storage have a better reliability.
* user create snapshot in A region, he can create volume from the snapshot in B region.
+
* user create snapshot in A region, he can create volume in B region from the snapshot.
 
* the qcow2 image of volume will really created when the volume was attaching.
 
* the qcow2 image of volume will really created when the volume was attaching.
  
Line 41: Line 44:
  
 
# cinder-api create a new volume DB item;
 
# cinder-api create a new volume DB item;
# cinder-driver do noting.
+
# island do noting.
  
 
''NOTE'': It create the qcow2 image of the volume when the volume is attaching.
 
''NOTE'': It create the qcow2 image of the volume when the volume is attaching.
Line 48: Line 51:
  
 
# cinder-api create a new volume DB item and set volume['snapshot_id'];
 
# cinder-api create a new volume DB item and set volume['snapshot_id'];
# cinder-driver do nothing.
+
# island do nothing.
  
 
=== Use case 3: Delete volume ===
 
=== Use case 3: Delete volume ===
  
# cinder-driver check the status of snapshots of the volume.
+
# island check the status of snapshots of the volume.
 
# cinder-api destroy volume DB item.
 
# cinder-api destroy volume DB item.
  
 
=== Use case 4: Create snapshot ===
 
=== Use case 4: Create snapshot ===
  
# cinder-driver use qemu monitor command to create snapshot in image;
+
# island use qemu monitor command to create snapshot in image;
# cinder-driver upload incremental snapshot to swift;
+
# island upload incremental snapshot to swift;
# cinder-driver delete old snapshot in image.
+
# island delete old snapshot in image.
  
 
''NOTE'': snapshot can be created when the volume state is attached. When the volume is detached, there are not changes in volume, so it don't need to create snapshot.
 
''NOTE'': snapshot can be created when the volume state is attached. When the volume is detached, there are not changes in volume, so it don't need to create snapshot.
Line 65: Line 68:
 
=== Use case 5: Delete snapshot ===
 
=== Use case 5: Delete snapshot ===
  
# cinder-driver delete snapshot in swift.  
+
# island delete snapshot in swift.  
  
 
=== Use case 6: Attach volume ===
 
=== Use case 6: Attach volume ===
  
# cinder-driver create the qcow2 image of the volume.
+
# island create the qcow2 image of the volume.
 
# if the volume is new volume, goto (5);
 
# if the volume is new volume, goto (5);
 
# if the volume is new volume from snapshot, download the snapshot and write it to the qcow2 image, goto (5);
 
# if the volume is new volume from snapshot, download the snapshot and write it to the qcow2 image, goto (5);
Line 76: Line 79:
  
 
=== Use case 7: Detach volume ===
 
=== Use case 7: Detach volume ===
 
+
# island create a new snapshot DB item, set snapshot['volume_id'] to the volume.
# cinder-driver create a new snapshot DB item, set snapshot['volume_id'] to the volume.
+
# island use qemu monitor command to create snapshot in image;
# cinder-driver use qemu monitor command to create snapshot in image;
+
# island upload incremental snapshot to swift;
# cinder-driver upload incremental snapshot to swift;
+
# island delete the qcow2 image of the volume;
# cinder-driver delete the qcow2 image of the volume.
 
  
 
== Requirements ==
 
== Requirements ==
Line 96: Line 98:
 
The qcow2 image format can store all incremental snapshots in one image. Its implementation detail is in [http://people.gnome.org/~markmc/qcow-image-format.html  The QCOW2 Image Format]. We copy the ''design idea'' and use ''the idea'' to store all incremental snapshots of a volume in swift. All active snapshots will contain all the information needed to restore the volume.
 
The qcow2 image format can store all incremental snapshots in one image. Its implementation detail is in [http://people.gnome.org/~markmc/qcow-image-format.html  The QCOW2 Image Format]. We copy the ''design idea'' and use ''the idea'' to store all incremental snapshots of a volume in swift. All active snapshots will contain all the information needed to restore the volume.
  
* 使用qemu qcow2的快照机制;
+
Our design is like the follow picture.
* 支持在线快照,在qemu增加2个monitor命令.
+
 
* 在swift实现增量快照;
+
[[Image:03-ebs_snapshot2.gif]]
  
 
== Pre-requisites ==
 
== Pre-requisites ==

Latest revision as of 14:25, 2 November 2014

Warning.svg Old Design Page

This page was used to help design a feature for a previous release of OpenStack. It may or may not have been implemented. As a result, this page is unlikely to be updated and could contain outdated information. It was last updated on 2014-11-02


Glossary

Qcow2: The QCOW2 image format is one of the disk image formats supported by the QEMU processor emulator.

Incremental Snapshot: This snapshots are incremental backups, meaning that only the blocks on the device that have changed since your last snapshot will be saved.

Pointer Table: The pointer in table is point to a data block. Pointer table is used by the implementation of incremental snapshot.

Summary

The goal of this blueprint is to implement a plugin for cinder. This will allow to create volume in local storage and back up point-in-time snapshots of your data to Swift for durable recovery. This snapshots are incremental backups, meaning that only the blocks on the volume that have changed since your last snapshot will be saved.

Even though the snapshots are saved incrementally, when you delete a snapshot, only the data not needed for any other snapshot is removed. So regardless of which prior snapshots have been deleted, all active snapshots will contain all the information needed to restore the volume. In addition, the time to restore the volume is the same for all snapshots, offering the restore time of full backups with the space savings of incremental.

All in a word, our solutions is local storage + qcow2 image + dependent snapshot + swift. This is like cloudstack:local storage for data volumes, but we have incremental snapshot than cloundstack.

The name of the plugin is island.

Rationale

  • high speed and low latency in local disk I/O
  • point-in-time snapshot
  • incremental snapshot
  • cost reduction from using inexpensive local disks
  • raid 10 in local storage have a better reliability.
  • user create snapshot in A region, he can create volume in B region from the snapshot.
  • the qcow2 image of volume will really created when the volume was attaching.

Use cases

Use case 1: Create volume

  1. cinder-api create a new volume DB item;
  2. island do noting.

NOTE: It create the qcow2 image of the volume when the volume is attaching.

Use case 2: Create volume from snapshot

  1. cinder-api create a new volume DB item and set volume['snapshot_id'];
  2. island do nothing.

Use case 3: Delete volume

  1. island check the status of snapshots of the volume.
  2. cinder-api destroy volume DB item.

Use case 4: Create snapshot

  1. island use qemu monitor command to create snapshot in image;
  2. island upload incremental snapshot to swift;
  3. island delete old snapshot in image.

NOTE: snapshot can be created when the volume state is attached. When the volume is detached, there are not changes in volume, so it don't need to create snapshot.

Use case 5: Delete snapshot

  1. island delete snapshot in swift.

Use case 6: Attach volume

  1. island create the qcow2 image of the volume.
  2. if the volume is new volume, goto (5);
  3. if the volume is new volume from snapshot, download the snapshot and write it to the qcow2 image, goto (5);
  4. if the volume is old volume, download the last snapshot and write it to the qcow2 image;
  5. update volume['host'] to new host which the instance besides. the volume is attached to the instance.

Use case 7: Detach volume

  1. island create a new snapshot DB item, set snapshot['volume_id'] to the volume.
  2. island use qemu monitor command to create snapshot in image;
  3. island upload incremental snapshot to swift;
  4. island delete the qcow2 image of the volume;

Requirements

R1. Support qcow2 image.

R2. Modify qemu-kvm, add tow new monitor command to support point-in-time snapshot when the volume was attached.

R3. Install swift, upload snapshot in qcow2 image to swift.

R4. modify attach_volume API, add host parameter.

Design Ideas

The qcow2 image format can store all incremental snapshots in one image. Its implementation detail is in The QCOW2 Image Format. We copy the design idea and use the idea to store all incremental snapshots of a volume in swift. All active snapshots will contain all the information needed to restore the volume.

Our design is like the follow picture.

03-ebs snapshot2.gif

Pre-requisites

Development Resources

Work in Progress

Discussion