OVER PROVISION

Thin provisioning itself doesn’t provide much benefit unless we choose to oversubscribe. We should
make a decision on how much we feel comfortable oversubscribing and need to sign off the risks
involved.

Advantages

The advantages of overprovisioning and thin provisioning are compelling. Many consumers of storage
(servers, file share users, etc.) will request far more storage than they initially need, and continue to
ensure they have a safe margin for growth as they grow. A centrally provisioned safe margin for growth
is far more efficient than hundreds of small ones. The utilization of the underlying storage without
thin/overprovisioning can be very low, and this allows a higher rate of utilization.

Risks

All the risks of this scenario are linked with overprovisioning. The more you overprovision, the higher
your risk. The danger is the potential for the utilization of storage resources to completely fill the
available storage and buying fewer disks means we've got fewer spindles and thus fewer IOPs. Which
means disks will run hotter, and the performance will be degraded.

To mitigate we need to closely monitor the growth and performance and perform migration/expanding
the pool/array to increase the capacity.

Best practice

In order to get the benefits of higher utilization that come with overprovisioning while mitigating the
risk, we need to constantly monitor the storage and be able to take action when required.

Use Unisphere software to monitor and alert on pool utilization conditions. The frequency should be
high enough that none of pools is capable of filling up between polling events.

Establish a baseline threshold “Prod 120% and Non Prod 120%”.All new pools of storage with
overprovisioned clients should get this applied by default. This threshold should be the most
conservative one for KP environment.

Adjust the threshold up if the thin pool is less oversubscribed. If any pool that's only 75%
overprovisioned, hitting 50% utilization isn't nearly as risky as a pool that's at 120% overprovisioning. We
will continue the over subscription until we reaches the OP (120%).

How fast thin pool utilization is growing and how many new project we are implementing, considering
these parameters we need to review the OP every quarter and then Increase / Decrease the OP value.

Low utilized pool = Increase the OP by 5-10 %

High Utilized pool = Decrease the OP by 5-10%

Average growth needs to be calculated using 6 months historical data and Months to EOSL
Also needs to be calculated and based on the results we will adjust the OP Value.

The last 4 months of data not in a straight line perform a "Manual Review"

Adjust the threshold up if the pools are less utilized. If you have a pool that is <=50% utilized
We need to review the OP and then - “Increase the OP”

Adjust the threshold up if the pools are highly utilized and we don’t have unallocated pool space and no
free disks and no room to expand array - "Decrease OP"

Running out of disk too fast – some application who starts filling 'their' disks can run the rest of the
enterprise out of space we need to adjust the op in this case or perform migration or expand the pool.

consider the performance and if the arrays performance is degrading because of OP then we need to
review and decrease the OP.

The EFD Pool OP should be set to 0% so that no user accidently BINDs any TDEVs here.
So that we will give the full Capacity for Fast VP Data Movement.