FAST VP on VMAX

Hi Michael,

The best practice on binding TDEVs on a 3-tier policy is to bind it in the middle tier, which is on this case FC.  For a 2-tier policy, the best practice is to bind it to the lowest tier (i.e. FC for EFD-FC policy and SATA for FC-SATA policy).  Thus, you did the correct thing of binding your production TDEVs. 

FAST VP movements will be influenced by the following:

- I/O profile taken during the performance window - you need to make sure that you capture the correct profile of the LUNs.  As per best practice, the performance window should be running 24x7 so that FAST VP has the full view of the profile of the LUNs.  If you have the perf window not running 24x7, then FAST VP is prone to miss some idle and/or busy times for the LUNs.  The best practice for movement window is 24x7 as well to ensure that FAST VP is reactive to sudden change in performance profile and act on it accordingly.

-the upper usage limit (in %) set on the policy - as per the policy that you have mentioned above, the upper usage limit for the FC tier is 100%, thus FAST VP can actually have all the extents of the LUN to stay on FC as it deems fit (and if your performance window is not set to 24x7 then you might have missed out some idle times for the LUNs, thus extents are not being demoted as you would have expected)

-response time improvements that FAST VP determines - if the response time for the LUN with extents sitting on a specific tier (i.e. your FC tier) are within acceptable limits, then extents will not be demoted. If FAST VP determines that there will be a 50% improvement on the performance if extents are moved to the next higher tier (e.g. FC to EFD) then it will move it regardless of the I/O profile but provided your policy and the available space on the target tier allows it.  It is also possible for FAST VP to move extents from SATA directly to EFD if there will be 70% improvement on the response time.

When you disassociate a SG from FAST VP, you can use VLUN migration to move the extents back to where the TDEV is bound to.  You can also move the extents to any pool aside from where it's initially bound and do a rebind.

Hope the above cleared your doubts.

Andrew

Rebind will not cause any data loss.  It just changes the binding of the TDEV which means any new writes coming in will go to the new pool (target of the rebind).  Extents currently sitting on the previous pool will stay there unless you do a VLUN migration which moves the extents to the target pool.

Ok That clears up a few thingds suspect that the line - if the response time for the LUN with extents sitting on a specific tier are within acceptab;le limits then the extents will not be demoted is the key here. The reports are showing us that the EFD tier is fully utilised and the FC tier has a continued to grow in use as we add more production servers and bind to the FC tier on creation.

As FAST effectively does not see a reason to move it, the extents are staying on the silver tier and not moving as the customer expects which is skewing the usage figures

We see little use of SATA but higher level of use for FC and EFD which are limit in capacity

Will the rebind loose data on the move the customers comcern with binding to SATA is if he removes the FAS policy it will move all the extents back to the SATA tier and the only way to move it to another tier will be to unbind the LUN and then rebind if we could just rebind to a new tier without loss of data would make it easier

So even if we remove a FAST VP policy from a group it will not move the extents they stay where they are and only a LUn migration will move them

Yes, when disassociating a storage group from a policy, the extents stay where they are unless you do a VLUN migration to move those extents.  The process of disassociation does not move the promoted/demoted extents back to the original pool where the TDEV is bound to.

Thanks for this think the issue is we are not seeing any real take up on the SATA tier when looking at the LUNs and as the majority of the capacity on the array is in this pool it looks like FAST VP is not working

FAST VP works as designed and will behave as configured. You might want to re-check the parameters that you have set and the policy that you have associated your SGs to.

Andrew Consuegra Siaotong

Sr. Solutions Architect @ EMC

+971559549356

Agreed but in the main you have answered what I wanted I was unsure what happened when we removed a FAST VP policy from a storage group and how we can then rebind or move LUNs around without having to actually unbind and rebind the storage with the resultant loss of data

I just think it is a case of how fast we are adding new servers and the fact that the array is not really under any load etc so the FAST VP policy are not aggressively moving data around so whe nwe look at the three tiers we are not seeing the motion the customer expects

We also do not have the performacne set o 24 /7 and ,missoput the backup windows betweeen 16:00 - 23:00 daily so as yo ustated this could also skew the results

I have no control on changing what we are using unfortunately as the policy are set and agreed in the design etc

Thanks for the help however it has been effective