What is Thin Provisioning – Good Idea or Recipe for Disaster?
What are best practices around thin on thin provisioning? Well, I was part of a panel at a recent GreenPages event and a question was asked by the audience. More specifically, the question was, what is the best practice regarding thin on thin storage provisioning?
First, let me provide a bit of background on the question. Thin Provisioning is essentially a process for “faking out” an operating system or other platform in such a way that you make it believe it has more storage available than what truly physically exists. Why would I want to do this, you may ask? There are several reasons why this could make sense, such as that pesky application vendor who demands that you provision 200GB of disk space for a database that you know will only truly use maybe 5-10GB. It also allows for dynamic growth as one can add the true physical capacity to meet the ‘advertised’ capacity if/when necessary without any alterations needed within the OS or application.
So, “how” do I use this technology? Herein lies the challenge as there are really multiple ways to accomplish this. One method is within the virtual infrastructure itself, as I can create a virtual disk with a size of 100GB and choose to “thin provision” it. This means that the virtual disk actually starts out with a much smaller size than 100GB, and will dynamically grow as new data is created within the vdisk. The full 100GB is advertised to the OS, so it believes there is 100GB of capacity available even though in reality there is probably less than that. Hopefully you can see the challenge here from a management aspect. Take a single VMFS volume with a physical size of 500GB and, let’s say, I create 10 VMs on that VMFS volume, each with a single 100GB thin provisioned vdisk. I’m advertising 1TB of capacity collectively to the VMs, but I really only have 500GB there. What happens when the total used capacity of the 10 VMs reaches 500.0001 GB?? Let’s just say that wouldn’t be a good day for the VMware administrator. So I need a way to monitor the actual used capacity and be alerted far enough in advance of the 500.0001 problem so that I can add additional physical capacity or move VMDKs around to avoid running out of space.
Another method of thin provisioning involves the shared storage array itself. In this situation, we are provisioning a LUN or Datastore and advertising that it has a size of 1TB when in reality there is only 500GB of actual capacity on the array. Same situation as above, but in this case I will typically use true ‘thick’ provisioning on the actual virtual disks themselves, meaning that I could only create 5 VMs with each having a 100GB vdisk on this thin provisioned datastore. I can run into a similar issue with the monitoring here as I need to be notified in advance so I can move things around or add physical capacity prior to attempting to add that 6th VM to the datastore.
This Brings Us to Thin on Thin Provisioning
This brings us to the “thin on thin provisioning” question posed to the panel. This concept basically means that I’m using both of the above mentioned methods simultaneously. The good news is I can advertise a ton of capacity although I may be truly using only a small fraction of that space. The bad side of this is I REALLY have to continuously monitor and manage this environment because the edge of that storage capacity cliff gets pretty blurry when both methods are used. It has always been the recommendation of GreenPages that our customers choose to use one method or the other, but not both, as to minimize the risk of driving the car off the cliff while thinking you have a nice straight paved road in front of you. As for which method is the best to use, well the consultant in me always says “it depends” because everyone’s business and technical requirements and skillsets are different so I can’t really say there is a single correct answer in this regard. I’m interested in hearing your own experiences and thoughts around thin on thin provisioning so please feel free to comment!
