I’m seeing some interesting FAST behaviour on a VMAX 40K, this is quite a busy box and we are still migrating servers onto it.
The FC pool currently at ~80% capacity, SATA pool at ~34% capacity, PRC set to 10% on FC.
The Ingress and Egress counters are pretty flat ~1500 tracks in / out of each pool. On previous behaviour I would expect a portion newly migrated devices to filter down to SATA and this would reflect in the pool capacity. So either all this data really belongs on FC or for some reason it is not being allowed to move down but how can you tell?
The majority of devices are in a policy that has 100/100/10 (EFD) so this shouldn’t be a policy issue.
SATA disks are quite busy, could this be the cause of this behaviour?
Just looking for an idea of where to start in terms of performance counters that would give an indication of what is going on.
Have you looked at your FAST control parameter settings? What is your Max Device Moves Per Day set to? What about your Workload Analysis Period and Initial Workload Period?
It sounds like you bound these devices to the FC pool and want to let FAST move them up/down as needed. I believe the FAST algorithm favors promotion or demotions so you may just need to wait. We start most of our volumes on SATA and let them move up. This has worked well for us but may not fit your requirements.
Min initial Workload period is 8 hrs
Workload Analysis period is 7 days
Relocation rate is 8
This is a FAST/VP config so i don't think moves per day applies, it maybe if we leave it long enough it will move some data down, it will have a few quiet weeks over the holiday to sort itself out. For the last week it has been almost flat in terms of overall data movement, ingress and egress just balance out.
My personal experience is that to improve SATA demotion, you should be adjusting two controls:
FRR should be set at 5 for 5876 family and at 3 for 5875 family
Second, WAP should be reduced to 5 from 7. This means we will look back a shorter amount of time and less likely to see activity which will allow for quicker demotion.
Changing these two parms results in more tracks moving to SATA quickly.
Based off our experience and talks with engineering Rich's recommendations are spot on. We have many different workloads on a fully populated 20K and those settings have worked for us.
I wouldn't recommend this but I'll throw this out there as well. As long as all of your storage groups associated to a policy that has multiple tiers with available space you can even fill up a tier as long as you have the setting "allocate by FAST policy" checked. I know because we filled up our FC and EFD tier (PRC set to 3 in FAST VP and PRC set to 1 at the thin pool level). We expected performance degradation but things just keep going along as normal since there is still capacity in SATA.