Configuring Database Availability Groups in MS Exchange 2013

“Explore the world of high availability”

In today’s world we completely rely on e-mail as a major communication tool. What good is it if we don’t have the data available at the time of our need?
Database Availability groups are managed to safeguard communication data stored at Microsoft Exchange server.

What Are Database Availability Groups?

Exchange Server resolved all the problems related to data availability during disaster by creating Database Availability Groups. They consist of a highly available database that fail proofs loss of data, during an external or internal calamity. DAG makes the data available to almost every server or client present in the Group. DAG collectively works with other servers to provide complete and automatic recovery of databases.

What are Database Availability Groups?

Exchange Server resolved all the problems related to data availability during disaster by creating Database Availability Groups. They consist of a highly available database that fail proofs loss of data, during an external or internal calamity. DAG makes the data available to almost every server or client present in the Group. DAG collectively works with other servers to provide complete and automatic recovery of databases.

Database Availability Group

If we take a look back at the previous versions of the Microsoft Exchange Server attempts were made to make the data available during a disaster. Replication methods such as LCR, SCC, CCR and SCR provided somewhat access to old data during a disaster, but replica availability was scarce. Hence, they couldn’t provide automatic recovery of mailbox data from disaster.

Database Availability Group feature was available in Exchange 2010 and above versions. Now, it allows 2 to 16 replicas per database .With this; a user can easily achieve high availability and would be trouble free during a disaster. DAG provides a combined, onsite and offsite replication feature.

Creating a Database Availability Group:

Database level recovery is ensured for every mailbox when added to a Database Availability Group. It could be recovered from a network, server or database failure.
As discussed earlier, we need DAG to create a replica of our client’s mailbox data and therefore we need two network interface controllers one for current access and the other; completely dedicated to make replica. Microsoft supports one NIC (Network Interface Controller) but, it is recommended to separate replication traffic from client traffic. As, if replica managers utilized the same protocol then we would affect the client experience and cause utter chaos.

Backup & usage Network Connections

Here we have placed two NICs:
It is meant for client end communication.
It is the replication network for DAG.

NOTE:You should have sufficient permissions to perform this procedure. If you have multiple servers running Windows Server 2012 then, you need to pre – stage the Cluster name object, before adding members to DAG.

Database Availability Group can be created using the following methods:

Using Power Shell:

• This example creates the Database Availability Group DAG1 that's configured to use the witness server REPL and the local directory C:\DAG1.It uses DHCP as an IP addresses.

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer REPL -WitnessDirectory C:\DAG1

• This example creates the Database Availability Group DAG2DAG2 is assigned a single static IP address because in this example all DAG members have the MAPI network on the same subnet.

New-DatabaseAvailabilityGroup -Name DAG2 -DatabaseAvailabilityGroupIPAddresses 10.0.0.8

Ø Using Exchange Administration center:

Open EAC and then navigate to Servers->Database Availability groups.

Click on the add icon and create a new DAG.

Exchange Admin Center

Provide the following information:

Group Name: Ensure that the group name is unique. As soon as you join the DAG Cluster Name Object; CNO would be created in the Active Directory. It is highly recommended that you pre-stage CNO if you have Windows Server 2012 as it has changes in granting permissions.

Witness Server: It is an optional mirror server to support high availability and protects the DAG from automatic fail-over. If you do not have a witness server then Exchange chooses Client access Server in that site.

Witness Server

Points to remember while adding a Witness Server :

Witness Server is established to maintain a quorum for example :

  We have two host sites connected

   

Consider a situation where Network communication is lost between Host-A and Host-B
 

ü DAG sees that only 50% or 3 out of 6 are online so DAG discontinues staying online.
 o   The servers in Host-A dismount all databases.
 o    The servers in Host-B dismount all databases.
 o   Finally all users are offline.

Now, let's introduce a Witness

Again, we have the same scenario

 

We have a Witness on a hub transport server, making up the 7th "member" of the DAG's majority node set.

Introduction to Witness Server

Now again network communication is lost between Host-A and 

Host-B
ü Host-A sees 3 nodes go offline in Host-B and only know its own 3 nodes are online plus the Witness.
ü Host-B sees 3 nodes go offline in Host-A along with the Witness and only knows its own 3 nodes are online.
ü We have 57% a majority node set in Host-A.
ü No changes are made in Host A.
ü Host –B dismounts all the databases due to minority.
ü Hence we get majority databases online and the backup of the Host which is down.

NOTE: Add Witness Server only when the number of databases connected are even.
Database Availability Group IP Address:
§  Here we have to mention the “Static  IP address” to be used by the DAG.
§  If you leave it empty, it automatically assigns DHCP
§  We can also enter 255.255.255.255 , this creates a DAG without an IP address or cluster administrative access point

Click on “Save “ button to finalize and create a new DAG.