Exchange 2010 Database Availability Groups
Because I deal a lot with HA/site resilience in my job as a Technology Architect, one of my favorite features in Exchange 2010 is naturally the new Database Availability Group (DAG) HA/site resilience feature, which replaces CCR/SCR/LCR. Also note that SCC has been deprecated/cut with Exchange 2010.
DAG built on the functionality we know from CCR and SCR, that is it still uses asynchronous log shipping and replay etc.
An interesting thing about DAGs is that you’re no longer required to form a cluster before you install the MBX server role. The limited cluster features that are used by DAGs (primarily cluster heartbeat and quorum) are configured automatically when adding the first MBX server to the DAG and thereby more or less invisible to the administrator.
With DAG you can have up to 16 copies of a Mailbox database. In addition, you can also have other Exchange 2010 server roles such as HT and CAS installed on the MBX server which is member of a DAG. Also, you can have DAG members located on different subnets and in separate AD sites.
There’s a lot to say about DAG, but I’ll stop here and instead let you know I currently am writing a multi-part articles series on this very subject. Look forward to seeing it published here on MSExchange.org in a near future.
- Henrik Walther
Todd Says:
April 21st, 2009 at 5:55 am
Is the FileShareWitness an additional Exchange server? (Is it an additional license?)
In other words, if you have two Exchange servers sharing the same mailboxes, do you need three licenses?
Henrik Walther Says:
April 21st, 2009 at 7:34 am
A Hub Transport server is suggested/recommended, but only because its a little easier to create the FSW share on another Exchange 2010 server (because of the Windows firewall exceptions already there).
But a file server or some other server in the AD is just fine/supported as well.
Martin Says:
April 22nd, 2009 at 3:06 am
Looking foward to these new articles and the others that will be created on 2010.
I thought that public folders would be removed from Ex2010?
Will 2010 support migrations from 2000/2003 just like 2007?
Thanks Henrik
Henrik Walther Says:
April 22nd, 2009 at 3:30 am
Hi Martin,
Exchange 2010 includes public folders and they are supported at least until Exchange 2010 goes into extended support, which is quite a few years from now
And yes you will be able to transition to Exchange 2010 directly from Exchange 2003 SP2 (Exchange 2000 is not support).
Subhash Tiwari Says:
June 4th, 2009 at 5:45 am
Hi Henry,
I just wanted know that what is new features in Exchange 2010 Mailbox Database and also what is the default size of Mailbox Database in Exchange 2010.
Cheers,
Subhash Tiwari
Orient Technologies Pvt. Ltd
Henrik Walther Says:
June 5th, 2009 at 5:05 am
Well actually I wrote about this topic in the May newsletter.
“Welcome to the May issue of the MSE newsletter! So this month we are going to talk about some of the optimizations that have been done to the storage section in Exchange Server 2010.
As most of you know, we saw a significant reduction in I/Os per second when moving from Exchange 2003 to Exchange 2007. It was not uncommon to get a reduction of up to 70%. This was primarily due to the fact that Exchange 2007, unlike earlier versions, took advantage of a 64-bit based architecture, which then again made it possible for Exchange to access more memory and thereby use larger memory caches. The more data Exchange can retrieve directly from the virtual memory address space, the less I/Os need to be done against the disks in the underlying storage subsystem.
The main benefit was a much more efficient usage of the existing storage system (typically an expensive SAN) or a great excuse to move to a less expensive direct attached storage (DAS) based solution. Because of the reduced I/O requirements, we could host a lot more mailboxes (+5000) per Exchange 2007 Mailbox server than we could with Exchange 2003. In order to avoid virtual memory fragmentation, Exchange 2003 was typically limited to 4000 mailboxes per mailbox server. Yes, I know this depended on type of servers, storage, user profiles and Exchange infrastructure.
The Extensible Storage Engines (ESE) have always been the underlying database technology in Exchange, and ever since the first Exchange version (Exchange 4.0 was released in June 1996 until Exchange 2007 SP1 surfaced on the market), the Exchange Product group has made great efforts in tweaking and optimizing the ESE in order to achieve better performance.
So with a 70% reduction in I/Os per second in Exchange 2007, one would think it would not be possible to optimize ESE further right? Bringing us to the question: What kind of improvements have the Exchange Product group made in regards to storage optimization in Exchange 2010? Did they even manage to do any optimization at all?
The short answer is yes! As a matter of fact the Exchange Product group have managed to optimize storage more than what has been done the last 8 years! Yes you heard right!
In regards to storage in Exchange 2010, the Exchange Product group focused on delivering large (+10GB) and fast mailboxes while taking advantage of cheap storage/disks. Because of the ESE changes made in this version, we now have the option to utilize low performance disks such as desktop-like SATA disks (aka SATA/Tier 2 disks). Yes, I am talking about 7200 SATA disks, just like the ones in your workstation! If you use database availability groups (DAGs) for HA (+2 DB copies), you can even use JBOD (a single 7200RPM disk storing both a DB and the transaction logs) instead of expensive RAID configurations.
To achieve the above, the Exchange Product group had to make significant changes to the store schema. The primary goal was to move away from many random small-sized IOs to fewer sequential large-sized IOs. In order to move from random to sequential IOs, the store table architecture needed to be changed dramatically.
In Exchange 2007 and earlier versions, each database had a mailbox table (stored all mailboxes in the DB), folders table (stored mailbox folders for all mailboxes in the DB), message table (stored messages), attachment table (stored attachments for all mailboxes in the DB), and message/folder table (stored folder views for all mailboxes in the DB).
This architecture, which has not changed much since Exchange 4.0, meant that a lot of random I/Os had to be performed against the database. One of the benefits with this architecture was single instance storage. It was a great table architecture back when you had relatively small disks, but today, with 500GB SAS disks and 2TB SATA disks at our disposal, it does not make sense any longer.
In Exchange 2010, the store schema has changed so that all data in a mailbox have stored-in tables close to each other in the database. Actually, each mailbox has its own folder, message header, body, and its own view table. So, the concept of single instance storage no longer exists when it comes to Exchange databases. A side effect of removing SIS from Exchange was that a database was bloated by approximately 20%. Exchange PG found a solution to this by compressing the databases (more specifically message headers and text/HTML bodies). By giving each mailbox its own set of tables, most I/Os performed against a DB are now mostly sequential I/Os.
Other interesting changes that have been made in this area are that database space is allocated in a contiguous manner, database contiguity is maintained over time, the DB IO size has been increased from 8KBN to 32KB, and there is an improved async read capability. The Exchange PG is also working on increasing the cache effectiveness by changing the checkpoint depth to 100MB for HA configurations, using cache compressions and DB cache priority.
The result of all the changes made in Exchange 2010 is that we can expect an additional 70% reduction in I/O compared to Exchange 2007.
I only scratched the surface when it comes to storage optimizations in Exchange 2010 in this column. If you want a great insight with all the gory details on how storage was improved in Exchange 2010, I can highly recommend you grab a fresh cup of coffee and watch the recording of the Exchange 2010 Storage session Matt Gossage (Exchange PG responsible for ESE/DB) delivered at TechEd last week. It is a level 300 but although it is a complex topic, Matt does a great job of explaining it in plain English. Watch it here (you don’t need to have attended TechEd in order to watch it).”
Cheers,
Henrik Walther
Subhash Tiwari Says:
June 5th, 2009 at 8:25 pm
Hi Henry,
Tons of Thanx for sharing the usefull Exchange 2010 Database improvement features.
But i am still very curious to know what is the Maximum size of Exchange 2010 Database.
Please just share this information.
Regards,
Subhash Tiwari
Orient Technology Pvt. ltd
Henrik Walther Says:
June 5th, 2009 at 9:00 pm
Same as in Exchange 2007. Now we just have a 100DB limit in Enterprise edition.
See my E2K7 article here:
http://www.msexchange.org/tutorials/Exchange-2007-...s.html
Henrik
mcsebala Says:
September 24th, 2009 at 3:12 am
Dear HW
Why there is no exchange server 2010 32-bit version.
Tariq Jaber Says:
December 13th, 2009 at 2:14 am
Thanks dear Henrik fir this article.
If Exchange 2010 is to be streched to more than one site, say 4 (or more ) sites, and the main site will contain 2MBX and 2HUB\CA servers, each site will contain 1MBX\HUB\CA server. what is the best distribution of the databases among DAGs, and how many DAGs should be used.
I’m thinking of :
-One DAG with the members: main-mbx1, main-mbx2 and all the branches MBX servers. Contains the databases of the users mailboxes in the main site.
-Another 3 DAGs, one for each branch DB. But if the branch DAG contains both MBXs in the main and the branch MBX server, and the connectivity between the main and the branch dropped, in this case the branch mbx server will goes down! right?
I asked this in Technet Exchange Server 2010 Forums
I highly appreciate you help.
Alan Shaw Says:
January 11th, 2010 at 5:14 am
Hi Henrik,
Currently swatting up on Exchange functionality in order to design a system using 2 mailbox servers in a DAG. I was under the impression that precluded adding further roles to the hardware. In your article you state this can be done but I wondered if that is still the case. If so, assuming it is possible, would I then be able to cluster these roles. I say this tongue in cheek as I would have thought CAS\HT roles would need to use NLB.
Thanks for a very informative and thought provoking article.
Kind regards,