Early on in the thought process the customers were keen to retain one copy of the storage on one set of disks and another set of storage on an entirely different set of disks. This met the Exchange requirement of having a two copy DAG in production before consideration was given to the DR site. However, the storage people really thought the Exchange people were, to put it charitably, somewhat excessive in their storage requirement. How could the Exchange people be satisfied that they had their two copies and the storage people be satisfied that they were getting the best use out of their highly resilient storage platform.
Some bright soul had a plan (there's a clue for you). Let's fool the Exchange guys because, being one, I know they're far easier to fool than the storage boys. Take two servers. Create a FlexVol and put a LUN in it. Create a database. Get the users to load up the store with normal data. Deduplicate it. As you've seen you're looking at between 10 and 25% saving in physical, consumed, space. My home lab is sat at around 13% which is typical for a store that receives emails with body but few attachments.
Now for the next part.....
Set up a replica. You now have two LUNs. Put those two LUNs into the same FlexVol. Run deduplication.
The picture is just a screenshot from System Manager showing that the two copies as far as Windows is concerned, is only taking the physical space of one.
Ohh, I can hear you now. Single point of failure. Sky falling. Visigoths. Barbarians. End of days. Not at all. Keep calm and carry on. It's all on RAID-DP. Two disks can fail and nothing happens. And anyway, if you're doing a 2+1 there's still that 3rd copy in the remote location.
4 comments:
Love the idea of deduping the passive copy. What's the best setup? Is it 1 volume with 2 luns (one active and one passive) for each database or is it 1 huge volume for all the database luns?
We are doing a migration in the next month and need to get my storage squared away and ready for snapmanager as well.
@Carlos.
Well, the idea here is that you're deduplicating both copies, not just the passive. In essence though you're right if you mean that we're effectively eliminating the space consumed by the passive.
One Flexvol. Two DB LUNs inside it. Svr1/DB1 and Svr2/DB1 in each of the LUN. Deduplicate.
Now, I would suggest that you look carefully at the I/O. If you are running 24/7 OLM you might well find yourself short of IOPS on SATA so you can't get away with that setup. If you look at, and cost out, SAS, you might well find that the $/(actually consumed)GB ratio is cheaper than separated LUNs on SATA. You gotta do the numbers and do what makes sense.
As regards the whole idea of shoving a load of data into one Flexvol you can get some serious numbers if you are implementing the archive mailbox in a bog enterprise you can put a lot of those archive databases into a single FlexVol and dedupe the whole shebang. Kinda like SnapVault really if you look at it with a squint! :-).
Remember that if you implement SME you are going to want to do this from the Node or at least ensure that you take precautions not to back up in such a way as to run into a locked volume scenario. That wouldn't cause any damage; it would just suck and you wouldn't get any snapshots. #fail.
Thanks for the info. I'm glad you mentioned SME cause we will be implementing it along with the Exchange 2010 install. Anything else we should look out for besides locked volume issues?
Pay attention to database, LUN and FlexVol layouts. You don't want to get yourself into a situation where you're trying to backup a gajillion stores at the same point in space-time. Separate them out so you can do multiple processes within the same jobs.
Decide where you want the snaps to be done. That's a long old discussion.
I understand you met my man Will in Miami. He's following through on the email you sent him. It's a small world!
Post a Comment