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/ |