Start a Conversation

Unsolved

This post is more than 5 years old

1 Rookie

 • 

20.4K Posts

29799

February 14th, 2016 21:00

Reproduce TimeFinder/Clone functionality on VMAX3

Hello guys/gals,

I am trying to reproduce TimeFinder/Clone functionality on VMAX3. I would prefer not to use "emulation" and achieve the same thing using symsnapvx. One requirement is that clone target is a fully copy and not just a snapshot.  Here are the steps that i am attempting:

1) create target TDEVs same size as source TDEVs, add them to a storage group.

2) create snapshot

symsnapvx -sid 123 -sg sg_oracle -name snap establish

3) link to target TDEV, specify -copy to get full copy

symsnapvx -sid 123 -sg sg_oracle -snapshot_name snap link -copy -lnsg sg_snaptarget

so far so good, i can SRP utilization go up so it's making a full copy.

4) next i need to perform symsnapvx equivalent of symclone recreate. I don't see any options but to establish snapshot again

symsnapvx -sid 123 -sg sg_oracle -name snap establish


5) next i relink to target devices


symsnapvx -sid 123 -sg sg_oracle -snapshot_name snap relink -copy -lnsg sg_snaptarget



So these steps appear to achieve what i typically do with symclone, except for one thing. When i look at snapshots i see two snapshots with the same name.  I don't want multiple snapshots, i just need the one that i just established.  I can't terminate gen 1 snapshots because that will break "incremental" nature of this approach ? Am i understanding correct ?  If that's the case what are my options, setting TTL on each snapshot and let it auto expire after 25 hours or so ?



symsnapvx -sid 123 -sg sg_oracle list   -detail

Storage Group (SG) Name   : sg_oracle

SG's Symmetrix ID         : 0000000123    (Microcode Version: 5977)

------------------------------------------------------------------------------------------------------------------------

                                                                          Total

Sym                                         Flgs                          Deltas     Non-Shared

Dev   Snapshot Name                    Gen  FLRG Snapshot Timestamp       (Tracks)   (Tracks)   Expiration Date

----- -------------------------------- ---- ---- ------------------------ ---------- ---------- ------------------------

000B3 snap                                0 .X.. Mon Feb 15 05:03:38 2016          0          0                       NA

      snap                                1 .... Mon Feb 15 04:43:22 2016          0          0                       NA

                                                                          ---------- ----------

                                                                                   0

Thoughts ?

Thank you

465 Posts

February 14th, 2016 21:00

I don't think the copy feature of SYMSNAPVX is there to support the legacy CLONE COPY feature. I would be interested to know if there is a technology reason to use COPY (outside cascade operations) with snapvx in your environment.

As I understand it, when using cascade SYMSNAPVX, you have a dependency on terminating the the cascading snaps in reverse order typically (can't terminate the original source>tgt if there are cascades). If the original source>tgt snapvx is set to copy (and all tracks copied), this relationship may be terminated, even if the TGT is a source for a cascaded snapvx.

465 Posts

February 14th, 2016 21:00

Edit: relink -copy should provide the function you are after. I see that there are 2 instances of snapshot name "snap" in your output. Let me look at this in more detail....

522 Posts

February 15th, 2016 05:00

The relink command is the recreate from my experience since it will incrementally re-sync from the source to the linked target. You would likely create a new snapshot form the prod volume for the updated PiT image and then issue a relink from that snapshot to your existing linked target and it will be an incremental refresh, so your #4/#5 above is the way that I am aware of.There is no recreate that I am aware of with snapvx.....I think your procedure above is correct and the intended process.

1 Rookie

 • 

20.4K Posts

February 15th, 2016 05:00

Jasonc,

reason i am doing -copy is because target devices  needs to be an R1, according to timefinder docs it requires -copy.

As you can see in step 5 i am using relink -copy but how do i "refresh" my snapshot so that it's an incremental copy. I don't see a recreate command for the snapshotvx, i only see establish. When i run establish with the same name as my previous snapshot ..it creates a new one.

522 Posts

February 15th, 2016 05:00

I have done both, but tend to do with the manual deletion or script it as cleanup upon creation of a new one just because of preference/control versus anything else really.

1 Rookie

 • 

20.4K Posts

February 15th, 2016 05:00

Thank you Keith. How do you deal with "old" snapshots, do you set TTL when you create them or manually/script delete them ?

522 Posts

February 15th, 2016 06:00

hmm...you have the -copy which is what makes it incremental so I wouldn't expect a full push. Does the -summary listing show anything different?

1 Rookie

 • 

20.4K Posts

February 15th, 2016 06:00

something is not right. Everytime i run this command:

symsnapvx -sid 123 -sg sg_oracle -snapshot_name snap relink -copy -lnsg sg_snaptarget


even if i did not create a new snapshot, output from "symsnapvx -sid 123   -sg sg_oracle list   -linked -detail -gb" shows that it's performing a full copy. Same snapshot, nothing changing, i am simply re-running the same relink command. Any thoughts ?

1 Rookie

 • 

20.4K Posts

February 15th, 2016 10:00

same thing, shows how much is remaining to copy

symsnapvx -sid 123 -sg sg_oracle -snapshot_name snap list -summary -gb

Storage Group (SG) Name : sg_oracle

  Snapshot  State               Count

  -----------------------      ------

  Restored                          0

  RestoreInProg                     0

  Established                       2

  EstablishInProg                   0

  Linked                            0

  CopyInProg                        1

  Copied                            0

  NoSnapshot                        0

  Failed                            0

  -----------------------      ------

  Total                             3

                              GB(s)

                              -------

Total Remaining                 157.3

465 Posts

February 15th, 2016 19:00

I tested this on a VMAX 3 running SE v8.0.3 and 5877.790 (EMC lab box) using the following:

symsnapvx -sid 89 -name jason establish -dev cd8

symsnapvx -sid 89 -snapshot_name jason link -lndev cd9  -dev cd8 -copy

symsnapvx -sid 89 list -dev cd8:cd9 -summary -gb  << This shows non-zero value in GB to copy field

symsnapvx -sid 89 -snapshot_name jason relink -lndev cd9  -dev cd8 -copy

symsnapvx -sid 89 list -dev cd8:cd9 -summary -gb  << This shows zero value in GB to copy field


Repeat last two commands numerous times and consistently get zero value in GB to copy. My test appears to be working as designed. What code levels are you running?

465 Posts

February 15th, 2016 19:00

You will see in my example there is just a single establish. The relink will obtain a new PIT and produce a copy delta. So I think in your case, the second establish isn't required and this is causing another full copy. From the TF CLI prouct guide:

RELINK:

Remove the link to target device and present a different snapshot from the same source device, or relink to

the same snapshot. Refreshes the point-in-time copy on the link target when it's been modified by host

writes.

I think when it says "...when it's been modified by host writes" actually means when the source or target has been updated. In other words the relink will make the target device the same as the source. The wording is a little unclear.

522 Posts

February 16th, 2016 04:00

From previous testing (don't have a box right now), I was seeing incrementals I believe with new establishes on the source volume to create the new PiTs (like ProtectPoint) like dynamox is doing so I think I would expect it to work incrementally as long as the relink is used and the source stays the same. that snippet above seems to state both will be incremental:

RELINK:

Remove the link to target device and present a different snapshot from the same source device, or relink to

the same snapshot. Refreshes the point-in-time copy on the link target when it's been modified by host

writes.

It's odd that you are seeing a full copy, If you re-run a test and use the -detail at the end on the list, does it show you a number of shared and non-shared tracks between your generations since I am assuming you will have 2 generations if you are using the same source and snapshot name. Just curious if that gives any insight.....

1 Rookie

 • 

20.4K Posts

February 16th, 2016 08:00

Jasonc,

If i relink to the same snapshot over and over and look at the output from this command

symsnapvx -sid 123   -sg sg_oracle list   -linked -detail -gb


remaining GB column always starts out by showing 200G remaining. (200G is my device size).  Snapshot has not changed, target devices are not presented to any hosts, then there should be nothing to copy, it should be done instantly.  What am i missing ?


Thank you

465 Posts

February 17th, 2016 21:00

Let me redo my test using the same query format you use and see what i get.... Next week most likely.

465 Posts

February 22nd, 2016 02:00

I have rerun the same test i did before using a device file and also using storage groups as in your jobs Dymox. The initial link performs a copy operation. Subsequent relink operations produce no data to copy since I havent updated the source.

I had non RDF and RDF1 type devices in the lnsg.

I note that the RDF1 devices that are the linked target need to be suspended before the relink -copy can work. As an added check, doing an  RDF query after the relink showed no RDF invalids.In other words, i cant recreate your scenario unfortunately. Everything I do seems to be in alignment with what is documented.  You many need an SR...

No Events found!

Top