CIFS and NFS data is placed directly in the flexvol, LUNs only apply when you're using block based protocols.
I would go with a one LUN per flexvol method, as I just find it alot easier and less confusing to managed. For VMware TR3479 recommends one datastore per flexvol (page 49) for virtual servers, so this would equate to one LUN per flexvol is you are using iSCSI/FCP.
For VMWare, I agree with Chris to use 1 lun in a flexvol. But for some other applications, we use several lun's in 1 volume, depending on the size of the luns, the amount of the luns and (most important) DR/backup policy. You have the limit of amount of flexvols for each controller (+- 500) and also the benefit of deduplication is less when you have smaller flexvols (dedup is on flexvol level).
ps: When you want to start with vmware on netapp, try also nfs instead of iSCSI or FCP.
Now that you have mentioned dedup can I ask some questions on this in a VMware environment.
If you create a flexvol with one lun (both thin), you enable dedup on the flexvol then P2V 15 VMs (example) – Hasn’t your lun already grown to a certain size, so when you run dedup the lun/flexvol does not decrease in size and the saved space from the dedup process cannot be used elsewhere in the array???
If everything is thinly provisioned, LUN 'nominal' size is pretty much meaningless (on the storage side). When you run dedup, you effectively replace redundant blocks with pointers, hence your LUN will simply occupy less space in its parent volume &, consequently, in its parent aggregate.
That way some space has been released which now can be used for creating another volume and/or LUN.
Yes but if you create a thin vol/lun of say 2TB - You P2V some VMs and end up with 1.5TB used on the vol/lun - When you run dedup and replace sufficient block so you end up with 500GB used, your vol/lun is still 1.5TB in size (provisioned from 2TB) as this cannot be reduced in size.
You end up with no real benefit apart from the fact the vol/lun will allow you to store a further 1.5 TB on the vmfs datastore, however you cannot place more VMs on the datastore due to vmfs limits (this is an example)????
What I am getting at is that the lun can not be reduced in size after dedup has been ran and hence no other volumes/luns can benefit...
So initially the amount of consumed space in agg0 & vol1 is pretty much 0. Then we put ~2TB of data inside lun1, so agg0 has roughly 1TB free space & vol1 has ~0.5TB free space left. So far, so good.
When we run dedupe on vol1, ONTAP does not inspect the actual content of the lun1 (which is just a special file) - it looks for redundant blocks & when finds them, replaces with pointers. If dedupe ratio is 4:1, then lun1 space consumption will drop to 500GB on the storage side. Nothing changes on the ESX host side, so if the LUN was almost full, it will still look like almost full. Yet vol1 will now show ~2TB of free space & agg0 will show ~2.5TB of free space.
So now we have a choice how to use reclaimed space: a) put another LUN inside vol1 and/or b) create another volume inside agg0.
Think of a NetApp volume as a container - when you thin provision it, you are not booking any space upfront & the 'nominal' size simply defines the container maximum capacity. So, again, nominal size is pretty meaningless, until you fill the volume completely.
Volume is not shrinking / growing - dedupe simply increases the amount of free / available capacity
in your example above if the thin lun has 2TB of data dumped onto it and later deup reduces the used stroage down to 500GB on the storage size will it look as though the lun has only 500GB of data within or the full 2TB? - This also has the affect of the containing volume now only using 500GB and thus the arrg has been freed of 1.5TB which can be used by other volumes?
Do you all use a-sis on your systems for vmware environments? - If so, does it impact performance in anyway (dedup on primary data) - Also, anything one should be aware of when using this technology with vmware?