FAST VP and TimeFinder/Clone

I found this primus, but I don't understand what exactly means:

Clone has the ability to check only on a bound pool. It is not aware of FAST policies. Even if the allocation follows a FAST policy, both Solutions Enabler and Enginuity check for space on the bound pool during a Clone Create.

Virtual Provisioning (VP) allocation by policy will first attempt to allocate from the bound pool. If there is no space, then it will attempt to allocate from the pools that are part of the policy it is under. Clone, as part of the Create, calls a sanity check function which will only check the bound pool.  Therefore, if during the Create, the Source Thin is allocated, but the Target Thin is not allocated, then the code will allocate the Target. For this to happen, the code needs to ensure there is available space. If there is not, the Create will fail.

¿?

as far as i remember clones are not fast vp aware. Also, as there will be backend writes for the clones so you should see some of the data moving across the tiers for the clone but the allocation will be different than source.

What I understand is that clones are not fast aware, they don't look if the tracks of the source are in EFD or FC or SATA, and copies the DATA to the clone in the pool where the clone was bounded. But if the clone drive is in a storage group with a FAST policy, I understand tracks will be moving between tiers.... like a production TDEV.

But If we do a refresh, and tracks was already moved between tiers...¿?

When we say clones are "not fast aware," we're saying two things:

1. The source device layout on EFD / FC(SAS) / SATA is not taken into account when the clone copy is made.  The clones will be allocated from whatever pool they are bound to.
2. FAST VP acts on them independently of the source devices.  When host IO begins to hit the clone devices, assuming they are part of a FAST VP policy, FAST will tier their data independently over time from the source data.

Ok, I see, but if the target clone moved tracks between tiers, if we execute a recreate to refresh the clone target, it starts from the beginning again (in the binded pool) or not? The target clone will be x% is EFD, y% in FC and z% in SATA. How clone session handle that?

Great!. Thanks for your help....

hi,

according to this document, i would say that only the shared extents of VP SNAP sessions of the same source volume will not be moved. The other extents (not shared) will be..... someone to back me up on this ?

https://support.emc.com/docu31003_FAST-VP-for-Symmetrix-VMAX-Theory-and-Best-Practices-for-Planning-and-Performance.pdf?language=en_US

page 51

TimeFinder VP Snap

The source device in a TimeFinder VP Snap session can be managed by FAST VP. Target devices may also be managed by FAST VP, however, extent allocations that are shared by multiple target devices are not moved.

Frederik,

That was true and is what was documented.  However, we recently found out that the behavior has changed.  If a VP Ssnap target has any shared allocations, then FAST will not move any data on that target volume.  The following VP Snap document has recently been updated with this information.  FAST documents will be updated as well.

https://support.emc.com/docu40346_White-Paper:-Implementing-EMC-TimeFinder-VP-Snap-for-Local-Replication.pdf?language=en_US

However, VP Snap targets can take advantage of Allocation by FAST Policy, as described in the document.

Mike

Hi,

Thank you for the update !

That’s a good thing to know…

Cdt.

Frédérik KAPLER

HI ,

i a little confused,

VP Snaps must work on Fast VP ?

No, vp snap have nothing to do with fast. They just need 5876 code and a tf clone license.

Sent from my iPad

Hi Dear Rich,

Thanks a lot .

Sent from my iPhone.

‫ב-15 בדצמ 2013, בשעה 16:31, ‏"Rich" > כתב/ה:‬

ECN

FAST VP and TimeFinder/Clone

reply from Rich in Symmetrix Support Forum - View the full discussion