12 Replies Latest reply on Jul 16, 2013 9:36 AM by michael stump

    Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”


      Thin provisioning is one of those ideas that seems really nice, but has some caveats that can really make it tough to use. First, volumes that are thin provisioned rarely shrink again. There are some ways to do it, especially with deduplication, but they’re I/O and labor intensive. Over time your volume will always get bigger, and rarely gets smaller. Second, thin provisioning introduces variability in your storage, especially in environments that allow customers to change, add, and delete data. It’s very possible to be caught short.


      Of course there are upsides, too. In the virtual world it means a VM can look larger than it is, but save space that isn’t in use. That saves admin time extending volumes. There are also some newer technologies, such as the VMware VAAI “UNMAP” command that are starting to work to re-thin volumes in an automated fashion.


      So are you using thin provisioning? Where are you doing it: on the array, on the hosts, or both? How are you managing the risks associated with it?

        • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”

          We use thin provisioning, by default, using VMware tools only.  We also set up alerts in vCenter to monitor overall usage of the SAN and alerts for over-provisioning.  That is key!  If you are going to walk the line, which I recommend as it helps boost revenues, reduce TCO, and general helps control hardware costs, you need to watch your environment like a hawk.


          There are some exceptions to this rule -- I really don't like to TP mail servers and DB servers, but I have done it in the past.  Why?  Lots of variability in volume size (though usually up!).  Application servers of all flavours make a good target for TP.



          • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”
            Scott Sadlocha

            I agree with jbiggley that it has to be watched, but if so, it can be effective to keep hardware costs down and reduce TCO. I think the technology needs a bit more along the lines of automation, but it is on the horizon as you mentioned in the original post. The pitfalls are there though. At my previous position, WSUS admin was one of my additional duties, and I was forced to skip patching one month due to a large datacenter move. The following month I ended up double patching, and it was a large repository of patches because we had multiple languages and operating systems to support. We used the DCs at our 40+ sites as the downstream servers to house and distribute WSUS patches, and when I approved the patches, they started replicating from the primary server.


            What I didn't know is that the DCs were all thin provisioned, and this ended up being my first real experience with it. We had a product called Attention bolted on to our Solarwinds environment, and it had a mail collector agent running that we used to pick up system generated emails sent to a specific address, and I monitored this along with the Solarwinds environment. Well, I started seeing all kinds of storage disk alerts come in to the agent and got a bit worried. Minutes later, one of our VM and Filer admins called me up to say that the patches I approved were filling up the volumes at multiple sites. I was logged in to several of the DCs and had seen plenty of space on them, but didn't realize that on the backend, there was far less space available. I frantically turned off WSUS services at the sites to stop downstream replication until we could clear up some space. I also did some needed WSUS maintenance to clear out old patches, and we got it straightened out, but had we not been vigilant and monitoring, we would have had some major issues at multiple regions around the globe.

            • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”

              I would love to comment, however, I do not really have time to do so.  I am too busy checking all my storage now, attempting to save my world before it ends.

              • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”
                Carlo Costanzo

                I'm all for Thin Provisioning on the VM level. Not having to 'retrain' an OS to see it's larger Volume ha been super handy.  Most times they never use the extended areas but the DEvelopers ALWAYS ask for it.  Thin Provisioning is my default for VMs.



                • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”

                  We are a cloud service provider so Thin Provisioning on the VM side is a great thing for us.  On the flip side, it does add an extra level of complexity when it comes to storage management.  If you don't watch your storage systems very closely you can find yourself in a pickle. 

                  • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”

                    We're using it for almost all our VMs via vCenter...DB and email boxes are the exception. As far as managing risks, we're fortunate in that we have a pretty robust set of storage resources. Of course, we also have monitoring set up that allows us to watch these utilizations as well. We use this cool product called Solarwinds.

                    • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”

                      Thin provisioning is a nice idea .. we don't use it.  To me, there are too many variables that could wreak havoc in an already delicate environment.  We've found that we can't purchase new storage and have it delivered to us in a fast enough period of time to feel comfortable with thin provisioning.  I'm sure there are lots of real-world use cases for it and people that are getting along just fine with no need to worry.  We're just not willing to risk it.  The storage that is assigned is the storage they get.  If more storage is needed, increasing the drives (in Windows 2008 and higher) is really no big deal (aka no reboot/disruption required).


                      Maybe someday I'll get bold and start using thin-provisioning, but for now, I think I'll pass.

                      • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”

                        I've used thin provisioning on a HDS USP-V.  When it was replaced with a HDS VSP, we used it again.  On HDS enterprise arrays, you get a performance/tuning benefit as it stripes your data across many volumes.  It has been a wonderful, horrible thing!  It certainly helps raise device utilization a lot higher.  Lots of time people ask for 1 TB and use 200  GB,   Thin really helps with that.  Bad thing, you never really know when you will 'run' out of space.  Toward the end of lease or end of life of the array when space gets tight, you worry that someone will create a true out of space condition that will create all kinds of bad stuff like lots of databases shutting down at once since it can't write out log files.  Seems like every 'new' virtualization idea brings good and bad to the table. 

                        • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”

                          For our customers, thin provisioning seems to be the default. But for our internal IT systems, all of our systems are thick lazy zeroed. In a company that is basically 90% IT, I think there is a large concern that we will go renegade and use up way too much storage. (which, let's face it, is something that IT people like to do). In a world of data hoarders, you have to be very careful how you architect or it can definitely bite you. If it was me, I would be inclined to use thin provisioning on a per VM basis versus as a default.

                          • Re: Thin Provisioning – Good Idea, Bad Idea, or “It Depends?”
                            michael stump

                            You mentioned the VAAI primitive that supports storage reclamation. I think that's the big change in vSphere over the last two years that makes the case for Thin Provisioning much stronger. But the missing piece here is that you need to manage your storage, or more specifically, your datastores to avoid capacity issues that can make Thin Provisioning blow up on you. Overcommitting storage via Thin Provisioning is risky.