[Gluster-devel] Snapshot CLI question

Wed Apr 30 06:06:44 UTC 2014

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.
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.

>
> 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?
>
>
>
>
>
> ------------------------------------------------------------------------
>
>     *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/dad70429/attachment-0003.html>