Microsoft IT Showcase: Storage Design for Exchange Server 2007

[The_Exchange_Team]

Microsoft IT just released a new IT Showcase whitepaper that you might find very interesting. Here is what the problem they were trying to solve was, and the solution:

Situation:

Microsoft IT ran Exchange Server 2003 mailbox servers in a clustered configuration to achieve high availability of 99.99 percent, but the Exchange databases remained a critical single point of failure, and the high costs associated with shared SAN storage hindered Microsoft IT from supporting employees with mailbox quotas of greater than 200 MB. The future Mailbox server design required a cost-efficient solution to support mailbox sizes between 500 MB and 2 GB. These increased mailbox sizes made it necessary to provide 10 times more data capacity on mailbox servers and implement redundancy at the storage level to eliminate the need for restores from backup as the primary recovery mechanism after a storage failure.

Solution:

By implementing Exchange Server 2007 with a storage architecture based on CCR, Microsoft IT eliminated shared storage as a critical single point of failure by maintaining separate up-to-date copies of mailbox data at all times. This provided an opportunity to replace SAN technology with DAS equipment and support employee productivity with substantially larger mailboxes that accommodated higher redundancy levels.

This is a very interesting read, go here to get it:

http://technet.microsoft.com/en-us/library/cc500980.aspx

A related TechNet Webcast: How Microsoft IT Implemented New Storage Designs for Exchange Server 2007 (Level 30... is also available. From that page, you can also download just the Webcast audio in WMA and MP3 formats.

- Nino Bilic

[#2]

Organizations started moving towards SAN from DAS to achieve Storage consolidation/avoid Storage wastage due to DAS silos being underutilized at times/ Storage expansion limitations as business requirements grow/ reallocate storage as needs change over time even though Storage itself remained single point of failure though the SAN has additional levels of redundant components not present in DAS.
Agreed that SAN introduces complexity, but there are other options such as geographically dispersed clusters/ snap shot / replication options in SAN to eliminate storage single point of failure.

CCR and DAS may be cost effective and simple solution with no single point of failure, but will  reintroducing DAS bring back those limitations that were inherent in earlier DAS implementations?

Do we have CCR and SAN solution for Exchange to get the best of both- eliminate single point of failure and get flexibility in Storage allocation and if the investment in SAN is already made?

Thanks
Manoj

[#3]

You can use CCR on a SAN.  This white paper, I believe, is just illustrating you can save a large sum of money by using DAS and DPM.  

As long as you have SANs on both sides of your CCR cluster links, you will be fine.  Odds are this is how we'll proceed.  Nothing says you can't use a SAN.

[#4]

I find it interesting, that you're all seem to work in companies, where you can force your users to a limited mailbox size. In the company I'm working right now, we're setting no limits to our users, and so reached an approx mailbox size of 3GB per user on our ancient E2K3 machine and today some boxes are gaining 6GB in size on a E2K7 for the most active users. The approx size dropped to 2GB due to gentle clean up requests from the admin front..
Our public folders will break the 1 million mails barrier this year. Receiving a few hundred mails for different teams every day into the public folders and saving every sent mail ("send on behalf of" mail) in a "sent" folder for every team (thus still done by a linux frontend , I'm sorry ;) - filtering sent mails and redirecting a copy back into the public folders). Still got no time to try out the E2K7's internal filtering. Maybe it'll spare me some transaction logs by using them instead of the "out+back" into the system?
Cheers

[#5]

@Alex
The reason why we force users to a standard for mailbox (and mail) size is because we have to in order to provide the required service to the business within the SLA's that they require.  My company hosts 25,000 mailboxes but could expand to host 500,000 or more mailboxes within the space of a month, all because of how we designed our messaging infrastructure (hint, think scalability).  Mailbox limits are a huge part of that, we know *exactly* how big our mailboxes will get so we know *exactly* how much storage to purchase for each Storage Group, and we never have to worry about expanding the storage assigned to a Storage Group, and considering the storage was 2/3 of the cost of our infrastructure that kind of control was critical in being able to provide what the business needed.

@Manoj
If you have a strict policy and enforcement on mailbox size then using DAS with Exchange 2007 actually becomes quite desirable, you always know how much space the Exchange server will be using (assuming you have the max number of users on it), and because you design with E2K7's 64 bit memory usage in mind you can get a much better space usage scenario than you did with Exchange 2003, where the number of spindles was more critical than the amount of space available.  DAS may still not fit into other application scenarios, but with the changes to Exchange 2007, and proper designing, you could move off of the SAN and onto DAS, saving a lot of money as well as simplifying your Exchange environment (which is always a good thing).  And in our case our storage team will love us as well, they hate that we have dedicated SAN's for Exchange 2003 while everything else is on shared SAN's.

[#6]

@sbg
But if you have today SAN for shared systems and for Exchange you have dedicated. What is the cost saving in case you move the Exchange from SAN to DAS and still having the SAN boxes for other servers? If you can decrease the numbers of the SAN boxes because you are moving Exchange. Then you might save costs, but if that is the case then you will not save anything. Or ?

And can someone remind me which where the limitations on the DAS, as like Manoj already mention:
> ....reintroducing DAS bring back those limitations
> that were inherent in earlier DAS implementations...