BEst PRactice to create one large LUn or small LUN

[MrVmware9423]

Dear Team,

Storage team created one raid group size of 4TB, Now if I want to map this lun on one of the ESXi host so what should I do

map two LUN size of 2TB and create two datastore

or

map one LUN size of 4TB and create one datastore.

Need ur assistance on the same.

regards

Mr VMware

[sajal1]

Hello MrVmware9423,

It would be better to go ahead with two Lun's of 2TB each. Saying that, it always depends. Single big lun and smaller lun both has its positives and negatives.

A single bug lun would be easier to manage, but it will host more number of VM's. In that case locking would be more. it is always suggested to have somewhere around 15 - 20 VMs per LUN (server grade). Again it varies depending on the VM size and stuff. Also when you have  a single lun of big size the IOPS would also be limited to the backing disks only related to those LUNs.

Whereas more smaller luns would be complex to manage, but would result in lesser lock and IOPS would be distributed over LUN's.

For further reading you can check these:

http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-storage...

http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf

Also check the following:

vSphere Documentation Center

You might want fewer, larger LUNs for the following reasons:

■	More flexibility to create virtual machines without asking the storage administrator for more space.
■	More flexibility for resizing virtual disks, doing snapshots, and so on.
■	Fewer VMFS datastores to manage.

You might want more, smaller LUNs for the following reasons:

■	Less wasted storage space.
■	Different applications might need different RAID characteristics.
■	More flexibility, as the multipathing policy and disk shares are set per LUN.
■	Use of Microsoft Cluster Service requires that each cluster disk resource is in its own LUN.
■	Better performance because there is less contention for a single volume.

Saying the above 2TB Lun size with 15 to 20 VM per datastore seems to be sweet spot for most of the cases

[FB_stefan]

I would like to chip in on this.

It is mentioned that more smaller LUNs would have the benefit of having less wasted space.

But my experience is different (or i am just confused, hence my post here).

We have a datastore cluster with around 15 datastores, each 2.1TB.

The total free space on the datastore cluster is around 4TB.

I want to deploy a 2TB VM, but i cannot because the biggest chunk of free space per datastore is around 400GB. And i do not want to spread VMDK's all over different datastores.

So i have 4TB wasted space that i cannot effectively use.

Moving around VM's in order to clear a datastore is not possible, no VM can fit anywhere else.

My only way to solve this (and to improve for the future) is to create a much larger datastore and add it to the datastore cluster.

THe idea is to completely get rid of the smaller datastores and replace them with just a few big ones.

This came to mind after seeing an exam question and my mind just cant get around this yet.

Does this make sense?

If i were to redesign the datastore clusters, i prefer having 3x5TB over 5x3TB.

[daphnissov]

You're always going to have "wasted" space no matter what size you standardize upon. Always. But in order to determine what general sizes work (and there may not be just one), you need to take into consideration a couple of things:

1. Are all your VMs generally homogeneous in size? If you have lots of ones in the 100GB-200GB range, and then one "large" one coming in at 2TB, then you might want to take that into account when either sizing your datastores up front, or allowing for slack space. With 4TB datastore sizes, you have to be under 2TB before landing a 2TB VM on it.
2. Alarm/alert thresholds need to be maintained. Having huge datastores and trying to minimize slack space means you're pushing the percentage of used capacity very high, possibly over 90%. That means you're going to have constant alerts/warnings in your inventory or monitoring tool. Disregarding those alerts also isn't good because then they're effectively meaningless possibly putting you into a dangerous position should one legitimately begin running out of space.

As with all things, there is no "one size fits all" approach here. There are multiple factors to consider. What works best for me in my environment may not work well for you in yours.

[FB_stefan]

Thanks for the reply.

One of the exam questions was about this and i found it very confusing.

But yeah i agree that it often depends on the situation.