<div dir="ltr">Another great "add-on" would be to have some sort of snapmirror feature build using the georeplication engine. Again, look at NetApp's implementation for inspiration.<div><br></div><div>An implementation could be like this: Be able to georeplicate a snapshot of a volume to a target and stop and remove the georepl connection when done. Doing that repeatedly to the same target, but from a next snapshot, will result in a snapshot based replication where the rsync based georeplication only replicates the delta. The result is that the target is the same as the snapshot and only the diff is synced. Ideal for failover scenarios where the target must be in a (crash) consistent state.</div>
<div><br></div><div>NetApp's implementation is different in that the snapshot states are preserved on the target. That would mean you must be able to georepl from a snapshot on the source volume to a newly created writeable snapshot on the target volume. Once the basic snapshot implementation is done, that would be rather easy to implement.</div>
<div><br></div><div>Bonus points if the target knows somehow that the replication is done, so it can do it's own thing based on that (like initiating a cascaded replication).</div><div class="gmail_extra"><br clear="all">
<div><div dir="ltr">Cheers,</div><div dir="ltr"><br></div><div dir="ltr">Fred<br><div><br></div><div><span style="background-color:rgb(249,249,249);color:rgb(85,85,85);font-family:sans-serif;font-size:12px;line-height:16.796875px">Seeing, contrary to popular wisdom, isn’t believing. It’s where belief stops, because it isn’t needed any more.</span><span style="color:rgb(85,85,85);font-family:sans-serif;font-size:12px;line-height:16.796875px;background-color:rgb(252,252,252)">. (</span><span style="background-color:rgb(252,252,252);color:rgb(85,85,85);font-family:sans-serif;font-size:12px;line-height:16.796875px">Terry Pratchett)</span><br>
</div></div></div>
<br><br><div class="gmail_quote">On Mon, Oct 28, 2013 at 7:38 PM, Paul Cuzner <span dir="ltr"><<a href="mailto:pcuzner@redhat.com" target="_blank">pcuzner@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks for responding on this.<br>
<br>
As far as snapshot schedules are concerned, I'd recommend that the definition of a schedule is separate from the snapshot and then the snapshot is associated with a schedule. This then enables<br>
- schedules to be centralised and used for other functions<br>
- schedules to be reused across volumes<br>
- schedules to be regarded as a "policy" and applied across multiple clusters, potentially by RHS-C - driving site standards and consistency.<br>
<br>
Cheers,<br>
<br>
PC<br>
<div class="im HOEnZb"><br>
----- Original Message -----<br>
> From: "Nagaprasad Sathyanarayana" <<a href="mailto:nsathyan@redhat.com">nsathyan@redhat.com</a>><br>
</div><div class="HOEnZb"><div class="h5">> To: "Fred van Zwieten" <<a href="mailto:fvzwieten@vxcompany.com">fvzwieten@vxcompany.com</a>>, "Paul Cuzner" <<a href="mailto:pcuzner@redhat.com">pcuzner@redhat.com</a>><br>
> Cc: "Shishir Gowda" <<a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a>>, "Anand Subramanian" <<a href="mailto:ansubram@redhat.com">ansubram@redhat.com</a>><br>
> Sent: Tuesday, 29 October, 2013 6:15:19 AM<br>
> Subject: Re: [Gluster-devel] Fwd: Snapshot feature design review<br>
><br>
> Hi Paul, Fred,<br>
><br>
> Thank you for providing valuable inputs. We shall certainly go through these<br>
> and update you further.<br>
><br>
> Regards<br>
> Nagaprasad<br>
><br>
><br>
> > On 28-Oct-2013, at 12:56 pm, Fred van Zwieten <<a href="mailto:fvzwieten@vxcompany.com">fvzwieten@vxcompany.com</a>><br>
> > wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > I have almost the same things as Paul mentioned. I also would like to see a<br>
> > snap retention feature. This could be build into the scheduling mechanism.<br>
> > Something like this:<br>
> ><br>
> > gluster snapshot create < vol-name > [-n snap-name][-d description][-s<br>
> > <name>:<start-datetime>:<delta-datetime>:<keep> ...]<br>
> ><br>
> > Where:<br>
> > <name> is the name of this schedule<br>
> > <start-datetime> is the timestamp for the first snapshot<br>
> > <delta-datetime> is the specification for the time between snapshots<br>
> > <keep> is the specification for the nr of snapshots for this schedule to<br>
> > keep<br>
> ><br>
> > Multiple schedules should be possible.<br>
> ><br>
> > Another thing, concerning the space management of snapshots. There should<br>
> > be an absolute max size limit on volume plus all of it's snap's. Look at<br>
> > NetApp's implementation for inspiration.<br>
> ><br>
> > Cheers,<br>
> ><br>
> > Fred<br>
> ><br>
> ><br>
> >> On Mon, Oct 28, 2013 at 4:26 AM, Paul Cuzner <<a href="mailto:pcuzner@redhat.com">pcuzner@redhat.com</a>> wrote:<br>
> >><br>
> >> Hi,<br>
> >><br>
> >> I've just reviewed the doc, and would like to clarify a couple of things<br>
> >> regarding the proposed design.<br>
> >><br>
> >><br>
> >> - I don't see a snapshot schedule type command to generate automated<br>
> >> snapshots. What's the plan here? In a distributed environment the<br>
> >> schedule for snapshots should be an attribute of the volume shouldn't it?<br>
> >> If we designate a node in the cluster as 'master' and use cron to manage<br>
> >> the snaps - what happens when this node is down/rebuilt or loses its<br>
> >> config? To me there seems to be a requirement for a gluster scheduler -<br>
> >> to manage snapshots, and potentially future tasks like post dedupe, data<br>
> >> integrity checking or maybe even geo-rep intervals etc.<br>
> >><br>
> >> - snapshots are reliant upon dm-thinp, which means this version of lvm is<br>
> >> a dependancy. Is there a clear path of migrating from classic lvm to<br>
> >> dm-thinp based lv's - or is snapshots in 3.5 basically going to be a<br>
> >> feature from this point forward i.e. no backwards compatibility.<br>
> >><br>
> >> - when managing volumes holding snaps, visibility of capacity usage<br>
> >> attributed to snaps is key - but I don't see a means of discerning the<br>
> >> space usage by snap in the CLI breakdown.<br>
> >><br>
> >> - on other systems, I've had hung backup tasks (for days!) holding on to<br>
> >> snaps causing space usage to climb against the primary volume. In this<br>
> >> scenario I was able to see snap usage and what client had the snapshot<br>
> >> open to troubleshoot. In this scenario, how will the glusterfs snapshot<br>
> >> present itself and be managed.<br>
> >><br>
> >> - How will the snapshot volume be perceived by Windows clients over SMB?<br>
> >> Will these users be able to use the previous versions tab for example<br>
> >> against the file properties in explorer?<br>
> >><br>
> >> - a volume snapshot is based on snaps of the component bricks. 3.4 changed<br>
> >> the way that bricks are used on a vol create to require a dir on a<br>
> >> filesystem not the filesystem itself. This change enables users to create<br>
> >> multiple volumes from the same physical brick by placing different dirs<br>
> >> on the bricks root - which is not necessarily a good idea. Given the 1:1<br>
> >> requirement of brick:volume, will this CLI behaviour be regressed to the<br>
> >> way it was with 3.3.<br>
> >><br>
> >> Happy to talk further about any of the above, if needed.<br>
> >><br>
> >> Regards,<br>
> >><br>
> >> Paul Cuzner<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> ----- Original Message -----<br>
> >> > From: "Nagaprasad Sathyanarayana" <<a href="mailto:nsathyan@redhat.com">nsathyan@redhat.com</a>><br>
> >> > To: <a href="mailto:gluster-devel@nongnu.org">gluster-devel@nongnu.org</a><br>
> >> > Sent: Friday, 18 October, 2013 5:22:31 AM<br>
> >> > Subject: [Gluster-devel] Fwd: Snapshot feature design review<br>
> >> ><br>
> >> > Gluster devel included.<br>
> >> ><br>
> >> > Thanks<br>
> >> > Naga<br>
> >> ><br>
> >> > Begin forwarded message:<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > From: Nagaprasad Sathyanarayana < <a href="mailto:nsathyan@redhat.com">nsathyan@redhat.com</a> ><br>
> >> > Date: 17 October 2013 9:45:05 pm IST<br>
> >> > To: Shishir Gowda < <a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a> ><br>
> >> > Cc: " <a href="mailto:anands@redhat.com">anands@redhat.com</a> " < <a href="mailto:anands@redhat.com">anands@redhat.com</a> >, " <a href="mailto:rfortier@redhat.com">rfortier@redhat.com</a> "<br>
> >> > <<br>
> >> > <a href="mailto:rfortier@redhat.com">rfortier@redhat.com</a> >, " <a href="mailto:ssaha@redhat.com">ssaha@redhat.com</a> " < <a href="mailto:ssaha@redhat.com">ssaha@redhat.com</a> >, "<br>
> >> > <a href="mailto:aavati@redhat.com">aavati@redhat.com</a> " < <a href="mailto:aavati@redhat.com">aavati@redhat.com</a> >, " <a href="mailto:atumball@redhat.com">atumball@redhat.com</a> " <<br>
> >> > <a href="mailto:atumball@redhat.com">atumball@redhat.com</a> >, " <a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a> " < <a href="mailto:vbellur@redhat.com">vbellur@redhat.com</a> >, "<br>
> >> > <a href="mailto:vraman@redhat.com">vraman@redhat.com</a> " < <a href="mailto:vraman@redhat.com">vraman@redhat.com</a> >, " <a href="mailto:lpabon@redhat.com">lpabon@redhat.com</a> " <<br>
> >> > <a href="mailto:lpabon@redhat.com">lpabon@redhat.com</a> >, " <a href="mailto:kkeithle@redhat.com">kkeithle@redhat.com</a> " < <a href="mailto:kkeithle@redhat.com">kkeithle@redhat.com</a> >, "<br>
> >> > <a href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a> " < <a href="mailto:jdarcy@redhat.com">jdarcy@redhat.com</a> >, " <a href="mailto:gluster-devel@redhat.com">gluster-devel@redhat.com</a> "<br>
> >> > <<br>
> >> > <a href="mailto:gluster-devel@redhat.com">gluster-devel@redhat.com</a> ><br>
> >> > Subject: Re: Snapshot feature design review<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > + Gluster devel.<br>
> >> ><br>
> >> > Hi all,<br>
> >> ><br>
> >> > Kindly review the design and provide any comments by next week. We are<br>
> >> > targeting to have the review comments incorporated in the design and<br>
> >> > post<br>
> >> > the final design by 28th of this month (October). If you need any<br>
> >> > discussion<br>
> >> > on the design, please let us know by 21st or 22nd this month.<br>
> >> > If anybody not copied must be involved in design review, please feel<br>
> >> > free to<br>
> >> > forward the design document to them.<br>
> >> ><br>
> >> > Thanks<br>
> >> > Naga<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > On 16-Oct-2013, at 7:03 pm, Shishir Gowda < <a href="mailto:sgowda@redhat.com">sgowda@redhat.com</a> > wrote:<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > Hi All,<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > The design document has been updated, and we have tried to address all<br>
> >> > the<br>
> >> > review comments and design issues to the best of our ability.<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > Please review the design and the document when possible.<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > The design document can be found @<br>
> >> > <a href="https://forge.gluster.org/snapshot/pages/Home" target="_blank">https://forge.gluster.org/snapshot/pages/Home</a><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > Please feel free to critique/comment.<br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> ><br>
> >> > With regards,<br>
> >> ><br>
> >> ><br>
> >> > Shishir<br>
> >> ><br>
> >> > _______________________________________________<br>
> >> > Gluster-devel mailing list<br>
> >> > <a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
> >> > <a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
> >> ><br>
> >><br>
> >> _______________________________________________<br>
> >> Gluster-devel mailing list<br>
> >> <a href="mailto:Gluster-devel@nongnu.org">Gluster-devel@nongnu.org</a><br>
> >> <a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/mailman/listinfo/gluster-devel</a><br>
> ><br>
><br>
</div></div></blockquote></div><br></div></div>