Home > VMware > Optimizing Storage utilization in VMware environments

Optimizing Storage utilization in VMware environments

One of the driving factors for organizations to embrace Virtualization has been ensuring optimal utilization of resources like CPU , Memory and Storage. On an average ,we get requests for Virtual Machines with Storage space requirement of 100GB or more . Although we know that this might not be used on day 1 , we still have to fulfill the request of the end-users . So how do we optimize on the storage usage ? No prizes for guessing , Thin Provisioning !!

Thin Provisioning is available with hypervisors like vSphere as well as on Storage array from vendors like EMC . The next debate was on which thin Provisioning to use – Thin provisioning from vSphere or thin provisioning available on the storage arrays or a combination of both . We also had to remember the performance implications like the overhead on the host and storage array and also on Disk IO. With VAAI , overhead of the host is handled by the Storage arrays but for that to happen we would need supported storage array and the hosts to be running vSphere 4.1 . While achieving vSphere 4.1 is easy , everyone might not have a supported storage array!!

I strongly believed that for optimizing storage , we will have to implement thin provisioning at vSphere as well as the thin provisioning available on the Storage array . Why ? I would like to take a small example and explain this.

Update : Ater experimenting EMC Thin Lun , I would say that Thin Provisioning at Storage also works well and would help us in optimizing storage and at the same time all overhead associated would be on the storage array and not on the host .

Requirement is to have 3 VMs of 200GB each whose actual space usage would be only 20GB each . We have 650GB lun from a storage array.

What if we use only Storage Thin Provisioning ?

For example consider we allocate a 650GB  lun to an ESX Server and if we wish to create VMs(Thick provisioned) with 200GB of space , we would be able to create only 3 VMs . Please note that when we create thick provisioned VMs , VMDK files would expand and occupy space on the datastore even if the actual utilization inside the VM in only 20GB . There is no space savings in this scenario.

Update : We tested Storage thin Provisioning with EMC Thin Pool and found that even though at the datastore you see the VM occupying 200 GB space ,  Utilization at the thin lun at the storage arrays is only the acual size of data inside the Guest Operating System .

So in this case , we will have to over-provision lun to accomodate more number of Virtual Machines . For example, considering the above example , When you create a Storage pool for 650GB , create  a lun for 2 TB ( Thin Lun ) and allocate the Lun to the ESX Server so that you can actually host 9VMs . Used space on the thin lun would only be (9*20) 180 GB and even down the line if the thin lun is about to use the complete capacity provided , we can extend it easily.

What if we use only vSphere Thin Provisioning ?

This is slightly better than the previous scenario . Since thin provisioning is at ESX level , VMDKs would grow only to the actual utilization of the VMs . Considering the above example itself ,  since you have already allocated 650 GB lun to the ESX Server , the free space that is available in that lun as a result of VM thin provisioning cannot be used for other requirements where storage is necessary . But you can obviously host more VMs with the space saved and this is the best way to go about in DAS environments and where Storage array is not supported for VAAI.

What happens when we use Thin Provisioning at vSphere and in Storage array ?

When we use thin provisioning at VM level as well in Storage level the actual space used inside a VM only will be consumed in the lun ( 60GB only in this case) and so once can start with the smallest required lun size and then grow as and when required. VM thin provisioning would ensure that VMDK file grows only as per the VM guest usage and Storage thin provisioning would ensure that additional luns can be bound from the Storage Pool .

Over the next few days , I would be running some tests to see performance impact associated with all three options mentioned above .

Please do let me know your thoughts on my post and which one would you recommend in your environments ?

Advertisements
Categories: VMware Tags: , ,
  1. Badri
    November 17, 2010 at 10:47 am

    Thin provision at the storage level helps in optimizing the disk space as it gives the flexibility to over provision and doing it at the ESX level as well will increase the VM foot print per server. I would prefer doing it at the storage level and observe the application behaviour and then enabling it at the ESX level to get the double benefits

  2. NandhaKumar
    November 17, 2010 at 7:09 pm

    Thin provisioning calls for the need to monitor real utilization. We need to monitor how much additional real storage is being used every day, and we need to make sure that we buy extra capacity before we hit the wall.

    Some of the points to keep in mind while using Thin Provisioning in VMs

    1) If you have temporary files occupying 10GB of space and if you delete it within windows OS, you will still see that 10GB usage in the VMDK file, eventhough it is deleted from windows.
    2) Thin provisioning is not recommended for systems with huge temp file growth.
    3) We need to test the behaviour of snapshots while using thin provision. Will the snapshot VMDK automatically fall under thin provision. Incase of comit, are we gaining the diskspace?

  3. November 17, 2010 at 11:29 pm

    Monitoring Mechanisms has to be put in place once we introduce thin provisioning , be it storage or VMware.

    My thoughts on the queries raised are :
    1) If we delete files after using say 10GB , we will not get the 10GB space back – Whatever be the thin provisioning mechanisms that we use ( VMware / Storage )
    3)Snapsots are anyways thin provsioned only even if the base disks are thick provisoned. We might not gain space when we commit a snapshot but would test this scenario and post an update.

    Thanks Badri and Nandha for the comments

  4. Sivakumar
    November 25, 2010 at 6:52 pm

    Seems your help is required to understand this stuff.
    Good one.

  1. No trackbacks yet.

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: