FAST VP Policy not working for some Storage Groups

No, none of the devices are pinned. I've opened a ticket with support to see what they can find also.

Hi hamilton00,

Have you left them "pinned" to the FC pool ?

Regards,

Kleanthis

It may be possible that there is not enough skew for fast to move the chunks across the tiers. Do you have enough IOs coming on the SG?

regards,

Saurabh

Since these are TDEVs, they don’t grow until there is data written to them. If you are running the 5876 code on your VMAX and have Allocation by Policy enabled, then as writes come in they will be distributed to the performance appropriate tier. Allocation by Policy will use another pool if the destination pool is full. As long as you have space in any one of the pools in your FASTVP policy, then the write will go through. Although, once a pool is full, it is not an optimal situation for FASTVP.

Also, you have to make sure that the pool reserved capacity is set to a very low number to allow for writes to continue to that pool. Ideally, you would want to allocate space from just one pool (FC), and let FASTVP move the data around. Pool bindings and oversubscription of any single pool are a rather abstract concept now due to Allocation by Policy.

Some of the tdevs aren't being actively used yet. They were presented to hosts to eventually migrate to. However some are in use but are also not being migrated up or down pools. Will FAST not demote devices that have no IO but leave them in the FC tier where originally bound? My FC pool is 90+% allocated and is over 100% subscribed. The SATA pool is only 9% allocated and has over 130TB available. I have many more devices to create. what will happen if i continue to bind to my FC pool? I assume FAST is smart enough not to fill up an entire pool when there are others available with ample space.

If you are on 75, binding will fail ?

If you have 5876 and SE 7.4+ then one of the control parameters of FAST VP is "VP Allocation by FAST Policy" which means that even if you bind something at the FC pool but there is not enough capacity there, then new allocations can be made from any pool that is part of the tiers in the FAST VP policy. In your case the new allocations will come from the SATA pool and you will avoid write failures due to pool full condition.

Thanks for the info guys. I'm running 5876.159.102. One thing I didn't mention is that all of my TDEVs are pre-allocated 100%. The pool reserve capacity is at the default 90% right now.

I spoke with support regarding the SR I opened and they are bringing in some FAST SMEs to look at the array also. One thing that was mentioned is that the response time for the FC tier is a little high and not far off from the SATA tier. Trying to see if that may be preventing some demotions.

Hello Hamilton00 (i hope the new season in Mercedes will be better for you:)

I will agree with Kleanthis and Aj2546 and i will try to give to you my point of view:

VP Allocation with FAST Policy

This feature allows new allocations to come from any of the thin pools included in the FAST VP policy that the thin device is associated with.
FAST VP attempts to allocate new writes in the most appropriate tier first. This avoids a double movement of initial allocation followed by storage tier promotion or demotion. If there is no information available to determine the most appropriate tier, then FAST VP allocates the extent from the pool the device is bound to.
If the pool chosen to allocate the data is full, FAST VP allocates to other pools contained within the FAST VP policy. As long as there is space available in at least one of the pools within the policy, all new extent allocations will be successful.
The allocation by policy feature is enabled at the Symmetrix array level and applies to all allocations for all devices managed by FAST VP. This feature is disabled by default. If the allocate by policy feature is disabled, new allocations will come from the pool the thin device is bound to.

Regarding PRC are you sure that the default is at 90%?

Actually the default is 5% but you can change it at anything you want.

But try to keep the EMC standard and EMC's recommendation.

TDEVs are fully pre-allocated i believe for some reason. Let's most of them are for Data files for Oracle and must be pre-allocated. Or the Boot or the Swap or the common files or the quorums must be FULLY PRE-ALLOCATED and pinned to the FC pool.

The pools themselves don't have a PRC configured however the array setting is 90%. This has not been modified from the default.

Good morning Hamilton,

i believe that you have to decrease that PRC value.

When you create a THIN POOL the default value is 5%.

I haven't created a THIN POOL for a long time so i have to create a new one and to check if this is the default value.

But 90% PRC is huge.

Sorry I read one thing and typed another. The PRC is 10%. I guess I was thinking that means 90% of the pool could be used.

Hamilton i must admitted that when you mentioned 90% i was scared!!!

But 10% is ok.

The default system wide PRC is 10%. So if you haven't modified the pool level setting then the system wide setting will apply.

If you are using fully preallocated volumes FAST VP will see all those unused allocated tracks as cold and start demoting them.

There are a few instances that I can think of where the data will not be moved when you would otherwise expect it. One is when you have high write pending limits on the system, but that should be a rare or infrequent occurrance.

There are also some instances where FAST VP will not move extents between tiers due to performance of the source or target tier. I recall reading about this and am trying to find more detail on this and will post back if I find it, but this may be the issue you are seeing on your frame.

I think I found the information I was looking for. This is my understanding of the process..

If an extent group is slated to be moved based on promotion/demotion thresholds then a response time comparison is performed betwee tne soruce and target pool. If the response time difference between the two pools is not above a certain percentage then the move is not peformed.

This could happen when, for example, an extent group is slated for promotion from your FC pool to the EFD pool but the response time between the two pools is very close. In this example the EFD pool is heavily utilized and therefor promotions will not occur becuase the extents will not realize a sufficient decrease in response time as a result of that move.

But... from what I have heard there is not a response time check for demotions. So this may not apply in your situation.

Another item to note is that preallocated extents that have not been written to aren't really migrated between tiers, simply the pointer is moved to the lower tier and the allocation freed up from the source pool. But I understand that demotion activity is a lower priorty than promotion activity so it may be that you are seeing less demotions becuase of the need to address performance related moves.

In general with FAST VP and binding to the FC tier you will have to oversubscribe the FC tier quite a bit in order to bind to the tier and allow the bulk of the low IO capacity tier down to SATA. Allocate by policy doesn't change this requirement if you are still binding to the FC tier but does help in that it will allocate from the SATA tier if needed.

Please post back with the result of your SR, this is an interesting case.