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:sah...@cloudops.com]
Sent: Thursday, May 11, 2017 1:08 AM
To: dev@cloudstack.apache.org
Cc: Harika Punna
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
mailto:sah...@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
mailto:njohn...@ena.com>> wrote:
Harika Punna mailto:harika.pu...@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 au
