Ashish Nadkarni, principal consultant with Glasshouse Technologies answers frequently asked questions about thin provisioning in the SMB space. His answers are also available as a MP3 for you to download.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
>>What is thin provisioning?
>>What are the benefits of thin provisioning?
>>What are the drawbacks of thin provisioning?
>>What vendors offer thin provisioning?
>>What are the alternatives to thin provisioning?
Thin provisioning, which is also called dynamic provisioning by some vendors, creates an additional layer of "virtualization." I'm using the word "virtualization" in a very loose manner here. What it really does is create this layer of how storage is traditionally provisioned and how the host that sees this storage.
This layer allows you to do two things: First, it allows you to allocate storage as it gets written by the system. Typically, in a traditional storage environment, once you provision the storage, the array considers it as used. It doesn't know how much the server has actually written to it. In this case, it actually allocates storage as the server starts writing to storage, so it's essentially write on-demand, which gives thin provisioning its name.
So what it means is that if you provision 100 GB of storage to a server, but the server only writes 10 GB, in a traditional environment all of those gigabytes would be marked as used. But in a thin provisioning environment, 90 GB of that storage would be marked as unused and you can leverage that 90 GB to provision that same storage to other servers, taking the calculated risk that the average utilization of each of those servers doesn't go beyond 30% to 40%. Essentially, what you're getting is old allocation in a thin provisioning environment. You can allocate more storage than what you really have physically in your environment.
The second thing that thin provisioning gives you is the ability to create a homogenous pool of storage resources. So you can take different sizes of logical unit numbers (LUNs) and create a single entity for provisioning storage. This gives the storage administrator various pools almost in the same way that you would create RAID levels, where you can use different homogenous pools of storage that you can then provision to the systems. Each homogenous pool collectively has more horsepower in terms of response time than individually provisioned LUNs.
The key benefit of thin provisioning is the ability to over-allocate storage and essentially try and squeeze as much storage that is provisioned to systems that is not actually used. What makes this particularly attractive is that if you have "x" storage provisioned, how much is really used by the server? The industry average is not more than 20%, which means that 80% of storage provisioned to servers is wasted because the system administrators have that overhead and don't want to give it back.
So that storage really gets wasted and, as a result, your budget gets higher and higher because you're essentially providing more storage than you really need. So the benefit of thin provisioning is the ability to get that storage back into the storage pool and be able to use it only as the server needs it and not as the demand comes in.
The other benefit of thin provisioning is performance. It's sort of a side benefit because not many people really advertise thin provisioning as a performance-enhancing system on the storage side. However, you can create a pool that has multiple resources in it and that pool collectively functions as a single energy, almost like a RAID group on steroids. In certain cases where you need more IOPS, you can use thin provisioning purely for performance improving measures.
And last, it allows you to manage storage as a holistic entity rather than disparate RAID groups and LUNs, which is traditionally how storage has been managed. This concept will go away once thin provisioning becomes mainstream and eventually you'll be talking in terms of storage pools with a certain function that defines that pool.
Thin provisioning is not a magic elixir to solve your problems at the storage site and it's not a substitute for sloppy storage management practices. In many cases, storage is just provisioned in an ad hoc manner and there is very little effort that goes into ensuring that storage is being provisioned the right way, that the server is using it the right way, and that you have control over how it gets provisioned. Thin provisioning does not solve these problems. You need to have a tight storage discipline and then thin provisioning will enhance the value of that discipline.
It is also not a magical solution to reclaim all unused storage. What I really mean is that it is very easy to fall into the trap and say that if I have 100 terabytes and if I provision 200 terabytes, I am really getting 200 terabytes. Not really. If all of the 200 terabytes are required by the servers, then you will physically need 200 terabytes. It's not a magical solution that suddenly gives you two times more storage, even though it seems that way from looking at various brochures.
Thin provisioning is not a substitute for planned performance or an alternative to host-based techniques. So, for example, host-based volume managers always have a benefit or certain practices on the storage site such as creating striped meta volumes. Thin provisioning is not a substitute for host-based techniques that improve performance.
Most enterprise vendors have some kind of thin provisioning in their enterprise space and are now releasing it in their midrange space as well. For example, EMC Corp. released dynamic provisioning in the DMX series and now it's also available in the CX Clarion series. Hitachi Data Systems did the same thing by releasing thin provisioning in TagmaStore; AMS, which is their midrange, will be getting it soon.
NetApp has thin provisioning, which they advertise fairly heavily. 3Par had thin provisioning for a long time and didn't seem to get the message out, but they were one of the first guys to have it in their arrays. I would expect that most vendors will have it sooner than later because it is one of those technologies that is here to stay and is not going anywhere.
You should always be smart about how storage is provisioned. What I mean by smart is that you don't necessarily have to be fancy; you have to be very tight. You have to run a tight shop, use standard LUN sizes, use host-based volume management and you have to use a good storage resource management tool that keeps tabs on how storage gets utilized, what is your trending and how are the storage requests coming into your environment.
Essentially you need a trend analysis that keeps a tab on how much storage you need and how much storage you need to buy. Then it gives you an end-to-end view from the server to the array level. Eventually, once you've cleaned up your shop you will realize that if you need to go for thin provisioning it's only to improve the value of what you have, and not a substitute for what you already have.
So, I would say start with creating a tight storage management shop and then examining thin provisioning as a version 2.0, which would still be valuable, but its value would be greatly improved if your storage management has all of its pieces in place.