cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harika Punna <harika.pu...@accelerite.com>
Subject RE: [PROPOSAL] Separate creation and backup operations for a volume snapshot
Date Mon, 15 May 2017 17:22:15 GMT
Hi,

I have checked both the PRs. My observations are-

Nathan, As per your implementation,
- When the parameter “snapshot.backup.rightafter” is set to false, when the snapshot is
created on primary, the state transitions are faked from CreatedOnPrimary -> BackingUp
and BackingUp -> Backup.
- For both values (true and false) of the parameter “snapshot.backup.rightafter”, the
Snapshot state is backed up, which is confusing.
- User doesn’t know which snapshot is backed up and physically available in secondary.
- The create template or create volume (whichever is the first) is slow for the snapshot created
when “snapshot.backup.rightafter” is false. The actual backup process is delayed and would
be done on demand.
- When snapshot on primary is backed up on demand, the state of the primary storage and the
snapshot on it, is unpredictable.

My proposal moves the global parameter to API level so that user can separate the backup at
snapshot creation time. The snapshot backup will be triggered immediately after creation of
the snapshot on primary and will be decoupled from the API async job. This unblocks the VM
queue after snapshot creation on primary and enables the user to perform other allowed VM
operations when snapshot is backing up in the background (which can be tracked using the snapshot
state/status). Also, the snapshot state transitions will be in the proper order.


Syed,
- User does not choose the location where the snapshot has to be stored for unmanaged storage.
In case of unmanaged storage, the snapshot should be backed up to the secondary. So locationType
would be always SECONDARY for unmanaged storage, no point in using this parameter for unmanaged
storage.
-My proposal separates the snapshot backup for unmanaged storage only.

Please let me know your comments.

Thanks,
Harika.



From: Syed Ahmed [mailto:sahmed@cloudops.com]
Sent: Thursday, May 11, 2017 1:08 AM
To: dev@cloudstack.apache.org
Cc: Harika Punna <harika.punna@accelerite.com>
Subject: Re: [PROPOSAL] Separate creation and backup operations for a volume snapshot

Oops I meant Harika, I know that Nathan you were working on something like this a while back
with Ceph so I assumed you where the one who proposed this. Anyways, Harika, look at the locationType
parameter in the CreateSnaphsot API command. This is what you are looking to implement. Note
that this currently only works for Managed storage (SolidFire) so you'd have to work it into
the standard non-managed storage.
Let me know if you have any questions.
Thanks,
-Syed


On Wed, May 10, 2017 at 3:24 PM, Syed Ahmed <sahmed@cloudops.com<mailto:sahmed@cloudops.com>>
wrote:
Hi Nathan,
This option to choose between primary and secondary was added by me a while back. You want
to look at

https://github.com/apache/cloudstack/pull/1600

On Tue, May 9, 2017 at 10:09 AM, Nathan Johnson <njohnson@ena.com<mailto:njohnson@ena.com>>
wrote:
Harika Punna <harika.punna@accelerite.com<mailto:harika.punna@accelerite.com>>
wrote:
>
> Currently, Volume Snapshots in Cloudstack take considerable amount of
> time to complete as snapshot involves creation on primary and backup on
> secondary. I would like to introduce an optional parameter in
> CreateSnapshotCmd API to separate these operations.
>
>
> More details in the FS:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Separate+creation+and+backup+operations+for+a+volume+snapshot
>
>
> Thanks,
> Harika.

Hello Harika.  There was a related discussion around a global configuration
parameter snapshot.backup.rightafter

See the thread here:
https://issues.apache.org/jira/browse/CLOUDSTACK-4858

And here is the PR where this was merged into 4.9:

https://github.com/apache/cloudstack/pull/1697

This is distinct from what you propose, and I like the idea of being able
to specify whether or not to back up at snapshot creation time, versus only
having a global configuration parameter.

Also one remaining issue with the current implementation of snapshots and
backups is that if the snapshot.backup.rightafter parameter is set to
false, on doing certain operations with snapshots (create template from
snapshot iirc, perhaps some others) it will then need to take the backup to
secondary at that time, and it will be very slow.  I think at some point
you have to take that hit, so maybe there is no way around this.

But that brings me to a followup point: since the PR was merged above, ACS
will backup on-demand any snapshots that need to be on secondary that only
exist on primary. it would be nice to also have an optional cleanup thread
and an expiration of backups to secondary.  Or maybe API endpoints that
would allow some external management of backups.

What do you think?


Nathan Johnson
R&D Engineer
Education Networks of America





DISCLAIMER
==========
This e-mail may contain privileged and confidential information which is the property of Accelerite,
a Persistent Systems business. It is intended only for the use of the individual or entity
to which it is addressed. If you are not the intended recipient, you are not authorized to
read, retain, copy, print, distribute or use this message. If you have received this communication
in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent
Systems business does not accept any liability for virus infected mails.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message