One of the topics I’ve often written and spoken about is thin provisioning. This series of 11 articles is an edited version of my thin provisioning presentation from Interop New York 2010. I hope you enjoy it!
I began by introducing the core problem: Storage isn’t getting any cheaper, even though raw capacity is cheap. Then I talked about storage utilization and provisioning problems. Now we’re going to talk about thin provisioning.
So, what is thin provisioning? I imagine everybody can just figure it out by the name. It means that instead of allocating storage that we’re not even going to use, we don’t allocate it, and give it to somebody else.
All right. We’re done. Anybody have any questions?
Ok, you caught me. This is actually not how it works. This is how you would like it to work, but this is not how it works. This is the “vendor illustrated” version of how it works. So let’s talk about why thin provisioning doesn’t work this way.
Thin provisioning is problematic. What happens is I allocate some space and suddenly I need a lot more. Perhaps I have temporary requirements and suddenly my application is spitting out log files like crazy, filling up all my storage, and locking everybody out. Oops, that’s a problem. But it’s probably exaggerated by thin provisioning opponents.
One of the biggest technical issues for thin provisioning is not the provisioning part: It’s fairly easy for a storage array to allocate on request:
- Operating system: “I need a block; here’s some data I want you to write.”
- Storage array: “I’ll just start allocating now.”
- But, the operating system never goes back and says “I don’t need that block anymore.”
De-allocating (de-provisioning) is the challenge of thin provisioning. And that’s something that has to be tackled. And the reason that I say that thin provisioning isn’t quite as bad as it used to be is because that problem is being addressed.
Another problem we’re going to talk about is chunk sizes and formatting conflicts. We’re also going to talk about application conflicts.
There are a lot of problems with thin provisioning, but it’s getting better. I’ve been talking about this for years. I actually had a version of this slide that I used in 2003 or 2004, right when 3PAR started really pushing thin provisioning. And at that point I was saying “hold you horses everybody.” Now I’m getting a little more friendly to thin provisioning.
I realized, after years of griping, that my discomfort with so many technologies comes down to this: If people are trying to solve a business problem with a technical solution, they’re going to fail. It doesn’t matter if you’re talking about thin provisioning or anything else.
If your problem is that the organization won’t give you funds to actually buy storage, so you have to steal it from the next project that comes along and then reapply that storage to other projects just to keep your growth up, well, then thin provisioning is not going to solve your problem. If your problem is that you can only buy once a year, or you can only buy when the EMC salesman gives you a super discount and leaves something on the loading dock, well, thin provisioning is not your problem. Your problem is somewhere else.
But if your problem is that you have file systems that don’t like to grow and shrink, or if your problem is that you have a standard size allocation unit that everybody has to use and it always leaves some space empty, you are in luck. These are technical problems and those are things that you can solve with thin provisioning.
I wrote more about this topic in Use Process Solutions For Process Problems, Technical Solutions For Technical Ones
So, just think about it. Are you trying to solve a business problem or a technical problem? And again and again you’ll see that technical solutions should be applied to technical problems and business solutions should be applied to business problems. And there’s no solution to political problems, so what can you do?
