Hey everyone. Usually we did created usual Thick LUNs in a Pool and after that we created VMFS stores within the ESXi Host / vCenter which is the same same like the LUN.
On this VMFS stores we created machines (.vmdk) which are Thin Provisioning.
When there have been space issues within the OS we increased the size of the .vmdk as long as this possible and when there VMFS stores was tight we expanded the EMC LUNs and after that the VMFS stores.
1) Is this a proper way and good design?
It's quite a lot of effort and the disk utilization is not even. Usually we created 2 TB LUNs and 2TB VMFS Stores.
2) Is 2 TB still a recommondation from VMWare?
3) Usually we are running 5-10 MVs per Store (is this still recommondation?)
Now with this design the following can happen: We have a file serve with a size of 1.5 TB and this on is residing on LUN 1 (2TB), space is used to 75%. But then we have a 2nd 2TB Lun with 10 VMs on it an 30% usage, and another 3rd one has got a usage of 60%. So it's not possible to spread VMs across due to their individual size (100 GB, 600 GB etc) when there is only for example 500 GB left on LUN1.
How do you take control of that scenario?
Well we would like to use thin provisioning on the pool layer within EMC. As far as I know you need a license is that true? Is this license within the default software delivery or do we need to buy this in addition?
4)Do you use thinprovisioning withn the VMware layer as well when you use thin EMC LUNs?
5)How is the behavior of the EMC LUNs and the VMFS Stores. When I create a 2 TB EMC Thin LUN and i add a VMFS store it will recognize the LUN as 2 TB right? But what's the utilization at that moment on the EMC? 100% due to the fact that the VMFS is 2 TB in size or really the acual size of the VMs on this VMFS so 0% at the beginning? Any influence within this range when using thick or thin prov. vmdk?
6)Expansion of a EMC Thin LUN does also require the expansion of the VMFS like usual?
7) Can i shrink a Thin LUN on EMC Level without any impact on VMFS store? Do i need to shrink after that task on VMFS store as well?
😎 Can i convert a Thin LUN to a Thick and vice versa?
Beside this we would like to create a Datastore cluster within vCenter for an optimal distrubtion of VMFs on the VMFS datastores. But does this work with multiple pools? Lets assume we've got 4 LUNs on two pools. One pool constists of fast disks and fast cache the other doesn't. Would VMwrae DRS move a machine from a LUN from the fast pool LUN to a slow LUN? Is it aware of speed or does it just check what's the amount of VMs per VMFS store? I think for a pool with tiers it's not a problem at all.
9) Is there a way to read out of the EMC GUI the actual used capacity of a Pool resp LUNs? When i create a pool with 10 TB of size and i created 5x 2 TB of size it tells me: Total 10 TB, Free 0, Allocated 10 TB, Subscriped 100% but within that LUNs there is no data. Within Datacore Storage Appliance for example i can see a tab "used" which tells me the actual used capacity. Is there some possibility to have such an tab within EMC as well? vCenter Integration does not give me that information.... i need to check the actual size of the LUN resp. VMFS Store within vCenter....
10) Is powerpath or an Agent necerssary which are able to give me such an information?
11) Is there performance impact when using thin LUNs?
What is your preffered way of design? In future i would like to create one big EMC Storage Pool based on different tiers, using dedup and Thin LUNs. Within this pool i would like to create vSphere VMFS Stores with a size of 2 TB, numbers needed based on the ammount of VMs necessary. Each VMFS store is a 1:1 to a EMC LUN in size and within this stores i would like to create VMs which are thin provisioing.
I addition we create VMFS datastores which take care of the optimal placement within the VMFS Stores, Block tiering is done by EMC. Monitoring will be done by vCenter and EMC GUI.
12) what do you think about this?
13) Do you know a centreal monitoring way?
Thank you and cheers and sorry for the amount of question but I would be more then glad to receive some answer on this questions. 🙂
From the VNX with MCx Virtual Provisioning White Paper, page 42:
For VMware environments, the Virtual Machine File System (VMFS) has many
characteristics that are thin-friendly. First, a minimal number of thin extents are
allocated from the pool when a VMware file system is created on thin LUNs. Also, a
VMFS Datastore reuses previously allocated blocks that are beneficial to thin LUNs.
When using RDM volumes, the file system or device created on the guest OS dictates
whether the RDM volume is thin-friendly.
When creating a VMware virtual disk, LUNs can be provisioned as:
Thick Provision Lazy Zeroed
Thick Provision Eager Zeroed
Thick Provision Lazy Zeroed is the default and recommended virtual disk type for thin
LUNs. When using this method, the storage required for the virtual disk is reserved in
the Datastore, but the VMware kernel does not initialize all the blocks at creation.
The VMware kernel also provides other mechanisms for creating virtual drives that are
not thin-friendly. The Thick Provision Eager Zeroed format is not recommended for
thin LUNs because it performs a write to every block of the virtual disk at creation.
This results in equivalent storage use in the thin pool.
When using Thin Provision, space required for the virtual disk is not allocated at
creation. Instead, it is allocated and zeroed out on demand.
As of vSphere 5, there is also the ability to perform thin LUN space reclamation at the
storage system level. VMFS 5 uses the SCSI UNMAP command to return space to the
storage pool when created on thin LUNs. SCSI UNMAP is used any time VMFS 5
deletes a file, such as Storage vMotion, delete VM, delete snapshot, etc. Earlier
versions of VMFS would only return the capacity at the file system level. vSphere 5
greatly simplifies the process by conducting space reclaim automatically.
In addition, features such as VMware DRS, Converter, VM Clones, Storage vMotion,
Cold Migration, Templates, and vMotion are thin-friendly.
For the full paper:
- You can covert a Thick LUN to a Thin one, but not vice versa. But you can migrate any type of LUN.
- Thin LUNs' performance is limited compared to Thick or Classic LUNs, due to the overhead associated with Thin LUN provisioning. You trade off performance for ease or management and efficiency.
I guess 13 questions are a bit much 🙂
quite a number are covered in the white papers and BPP.
some quick answers:
you cant shrink LUNs
allocated capacity == used capacity for thin LUNs
space reclaim in vSphere is a manual process
yes using thin LUNs requires alerting and monitoring
alerting on %full per pool is bultin
monitoring via the usual VNX monitoring tools
convert thick to thin and vice versa is possible
yes there is a performance difference between thin and thick LUNs