By all means provision storage economically but don't put applications on a starvation diet. That's the message from 3PAR CEO David Scott.
His company has had thin provisioning (TP) for what seems like a long time. Now that EqualLogic has added it to the IP Storage (iSCSI SAN block and file) space and HDS is set on adding it to the high-end enterprise drive array space, David wanted to mention a few aspects of thin provisioning that matter (and that, naturally, 3PAR has got well sorted out).
1) Thin Positioning should support thresholds, alerts, or hard limits to warn about storage capacity consumption otherwise there will be a high risk that customers suffer application write failures from running out of storage capacity before the administrator realizes there is danger.
2) The implementation should have a way of automatically assigning disk capacity that has been added to the array into a Thin Provisioning pool. If not then the process will involve a number of administratively intensive, manual steps (creating RAID groups, splitting RAID groups into LDEVs, assigning the LDEVs to Thin Provisioning pools). This is a high level of overhead which any good Thin Provisioning implementation should avoid. It also adds the risk that the Thin Provisioning pool could run out of spare capacity before the administrator realizes it is out of space (especially if there is no alert facility) - again causing write and application failures.
3) If a supplier's implementation doesn't support Thin Provisioned volumes with remote replication software then it can't protect their applications using standard disaster recovery techniques. This is a basic requirement of any Tier 1 system.
4) If the performance of Thin Provisioned volumes is less than that available with standard volumes then customers will be very sensitive to the impact on their applications and will resist using it. Customers may have to do a lot of configuration work to manually spread storage capacity assigned to Thin Provisioning pools over lots of array groups, and even then will typically get performance results that are a fraction of that they get with standard volumes.
In summary, a bad Thin Provisioning implementation is worse than no Thin Provisioning implementation at all. Scott recommends that you should ask any supplier how their implementation stacks up against these points.
Naturally, 3PAR stacks up very well. Scott says it has all the thresholds, alerts and hard limits necessary to minimize the risk that you run out of capacity. It automatically grabs free disk space, just in time, to replenish its Thin Provisioning pools so as to eliminate administrator involvement and minimize the risk that an application runs out of disk space to which it can write.
It is fully supported by 3PAR's Remote Copy solution for remote replication so that the applications can be protected by disaster recovery arrangements. And finally, performance is not meaningfully different from that of standard volumes. Customers don't gain efficiency, only to lose performance. He makes the point that 3PAR's architecture was designed for the implementation of Thin Provisioning, not as a bolt-on.