3PAR Users Group

A Storage Administrator Community




Post new topic Reply to topic  [ 2 posts ] 
Author Message
 Post subject: creating LUNs - best practice
PostPosted: Fri Nov 10, 2017 2:53 pm 

Joined: Thu Nov 09, 2017 1:30 pm
Posts: 1
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!


Top
 Profile  
Reply with quote  
 Post subject: Re: creating LUNs - best practice
PostPosted: Sat Nov 11, 2017 1:03 pm 

Joined: Mon Sep 21, 2015 2:11 pm
Posts: 454
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 


Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group | DVGFX2 by: Matt