VMware Solutions Discussions
VMware Solutions Discussions
Are flexvols the same as luns? - I am reading a document on creating luns for use by ESX and the document keeps referring to placing the lun within a volume?
I thought that it was the flexvol which is what the vmfs datastore was created on? - Please can someone explain why / reason for this? Also, if this is the case do you create a lun per flexvol?
Luns are not flexvols
Luns live within flexvols (or tradvols)
To clone a lun use the lun clone command
Is it best practice to create one lun per volume or xx luns per volume?
Also, nfs/cifs are created directly within a volume?
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.
Hope this helps.
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???
What is the best practice for this type of setup?
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.
Hope it makes sense!
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...
Am I right or wrong on this?
Luckily this is not the case.
Say we have following setup:
agg0 - 3TB
vol1 (inside agg0) - 2.5TB, thin
lun1 (inside vol0) - 2TB, thin
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.
Does it make sense?
So it is the volume which reduces in size (provisioned size)?
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
ok, a little confused.
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?
Radek has given you the right example. To answer your latest queries,
From your storage filer end, it will show you that only 500 GB of data has been used up. The aggregate and volume used space will come down to 500 GB although the total space will remain the same 2TB.
From your host server end, it will show you that 2 TB has been used up.
Radek. Please do correct me if I am wrong.
Thanks & regards,
Ok, I'm there! thanks to all...
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?