10 Replies Latest reply: Sep 27, 2011 7:35 AM by bjornkoopmans RSS

Exchange 2010 deduplication issues

acistmedical
Currently Being Moderated

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?

  • Exchange 2010 deduplication issues
    mh_sh_team
    Currently Being Moderated

    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.

    • Exchange 2010 deduplication issues
      bjornkoopmans
      Currently Being Moderated

      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

      • Exchange 2010 deduplication issues
        acistmedical
        Currently Being Moderated

        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

        • Exchange 2010 deduplication issues
          radek.kubka
          Currently Being Moderated

          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

          • Exchange 2010 deduplication issues
            acistmedical
            Currently Being Moderated

            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.

            • Exchange 2010 deduplication issues
              radek.kubka
              Currently Being Moderated
              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.

              • Exchange 2010 deduplication issues
                bjornkoopmans
                Currently Being Moderated

                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

                • Exchange 2010 deduplication issues
                  radek.kubka
                  Currently Being Moderated

                  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

  • Exchange 2010 deduplication issues
    acistmedical
    Currently Being Moderated

    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

More Like This

  • Retrieving data ...