Home > Storage Efficiency > Storage Efficiency – Thin Provisioning

Storage Efficiency – Thin Provisioning

Traditionally, we allocate storage required for an environment upfront which is also referred as thick provisioning or fat provisioning. For Example, when there is a request for a 100 GB Virtual disk space, we go ahead with creation & allocation of 100 GB space. But have you analyzed how long would it take for that 100 GB Space to be consumed?

  • If this is the case for a Single VM, Imagine the space that is being allocated to multiple virtual servers in the environment and how much space goes underutilized? In cases where they are optimally utilized, how long before they get consumed completely? Can we use the space for that time being for some other use cases or for provisioning more VMs?
  • Another use case is optimizing the free space in datastore. Depending on environment there is a certain amount of buffer space that is reserved in every datastore. For Example, if we consider 20% as buffer space, in a 2 TB datastore we would be left with 400 GB free space per datastore. If you environment has 25 datastore of 2 TB each, you would be approximately leaving 10 TB (400 GB * 25) of unused space. Can we optimize this 10 TB space?

Thin Provisioning help increase storage utilization by enabling dynamic allocation and intelligent provisioning of physical storage capacity. Thin Provisioning is an On-Demand allocation model where storage is allocated based on request from server rather than allocating everything upfront.

Thin Provisioning can be implemented in a Virtualized environment in either of the two ways or combination of both.

  1. Thin Provisioning at Hypervisor layer
  2. Thin Provisioning at Storage Array

Thin Provisioning at Hypervisor layer would mean that you present a thick LUN from Storage array or create datastore from your local HDDs and then do thin provisioning of virtual hard disk on the datastore. This would help you provision more VMs per datastore since space saved is at datastore level. You can look at Hypervisor based thin provisioning when you use local attached HDDs or your storage array doesn’t support the feature.

Thin Provisioning at Storage array can be implemented when your storage array supports the feature and you have appropriate license for it if need be. Typically you create a Storage pool and present Thin LUN back to your Hypervisor and you create VMs that are thick provisioned (Lazy Zeroed). Thin LUN presented from the Storage array would grow only when the data in the provisioned virtual HDDs grows. One would typically create multiple Thin luns from Storage Pool and present back to hypervisor for allocation. Advantage of doing thin provisioning at Storage array is that space saved an either be used back for the same hypervisor/cluster or for a different use case.

Whatever be the option you choose, it is imperative that you monitor any thin provisioned environment carefully for growth and do proper capacity planning. Also please be mindful of impact on the disk performance of the workload. Would not recommend thin provisioning if your workload is a critical disk intensive workload. There are lot of non-critical workloads that can be deployed on Thin Provisioned LUNs saving your Organization lots and lots of space which in return would mean lots of $$$ Savings !!

Advertisements
  1. Srinivasan M
    February 26, 2013 at 2:42 pm

    GOOD

  2. Shankar Rathinasamy
    February 27, 2013 at 10:56 pm

    Hi Sudarsan,

    It’s a good article, you gave a wonderful overview of Thin prvisioning. I have a doubt in the performance part of the article. As per the article, the recommendation is not to use thin provisioning for critical disk intensive workload.

    The best practice for disk intensive workloads(example – database servers) is to use multiple spindles, usage of multiple spindles increases the performance. In thin provisioning we always construct Thin pools using multiple devices that we carve from different drives. This means we construct thin pool using multiple spindles, hence I believe Thin pools are always recommendable for high intensive workloads.

    Please advice if I am wrong anywhere or If I misunderstood your point.

    Thanks,
    Shankar R

    • February 28, 2013 at 9:47 am

      The Problem that might arise with thin pools and critical high performance database workload is that,
      1. Thin Provisioning by nature would grow in small chunks as and when data is written which would mean there is a slight load back on the disks every time data is written.
      2 Database workloads carries a recommendations of doing a full format of the drive post presenting to an OS where the DB/Log is configured and when you do a full format , the back-end LUNs would expand and thin provisioning benefits becomes nullified.

  3. Shankar Rathinasamy
    February 28, 2013 at 8:15 pm

    Thanks Sudharsan 🙂

  1. February 27, 2013 at 7:16 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: