I like to think of thin provisioning as just-in-time resource commitment, where storage resources are available for any purpose at any time. In contrast to traditional storage which allocates (reserves) full volumes for systems and applications, with thin provisioning storage is only reserved when data is being written to disk.
IBM blogger Tony Pearson parlayed the Goldilocks analogy in his blog earlier this summer and discusses what fellow IBM blogger Barry Whyte calls the "extent size" of the TP allocation. Its an interesting discussion and worth a read because the topic is defintely relevant. But I think it fails to cast the discussion in the most relevant light for storage customers, which is "how many times do you guess wrong when you size a volume and wouldn't you rather not guess at all?"
And that's what the just-in-time element of thin provisioning fixes. Just make the virtual volume big and apply discipline to filling them up (for instance, don't let your end users run all over them).
Yes, you defintely should plan storage use and purchases, but best-guess mistakes don't have to be part of your plan. Working smarter means making fewer mistakes that have to be corrected and paid for later.
I recommend checking out thin provisioning with all the vendors, but make sure you check out 3PAR's thin provisioning. We invented it and are continuing to extend and expand this important technology.
There's a few things to be aware of with some other TP implementations (not 3Par's as far as I understand).
Firstly, round-robin allocations; this can lead to really unbalanced arrays and if you do not have the ability to relay automatically if you add disk into a thin provisioning pool; this could cause alot of manual rework.
Secondly, non-dual parity systems can be very harmful depending on how the pool is implemented; you could find yourself restoring your whole pool in a double-disk failure scenario. So be aware of what you are doing and what your data availability needs to be. Even with smaller disks, look carefully at the rebuild times and work out if you can afford to wait for the rebuild to complete.
Thirdly, not all workloads are thin-provisioning friendly but that should not necessarily stop you using thin-provisioning for them. Sounds counter-intuitive but if you thin-provision a disk and the first thing it does is fill it's space; as long you've right-sized your allocation, you might not have lost anything. And depending on the implementation, you might have gained something; for instance, if your thin-provisioning implementation can reclaim space; in the unlikely scenario that you can shrink the space requirement, you can get the disk back.
Just some thoughts anyway.....
Posted by: Martin G | October 15, 2008 at 12:50 PM