VMAX 10K Pool Utilization Confusion

If you preallocate your thin devices the unwritten to preallocated tracks will appear cold to FAST VP and will be demoted to the lowest tier.

You did not say what Enginuity release you were running.

What is your workload analysis period set to?  If it is the default of 1 week, you may want to consider increasing it so that workload statistics don't decay as quickly.

Enginuity is running 5876.229.145.

We only have about 1 TB preallocated, and about 800 Gig of that is in use.

I can't get to the Workload Analysis Period in the Optimizer dashboard, I get a message saying "Optimizer Get Status Failed, The requested feature is not supported for this Engiuity or SYMAPI version".

Under Performance, Settings, System Registrations, Data Collection Policies Details, I see Collection Recovery set at 24 Hours and Diagnostic Interval set to 5 minutes.  I'm not sure if those settings are related.

5876.268 was just made "target" code, AFAIK.  Previous was 5876.251.  I would recommend getting to more recent code.  I'm pretty sure there were some fixes in later releases that resulted in less data being demoted to SATA in some cases.

Also if you are having trouble setting or seeing the FAST VP parameters, you should probably open an SR to get that addressed.

The following CLI command should show your Workload Analysis Period:

symfast -sid xxx list -control_parms

The week period sets the decay rate.  The most recent activity will have the highest scores.  The workload a few days old will have decayed significantly.  You may want to increase the workload period to two weeks in order to keep active devices in higher tiers longer.  It won't stop the most recently active devices from having the highest scores for promotion, but could slow demotion. 

The workload analysis period is 168 hrs/1 week.  I wouldn't think data would get cold after a week, the only week we see little activity is end of December and weekends.  I'm going to look thru the release notes to see if I can find the issue that mentioned earlier.

Here is the full result of the command.

Optimizer and FAST Control Parameters:

Data Movement Mode                : N/A
Max Simultaneous Device Moves     : N/A
Max Device Moves Per Day          : N/A

Optimizer, FAST and FAST VP Control Parameters:

Min Initial Workload Period(hrs)  : 8
Workload Analysis Period(hrs)     : 168

FAST Control Parameters:

Swap Not Visible Devices          : N/A
Allow Only Swap                   : N/A

FAST VP Control Parameters:

FAST VP Data Movement Mode        : AUTO
FAST VP Data Relocation Rate      : 5
Thin Pool Reserved Capacity(%)    : 10
VP Allocation By FAST policy      : Enabled
FAST VP Time to Compress          : Never
FAST VP Compression Rate          : 5
FAST VP Compliance Mode           : N/A

Thanks for the explanations.  I have a SR that has been escalated to Level 2 about the error message.  I decided to set the time window for monitoring performance to 8 am to 5 pm, being that is time of day that we care about performance.  Maybe having the window at the default of 24 hours with little to no activity outside of server backups could have been an issue.  I'm hoping to see a difference in a few days by changing those settings.

Restricting the monitor window will likely result in more demotions, not less.

I'm guessing you just have a workload with a high skew - that means a small amount of data doing the vast majority of the work. Since FAST VP works sub-lub,  if you have only a few chunks of data doing most of the world it would attempt to move the cold data down.

You can engage your EMC pre sales team to look using tier advisor,  and that will tell you the skew in your workload.

The initial post said that the SATA drives had high utilization.  If it was just idle data being pushed down, the SATA drives wouldn't be too busy.

I took the posters original post about disk utilization alerting to mean pool utilization alerts and not performance alerts. The way I read it OP wants to know why all his data is on SATA but not FC, not why his SATA tier is under performing - mostly based on the line "Any thoughts on why the SATA Pool is so highly utilized while the FC pool isn't?"

I guess I could have phrased the question better.  The question was about why was so much(quantity) of the SATA disk being used vs leaving so much of FC being underutilized, ie pool utilization.  We are not aware of any performance issues, just trying to understand what is going on.   I know the hosts write to FC tier first and then the box sorts it out.  Our EMC rep will be visiting us next week, I'll ask them about Tier Advisor.  I never heard of till Mark mentioned it.

Ok, when I read "We see alerts about disk utilization for SATA pool" I just assumed that it was performance alerts.

FAST VP on VMAX does not try to keep the FC and EFD pools filled with idle data.  If 100% of the data was idle, and fit 100% in the SATA pool, the FC and EFD pools could be empty. 

A couple of things about your configuration. You have "VP Allocation By FAST policy: Enabled" so even though you may be binding to the FC tier allocations can come from any tier in the policy based on the performance metrics available for each volume. If you are only using the array level Pool Reserved Capacity setting you are not using as much of your SSD tier as you can. I would set the PRC for your SSD pool to 1%. If you want to limit how much of the SATA tier a Storage Group will use you may want to change your Gold policy to 50/100/50 and then implement a Silver policy that uses something like 25/100/100.