[Gluster-devel] Snapshot CLI question

[Paul Cuzner]

----- Original Message -----

> From: "Sahina Bose" <sabose at redhat.com>
> To: "Paul Cuzner" <pcuzner at redhat.com>, "Rajesh Joseph" <rjoseph at redhat.com>
> Cc: gluster-devel at gluster.org
> Sent: Wednesday, 30 April, 2014 6:06:44 PM
> Subject: Re: [Gluster-devel] Snapshot CLI question

> On 04/30/2014 07:14 AM, Paul Cuzner wrote:

> > I guess my point about loss of data following a restore boils down to the
> > change of brick names that the restore process "forces". I may be wrong but
> > doesn't this mean that any "downstream" monitoring/scripts have to adjust
> > their idea of what the volume looked like - it just sounds like more work
> > for the admin to me...
> 

> From a Nagios monitoring view, we have an auto discovery plugin that scans
> the volumes for any change. So once a volume snapshot is restored, it will
> be detected as though new bricks have been added to it (due to the new brick
> names) with the older bricks deleted.
Makes sense 

> What we're currently missing is a mechanism to know that the change in volume
> happened due to a snapshot restore.

> With regards to monitoring history, we plan to keep the previous
> configuration as backup along with any performance data that was collected
> on them.

Sounds good. From an admins standpoint, following a restore operation will a performance graph against the volume show data points before and after the restore - or will the previous data be kept but not immediately usable? 

> > The other thing that wasn't clear from the video, was the impact to fstab.
> > What happens here in relation to the brick name change?
> 

> > ----- Original Message -----
> 

> > > From: "Rajesh Joseph" <rjoseph at redhat.com>
> > 
> 
> > > To: "Paul Cuzner" <pcuzner at redhat.com>
> > 
> 
> > > Cc: "gluster-devel" <gluster-devel at nongnu.org> , "Sahina Bose"
> > > <sabose at redhat.com>
> > 
> 
> > > Sent: Tuesday, 29 April, 2014 10:13:00 PM
> > 
> 
> > > Subject: Re: [Gluster-devel] Snapshot CLI question
> > 
> 

> > > Hi Paul,
> > 
> 

> > > We are thinking of providing policy-driven auto-delete in future. Where
> > > user
> > > can provide various policies by which they can control auto-delete.
> > 
> 
> > > e.g. delete oldest, delete with maximum disk utilization, etc. What you
> > > mentioned can also be part of the policy.
> > 
> 

> > > Loss of monitoring history has nothing to do with dm-thinp. Monitoring
> > > tool
> > > keeps the history of changes seen by the brick. Now after the restore
> > 
> 
> > > the monitoring tool has no ways to map the newer bricks to the older
> > > bricks,
> > > therefore they discard the history of the older bricks.
> > 
> 
> > > I am sure monitoring team has plans to evolve this and fix this.
> > 
> 

> > > Best Regards,
> > 
> 
> > > Rajesh
> > 
> 

> > > ----- Original Message -----
> > 
> 
> > > From: "Paul Cuzner" <pcuzner at redhat.com>
> > 
> 
> > > To: "Rajesh Joseph" <rjoseph at redhat.com>
> > 
> 
> > > Cc: "gluster-devel" <gluster-devel at nongnu.org> , "Sahina Bose"
> > > <sabose at redhat.com>
> > 
> 
> > > Sent: Tuesday, April 29, 2014 5:22:42 AM
> > 
> 
> > > Subject: Re: [Gluster-devel] Snapshot CLI question
> > 
> 

> > > No worries, Rajesh.
> > 
> 

> > > Without --xml we're limiting the automation potential and resorting to
> > > 'screen scraping' - so with that said, is --xml in plan, or do you need
> > > an
> > > RFE?
> > 
> 

> > > Brickpath's changing and loss of history presents an interesting problem
> > > for
> > > monitoring and capacity planning - especially if the data is lost! As an
> > > admin this would be a real concern. Is this something that will evolve,
> > > or
> > > is this just the flipside of using dm-thinp as the provider for the
> > > volume/snapshots?
> > 
> 

> > > The other question I raised was around triggers for autodelete. Having a
> > > set
> > > number of snapshots is fine, but I've seen environments in the past where
> > > autodelete was needed to protect the pool when snapshots deltas were
> > > large
> > > -
> > > i.e. autodelete gets triggered at a thinpool freespace threshold.
> > 
> 

> > > Is this last item in the plan? Does it make sense? Does it need an RFE?
> > 
> 

> > > Cheers,
> > 
> 

> > > PC
> > 
> 

> > > ----- Original Message -----
> > 
> 

> > > > From: "Rajesh Joseph" <rjoseph at redhat.com>
> > 
> 
> > > > To: "Paul Cuzner" <pcuzner at redhat.com>
> > 
> 
> > > > Cc: "gluster-devel" <gluster-devel at nongnu.org> , "Sahina Bose"
> > 
> 
> > > > <sabose at redhat.com>
> > 
> 
> > > > Sent: Monday, 28 April, 2014 9:47:04 PM
> > 
> 
> > > > Subject: Re: [Gluster-devel] Snapshot CLI question
> > 
> 

> > > > Sorry Paul for this late reply.
> > 
> 

> > > > As of now we are not supporting --xml option.
> > 
> 

> > > > And restore does change the brick path. Users using their own
> > > > monitoring
> > 
> 
> > > > script need to be aware of this scenario.
> > 
> 
> > > > RHS monitoring will monitor the new bricks once restored, but the
> > > > history
> > 
> 
> > > > related to older brick might be lost.
> > 
> 

> > > > Sahin: Would you like to comment on the monitoring part of the
> > > > question?
> > 
> 

> > > > Thanks & Regards,
> > 
> 
> > > > Rajesh
> > 
> 

> > > > ----- Original Message -----
> > 
> 
> > > > From: "Paul Cuzner" <pcuzner at redhat.com>
> > 
> 
> > > > To: "gluster-devel" <gluster-devel at nongnu.org>
> > 
> 
> > > > Sent: Wednesday, April 23, 2014 5:14:44 AM
> > 
> 
> > > > Subject: [Gluster-devel] Snapshot CLI question
> > 
> 

> > > > Hi,
> > 
> 

> > > > having seen some of the demo's/material around the snapshot cli, it
> > > > raised
> > > > a
> > 
> 
> > > > couple of questions;
> > 
> 

> > > > Will --xml be supported?
> > 
> 

> > > > The other question I have relates to brick names. On a demo video I saw
> > > > the
> > 
> 
> > > > brick names change following a 'restore' operation (i.e. vol info shows
> > 
> 
> > > > different paths - pointing to the paths associated with the snapshot.)
> > 
> 

> > > > Is this the case currently, and if so does this pose a problem for
> > 
> 
> > > > monitoring?
> > 
> 

> > > > Cheers,
> > 
> 

> > > > Paul C
> > 
> 

> > > > _______________________________________________
> > 
> 
> > > > Gluster-devel mailing list
> > 
> 
> > > > Gluster-devel at nongnu.org
> > 
> 
> > > > https://lists.nongnu.org/mailman/listinfo/gluster-devel
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140430/686f8f50/attachment-0003.html>