Microsoft Exchange Server related News and Articles

Database Availability Group is the new cluster concept of Microsoft Exchange 2010. In other words DAG is the answer for Exchange 2010 database high availability. In this post I am trying to give you more insight about the Database Availability Group concept of Exchange 2010 and will try to clarify the queries as much as possible even though I know it is really not possible to cover every features of DAG in a post.

Before get into the feature of Database High Availability, let me tell you few more information about DAG. A Database Availability Group is a set of up to 16 exchange 2010 mailbox servers which gives automatic database-level recovery from a Database, Server or Network failures. DAGs are similar to Exchange 2007's SCR and CCR technologies, but mixed together, along with a few benefits.

• Incremental Deployment:- You don't require to plan the numbers of server for DAG clustering, as an when you feel you can add more servers into DAG membership. This means if you want to deploy a DR server as a part of your production DAG it is all easy.
• Continuous Mailbox Availability:- Failover of the Databases are managed within the exchange servers
• Database Mobility:- Databases are no longer associated with a server object, where as it is an organization level entity(flattened schema).
• Backup-less Organization:- If you plan your DAG implementation, you never require to restore the database from a backup. You can even create lagged database by specifying truncation log for up to 14 days. This will help us in maintaining an old database copy.
• Self Healing Database copies:- The database errors are corrected automatically.
• Online Mailbox Moves:- You do not require to inform a user before you initiate the mailbox movement. The mailboxes can be moved online, because it basically creates a copy and then links into it.

This is not the end, there are more features which you will find very interesting such as Co-existent with other roles, Switch/Failovers are much faster, DAG members can be in separate AD sites etc.

The public folder database is not supported by Database Availability Groups.

Below figure gives you a typical DAG overview.

The CAS server re-directs the client requests to the respective Mailbox Databases as shown in the above figure. The database copies are kept in different databases, for e.g. the DB2 is active on the server Mailbox Srv3 and also have a copy of it on different servers(Mailbox Srv1, Mailbox Srv5). The server Mailbox Srv-DR is in a different AD site, however it is still a part of the Database Availability group.

Requirements to Configure DAG

• General Requirement
  
  • Member must be in same AD domain
  • Not supported for mailbox role on AD Server
• Hardware requirement
  
  • No special hardware requirement different from mailbox server role
• Software requirement
  
  • Require WFC(failover clustering)
  • All the member of a DAG should run the same version OS
• Network
  
  • No special requirements, same as previous installation

Switch Over and Failover of Mailbox Databases in DAG:

The server that holds the active copy of database called as the database master. When an administrator moves the active copy from one DAG member to another member is called the database switchover, whereas when an automatic movement happens for database due to the unavailability of active database is called as failover.

Switchover allows the administrator to plan for maintenance on one of the DAG members and also helps in load balancing the active databases across the DAG members.

I will cover more about the DAG configuration and the DAG replication details in coming posts.

Ref - Managing High Availability

-Praveen