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.
Buy this article as PDF
(incl. VAT)
Buy ADMIN Magazine
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Most Popular
Support Our Work
ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.