11 Replies Latest reply: Oct 17, 2011 7:14 AM by Dje21 RSS

Reclaiming savvol space in 6.0.41.4

Dje21

Hello All,

 

I need help about reclaiming savvol space to the storage pool, we use replicator V2 and I already know the solution:

  •      delete all ckpt and rep ckpt and after you can relaunch a full copy over the WAN Of course!

The last part disturb me a little and I found in the release notes for the version 6.0.41.4 a new feature named "File system replication with common base checkpoints", but i do not see how to implement it in order to avoid a full copy. If we understand well, we need to create a local replica and checkpoint user on each fs involved and after use this checkpoint user to do a replication refresh.

Can someone explain to me how to do this?

Thanks.

  • 1. Re: Reclaiming savvol space in 6.0.41.4
    Rainer_EMC

    Hi,

     

    Replicator Incremental Attach helps in replications with 3 or more members like cascading or one-to-many.

    Its main use case is to replace a replicated system without having to do a full copy over the WAN.

     

    Basically you create a user checkpoint on each system and sync them.

    This is in addition to the two internal checkpoints per replication - these are still there but only valid between two parties

     

    Then you can remove a replication and setup a new one without a full resync since these checkpoints form a common base.

     

    In your config what should work:

     

    - lets say you are replicating from fs1 from A to fs1-repl1 on B with a WAN connection between A and B

    - create a new local replication from B:fs1_repl1 to B:fs1_repl2 (new fs) - this is a full copy but not over the WAN

    - create user checkpoints on all three file systems and sync them

    - remove the A:fs1 -> B-fs1_repl1 and B:fs_repl1 -> B:fs_repl2 replications

    - create a A:fs1 -> B:fs_repl2 replication and the Celerra will recognize that there is a common base and only do a delta copy over the WAN

     

    hope that helps

    Rainer

  • 2. Re: Reclaiming savvol space in 6.0.41.4
    Dje21

    Hi,

     

    Thanks very much for your reply.

    Here is my config and my idea:

    - fs1 on site A and fs1_repl1 on site B with a WAN connection between A and B

    - fs1 on site A use a lot of allocated savvol space. we need to delete all ckpt to reclaim space on our storage pool and avoid a full copy when we'll relaunch the replication

    -create a new local replication from A:fs1 to A:fs1-temp in full copy

    -create user checkpoints on all three file systems and sync them

    -remove the A:fs1 -> B-fs1_repl1 and A:fs1 -> A:fs1_temp replications

    -create a A:fs1-temp -> B:fs_repl1

    -Now we can clean A:fs1 to reclaim the space

    -Then we need to go back on A:fs1, how to do it?  we need to do again the last step (create a new replica from A:fs1-temp to A:fs1 in full copy, create user checkpoint, remove ....)

     

    I tried to mock up with celerra simulator but i can't, the last version of simulator is 6.0.36 and this new feature is only available from 6.0.41.3

     

    thanks again Rainer

  • 3. Re: Reclaiming savvol space in 6.0.41.4
    Rainer_EMC

    I think the easiest would be to just unmount fs1_temp and mount it on the mountpoint of fs1

    Then recreate your A -> B replication

     

    If you want the data to stay in fs1's place then

    create A:fs1_temp -> B:fs1_repl - differential

    delete all checkpoints on fs1 so that the savvol gets delete

    create a user checkpoint on fs1 - this way you also get to choose which pool and specific a max size

    create A:fs1_temp -> A:fs1 - full copy

    sync all three checkpoints

    delete and re-create replications

     

    This looks a bit complicated verbally - its easier on paper with some drawings.

     

    You can avoid the full copy to fs1 since in order to free up the savvol all checkpoints need to be deleted - also the user checkpoint for incremental attach

     

    I would suggest to test with a small test file system to get the order and commands correct

    using nas_replicate -info tells you when a full copy is done

     

    Rainer

    P.S.: you might want to try the VNX simulator - while Replicator incremental not yet supported in that version it might be there as grey content

  • 4. Re: Reclaiming savvol space in 6.0.41.4
    Avi

    Prior to this feature, there were checkpoints dedicated to preserve a common base between a replication pair.  The common base was created by the replication software.  In this new functionality, a user can use regular checkpoints to create a common base between two NAS objects.  The purpose of this feature is to create a common base between a replication pair that had no prior replication relationship. If they did not have a prior relationship, replication software would not have created a common base.  Now, a user can do that and then create a replication session between the two without the need of a full copy for initialization.

     

    The details of this feature are explained in the release note that you referenced. Is there anything specific that you were looking for?

  • 5. Re: Reclaiming savvol space in 6.0.41.4
    DHoffman

    Where can I find information about incremental attach?  Is there a document number or something that I can search for and find it?

     

    Thanks,

  • 6. Re: Reclaiming savvol space in 6.0.41.4
    Rainer_EMC

    Its described in the VNX OE 7.0.35.3 release notes:

     

    Incremental Attach Replication

    This feature makes use of common base checkpoints to be able to incrementally

    attach to either Cascaded or One-to-Many replication sessions, for both File

    System and VDM replication operations.

     

    Examples: Cascading Replication, where A to B to C: Drop B session, establish incrementally

    an A to C session using this new feature and common base checkpoints.

    One-to-Many Replication, where A to B, and A to C: Drop A, then incrementally

    establish a B to C session.

     

    When you replace the source or destination file systems, the replications and

    internal checkpoints are deleted. You will have to perform a full data copy in order

    to create future replications with the original configurations. To avoid performing

    a time-consuming full data copy over the WAN, you can create a local replica of

    the file system that you want to replace. You can then create one or more

    user-specified checkpoints on the file system to be replaced, the local replica, and

    each of the other file systems involved in the replication. After creating userspecified

    checkpoints, you must refresh each replication by specifying the user

    checkpoint on the source and destination file system for that replication. The user

    checkpoint of each destination file system (including local replica) will then have

    the same view of the file system as the user checkpoint on the source file system

    that will be replaced. User checkpoints on the source and destination file systems,

    which have the same content, are called common base checkpoints. You can now

    use the local replica for replications without performing a full data copy over the WAN.

     

    Implementing this technique is useful in disaster recovery scenarios as well. To

    avoid a full data copy in the event of a disaster, create one or more user-specified

    checkpoints on the source and destination file systems and refresh their replication

    by using these user checkpoints. This process transfers data from the source user

    checkpoint to the destination file system through the existing replication session.

    Thus, the destination user checkpoint has the same view of the file system as the

    source user checkpoint. This process is repeated for each destination in the

    one-to-many configuration. For a cascading replication, the replication must be

    refreshed for this first hop and then for the second hop.

     

    After this process, even if you delete the replication sessions, you can configure

    new replication sessions between any two destinations because replication

    automatically identifies the common base checkpoints and avoids full data copy.

    You can create user checkpoints for file system and VDM replications. For VDM

    replications, you can create the user checkpoints on the root file system of the

    VDM. You cannot delete user checkpoints when they are being used by replication

    either for transfer or as an active common base.

     

    The main work is in a new option for the nas_replicate -refresh

     

    From the nas_replicate man page:

     

    nas_replicate -refresh { <name> | id=<sessionId> }

                [ -source { <ckptName> | id=<ckptId> }

                  -destination { <ckptName> | id=<ckptId> } ]

     

    REFRESH OPTIONS

    [-source{<ckptName>|id=<ckptId>} -destination{<ckptName>|id=<ckptId>}]

    Instructs the replication -refresh option to use a specific checkpoint on the

    source side and a specific checkpoint on the destination side.

    Specifying source and destination checkpoints for the -refresh option is

    optional. However, if you specify a source checkpoint, you must also specify a

    destination checkpoint. Replication transfers the contents of the

    user-specified source checkpoint to the destination file system. This transfer

    can be either a full copy or a differential copy depending on the existing

    replication semantics. After the transfer, the replication internally

    refreshes the user specified destination checkpoint and marks the two

    checkpoints as common bases.

     

    After the replication refresh operation completes successfully, both the

    source and destination checkpoints have the same view of their file systems.

    The replication continues to use these checkpoints as common bases until the

    next transfer is completed. After a user checkpoint is marked with a common

    base property, the property is retained until the checkpoint is refreshed or

    deleted. A checkpoint that is already paired as a common base with another

    checkpoint propagates its common base property when it is specified as the

    source in a replication refresh operation. This propagation makes it possible

    for file systems without a direct replication relationship to have common base

    checkpoints.

  • 7. Re: Reclaiming savvol space in 6.0.41.4
    Dje21

    Hi,

     

    Last week, we tried to implement this solution on a big FS (~5T). From the first step, we have had a bad surprise!

    "-create a new local replication from A:fs1 to A:fs1-temp in full copy"

    The local replication worked well but the savvol linked to fs1-temp has grown up as much as the size of the FS. Thus I had : fs1-temp size 5,4T, savvol 6T

    Did I forget something? I believed that the first replication(full copy) would not impact the savvol.

  • 8. Re: Reclaiming savvol space in 6.0.41.4
    bergec

    What command are you using (or steps in Unisphere) to look ate SavVol size?

     

    Claude

  • 9. Re: Reclaiming savvol space in 6.0.41.4
    Dje21

    That depends

    you can use rootnas_fs -size "ckpt_Internal_replication"

    or

    nas_fs -size "ckptuser"

    and we can check directly with the command nas_pool as well.

  • 10. Re: Reclaiming savvol space in 6.0.41.4
    bergec

    Have you been able to finaly recover the  space in SavVol using the Incremental attach Procedure?

     

    Claude

  • 11. Re: Reclaiming savvol space in 6.0.41.4
    Dje21

    Not yet!

    We still have the same issue during the first local replication. Apparently it would be caused by the param smartsnaplimit, this param has been modified 1year ago but we are still waiting an answer of EMC support to be sure.

    I will keep you informed if one day we are able to do it!