Thanks Rajesh - happy to help with the docs/diagrams for the revisions to the wiki
Personally, I'm still dubious about the replica 3 support though. People I've dealt with already 'groan' about 2-way mirror and the associated cost, so a 3-way in the current architecture is going to be a pretty expensive exercise. In some regards, I would have thought with bricks/nodes down the admins should be focusing on restoring service to 100% - if a snapshot aborts due to a cluster 'health' issue it just makes sense to me. I like simple :) Cheers, PC ----- Original Message ----- > From: "Rajesh Joseph" <rjos...@redhat.com> > To: "Paul Cuzner" <pcuz...@redhat.com> > Cc: "gluster-devel" <gluster-devel@nongnu.org> > Sent: Monday, 23 December, 2013 4:48:24 PM > Subject: Re: [Gluster-devel] Glusterfs Snapshot feature > > Thanks Paul for going through the Snapshot design wiki and providing your > valuable inputs. The wiki needs lot of update. I will update it soon and > circulate it here again. > > The cli status and list commands will provide space consumption by the > snapshot. Snapshot scheduler is planned for phase 2. I will update the > document with details of phase I and phase II. > > As of now auto-delete feature is based on maximum allowed snapshot count. > Admins can set a limit on number of snapshots allowed per volume. More > details will be provided in the wiki. > > We still have to iron out details of Replica-3 and quorum support, but the > intention of providing the feature is to allow admins to take snapshots even > some bricks are down without compromising the integrity of the volume. > > When snapshot count reaches the maximum limit then an auto-delete is > triggered. Before deletion the snapshot is stopped and then it is deleted. > > User serviceable snapshots is planning in phase II and yes .snap directory > will list in accordance with snap time-stamp. > > Snapshot can be restored only when the volume is stopped. It is a completely > offline activity. More details will be provided in the wiki. > > Thanks & Regards, > Rajesh > > ----- Original Message ----- > From: "Paul Cuzner" <pcuz...@redhat.com> > To: "Rajesh Joseph" <rjos...@redhat.com> > Cc: "gluster-devel" <gluster-devel@nongnu.org> > Sent: Monday, December 23, 2013 3:50:45 AM > Subject: Re: [Gluster-devel] Glusterfs Snapshot feature > > > 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" <rjos...@redhat.com> > > To: "gluster-devel" <gluster-devel@nongnu.org> > > 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 > > Gluster-devel@nongnu.org > > https://lists.nongnu.org/mailman/listinfo/gluster-devel > > > _______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
