VMware Solutions Discussions

Dedup only saving 5% on 750gb of windows VM's

wally_kroeker
7,697 Views

I currently have two ESX 3.5 hosts connected to a 2050 running 7.3.1.1 through iscsi.  I recently had to create a brand new lun and migrate all of my VM's to it becasue the vmfs file system became corrupted.  On my old lun dedup was saving me 65% of my space but on the new one I am only saving 5%.  It is a 1 TB volume with space settings set to volume, fractional space reservation set to 0% and snapshot reserve set to 0%.  On the Lun space reservation is turned off.  I have set dedup to run between 3 and 6 am everyday and it now seems to take 6 min to run every night.  I can't figure out why this would have changed.  Any help would be apreciated.

27 REPLIES 27

rogilvieisc
6,824 Views

Hey Wally,

You might want to check that no snapshots have been taken - did you set the snap schedule to 0 0 0 on the new volume created before migrating the VMs over? (snap sched <volumename> 0 0 0). 

If there are snaps residing on that volume the data will be locked and dedupe will not touch the data until the snap releases it (i.e. snapshot deleted).

Other than that I'm not sure, I'll have a think...

radek_kubka
6,824 Views

If there are snaps residing on that volume the data will be locked and dedupe will not touch the data until the snap releases it (i.e. snapshot deleted).

It actually behaves in a slightly different way:

if there is even a single snapshot in the volume in question, then de-dupe will show whatever savings has been made, but the snapshot will grow by exactly the same figure as the "saving".

So the bottom line is that the described behaviour is weird, as even with snapshots in the volume in question, de-dupe "savings" ought to be measurable.

Regards,

Radek

wally_kroeker
6,427 Views

The Only Snaps that are on the volume have been taken with SMVI

radek_kubka
5,523 Views

That actually doesn't make a difference - unfortunately A-SIS is not really snapshot-aware (other than the fact it won't mess with protected blocks), so with or without SMVI, the end result will be the same.

But as I said before - sis output still should show some reasonable savings anyway, they only won't be really available due to snapshots being inflated.

Regards,
Radek

amiller_1
6,824 Views

A few thoughts.....

  • Generally speaking (not related to the actual issue), NFS does expose deduplicated space more easily (no frac reserve, shows directly in the VI client, etc.).
  • If you deploy 2 new VM's from the same template (no need to power them up), check "df -Sh", run dedup, "df -Sh" again, what do you see? (should get a lot of space back)

wally_kroeker
5,523 Views

It seems to be doing something to new data.

Deployed 2 10 gb VM’s 

Pre dedup

san2> df -Sh

Filesystem                used       compressed         a-sis     %saved

/vol/vol0/              1816MB              0MB           0MB         0%

/vol/lun2/               812GB              0GB          45GB         5%

After dedup

Filesystem                used       compressed         a-sis     %saved

/vol/vol0/              1817MB              0MB           0MB         0%

/vol/lun2/               814GB              0GB          48GB         6%

lfreeman
7,069 Views

Yes you should of course see 65% savings on the new LUN just like you did on the old LUN.  Your LUN settings seem correct.  Question, did you run the "sis on" command on the volume before you did the migration, or run "sis start -s" on the volume after the migration?  You'll have to have done one or the other to get the full dedupe savings.

DrDedupe.

wally_kroeker
6,427 Views

I turned on dedup after I moved all of the vm's to the new lun.  I have a schedule that runs every night at midnight

eric_barlier
7,067 Views

I reckon you need to set vol guarantee to none. Can you look in old autosupports to set what the old volume used to have? you find old asupsin /etc/log/ folder on controller.

If you are worried about writes to your LUN you can then use "vol autosize" command so that the volume will grow when

the LUN needs space. We use this config and it works like a charm. This config forces free blocks back to

aggr. level = easier to monitor/monitor.

So long you dont use snapshots you dont have to worry about "snap autodelete" once/if the volume reaches its max size.

Cheers,

Eric

radek_kubka
7,068 Views

I reckon you need to set vol guarantee to none.

That's bad idea, as vol guarantee set to none enforces 100% fractional reserve (can't be changed).

Vol guarantee set to volume (plus vol auto-size & snap auto-delete, plus FR of 0%) & thinly provisioned LUNs within that volume is a way to go!

Regards,

Radek

eric_barlier
7,068 Views

Hi Radek,

By setting it to none you can start monitoring your space at aggregate level as opposed to have to monitor X numbers of volumes. It obviousily a lot

easier and allows for cap. planning to be facilitated at the same time.

However for some customers setting vol guarantee to none is not good of course. I just think any statement that categorically states

its not good to set it to none will not be right 100% of the time. it does work for us, in fact I love it! :-0

Cheers,
Eric

Message was edited by: eric barlier

radek_kubka
6,672 Views
I just think any statement that categorically states

its not good to set it to none will not be right 100% of the time. it does work for us, in fact I love it! :-0

Hi Eric,

Yes, yes - point taken.

What I was trying to stress is the fact that 100% fractional reserve kicks in when vol guarantee is set to none & there is no way to dodge this. Setting FR to 0% (or some small number when SnapManager products are in place) is now a part of official NetApp best practice, so you see where I am coming from...

Having said that, I fully appreciate 100% FR may still be a good thing for some people in some environments. And I also admit FR in itself is still a very hairy topic! (see my post about FR & reallocation: http://communities.netapp.com/thread/4431?tstart=0)

NB this is all irrelevant if there are no LUNs in the volume in question.

Regards,
Radek

eric_barlier
5,632 Views

Hi Radek,

Good points. I was never a fan of FR 100%.. I believe "vol guarantee none" should only be used when you  fully thin provision by turning

LUN space reservation off as well, and you have <vol autosize on> with <snap autodelete> as well.

thanks for sharing your valid points with us.

Eric

radek_kubka
7,066 Views

On my old lun dedup was saving me 65% of my space but on the new one I am only saving 5%.

Isn't your block alignment screwed up by any chance? That may explain poor dedupe ratio (I think)

eric_barlier
7,066 Views

I have not heard that block align. issues will impact on dedupde savings. Dedupe is at WAFL level and the block un-alignment issue is when you put

a file system on top of WAFL and its not aligned = impact on perf.

Its an interesting thought though. Does anyone hold conclusive information about this? Is Radek onto something here?

Cheers,
Eric

scottgelb
6,669 Views

I'm interested in hearing the official answer on this too... in early asis presentations I remember seeing something about fixed 4k blocks but could be wrong...then also heard misalignment didn't hurt deduplication but haven't heard confirmation from an engineering resource.

radek_kubka
6,669 Views

Guys,

This is where I am coming from, using purely common sense:

Scenario A, three identical VMs, but no identical blocks within each VM, all properly aligned, so NTFS blocks are mapped identically to WAFL blocks.

Scenario B, same VMs, vm1 properly aligned, vm2 has 1k offset & vm2 has 2k offset, so NTFS blocks from each VM are mapped in a different way to WAFL blocks.

Scenario A should give 3:1 de-dupe savings, whilst scenario B will give no savings, as NTFS blocks will be "chopped" from a different starting point in the case of each VM (unless purely by chance some aligned blocks will get identical 'twins' from miss-aligned ones).

Am I missing something?

Regards,
Radek

wally_kroeker
6,669 Views

Interesting.  I just started reading about alignment and how it affects performance.  Can someone point me to an easy tutorial on how to check alignment and how to fix it if it is off?  I had someone tell me that when I create the lun and choose vmware as the type that will take care of the WAFL to vmfs alighnment.

keitha
5,765 Views

Wally,

Included in the Host Utilities Kit are mbrscan and mbralign. mbrscan accepts the path to a vmdk file as input and tells you if the NTFS filesystem in the vmdk is properly aligned with the VMFS filesystem. The VM can be running during the scan. mbralign accepts the same parameter and will fix any alignment issues with the VM. The VM does need to be off for the align process though and you do need at least enough space in the volume for a copy of the VMDK. The end result is a properly aligned VM.

Alignment certainly helps performance and load on the storage array but I would be surprised if it effected dedupe this much as I would expect all the VMs to be equally misaligned thus dedupe well. Especially if they deduped well on a different volume.

Keith

satheesh1
5,766 Views

I was under the impression we need to shutdown VM, when we do mbralign. That's the mbralign documentation says. Please correct me if I'm wrong.

Satty

Public