Exchange 2010 deduplication issues

acistmedical · ‎2011-09-23

Here is my setup:

VM Exchnage 2010 SP1, 1 to 1 volume to LUN setup.

1TB volume for DB - 1 1TB LUN on it

300GB volume for Log - 300GB LUN on it

10GB Volume for RDM - 10 GB LUN on it

Both volumes are NOT thin provisioned, Enable Fractional Reservation (100%) is unchecked on both.

Both LUNS are NOT thin provision either.

Both LUNS are iSCSI presented to 2 ESXi hosts and mapped to VM Exchange as physical mode through RDM

I have dedupe anabled on both volumes and im getting 30GB savings on Log volume and about 130GB on DB volume.

However, i dont see this space being given back to LUNS, is it given back to volume and since LUNS are not Thin provisioned i will not see any benefits of doing it?

If so, what do i have to do to see the space reclained?

mh_sh_team · ‎2011-09-24

As you said, you don't see the saved space because your luns are thick provisioned. The saved space is at the volume level and in order to benefit from it you should disable space reservation on the luns. This extra space can be used for more snapshots for example.

bjornkoopmans · ‎2011-09-25

Well, as your LUN's fill 100% of your volumes, I suspect you're not using snapshots. 🙂 So you could indeed give it back to your LUN's by thin provisioning them, or give it back to the aggregates to create new volumes and such.

Bjorn

acistmedical · ‎2011-09-25

You are correct, im not using snapshots on threse LUNS as they only hold Exchnage data.

DB on one and Logs on another. DB LUN has about 400GB used and 600GB free

So, if i go to system manager --> LUNS and check "Thin provision" on these LUN will the used space decrease by areound 100GB?

Or will Exchange still see 400GB used and 600 free on the drive?

How safe is to chenge LUN provisioning tron thick to thik while there is ton of data on it and it is actively used by Exchange?

Thanks

radek_kubka · ‎2011-09-26

Hi,

If you do thin provisioning, nothing will change from the OS perspective: it is totally transparent.

Disabling LUN space reservation is a safe operation in itself. The (long-term) consequences are a different story - it is possible that one day this LUN will need all its space & there is none left in the containing volume / aggregate. And OS will go mental, as it is unaware the 'free' space in the LUN is in fact unavailable.

Personally I like thin provisioning, but it is really down to individual preferences and methods of monitoring / alerting about free space left on the filer.

Regards,
Radek

acistmedical · ‎2011-09-26

So that means that I can achieve saving ONLY on Volume level or Aggregate, correct?

If so, to move savings from Volume to aggregate level I would have to thin provision the Volume and the LUN, I which I don't want to do (at least not on the volume level).

If this is all correct I guess that there is really no benefit for me in doing dedupe on these 2 LUNS at all, looks like it may be better just to turn it off.

radek_kubka · ‎2011-09-26

If this is all correct I guess that there is really no benefit for me in doing dedupe on these 2 LUNS at all, looks like it may be better just to turn it off.

Yes, I think that's a fair statement.

Dedupe savings cannot be easily used without thin provisioning, especially with 1 LUN to 1 volume mapping.

bjornkoopmans · ‎2011-09-26

Radek Kubka wrote:

If this is all correct I guess that there is really no benefit for me in doing dedupe on these 2 LUNS at all, looks like it may be better just to turn it off.

Yes, I think that's a fair statement.

Dedupe savings cannot be easily used without thin provisioning, especially with 1 LUN to 1 volume mapping.

I do not fully agree with that. You could easily make use of some of the free space without thin provisioning, by shrinking the volumes and thereby giving the free space back to the aggregate. By using active monitoring and volume autogrow you should be safe from sudden low dedup results.

Bjorn

radek_kubka · ‎2011-09-27

Yep, that would work - although the use of word 'easily' is subject to a further discussion

As already said, many things are down to personal preferences.

I prefer thin provisioning, because:

- it consolidates capacity worries to the aggregate level

- makes the design process more flexible / forgiving

- doesn't require ongoing adjustments (other than chucking in new disks when aggregate runs out of space)

But as usual with NetApp - your mileage may vary!

Regards,

Radek

bjornkoopmans · ‎2011-09-27

I totally agree with you that thin provisioning is preferable, though many companies still find it a bit scary. 😉

Bjorn

acistmedical · ‎2011-09-26

Thanks for all the responses, hopefully Exchange 2012 (or something like that) will support NFS so we can see dedupe savings directly on the OS level