This post is more than 5 years old
4 Posts
1
2287
Move extends from SATA to FC in FAST
I have a policy which is 7/100/70 currently and want to eliminate the 70% SATA pool for one of the hosts which is perfoming poorly. Can I create a new policy 7/100 and add the host to this pool and let FAST move the extends from SATA to FC? I do not want the extends in EFD to move.
SYMCLIGuy
98 Posts
1
May 20th, 2013 07:00
You can do this, however, don't expect the movements to happen very quickly. When you move the SG to the new policy, all the data on the SATA tier will be shown as 'out-of-policy' in the demand report. Most of the movement performed to get the data off SATA will be performed by the FAST VP compliance algorithm which is not designed to move a lot of data quickly. If you have the default relocation rate set (5), the compliance algorithm will move 2GB approximately every 10 mintues.
If you want the data moved more quickly, you can use VLUN. Starting in 5876 and SE 7.4, the symmigrate command has an optional source pool flag. With this, you can specify the source pool as SATA and the target pool as FC. Only the data in the SATA pool will be moved as part of the migration - any data that FAST VP promoted to EFD will be left alone.
Narahari1
127 Posts
1
May 17th, 2013 13:00
Yes. you can create a new FAST policy and switch SG association to new FAST policy and FAST will do the rest
leif3
14 Posts
0
May 20th, 2013 07:00
Hey SYMCLIGuy with the relocation rate set to (5) and only 2GB every 10 minutes referenced in any one document published by EMC or did you just manually monitor your relocation from pools? I actually was looking for the FRR of (1) and how much it moves in any given time. Thanks!
SYMCLIGuy
98 Posts
1
May 20th, 2013 08:00
Leif,
it's documented in the "FAST VP for Symmetrix VMAX Theory and Best Practices for Planning and Performance" tech note available on support.emc.com.
The maximum size of a compliance algorithm request is 10GB, based on a relocation rate of 1. If the relocation rate is something other than 1, divide the value into 10GB to see what the new max request size is. So, the relocation rate of 5 makes the request size 2GB (10/5).
Note: this max request size formula only relates to the compliance algorithm, it does not limit the number of requests generated by the performance algorithm.
I would recommend against setting the relocation rate to 1 as there is the potential for host i/o response times to be impacted. this is talked about in the best practices guide, too.
leif3
14 Posts
0
May 20th, 2013 09:00
Thank you sir i was reading the 2012 I now have the newest doc with what you stated. Thanks again!
Rdamal
165 Posts
0
March 31st, 2014 21:00
Hi,
I noticed that fast vp moves data at sub-lun level which is 360mb and the max moves per day is 200.
I was wondering what is the size of each move
Thanks,
Damal
SYMCLIGuy
98 Posts
0
April 1st, 2014 07:00
Rdamal,
the max moves per day applies only to full LUN movements performed by Optimizer of FAST DP - it does not affect subLUN movements performed by FAST VP. There is no daily limit on the number of movements that can be performed by FAST VP.
Also, the data movement requests for FAST VP are generated on extent groups, which are 120 tracks in size. This equates to 7.5 MB for open systems (FBA) devices.
Rdamal
165 Posts
0
April 1st, 2014 07:00
Thanks for the info.
If we have tdevs binded to a pool and if that pool gets 100% utilized, does new incoming data redirected to a different pool with fast not enabled. If redirected, how would it even know to what pool it has to redirect, and are there any parameters it considers ?
Is there a document that speaks on VP allocation by FAST policy configuration
SYMCLIGuy
98 Posts
0
April 1st, 2014 08:00
Enabling the allocation by policy feature will allow writes to come from a pool other than the pool the device is bound to. In order to take advantage of this feature, the device must be associated with a FAST VP policy.
If the device is not managed by FAST VP, then new allocations will fail if the pool the device is bound to is full.
There is a lot of information on how allocation by policy works contained in the FAST VP best practices technote. Here's a link
https://support.emc.com/docu31003_FAST_VP_for_Symmetrix_VMAX_Theory_and_Best_Practices_for_Planning_and_Performance.pdf?language=en_US
Rdamal
165 Posts
0
April 1st, 2014 08:00
Thank you very much
Rdamal
165 Posts
0
April 2nd, 2014 09:00
From the pdf, If a SG or device is disassociated and then associated to a new policy, the performance metrics collected will be discarded.
What happens if we make changes to max_sg_percent in a policy
Does it discard the existing performance data?
Is there a way to calculate how much time it takes for the new changes made to take effect (assuming we have a performance time window open 24hrs)?
SYMCLIGuy
98 Posts
1
April 8th, 2014 06:00
Making changes to the policy percentages will not cause performance metrics to be discarded. The change to the policy will take immediate effect and FAST VP will start moving data based on the new percentages.
One other note - disassociating an SG from a policy no longer causes the previously collected perfromance metrics to be discarded - the next update of the documentation is going to reflect this newer behavior. What will happen, however, is that the initial analysis period will be reset when the SG is associated back to a policy, so movements will not occur for the devices in the SG until the IAP time passes.
bhalilov1
114 Posts
0
April 9th, 2014 07:00
Is there a way to force the perf metrics to be discarded for particular SG ? In my case I did migration that caused a lot of IO and moved the extend to FC tier. I moved them back to SATA with symmigrate, but FAST VP moved them back to FC.
Rdamal
165 Posts
0
April 9th, 2014 09:00
Is there a way to check how busy a device is from Univmax performance monitor
rawstorage
419 Posts
0
April 9th, 2014 09:00
FAST VP is promoting that data again because it is deeming it to be active and based on the policy you have defined and the activity profile FAST VP is doing what it thinks best.
If you want to move tracks and exclude them from promotion/demotion you can pin the devices and this will exclude from FAST movement, i fyou want to dissassocate the SG form the FAST policy this will disgard the metrics.. But if the tracks are truly busy you may be better leaving FAST VP to work rather than keeping a busy workload in SATA.