Database availability groups – High availability with Exchange Server 2012
Safe Domicile
If you want to keep your Exchange databases in sync across multiple servers, you can do this with database availability groups (DAGs) – even without a cluster configuration. However, DAGs use components of the Windows Server 2008 R2/2012 cluster functionality to replicate Mailbox Databases. For this reason, you must use the Enterprise Edition of Windows Server 2008 R2 or the Standard or Enterprise version of Windows Server 2012.
DAGs are also possible with the Standard Edition of Exchange 2013. DAGs are therefore an excellent means of implementing highly available Exchange databases without a complex Exchange 2013 configuration, even for smaller companies and public folders.
Understanding DAGs
Databases are replicated between servers via transaction logs. Because the Exchange databases in Exchange 2013 have a unique name in the organization, you can use Mailbox copies in a DAG to copy all production databases to all Mailbox servers, enabling them as needed. In case of a failure, you do not have to move the entire Exchange server to another cluster node.
Exchange 2013 uses a fixed TCP port for the data exchange. Active transaction logs from the production Exchange database send a data stream to the passive copies; the stream is encrypted and compressed. Exchange 2013 can use the production database, or a different Mailbox Database copy, as a source for replicating data. Both editions of Exchange 2013 support high availability of DAGs. You can even mix editions in a DAG.
Database availability groups are created either in the Exchange Management Shell or the Exchange Management Console. In the shell, you need to work with the New DatabaseAvailabilityGroup commandlet. In the Exchange Management Console, the settings are accessed by selecting Server | Database Availability Groups. A DAG is initially an empty object in Active Directory. When you add the first server to the DAG, Exchange automatically creates a failover cluster for the DAG. The DAG has a unique name and a static IP address. The DatabaseAvailabilityGroupIpAddresses option also lets you assign multiple IP addresses to a DAG. If you assign a value of 0.0.0.0 to this option, the DAG uses DHCP for the IP addresses.
The Add-DatabaseAvailabilityGroupServer commandlet adds Mailbox servers to the DAG. The cluster service registers IP addresses for the cluster in DNS. Administrators and receivers do not need to open a connection to the name or IP address of the DAG. This data is only for internal replication. If you add further servers to the DAG, they automatically join the cluster. After adding members to a DAG, you can replicate the Mailbox Databases on each server to other DAG members.
For a DAG cluster, Exchange also uses another server on the network that stores a folder containing the cluster data. This server (known as the witness server) is not part of the cluster but is logically located outside the cluster. The share is known as the File Share Witness and is used to secure the flow of data between the cluster nodes.
Creating and Deleting
When you create a DAG, you must specify the group name and an IP address that you are assigning to it. After creating a DAG, you can use the Set-DatabaseAvailabilityGroup commandlet to modify the settings. In the Exchange Management Console, the DAG controls are accessed via Server in the Database Availability Groups menu (Figure 1).
If you use IPv6 in the enterprise, the new database availability group wizard tries to assign an IPv6 address. If the witness server is not an Exchange server, you need to add the Windows Exchange Trusted Subsystem group to the Local Administrators group before you create a DAG.
However, the same operating system version must be installed on all servers. You cannot use servers running Windows Server 2008 R2 and Windows Server 2012 simultaneously in a DAG. The witness server for the DAG cluster is allowed to run another operating system, however.
In Exchange 2010, specifying a witness server is optional when creating a DAG, but in Exchange 2013, this is mandatory. If you do not want to use the Exchange Management Console, but the Exchange Management Shell, to create a DAG, use the command shown in Listing 1. If you want to delete a DAG, you must first delete the Mailbox Database copies in Exchange Management Console using Databases in the Server menu.
Listing 1: Creating a DAG
New-DatabaseAvailabilityGroup -Name <DAG> -WitnessServer <FileShareWitnessServerName> \ -WitnessDirectory <NonRootLocalLongFullPath> -DatabaseAvailabilityGroupIpAddresses <IPAddresses>
After accessing the properties of the DAG in the Exchange Management Console, you can configure settings via the menus. Exchange stores the DAG properties in Active Directory. The General menu shows you the members of the DAG, the DAG witness server, and the DAG folder. You can use Manage Database Availability Group Membership to specify the servers on which you want to protect databases with DAGs.
The Set-DatabaseAvailabilityGroup -Identity DAG commandlet also lets you modify the settings for the DAG. The same options as for creating the DAG are available here. The Get-DatabaseAvailabilityGroup <DAG-Name> **| fl commandlet shows the settings for a DAG. Get-DatabaseAvailabilityGroup <DAG-Name> **| fl returns the list of all DAG members (Figure 2).
DAG Members
The next important step when using DAG is adding members to the group. The members are servers with the Mailbox role that replicate the databases on this server via DAGs. Exchange adds each server that is a member of the DAG as a cluster node to the underlying Windows cluster. You can also remove servers from the properties of a DAG. First, however, you need to remove all replicas of the database from the server.
Besides the Exchange Management Console, you can also use an Exchange Management Shell commandlet to add servers to a DAG:
Add-DatabaseAvailabilityGroupServer -Identity <DAG> \ -MailboxServer <Servername>
To remove a server from its DAG with the Exchange Management Shell, use the following command:
Remove-DatabaseAvailabilityGroup -Identity <DAG> \ -MailboxServer <Servername>
If a server is no longer available in a DAG, you can restore it through the Exchange Setup program. To do so, proceed exactly as for the restoration of a normal server and then check whether replication is working. You might have to stop replication on the other servers and manually add the server to the DAG and the Mailbox copies.
Microsoft recommends that you load-balance the traffic for replication and user connections with multiple network cards, which you can define when you create the DAG. Alternatively, DAGs can also be used on servers with only one network card. In this case, however, all the DAG members are only allowed to use one network card. The total number of network connections must be identical for all DAG members. DAG networks support IPv4 and IPv6. If you use IPv6, you must not disable IPv4, however.
You can create a DAG network to replicate the data in the Exchange Management Shell using the command shown in Listing 2.
Listing 2: Creating a DAG Network
New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup <DAG> \ -Name <NetworkName> -Description <NetworkDescription> \ -Subnets <DatabaseAvailabilityGroupSubnetId> -ReplicationEnabled $true
To retrieve the settings or change them retroactively, use the commandlets Set-DatabaseAvailabilityGroupNetwork and Get-DatabaseAvailabilityGroupNetwork. You will find your DAG networks in the Exchange Management Console in Database Availability Groups after selecting Servers. After clicking on a DAG, you can see the connected networks on the right.
A DAG is initially an empty framework. The DAG only becomes active when you add servers as members and replicate the databases of these Mailbox servers. Mailbox database copies are replicas of the Mailbox Databases on the various members of the DAG. Exchange handles replication on the basis of the transaction logs.
Setting Up Mailbox Database Copies for DAG
You can only create database copies on Mailbox servers that do not host the production copy of a database. You cannot create two copies of the same database on the same server because all copies of a database on all servers use the same path. Up to 16 copies of a Mailbox Database can be created on different Mailbox servers. You cannot create a database outside of a DAG or replicate an Exchange 2013 Mailbox Database on an Exchange 2010 server or earlier. You can create database copies using either the Exchange Management Console or the Add-MailboxDatabaseCopy commandlet in the shell.
When you create a copy, you also specify a time period for the replication delay in the transaction logs. A value of 0 disables the log replication delay. In this case, Exchange immediately transfers a transaction log after its completion to the copy server so that the database copy is always at the same level as the original. The activation preference number is used as the decision-making basis for activating the database. In a failure scenario, if Exchange detects that multiple database copies meet the same activation criteria, Exchange uses the copy with the lowest activation preference number.
The active copy of the database must be provisioned. No copy of the database may be located on the specified Mailbox server. The path for the specified database copy and its logfiles must be available on the selected Mailbox server. The server hosting the active copy and the server that will host the passive copy must be in the same DAG.
To make a copy, open the Exchange Management Console and navigate to Servers | Databases. Select the database, click the …, and choose Add database copy. This option is only available on the server that hosts the active database (Figure 3).
Seeding
Once you have saved the configuration, Exchange begins with seeding. The data from the source database are transferred to the database copy. If you want to make a copy in Exchange Management Shell, use the following command:
Add-MailboxDatabaseCopy -Identity <Database> \ -MailboxServer <TargetMailboxServer> \ -ActivationPreference<ActivationPreferenceNumber>
After starting the copy, you can see its status in Servers | Databases on the right-hand side when you click on the database. The event log lists any errors that occurred.
The Get-MailboxDatabaseCopyStatus commandlet lets you view the replication status for the database copy in the Exchange Management Shell; the Test-ReplicationHealth commandlet shows you the status of the database availability group and the replication. Again, no errors should occur here. If you switch to the script folder for Exchange 2013 Exchange Management Shell C:\Program Files\Microsoft\Exchange Server\V15\Scripts), you can enter .CheckDatabaseRedundancy.ps1 to test the replication.
If you want to remove a Mailbox Database copy, click on the database and select the Remove command for Passive in the right pane of the console. In the Exchange Management Shell, use the following command:
Remove-MailboxDatabaseCopy \ -Identity <DatabaseCopy> -Confirm:$False
You can disable copy operations for replication temporarily. In this case, the configuration is kept, but Exchange no longer copies data from the production database to the copy. Your best bet is to perform these operations in the Exchange Management Shell using the following command:
Suspend-MailboxDatabaseCopy -Identity <DatabaseCopy> \ -SuspendComment <Comment>-Confirm:$False
Resume-MailboxDatabaseCopy continues replication. In the Exchange Management Console, click on the Stop link for this operation after selecting the database copy on the right-hand side of the console. You can manually trigger a replication with Update-MailboxDatabaseCopy.
Switchover
When you activate a passive Mailbox Database copy, you promote one of the Mailbox Database copies you created to the production database; in future, your users will work with this database. The previous database then becomes a passive copy. Microsoft refers to this process as a switchover.
Navigate to Servers | Databases in the Exchange Management Console. Click on the passive Mailbox Database that you want to use as a production database in the future. Click on Activate. Under certain circumstances, logged in users may need to log in again in the Outlook Web App (OWA) or restart Outlook to restore the connection.
If servers fail, or even an entire data center, you can make the Exchange infrastructure available again by switching over servers or entire data centers. In the case of a server switchover, you can switch all the active Mailbox Databases on the current Mailbox server to one or multiple Mailbox servers with appropriate Mailbox Database copies.
To perform a server switchover, use the Exchange Management Console (Figure 4). Navigate to Servers, select the desired Mailbox server, on which the productive databases are currently stored, and click on the server. Then, select Server Switchover. You can then leave the choice of which Mailbox Database copies are activated on the various servers with the copies to Exchange or manually select a target server on which Exchange will – in future – use the Mailbox Database copies as its production databases.
You can also do this in the Exchange Management Shell using the following commandlet:
Move-ActiveMailboxDatabase -Server <SourceMailboxServer> \ -ActivateOnServer <TargetMailboxServer>
DAGs have a special mode for data centers that is disabled by default. It is useful if you are running larger DAGs that are distributed over different Active Directory sites. You can enable data center mode in the Exchange Management Shell with the Set-DatabaseAvailabilityGroup commandlet, as follows:
Set-DatabaseAvailabilityGroup -Identity <DAG> \ -DatacenterActivationMode DagOnly
The DAG members in the primary data center must be marked as stopped to avoid accidentally provisioning the databases. To do this, you need to use the Stop-DatabaseAvailabilityGroup with the ActiveDirectorySite option for the site. You need to run the Stop-DatabaseAvailabilityGroup commandlet on all servers at the primary data center.
At the second data center – the standby center – you need to find out which servers were stopped at the primary data center. To do so, again use the Stop-DatabaseAvailabilityGroup commandlet with the ConfigurationOnly and ActiveDirectorySite options using the name of the Active Directory site with the failed primary data center as the value.
Conclusions
All in all, the use of DAGs is not a complicated matter. Companies that use more than one Exchange server should use the function to provide failsafes in the enterprise. The setup is quick, whether you use the Exchange Management Console or the shell. However, these copies can never replace a professional data backup.