This post is more than 5 years old
5 Posts
0
2495
Timefinder VP Snap and FAST VP
Hi,
I have couple of questions regarding the way FAST VP works with Timefinder VP Snap.
1. If I have a VP Snap target device mounted on a host (the source dev is not mounted at present) and it is heavily doing read operations, will it move the corresponding extents on the source device which are heavily utilized to a higher tier based on the FAST VP Policy associated to its storage group? I hope those extents will be moved to a higher tier irrespective of which device (VP snap source or target) is causing the read IOs on it. Am I correct?
2. If I write some data to the VP Snap source/target device, where does the COFW changes land? Will it be on the same tier as of the source extent or will it be from the pool to which the target device is bound to? The feature "VP allocation by FAST policy" is enabled on the VMAX array. Does it consider this COFW as a new allocation and put it in the pool to which the target device is bound to or will it consider the performance metrics of the source extent set and then allocate new extents from the same tier (if both source and target devs are associated to same FAST policy)?
SYMCLIGuy
98 Posts
0
May 24th, 2013 10:00
Joseph,
I need to provide some clarification to the answers you have received regarding your first question. When a VP Snap target device is read from, but the track being read is still associated with the source device (i.e. it has not changed on source or target since the session was activated), the read will be credited to the source device as this is the device that ultimately owns the data. If the read is serviced from disk, then the FAST VP metrics for the source device are updated. If the source device is under FAST VP control, then the target reads being redirected to the source may cause the extents to be promoted to a higher tier.
I just ran a test that would be similar to your example. I created a VP snap session between one source and one target. The source device is associated with a FAST VP policy, but the target device is not being managed by FAST VP. I then ran no I/O against the source device and a 100% read workload against the target device. FAST VP metrics were only updated for the source device, not for the target device. As the source device was managed by FAST VP, extents were then promoted to the EFD tier in the array.
Regarding your second question, the allocation caused by a COFW will only consider the metrics collected for the target device. The normal rules of allocation by policy will then apply. If other extents have previously been copied for the target device, then there may be FAST VP metrics for the extent group set local to the target device, but the FAST VP metrics of the source device will not be considered.
Hope that helps.
sauravrohilla
859 Posts
1
May 22nd, 2013 00:00
1. If I have a VP Snap target device mounted on a host (the source dev is not mounted at present) and it is heavily doing read operations, will it move the corresponding extents on the source device which are heavily utilized to a higher tier based on the FAST VP Policy associated to its storage group? I hope those extents will be moved to a higher tier irrespective of which device (VP snap source or target) is causing the read IOs on it. Am I correct?
Saurabh: Movement will only happen if your Target dev is part of fast policy and if it is part of a fast policy then yes, your target dev will move its chunk across tiers.
2. If I write some data to the VP Snap source/target device, where does the COFW changes land? Will it be on the same tier as of the source extent or will it be from the pool to which the target device is bound to? The feature "VP allocation by FAST policy" is enabled on the VMAX array. Does it consider this COFW as a new allocation and put it in the pool to which the target device is bound to or will it consider the performance metrics of the source extent set and then allocate new extents from the same tier (if both source and target devs are associated to same FAST policy)?
Saurabh: COFW will be on target dev. If your SNAP target is bound to a diff pool then protected data will be copied to target pool and if the snap target is on the source pool then it will be on the source pool only (it infact does not copy the data, it just refers to the tracks of the source dev when the target is bound the source pool).
regards,
Saurabh
rbhat23
15 Posts
1
May 22nd, 2013 06:00
Answers to 1: Data extents will start moving only if your Target dev is part of fast policy.
Answers to 2: COFW will be on a target device. If your target device is bound to some other pool then protect device will be moved or copied to a target pool.
Hope this helps!
joseph_gk
5 Posts
0
May 24th, 2013 13:00
Thanks a lot for the clarification. This is really helpful. I was expecting those results, but thanks for testing that and confirming that.
emcsanman101
17 Posts
0
June 2nd, 2014 17:00
I am lost, if target device is bound on different pool, then COFW will be written and if same pool it wont?
Quincy561
1.3K Posts
0
June 3rd, 2014 06:00
Even if the source and target are in different pools, only the changes (writes) to source or target will be copied to the target pool. The unchanged extents will remain in the source pool and will be common to both source and target.
pete2c
76 Posts
0
June 3rd, 2014 06:00
If the source/target are in the same pool, they will share the data they have in common. The COFW would still be written either way when you have a target (or several) in use.
The difference between using the same pool and a different pool for the source/target is the overhead. If you use a different pool for the target you'll have another full copy of the data on the TDATs in the target pool. All targets have to be in the same pool whether it is the pool the source is in or not. So the targets will always share a single instance of the data they have in common.
Hope this helps.
Quincy561
1.3K Posts
0
June 3rd, 2014 06:00
The only difference is where the first writes go, to the same pool or different pool. All other operations are the same.
emcsanman101
17 Posts
0
June 3rd, 2014 06:00
Does it mean, there is no difference in having source/target on same pool or different pool? the only caveat is available capacity on the pools?
pete2c
76 Posts
0
June 3rd, 2014 07:00
My mistake Quincy, thanks for clearing that up