VMAX Thin Provisioning Subscription Rate

Utilization measures how much data is actually written to a Thin Pool.

Subscription measures the size of the LUNs bound against a Thin Pool.

In your example, your 38TB pool has less than 10TB written (utilization), but a subscription of 501% means that more than 180TB of LUNs have been bound to this pool.  I'll let that sink in a moment.

The danger is, if all of the bound TDEVs begin to write all of their allocation, you can run out of space in the Pool.  This means that LUNs will encounter errors on the host side and could lead to loss of data access.

The best remedy is to either very closely monitor space consumption and plan for purchasing additional disk, or work with server/application owners to resize LUNs allocated for use.

Let us know if that helps!

Karl

Subscription of 501% means that more than 180TB of LUNS can be bound to that particular pool. It does not mean it's been already bound. 501% is the maximum limit this pool can be allocated logically.

I'm going to make some assumptions here:

• I suspect you have FAST VP enabled
• I suspect this might be your FC/SAS pool (depending on the model of Symm)
• I suspect there is at least a SATA/NL-SAS pool with more capacity (and likely an EFD pool as well
• Based on these assumptions I'm going to propose that you probably follow Best Practices and initially bind most of your volumes to this pool. FAST VP would then do its thing and migrate a lot of the data down and some of it up

All that leads to a situation where you have a lot of capacity initially bound to a middle tier while not a lot of capacity is actually consumed in that middle tier over the long run. If this is accurate then it is important to monitor the total subscription of the array against the overall total pool capacity on the array. We ran into this very issue and had to come up with some customer scripts to report on this through an Excel workbook. Basically we gather the total capacity of the pools on the array and compare it against the total used capacity in those pools (for FAST VP % Used), then we measure the total allocated (how big did you say the volume could be) capacity of bound thin devs against the total capacity of all the pools to get a more useful subscription rate.

Hopefully I'm not way off base on my starting assumptions. If I am then the rest probably isn't that useful.

I've got to side with Karl on this one. There is a setting where you can cap the maximum subscription rate but that is NOT this number. A subscription rate of 501% means that volumes totaling 501% of the pool capacity have been bound to that pool. See my other response directly to original question.