HPE Storage Users Group
https://3parug.com/

creating LUNs - best practice
https://3parug.com/viewtopic.php?f=18&t=2715
Page 1 of 1

Author:  ebowman [ Fri Nov 10, 2017 2:53 pm ]
Post subject:  creating LUNs - best practice

Hi, Im new here and fairly new to 3PAR or SANs in general. I know enough to be dangerous but would like to learn more to develop a solid skill-set.

How should you create a LUN (or Virtual Volume, are those the same thing?) should you create one for each VM? Or have multiple VMs in a single LUN? To add to that, if you have a VM that has multiple disk drives (C:\, D:\, E:\, etc) should those be all part of the same LUN or should each drive be split into a different LUN?

thanks for the info!

Author:  MammaGutt [ Sat Nov 11, 2017 1:03 pm ]
Post subject:  Re: creating LUNs - best practice

ebowman wrote:
Hi, Im new here and fairly new to 3PAR or SANs in general. I know enough to be dangerous but would like to learn more to develop a solid skill-set.

How should you create a LUN (or Virtual Volume, are those the same thing?) should you create one for each VM? Or have multiple VMs in a single LUN? To add to that, if you have a VM that has multiple disk drives (C:\, D:\, E:\, etc) should those be all part of the same LUN or should each drive be split into a different LUN?

thanks for the info!


In 3PAR lingo a volume/disk on the 3PAR is called Virtual Volume. A Virtual Volume is exported (many call it presented) to one or more hosts over usually two or more paths. Each export over each path is called a VLUN in the 3PAR world. LUN is usually the ID which the VV (Virtual Volume) is presented with. This ID is definable for each VLUN so if you present a VV to lets say a VMware cluster, you could use different LUN (3PAR lingo is LUN ID) for each presentation.

So you create a VV then export. Best practice is to use the same LUN ID for VLUNs for a single VV when exported to a VMware cluster.

The other part of your question is more a VMware and not a 3PAR question. For ease of management you want as little datastores as possible, but each datastore has a set queue length which means that you need to spread the load. My rule of thumb is that the "correct" number of VMs per datastore is somewhere between 1 and 15 depending on the IO pattern of the VMs.

As for whether you want to store all the VMDKs for a single VM within a single datastore is also down to ease of management (+ potential requirements for backup tools) and the possible need to split them based on IO pattern. In 99+% of the cases you want them on the same datastore.

Page 1 of 1 All times are UTC - 5 hours
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/