An Exchange Server database administrator aims to maintain high-availability of data that a user saves in his mailbox. Amongst the various tasks that a DBA performs in order to manage Exchange database, maintaining high availability of mailboxes is the most challenging one. As versions of Exchange Server improve, new technologies for availability have been introduced by Microsoft that has proved quite effective. In this segment, we will discuss high-availability of Exchange 2010 mailbox database using the Database Availability Group (DAG) technique.
Earlier to Exchange 2010, there was facility to cluster mailbox Servers using Continuous Replication technique where transaction log from active database to passive database are copied. In Exchange 2010, continuous replication has improved in the form of DAG.
A DAG is a group of mailbox Servers (a maximum of 16) that shares replica of a mailbox database. One Server has an active copy of database while another has passive copy of same database over one or more Servers installed with Mailbox Server Role . All copies of DBs (active and passive) are kept in sync through log shipping.
The basis of Exchange 2010 DAG technology is Windows Failover Clustering (WFC). Nevertheless, there is a difference between general concept of WFC; instead of entire cluster failover to passive node, here a mailbox database can failover with DAG database without worries about other DAG members.
In Exchange 2007, the concept of Windows Failover Clustering (WFC) was used in the backend. DAG uses some of the components of WFC like Heartbeat, cluster DB, and cluster network. The failover between DAG members is managed by Active Manager.
"In Exchange 2010, a new element called "Active Manager" has been introduced. Earlier, Cluster Resource DLL (exres.dll) was used for clustering Servers while in Exchange 2010; Active Manager is being used in order to manage switchovers and failovers of mailbox Servers that are a part of DAG. There are two types of Active Managers: Primary Active Manager (PAM) and Standby Active Manager (SAM)."
Since Windows Failover Clustering is the backend technique for DAG, the concept of Quorum applies here. If you are new to it, then just consider it like a voting process where odd numbers of voters should be available so that a decision is made with majority. When we link this concept with clustering, it means odd number of Servers must be available in order to decide (with majority) as which passive copy of mailbox database should be activated when active copy fails.
If there are two Servers (or any even number counting to 16) under DAG, then none of them will be able to decide as which one should make its copy of database active. In order to attain Quoram for DAG that has even number of mailbox Servers, assign additional Server in same site that will work as File Share Witness for the cluster. This job is generally performed by Hub Transport Server.
Database replication amongst DAG members takes place through Continuous Replication mode which is further divided as:
File Mode replication is used in Exchange Server 2010 RTM where a log file is shipped and synced with passive copy of database once it is full (1MB). This type of replication service works fine but has a drawback that until the log file is full; the transactions will not be committed and replayed to the passive copy database. It means if active DB failure happens; the data in log that have not been shipped to passive copy Server will be lost. In such scenarios, the DAG member can send a request to the Hub Transport Server in the site to resend all mails from the transport dumpster.
Meanwhile, in Exchange Server 2010 SP1, Block Mode replication is used where log file updates once written to the active database is immediately copied to passive mailboxes. In this case, update in transaction log will be written to the log buffer of active database and is then shipped to the log buffer of passive database. Once the log buffer of passive mailbox is full, database is build and new log file generation gets started. This means if active DB failure occurs, the most updated copy of mailboxes is available in the form of passive copy.
DAG in Exchange 2010 can be created either by using Exchange Management Console (GUI) or Power Shell cmdlets (Command-line interface) and then required mailbox Servers are added to them. Servers that become a member of DAG host a passive copy of active database and the entire process of log shipping is being protected by Network compression and encryption services. However, it is recommended to create a different network for log shipping and DB replication as a lot of network bandwidth is being consumed which could result in network overloading. A unique IP address is delegated to DAG and when a Server is added to DAG, its DAG object is added into Active Directory.
Here, we have three Servers:
Note: Please ensure that within an organization, every mailbox database is has a unique name.
Since the Servers in example are configured with primary and secondary interface, it is necessary the secondary interface do not register itself with the Domain Name System. For this:
Open TCP/IPv4 properties for secondary interface and click on "Advanced" button.
Under the DNS tab, move down to disable the check box for "Register this connection's address in DNS"
Open Exchange Management Console by logging in to any of the mailbox Server. Move to Organization Config/Mailbox and then select New Database Availability Group from the actions panel at top-right of the screen.
A new dialog box named New Database Availability Group will get opened. Here, define name of name of DAG, the Witness Server, and the file path for Witness Server.
Click on New button for DAG creation and click Finish to exit the Wizard.
In Exchange Management Console, right click the newly created DAG and select Manage Database Availability Group Membership.
Click on "Add" button to select the mailbox Servers that are to be a part of DAG.
Now right-click on newly created DAG and then drop down to "Properties"
In the IP Address tab, click on Add button to select IP for DAG (make sure that a static IP is provided).
DAG will be configured with DAG networks for subnets that members added to the DAG have interface connected to.
When DAG is established and is configured with network, the next step is to ad mailbox database copy to the DAG Servers.
Click on Browse button to select the DAG Server in which mailbox database should be copied.
Click on "Add" button to copy active database into passive copy of database. Click Finish to exit the wizard.
In routine, we prefer to make a copy of our crucial data so that if anything goes wrong, backup is available to provide redundancy. Similarly in case of Exchange database, there is facility called Continuous Replication that allows maintaining a second copy of mailbox database of production Server on different Server/disk. So, if anything goes wrong, this alternate copy acts as a savior against corruption, failure or loss of DB of production Server. Here, in spite of wasting time in restoring DB from tape backup , the second copy of database is activated and is converted into production database within few minutes.
Introduced in Exchange 2007, this Continuous Replication used Log Shipping technique where an automatic replication of log files from active database (DB on production Server) to passive database (copy of DB located on different Server (CCR) or disk (LCR)) takes place. When log files are copied to the passive database, they are replayed against it so that both the DB's remain in sync.
In Exchange Server 2010, CCR and SCR are collaboratively used to give DAG a high-availability base component. Also, failover takes place at database level rather than Server level which means less time consumption to resume the services.
Failover: A failover is an unanticipated event that can cause termination is service or the data. This involves automatic recovery from failure by activating passive DB copy as production Server.
