Re: [Gluster-devel] Glusterfs Snapshot feature

[Paul Cuzner]

Hi Rajesh,

I've just read through the snapshot spec on the wiki page in the forge, and 
have been looking at it through a storage admin's eyes.

There are a couple of items that are perhaps already addressed but not listed 
on the wiki, but just in case here's my thoughts;

The CLI definition doesn't define a snap usage command - ie. a way for the 
admin to understand which snap is consuming the most space. With snaps comes 
misuse, and capacity issues, so our implementation should provide the admin 
with the information to make the right 'call'.

I think I've mentioned this before, but how are snaps orchestrated across the 
cluster. I see a CLI to start it - but what's needed is a cron like ability 
associated per volume. I think in a previous post I called this a "snap 
schedule" command.

A common thing I've seen on other platforms is unexpected space usage, due to 
changes in data access patterns generating more delta's - I've seen this a lot 
in virtual environments, when service packs/maintenance gets rolled out for 
example. In these situations, capacity can soon run out, so an auto-delete 
feature to drop snaps to ensure the real volume stays on line would seem like a 
sensible approach.

The comments around quorum and replica 3 enable an exception to a basic rule - 
fail a snap request if the cluster is not in a healthy state. I would argue 
against making exceptions and keep things simple - if a node/brick is 
unavailable, or there is a cluster reconfig in progress, raise an alert and 
fail the snap request. I think this is a more straight forward approach for 
admins to get their heads around than thinking about specific volume types and 
potential cleanup activity.

It's not clear from the wiki how snaps are deleted - for example, when the 
snap-max-limit is reached, does the create of a new snapshot automatically 
trigger the delete of the oldest snap? If so presumably the delete will only be 
actioned, once the barrier is in place across all affected bricks. 

The snap create is allowing a user-defined name, which is a great idea. 
However, what is the order that the snaps would be resolved in when the user 
opens the .snap directory? Will create time for the snapshot be the order the 
user sees regardless of name, or is there a potential of a name for a more 
current time appearing lower in the list causing a potential recovery point to 
be missed by the end user?

snap restore presumably requires the volume to be offline, and the bricks 
unmounted? There's no detail in the scoping document about how the restore 
capability is intended to be implemented. Restore will be a drastic action, so 
understanding the implications to the various protocols smb,nfs,native, swift 
and gfapi would be key. Perhaps the simple answer is the volume must be in a 
stopped state first?

There is some mention of a phased implementation for snapshots - phase-1 is 
mentioned for example towards the end of the doc. Perhaps it would be 
beneficial to define the phases at the start of the article, and list the 
features likely to be in each phase. This may help focus feedback specific to 
the initial implementation for example.

Like I said - I'm looking at this through the eyes of an "old admin" ;)

Cheers,

Paul C




----- Original Message -----
> From: "Rajesh Joseph" <address@hidden>
> To: "gluster-devel" <address@hidden>
> Sent: Friday, 6 December, 2013 1:05:29 AM
> Subject: [Gluster-devel] Glusterfs Snapshot feature
> 
> Hi all,
> 
> We are implementing snapshot support for glusterfs volumes in release-3.6.
> The design document can be found at
> https://forge.gluster.org/snapshot/pages/Home.
> The document needs some update and I will doing that in the coming weeks.
> 
> All the work done till now can be seen at review.gluster.com. The project
> name for the snapshot
> work is "glusterfs-snapshot"
> http://review.gluster.org/#/q/status:open+project:glusterfs-snapshot,n,z
> 
> All suggestions and comments are welcome.
> 
> Thanks & Regards,
> Rajesh
> 
> _______________________________________________
> Gluster-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
>