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@xxxxxxxxxx>
To: "Paul Cuzner" <pcuzner@xxxxxxxxxx>
Cc: "gluster-devel" <gluster-devel@xxxxxxxxxx>,
"Sahina Bose" <sabose@xxxxxxxxxx>
Sent: Tuesday, 29 April, 2014 10:13:00 PM
Subject: Re: 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@xxxxxxxxxx>
To: "Rajesh Joseph" <rjoseph@xxxxxxxxxx>
Cc: "gluster-devel" <gluster-devel@xxxxxxxxxx>, "Sahina
Bose" <sabose@xxxxxxxxxx>
Sent: Tuesday, April 29, 2014 5:22:42 AM
Subject: Re: 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@xxxxxxxxxx>
> To: "Paul Cuzner" <pcuzner@xxxxxxxxxx>
> Cc: "gluster-devel" <gluster-devel@xxxxxxxxxx>,
"Sahina Bose"
> <sabose@xxxxxxxxxx>
> Sent: Monday, 28 April, 2014 9:47:04 PM
> Subject: Re: 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@xxxxxxxxxx>
> To: "gluster-devel" <gluster-devel@xxxxxxxxxx>
> Sent: Wednesday, April 23, 2014 5:14:44 AM
> Subject: 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@xxxxxxxxxx
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
|
