Best practice for publishing luns?

[thesixuk]

I'm a little confused as to the best way for me to go and publish our luns.

We use a Netapp FAS270c to host our VM storage.

Our current set-up is as follows:

For each VM we currently create a separate volume for each HDD the VM will

use.

Each volume has enough space for the VM's memory and if needed snapshot space

We create a LUN on each volume and publish them to our ESX Cluster

We create a new storage using all the space on the LUN

We create the VM using the new storage.

I inherited this method of creating VM's from our previous VMWare Admin. His

reasoning for a volume and LUN for each VM was that if the LUN corrupts we only

lose that VM's HDD.

Now the first problem I've discovered is that this micro management is a

pain. Secondly, should I at a later date want to snapshot a VM that I haven’t

accounted the extra space for, I can't do it without adding an extent to the

VM' data store.

So I'm left with three options that I can think of.

1. We continue with our current process.

2. We create a large single volume on the FAS270c, and on that volume we

create individual luns for each data store.

Advantages: Can utilise

Disk Dedupe (should the feature ever be added on the 270 series by Netapp), individual

luns retain the security of only losing a single data store should the lun

corrupt

Disadvantages: Not too different from the above solution

3. I create one big volume, one big lun and host all the VM’s of that luns data store

Advantages: Can snapshot the VM's easily, can resize VM memory without a worry

Disadvantages: should the lun corrupt, we lose all our VM in one hit

So basically, I'd like to know what are the chances of a lun being corrupted?

What method would you guys recommend?

Regards

Niels

[RParker · Accepted solution]

>3. I create one big volume, one big lun and host all the VM’s of that luns data store

Probably the reason he is your previous VM Ware admin, he isn't the brightest light bulb in the drawer. That has to the most backwards, rediculously micro managed solution to date. That is incredibly limited, not to mention you are limited from the number of LUNS on Netapp AND ESX can only manage so many LUNS as well.

Scrap the entire thing. Start over. The way you should do it is this:

Create 1 LUN equal to the size of your VM's * 12 (12 VM's seems to be a good number to stay minimally small). A good size is around 500-700Gb (but probably not larger than that). Netapp recommends that your LUNS shouldn't be guaranteed, but the volumes should. So if you create a 500Gb LUN the volume should be 500Gb + 10%~15% overhead remaining. So probably 550GB Volume is good. This is because the WAFL (VOL Filesystem on Netapp) needs to scrub and do maintenance periodically to keep things working well..

You are going to be looking at a lot of work, because I am sure you have a hundred LUNS by now.. but going forward you should be fine. A LUN doesn't get corrupted. the VMFS volume MAY but the LUN will be fine. And of all the posts in this forum,very few refer to an actually VMFS corruption, occassional VM's, but those can be corrupted no matter what you do.

[JDLangdon]

We're using IBM ds4800 with enclosure protection so my LUNs are created with one disk on each enclosure up to a max of 1TB in size. Not sure if this will work for your storage but it is easy to manage.

________________________________

Jason D. Langdon

This space is for rent.

[Texiwill]

Hello,

THere are as many opinions about this as there are people using ESX. However the math is simple:

Size of VM = Size of VMDKs * 2 (for snapshots) + size of memory + 4.15 GBs for logs and sundry files

Size of LUN = Size of VM * 12 * 1.25 to get you to 80% utilization. You really do not want to be over 80% utilization.

More LUNs = More simultaneous LUN/Metadata actions.

12 is just a round number for the number of VMs per LUN. 15 also works. I would say LUNs should not be greater than 700GBs. You are really looking about # of spindles per LUN as well for performance reasons.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

Blue Gears Blogs - http://www.itworld.com/ and http://www.networkworld.com/community/haletky

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[mcowger]

While I agree with parker's recommendation in spirit, given that he has a NetApp filer, I'd STRONGLY recommend that you look at using your NetApp over NFS. You gain a lot of really cool manageability with NetApps awesome NFS implementation, dont have to deal with VMFS lokcing restrictions, and gain the ability to see your VMs from any NFS enabled machine you want.

--Matt

[thesixuk]

Thanks for the replies guys. We're getting a 3020 implemented in the next few weeks, so I'll use that as the opportunity I need to change the way we do our storage

In the previous admin's defense, he was dumped with the task of being the VMWare admin without any training or foreknowledge.