Posts Tagged ‘thin provisioning’

Storage Efficiency – Thin Provisioning

February 26, 2013 5 comments

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 !!

Storage Efficiency with EMC Thin Provisioning and VMware ESX

February 5, 2011 3 comments

Thin Provisioning  is a way of increasing Storage Efficiency of available storage. It is nothing but on-demand allocation of blocks of data versus the traditional method of allocating all the blocks up front also called as “thick” provisioning. EMC introduced Thin Provisioning from FLARE 29 for their CLARiiON Systems. Host operating System also needs to be aware of thin provisioning from Storage and compliment it to achieve efficiency.

How much Storage optimization with Thin provisioning and VMware ESX did we manage to achieve ?

  • Storage Pool Size: 1.6 TB
  • Thin LUN Allocation (Subscribed capacity) : 1TB + 250GB = 1.25 TB
  • Datastore Utilization: 643GB + 210GB = 853GB
  • Actual Usage on Storage Pool (Consumed capacity) = 431 GB

Space Savings = 853GB – 431G B = 422GB ~~ 50% Savings !!

Lets get some basic terminologies that are used –

ŸStorage Pool – Raid Group and Thin Pools are called so. Thin Lun can be created only from Storage Pools.
ŸThin LUN – Logical unit of storage where physical capacity allocated may be less than the user capacity seen by the host.
ŸSubscribed Capacity –  Total amount of capacity configured for thin LUNs in the pool. This could be greater than available user capacity.
ŸOversubscribed Capacity: – Amount of user capacity configured for thin LUNs that exceeds physical capacity in the thin pool.
ŸConsumed Capacity – Space used by all thin LUNs in the pool. For a thin LUN, this is the physical space used by the LUN.
ŸUser Capacity – Total amount of physical storage capacity in the thin pool that is available for thin LUNs
This Saving is based on initial deployment of Thin Provisioning itself and I am sure more savings is to come once we start loading more VM’s.
Some Considerations would be :-
Create a Storage Pool ( and not Raid Group)  and ensure you enable Thin provision on Luns that are bound from the Storage Pool.
Configure Alerts as per your Organization standards. Monitoring Storage allocation and growth in a thin provisioned environment is very critical since additional space has to be added onto Storage Pool as and when required.
In a VMware ESX environment , when creating Virtual machines on Thin Luns please go with the default option on “Create a Disk”  option as this would create lazy zeroed VMDK files.
To achieve Double Storage savings one can select Thin Provisioning at ESX Level too but I would personally not recommend it since it would require monitoring at Storage and ESX level. Why load your ESX box when we can achieve the same at the storage level ?
Note : If we select “Support clustering features such as Fault tolerance” when creating the VM , It would create eager zeroed disks which would zero on creation and you would not observe any space savings !!
When a thin LUN is first created it would consume 2GB ( 1GB Meta data and 1GB user space) per LUN and then would grow by 1GB on writes.
Categories: Storage, VMware Tags: , ,

Optimizing Storage utilization in VMware environments

November 14, 2010 4 comments

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 ?

Categories: VMware Tags: , ,