Solved!
Go to SolutionDD
Dr.diSousa
1 Rookie
•
97 Posts
0
2442
April 29th, 2013 09:00
FAST VP and TimeFinder/Clone
Hi, customer is using FAST VP in their production devices with 3 tiers (EFD, FC and SATAII), and he wants to clone this devices not for backup purposes, just for DB testing, or performance stress, etc...
Like the Source Devices are in FAST VP, their tracks must be in the EFD disks, FC and/or SATAII devices, it depends in the FAST VP analysis. Clones was binded to FC POOL in the beginning, and customer wants to put the clone device in the same FAST policy as source device to have the more similar situation.
Is the clone FAST aware? If we have the clone device with a FAST policy, will it move the data between tiers? What happens if I want to refresh that clone?
Do you recommend to remove the FAST policy from clone devices? and what about clone -vse?
Note: Box is a VMAX 20k with enginuity 5876
Thanks in advance,
Dario
IPM
1012
0
Posted April 29th, 2013 10:00
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.
¿?
1012
0
Posted April 30th, 2013 04:00
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.
1012
0
Posted April 30th, 2013 04:00
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...¿?
1012
1
Posted April 30th, 2013 08:00
When we say clones are "not fast aware," we're saying two things:
- 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.
- 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.
1012
0
Posted May 2nd, 2013 08:00
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?
1012
0
Posted May 2nd, 2013 08:00
Great!. Thanks for your help....
1012
0
Posted July 11th, 2013 09:00
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 ?
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.
1012
0
Posted July 12th, 2013 09:00
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.
However, VP Snap targets can take advantage of Allocation by FAST Policy, as described in the document.
Mike
168
0
Posted July 12th, 2013 12:00
Hi,
Thank you for the update !
That’s a good thing to know…
Cdt.
Frédérik KAPLER
ScottBrightwell
9 Posts
1012
0
Posted May 2nd, 2013 08:00
For VSE clones, the vse target extents will not be tiered by FAST VP. They will remain in their bound pool.
For full size clones, they are normal symmetrix devices in all respects. If their allocated extents have been tiered, then they will remain tiered until something like FAST VP acts upon them. You can terminate the clone, recreate the clone etc, and the extents will not "revert" back to the bound pool unless you explicitly do so with a symmigrate command.
Also, the workload caused by creating the clone is not counted by FAST VP. Only host io will cause FAST to begin tiering the clone target, so it's important that you bind them to an appropriate tier up front for the copy performance you need from them. Many customers use a set of 10K spindles as a clone target pool.