The ‘replication’ feature from Microsoft Exchange Server enables high availability for Exchange Server data. With replication, a duplicate copy of the database is stored at a remote location, and data from this database can be used in the course of planned or unplanned downtime. However, this feature is useful only when it runs without issues. Exchange is one of those applications that no matter how many times you have worked on it, every time you are surprised with a new kind of issue. Even worse, if issues pop up during replication, this feature used for high availability may turn out to be a headache. The discussion further is about Database Availability Group (DAG) mailbox database replication and factors to be taken care to avoid these issues.
Let us see what “DAG mailbox database replication” is and then move on to aspects that can be validated to avoid issues. Mailbox databases can be duplicated on up to 16 servers, provided these servers are in the same DAG. What is a DAG? A DAG is a collection of mailbox servers that host a set of databases. The DAG provides automatic database recovery thus increasing high availability of mailbox databases in the Microsoft Exchange Server. Let’s see an example of mailbox database replication. Consider four Exchange Server mailbox servers, each configured with a single mailbox database and each of these servers is a member of the same DAG.
When a server is taken down for maintenance or if a server crashes, the requests from that mail server are automatically redirected to the server housing the backup database, and thereby cause no impact to the mailbox users.
For example, when mailbox server 2 goes offline, database 4 will be disconnected from the DAG, because database 4 is the active database on mail server 2. Thus the database 4 from a different mail server (which was passive) will become active.
The component known as Active Manager manages automatic recovery and failover of the databases. Active Manager achieves this using one of two different roles, Primary Active Manager (PAM) and Standby Active Manager (SAM). The PAM is accountable for responding to server failure and controls all movement of active designations between database copies (only one copy of the database can be active at any moment). The SAM will access the active database to answer the queries it receives.
What are the general requirements for DAG mailbox replication to avoid replication issues?
- All mailbox servers should be in the same Active Directory domain.
- The round-trip latency between mailbox servers must be less than 500 milliseconds to ensure reliable replication.
- Ensure that each server in the DAG can communicate with each other. Even a firewall can break this communication and cause replication failure.
- Verify that the Domain Name System (DNS) is working. I.e. The name of the DAG should be registered in the DNS and should be solvable in the network.
- Confirm that all the servers in the DAG are running the same OS and all are on the same version of Exchange Server (a mailbox database running on Exchange Server 2013 cannot be replicated to a server running on Exchange Server 2010).
Your task is not done once you have set the replication for high availability. As an administrator you should make sure that the exchange server’s mailbox replication stays up and running. For this proactive monitoring is mandatory.
Some factors to be monitored are given below and this helps you to ensure that the mailbox server’s replication is operating as it should be:
- Only a single instance of a database copy will be active across all members of the DAG. It is advisable to monitor the active and passive copies of that mailbox’s databases. This also helps the exchange administrator find which Exchange Server has the Active Copy for any given Mailbox Database.
- Replication factors like Active Manager, Cluster Service, Replay Service etc. need to be monitored to check on the health and status of DAG mailbox database replication.
- The size of all Mailbox Databases running on the Exchange Server, and the amount of white space contained in the database should be observed as well. This helps find free space remaining on the volume where the databases reside.
Once you have a monitoring tool which can observe the above mentioned factors, you are all set to go! Make sure you monitor your Exchange Server and its performance along with the mailbox database replication.
To learn how you can get proactive insights to pinpoint Exchange issues, please join the SolarWinds Head Geeks for a special Labs episode on monitoring Exchange on March 19th, at 1 p.m. CDT.
Praveen is a Head Geek at SolarWinds, a global IT management software provider based in Austin, Texas. He has seven years of IT industry experience in roles such as Support Engineer, Product Trainer and Technical Consultant, and his expertise lies in technologies including NetFlow, Flexible NetFlow, Cisco NBAR, Cisco IPSLA, WMI and SNMP. Praveen gives strategic guidance for end users on applications, networks and performance monitoring tools.