[Gluster-devel] Snapshot CLI question
Sahina Bose
sabose at redhat.com
Fri May 2 06:19:02 UTC 2014
On 04/30/2014 12:03 PM, Paul Cuzner wrote:
>
>
> ------------------------------------------------------------------------
>
> *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?
Yes. The performance graph for the volume should show the volume
capacity metrics before and after restore (Need to test this out)
The brick performance graphs will however be separate with the old
bricks' data being kept as backup.
>
>
>
> 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/20140502/087194f4/attachment-0003.html>
More information about the Gluster-devel
mailing list