While reviewing some of the new changes made to Exchange 2010 I came across an interesting article regarding Database Availability Groups (DAGs) and the recommended database size limits. Microsoft has done away with Storage Groups in Exchange 2010 and have gone directly to simply databases, which gives us the highly available architecture of DAGs. A database availability group (DAG) is the base component of the high availability and site resilience framework that is built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. System administrators can leverage multiple mailbox servers and replicate a mailbox database to a maximum of 16 mailbox servers, as 16 servers is the maximum number of servers in a DAG. In the event of an issue on one of the mailbox servers an Administrator can move a user’s mailbox to another database in the DAG. This process is seamless and requires about 30 seconds. During the transferring of the user’s mailbox to another server in the DAG the users experience no outage!
Now, enough with the explanation, in Exchange 2010 Microsoft has suggested a maximum database size of 2TB! The explanation: With the significant core improvements made to Exchange 2010, the maximum recommended mailbox database size has increased from 200 GB in Exchange 2007 to 2 TB in Exchange 2010. Supporting these much larger databases means moving away from legacy recovery mechanisms, such as backup and restore, and moving to newer, faster forms of protection, such as data replication and server redundancy. This is where the DAGs come in play. As I mentioned above, a database can be replicated to 15 other servers in a DAG. Keep in mind the max servers in a DAG is 16.
I was able to find out this information and more at: http://technet.microsoft.com/en-us/library/dd638137(EXCHG.140).aspx
[...] includes Outlook 2007/2010 as well as Outlook Web App. This works rather slick when using DAGs and moving a users mailbox. Since the user is connected to the CAS they will not see an [...]
Exchange 2010 (Part 4 of 4) – Installing the Hub/Transport, Mailbox and UM Roles…
In our small environment, we combine the Hub/Transport, Mail ……
The Exchange Product Team is obsessed with reducing the TCO of Exchange – which is good for themselves and consumers – but they have been ignoring important facts in the promotion of big, slow, dumb disks for Exchange.
The 2TB recommendation is for multiple copies (at least a 3-member DAG), and requires a 4th copy through Data Protect Manager or a passive-node VSS backup product. This is a highly-complex configuration. The performance impacts of online maintenance, reseeding, journaling, indexing, and MRM policies are ignored – in fact, Microsoft itself has suffered numerous, massive outages based on DAG failures and extreme rebuild times based on its own recommended architecture.
One good outcome of the Product Team’s recommended architecture is that it has driven millions of customers to Microsoft’s Exchange 2007-based BPOS (Cloud Services platform).
For the next disasterous recommendation, stay tuned for Exchange Product Team’s “Dumpster 2.0″, aka “Exchange now does Native Discovery”. Brought to you by the same folks who thought up “Move 20% of your users every night” and the Matrix backup table (Database 1 full on Sunday, then incrementals the rest of the week – Database 2 full on Monday, then incrementals the rest of the week), etc. If you want to know how to crash the platform and invalidate Big Brother’s copy of your email, please leave a post here.
Clearly some of those folks never came down from Whistler Mountain and have brain freeze…..
Having a max size of 2TB makes sense in terms of NTFS, but i hear it goes up to 16TB – can you even have that in NTFS?! How can they claim that?
You would have to use a GUID Partition Table for the disk. GPT can support a large amount of disk and could take a user to 16TB and beyond.
Thanks for this awesome post.This post is really helpful !