MS Exchange 2007 disk Requirements

I got it from two very reliable sources that MS is recommending that best prcatice for Exchange 2007 is that it should be on RAID 1+0 (fair enough), but that it should also only be hosted on DAS.
What is the your (and the SAN community’s) perspective on this?
Is this only for very large user bases? Does this mess up some of my Clariion plans?
Have we finally found a use for SAS shelves?

Thanks

9 comments

Skip to comment form

  1. Um, no?

    I don’t mind the Raid-1/0 requirement, though because of the Symmetrix architecture a 10-way striped raid-5 meta shouldn’t present a problem.

    I can’t figure out what MS is trying to accomplish. Array-based storage, IE, SAN, is infinitely faster than DAS because of the utilization of predictive-read-ahead and cached writes. As I keep explaining to DBA,s it really just doesn’t matter what the physical layout on the back end is, it’s all about the cache.

    Jesse

    • on May 23, 2007 at 4:43 am
    • Reply

    Sounds fishy. Might they be recommending against NAS or iSCSI rather than SAN? I have a hard time believing they’ll actually be telling people to ditch their Symmetrix attached 4Gbps PCIe HBAs in favor of internal Dell PERC RAID or some such.

    • on May 23, 2007 at 4:48 am
    • Reply

    Fighting DBA disk logic indeed painful. I try to tell them as little about the back end layout as I can without being untruthful. Reminds me of the old joke: What’s the difference between a DBA and a terrorist? You can negotiate with a terrorist.

    • on May 23, 2007 at 6:59 am
    • Reply

    I think you heard wrong Jesse. We work pretty closely with MS, and they aren’t throwing that out there that I’ve heard. There’s WAYYYY too many storage companies that *feature add* to exchange for them to pull that crap.

    To me this sounds like a common game of telephone. MS probably said *we recommend you use external disk*, which clueless reporter wrote down as “MS recommends using DAS only for exchange” and then spread to everyone he could find. When in reality, MS just doesn’t want Joe admin sticking his exchange database on that sweet new 500GB ata drive.

    • on May 23, 2007 at 2:05 pm
    • Reply

    Wow that confused the heck out of me… forgot this was a free for all now.

    I agree Jesse, the hardest thing is getting people to “un-learn” about disk structure. Just tell us if its sequential vs. random and reads vs. writes and leave the rest of it up to us.

    jm, i totally forgot about that one. 🙂

    Reminds me of small-medium (1500 mailboxes) pair of Exchange 2003 boxes that got implemented on a baby CLARiiON CX300 at a company I was working with a couple of years ago. The Messaging group came back with their “recommendation” = 2 shelves @ 30x15k disks. Hilarious. We finally got them down to accepting 14 disks (they wouldn’t go below 1 shelf). They gave us JetStress numbers to meet. Someone on their side ran the tests and the numbers came back at greater than 200% faster than what was their ideal numbers. So that was the end of that…

    Well that is until shortly there after, when we turned the read/write cache on (it was disabled and the SPs needed to be reset – ancient FLARE code) – it was at that point we realized we had beat those numbers by 200% *without* any cache.

    At least it wasn’t my money.

    • on May 23, 2007 at 7:42 pm
    • Reply

    Hi folks,
    Sorry for the confusion. Yes it was my original post that SanGod kindly put in as its own thread.

    I took this DAS stuff with a pinch of salt, but was hearing about it from different sources so thought it would be great to hear the views of the SAN expert community out there and we seem to be in agreement that what I heard is definitely a distortion.

    I guess the best place to find the truthis direct from the horse’s mouth so here’s a couple of links:
    http://technet.microsoft.com/en-us/library/c5a9c0ed-e43e-4bc7-99fe-7d1a9cb967f8.aspx
    (Planning Disk Storage for Exc 2007)
    Which seems to start off by saying ‘go hog-wild and use what you want as long as the capacity and throughput meet SLAs’ , but does give some real in-depth stuff on requirements. The closest we get in here is one statement that says that 2007, unlike previous versions, does not support Network Attached Storage (maybe not a wise move anyway…) but does support iSCSI.

    But I reckon that this DAS thing comes from the CCR (Cluster Continuous Replication) of 2007 where the Geoclusters use separate storage rather than shared.
    See this link :
    http://www.microsoft.com/technet/itshowcase/content/64bitexchange2007.mspx

    Thanks for all responses above.

    • on May 24, 2007 at 12:30 am
    • Reply

    RacaSAN: the way I read that is basically MS wants you to use LUNs only, no file-level sharing protocols. In other words, don’t plan on putting your outlook on a CIFS share. I don’t blame them, that was never a good idea 😀

    • on May 24, 2007 at 4:58 pm
    • Reply

    Agreed. I’ve seen it done but never thought it a great way.

    BTW. I was only half joking about my statement “Have we finally found a use for SAS shelves?”.
    At LSI where they have spent a lot more time and money on SAS though this is a golden opportunity for them. See link below..
    http://www.linux-mag.com/id/3260/
    They are pitching their SAS shelves as ideal DAS solutions for Exchange 2007 clusters.

    • on March 28, 2008 at 1:22 pm
    • Reply

    You need to cehck you sourced dude.

    Microsoft provides 2 options for deloying Exchange 2007 back end disk:

    Single Copy Cluster: traditional SAN attached cluster with fibre disks, etc. SIngle point of failure with SAN luns. (Add SCR to gain log shipping)

    Cluster Continuous Replication: DAS based solution with replication of storage groups for essentially always available email.

    They are not abandoning SAN, they are providing users and busineses options for deployment as SAN architectures are expensive, not always required, and replete with vendor (and Gartner driven) fantasies they do not always provide return, etc.

Leave a Reply

Your email address will not be published.