VMware Cloud Community
tmcd35
Enthusiast
Enthusiast
Jump to solution

LUN's

Hi,

I'm currently reading up on LUN's and was wondering if someone could confirm if I have the right idea.

We are looking to take 7/8 existing physical servers and make them VM's. We then want to spread the services provided by these servers into around 20 VM's. We currently use around 1.1Tb total over the existing servers and would be looking for a SAN of around 1.5-2Tb giving us room to grow into. We would most likely use a RAID-50 array of 250Gb or 500Gb drives to gain this capacity.

Am I correct in thinking that the LUN's are basically partitions of the array and they do not necessarily map to physical drive within the array?

A post in a previous topic suggest we can use varied sizes for each LUN. Is there any performance issue in doing this?

I understand that VMFS formated LUN's woul hold the VMDK files which in effect would be the C: drives and the virtual machines can have their 😧 drives mapped directly to their own LUN.

I'm mainly thinking of our file/application servers. They may need between 100Gb and 400Gb dependant on server to store user files or applications and am trying to understand how these would map into the LUN's. Would we create an individual LUN for each server?

Also would we need to use VMFS/VMDK for these 😧 drives if we want the servers to work with vMotion, or is only the C: drive required to be a vmdk?

Most importantly, and I can't find the answer to this anywhere, I understand that the LUN's/VMFS drives cannot 'grow'. So I can't set up a 100Gb drive with provision to grow to 300Gb as usage requires. But, can I delete a LUN and reallocate it's space with any other existing free space as required.

I'm thinking of the transition from 7/8 servers to 20 more targeted servers. Server1 may require 300Gb of file storage now, but it might become 6 smaller servesr with 2 of them only needing 100Gb each and the rest split between the other 4. If I have enough free space on the array to create the new LUN's needed can I then remove the 300Gb LUN used by server1 and reallocate it into a series of smaller LUN's for Server2? Or combine the 300Gb with perhaps another 100Gb unused space to create a new 400Gb LUN for another server?

Also I read in another thread of a user having perhaps a 300Gb LUN and keeping 5/6 say 50Gb VMDK images of the different VM's within 1 LUN rather than having 1 LUN per server, is this the correct thing to do?

How do other people provision VM file/application servers from a SAN?

Cheers

Terry

0 Kudos
1 Solution

Accepted Solutions
MR-T
Immortal
Immortal
Jump to solution

See my comments:

Am I correct in thinking that the LUN's are basically

partitions of the array and they do not necessarily

map to physical drive within the array?

This depends on your storage array. On certain arrays it might be possible to identify disks 1 to 10 as array 0, but on others you wouldn't stand a chance.

A post in a previous topic suggest we can use varied

sizes for each LUN. Is there any performance issue

in doing this?

The various sizes shouldn't change the performance. The number of spindles in a disk group will improve performance.

I'm mainly thinking of our file/application servers.

They may need between 100Gb and 400Gb dependant on

server to store user files or applications and am

trying to understand how these would map into the

LUN's. Would we create an individual LUN for each

server?

Creating a LUN for each virtual machine is not a good idea. Before you know where you are, you'll have 100 LUNS and it's a management mess. Typically create a LUN to hold many VM's up to a maximum of around 10 or 15.

Also would we need to use VMFS/VMDK for these 😧

drives if we want the servers to work with vMotion,

or is only the C: drive required to be a vmdk?

For VMotion, you need to ensure that the target and source machines can see the same LUNs using the same LUN ID's.

Most importantly, and I can't find the answer to this

anywhere, I understand that the LUN's/VMFS drives

cannot 'grow'. So I can't set up a 100Gb drive with

provision to grow to 300Gb as usage requires. But,

can I delete a LUN and reallocate it's space with any

other existing free space as required.

You can create multiple VMFS volumes and join them together to create 'Extents'. But my choice would be provision new single large LUNs and migrate the data to them.

I'm thinking of the transition from 7/8 servers to 20

more targeted servers. Server1 may require 300Gb of

file storage now, but it might become 6 smaller

servesr with 2 of them only needing 100Gb each and

the rest split between the other 4. If I have enough

free space on the array to create the new LUN's

needed can I then remove the 300Gb LUN used by

server1 and reallocate it into a series of smaller

LUN's for Server2?

Yes you can.

Or combine the 300Gb with perhaps

another 100Gb unused space to create a new 400Gb LUN

for another server?

Yes

Also I read in another thread of a user having

perhaps a 300Gb LUN and keeping 5/6 say 50Gb VMDK

images of the different VM's within 1 LUN rather than

having 1 LUN per server, is this the correct thing to

do?

This is best practice, but ensure you mix low, medium and high I/O VM's in the same LUN to get best performance.

>

View solution in original post

0 Kudos
8 Replies
MR-T
Immortal
Immortal
Jump to solution

See my comments:

Am I correct in thinking that the LUN's are basically

partitions of the array and they do not necessarily

map to physical drive within the array?

This depends on your storage array. On certain arrays it might be possible to identify disks 1 to 10 as array 0, but on others you wouldn't stand a chance.

A post in a previous topic suggest we can use varied

sizes for each LUN. Is there any performance issue

in doing this?

The various sizes shouldn't change the performance. The number of spindles in a disk group will improve performance.

I'm mainly thinking of our file/application servers.

They may need between 100Gb and 400Gb dependant on

server to store user files or applications and am

trying to understand how these would map into the

LUN's. Would we create an individual LUN for each

server?

Creating a LUN for each virtual machine is not a good idea. Before you know where you are, you'll have 100 LUNS and it's a management mess. Typically create a LUN to hold many VM's up to a maximum of around 10 or 15.

Also would we need to use VMFS/VMDK for these 😧

drives if we want the servers to work with vMotion,

or is only the C: drive required to be a vmdk?

For VMotion, you need to ensure that the target and source machines can see the same LUNs using the same LUN ID's.

Most importantly, and I can't find the answer to this

anywhere, I understand that the LUN's/VMFS drives

cannot 'grow'. So I can't set up a 100Gb drive with

provision to grow to 300Gb as usage requires. But,

can I delete a LUN and reallocate it's space with any

other existing free space as required.

You can create multiple VMFS volumes and join them together to create 'Extents'. But my choice would be provision new single large LUNs and migrate the data to them.

I'm thinking of the transition from 7/8 servers to 20

more targeted servers. Server1 may require 300Gb of

file storage now, but it might become 6 smaller

servesr with 2 of them only needing 100Gb each and

the rest split between the other 4. If I have enough

free space on the array to create the new LUN's

needed can I then remove the 300Gb LUN used by

server1 and reallocate it into a series of smaller

LUN's for Server2?

Yes you can.

Or combine the 300Gb with perhaps

another 100Gb unused space to create a new 400Gb LUN

for another server?

Yes

Also I read in another thread of a user having

perhaps a 300Gb LUN and keeping 5/6 say 50Gb VMDK

images of the different VM's within 1 LUN rather than

having 1 LUN per server, is this the correct thing to

do?

This is best practice, but ensure you mix low, medium and high I/O VM's in the same LUN to get best performance.

>

0 Kudos
Dave_Mishchenko
Immortal
Immortal
Jump to solution

There's a good page of links here that will provide you with some reading. Look specifically at the SAN section. http://www.vmware-land.com/Vmware_Links.html

Yes, a LUN is basically a partition on the array. With LUN size you don't want to go with too large of a LUN with many (30 +) VMDK files as this can present problems with SCSI reservations. A SCSI reservation is when ESX locks the entire drive to perform certain file operations (creating files, expanding VMDKs, etc). The duration of a reservation is very short, but during that time the VMs can't write to their VMDK files. Generally you'll see suggestions for LUN sizes of 300 to 500 GB with 10 to 15 VMs, but that will depend on the actual situation.

A VMFS will hold VDMK with could be both the C and D drives. You could also use RDM for either C and D which effectively allows the VM to write directly to the SAN LUN.

http://www.vmware.com/community/thread.jspa?threadID=36725&start=0&tstart=0

Growing VMFS partitions. Yes you can't resize the LUN and the resize the VMFS partion. You would have to create a new LUN and then add an extent to the current VMFS to add the space from the new LUN. But as you mention it is better to delete the LUN, recreate the LUN with a new size and then recreate the VMFS partition.

In regard to "Server1 may require 300Gb " - you can assign more than one LUN to each server and you can share those LUNs between ESX hosts as well, which is a requirement for Vmotion. You could add storage as needed as well. One thing to note when you're creating VMFS partitions is that the block size will affect the maximum size of the VMDK file that can be created. The default of 1 MB block size will limit the VMDK to a max of 256 GB.

If you're interested in Raw device mappings see page 22 here

http://www.vmware.com/pdf/vi3_301_201_san_cfg.pdf

and this guide page 141

http://www.vmware.com/pdf/vi3_30_20_server_config.pdf

tmcd35
Enthusiast
Enthusiast
Jump to solution

Thank you to you both. I think I have a handle on this. So I'd perhaps have on or two LUN's for the main vmdk's which would basically be the VM's C: drive. And then for the odd file/app server that needs extra storage create a LUN for it's 😧 drive. I can then leave the rest of the array unallocated until it is required.

If a vdmk's max size is 256Gb, what would I do if I needed a single 500Gb volume within windows? Does the extent allow me to tie two 250Gb vmdks together so windows sees a single 500Gb drive?

Also I take it, if I mapped a RAW LUN to a VM and vMotion moved that VM to the other host, the VM would still access the RAW VM because it's mapped to the VM and not a particular host.

Terry.

0 Kudos
esiebert7625
Immortal
Immortal
Jump to solution

Hey thanks for referring to my site!

0 Kudos
Dave_Mishchenko
Immortal
Immortal
Jump to solution

If a vdmk's max size is 256Gb, what would I do if I

needed a single 500Gb volume within windows? Does

the extent allow me to tie two 250Gb vmdks together

so windows sees a single 500Gb drive?

If you expect to have 500 GB drives you should format the VMFS partition with a 2 MB block size. You have a block size option of 1 - 2 - 4 or 8 MB which corresponds to maximum VMDK file sizes of 256 - 512 - 1024 - 2048 GB.

Also I take it, if I mapped a RAW LUN to a VM and

vMotion moved that VM to the other host, the VM would

still access the RAW VM because it's mapped to the VM

and not a particular host.

You will be able to vmotion a VM with a RDM but it isn't a requirement for it. VMFS partitions can be shared between hosts so a VM with just VMDK files can also be vmotioned. An imporntant requirement for this will be that all ESX hosts have to see the LUNS (RDM or VMFS) with the same LUN IDs.

0 Kudos
Dave_Mishchenko
Immortal
Immortal
Jump to solution

No problem. It's faster than cut and paste and you deserve the credit for your effort.

0 Kudos
whitejul
Contributor
Contributor
Jump to solution

"If you expect to have 500 GB drives you should format the VMFS partition with a 2 MB block size. You have a block size option of 1 - 2 - 4 or 8 MB which corresponds to maximum VMDK file sizes of 256 - 512 - 1024 - 2048 GB."[/i][b][/b]

Could you please explain what are the best practices for choosing a block size? any pros and cons of a smaller or a larger one?

Thanks

White

Message was edited by:

whitejul

0 Kudos
Dave_Mishchenko
Immortal
Immortal
Jump to solution

It's just about the size of the maximum VMDK that you might need to create. Once you format a VMFS partition you can't change the block size. 1MB is recommended unless you'll have large VMDK files.

http://www.vmware.com/community/thread.jspa?threadID=47171

0 Kudos