Exchange 2010 LUN/Volume Configuration

[#1]

We're in the process of migrating from Exchange 2007 to 2010, and moving to Netapp for storage, and I just had some questions regarding LUN/Volume configuration. Currently, our Exchange Admin created a volume, and linked a bunch of LUN's into it, all which are space reserved. Since Exchange 2010 removed SIS, we would like leverage dedupe on Netapp. My question is, should I remove the Space Reserved setting on my LUN's, and enable dedupe on the volume, similar to what is done with VMFS LUNs? I suppose there is no way to reduce the size of my volume after enabling dedupe if the LUNs pointed to it all have Space reserved, but I figured I would check with the community and see if this is the standard config for 2010.

Tks

[#2]

Hi, there are many different ways how to setup and use dedupe. Here are just 2 of it

Example 1:

Set up a 100GB LUN spacereserved and a 200GB volume to space guarantee volume.

Without dedupe:

Aggr = Total:1000GB  Free:800GB

Volume = Total:200GB Free:100GB

LUN = 100GB

With dedupe 50% saved:

Aggr = Total:1000GB  Free:800GB

Volume = Total:200GB Free:150GB

LUN = 100GB (50%/50GB saved by dedupe)

As you see the dedupe saves 50GB and give it to the Volume but not to the Aggr. You can use the saved space to setup an additional LUN in your Volume.

Example 2:

Set up a 100GB LUN spacereserved and a 200GB volume to space guarantee none.

Without dedupe:

Aggr = Total:1000GB  Free:900GB

Volume = Total:200GB Free:100GB

LUN = 100GB

The Aggr freespaces changed cause the Volume just reserve the space of the 100GB LUN

With dedupe 50% saved:

Aggr = Total:1000GB  Free:950GB

Volume = Total:200GB Free:150GB

LUN = 100GB (50%/50GB saved by dedupe)

Instead of example 1 now the Aggr freespace also changed and you can use it for additional Volumes

The spacereserved options does not change your dedupe results. If we look again to example 2, It doesn't matter if the LUN is spacereserved or not the amount of saved space would be exactly the same cause dedupe is volume based. Here is what spacereservation does:

Example 1: We install Windows at our 100GB spacereserved LUN and our 100GB Windows partition uses 20GB of Space. The Volume is still 200GB and spacereserved none.

AGGR = Total:1000GB Free:900GB

Volume = Total:200GB Free:100GB

LUN = 100GB

Example 2: We install Windows at our 100GB !!NOT!! spacereserved LUN and our 100GB Windows partition uses 20GB of Space. The Volume is still 200GB and spacereserved none.

AGGR = Total:1000GB Free:980GB

Volume = Total:200GB Free:180GB

LUN = 100GB

As you see the hole filer just reserve the space that Windows actually uses

So in my opinion the best option is to set up the Volume to space guarantee none and use the new free space for additional volume.

[#3]

Thanks alot Dennis. I think he solution I'd prefer is to set a reserved space volume in the aggregate, say for 200GB. I would then have 300GB worth of LUN's pointing at that volume, but with dedupe, As long as I'm getting 50% dedupe, I'll only be consuming 150GB of the volume. Obviously if I'm only getting 25% dedupe, I'll adjust my volume size properly to allow for space, and put autogrow on for the volume in the event it needs it. Does this sound like a good solution, or is there another one that would be more applicable? I'd just like to stay with volume space guarantee's to ensure we don't oversubcribe from the aggregate.

[#4]

Hmm...well interesting conversation....Well if you think you don't want to keep Volume reservation to NONE because you don't want to oversubscribe  the aggregate, then maybe you have options:

Well, once you deicded you don't want to overcommit the aggregate, you can make sure the total size of your volume is not exceeding the total size of the Aggregate. In normal scenario's you aren't allowed since Data ONTAP will not allow you. However, in case of no space reservation you can. But you can be smart enough to see the total space and make sure you aren't exceeding the Aggregate space.

This way, you have enabled Thin-Provisioning and not over-committed the aggregate

[#5]

This is a good solution if you want to be save.

I would do it in the other direction: first set up the Volume to 300GB and after dedupe resize it to a smaller size, but the result would be the same.

BTW: a good command which most people don't know is the "aggr show_space -h" command. You will see the total, the real and the committed space of each aggregate.

[#6]

Thanks guys, definately good discussion. Also good point Dennis, I'll see what the dedupe rate is before reducing the volume size. Does anyone know; if I remove the Reserved setting on the LUN's, will anything weird happen to my data?

[#7]

Nothing to the Data. you can change them online.