Thin provisioning virtualizes storage capacity in the same way virtualization virtualizes server capacity. The idea behind thin provisioning is to create a pool of virtual storage that is allocated to users in the conventional fashion. This pool is supported by a much smaller pool of actual storage that is parceled out as needed.
It is best to approach thin provisioning carefully, making sure you understand all the possible pitfalls in your system. Thin provisioning should also be tested thoroughly before being put into production.
So, how does it work? In effect, thin provisioning works like fractional reserve banking. Banks routinely loan out more money than they have on deposit, secure in the belief that they won't need to disburse all their deposits at once.
Like fractional reserve banking, thin provisioning depends on the idea that you aren't going to need all your resources at once. For a variety of reasons, including optimistic estimates of application use and the natural conservatism of applications managers and network administrators, most systems have allocated far more storage than they really need. In a conventional system, once that storage is allocated, it is lost. It must be supported and managed, but unless the application it is allotted to needs it, no one will ever use it. Meanwhile, storage administrators have to allocate storage piecemeal, meaning that every server, or sometimes every application, has to have its storage managed individually.
Adding more storage to a thinly provisioned system is quite easy. Vendors like Compellent allow you to add capacity to applications as needed. Generally, thin provisioning applications handle allocation on the fly without the need to shut down and repartition storage subsystems.
Of course, the problem with thin provisioning is the same as the problem with fractional reserve banking. At some point you're going to need more resources unexpectedly, and if you're not careful, you may not have enough on hand to avoid a crisis. Unlike banks, thin provisioned systems won't experience a run from nervous depositors if they have written a check their backsides can't cover, but the consequences can be almost as serious. When a thinly provisioned system runs out of storage, the whole system runs out of space, not just a single application or a server. This brings everything to a screeching halt.
One of the most important keys to successful thin provisioning is to carefully track and manage storage capacity. Thin provisioning vendors like 3Pardata Inc. provide an elaborate series of alerts to keep track of actual storage use, but it still falls to the storage administrators to carefully monitor storage capacity and add more before the situation becomes critical.
The good news is that with thin provisioning, you're only tracking one number -- the storage capacity for the entire storage subsystem -- instead of having to track capacity for every application or user group. The bad news is that you need to track it more closely, and not everyone finds the alerts and other tools easy to use.
Of course, part of thin provisioning's reputation for problems comes from older products. Thin provisioning on mainframes has been around at least since the early 1990s when StorageTek released its Iceberg storage system for IBM mainframes running Multiple Virtual Storage (MVS). There have been other products in the intervening years, but not all of them worked with all applications, and some of them were quite finicky. The current generation of products is much more reliable.
About the author: Rick Cook has been writing about mass storage since the days when the term meant an 80K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last 20 years, he has been a freelance writer specializing in storage and other computer issues.