EXCHANGE DAG: SET IT UP BEFORE A DISASTER TAKES YOU DOWN

Exchange database availability groups (DAG) have been around since Exchange 2010. So why are some admins under the impression they don’ need them? Some say, “I have Hyper-V replicas as my backup” or “Why the hell do I need another Exchange server to manage?” In some cases, I have seen an Exchange DAG save a customer when they lost a host and all the virtual machines on it or a physical Exchange server and the second copy kept them running. Others believe that an Exchange DAG is their backup and they don’ do Exchange backups. This is true if you have four copies or more — then you are more likely not to have backups.

Database availability groups are there to ensure you have high availability or resilience for your server. An Exchange DAG does not need to be kept in the same data center. You can have one copy in one data center and one in another and a third at the head office branch or a lagged copy in a remote location — it all depends on your business requirements.

This brings eight questions to many IT managers’ minds:

1.   Do I need to license it?

2.   Do I require more storage?

3.   Do I need to back up?

4.   What are the benefits?

5.   I have backups, so why do I need a DAG?

6.   I have Hyper-V replicas and they are clustered, so why do I need a DAG?

7.   I have snapshots of the server, so why do I need a DAG?

8.   Will this increase resource time to patch?

So, to answer the questions, let’s take a look at each one:

Licensing

Yes, you would need to license the second server but if you are a company that bought a volume license from Microsoft you can use one of those, or you would need to purchase another one.

Storage

Yes, you will require additional storage. It needs to be the same as what your current server is as the Exchange DAG is in a cluster and they have to match.

Backups

Most vendors today have the ability to back up Exchange DAG, meaning the software can check where the active copy is and back it up and this will truncate the logs. Question 5 above also touches on backups — yes you need to do backups unless you are running a 4-node DAG or higher. In that case, backups will be replaced by an option you turn on called circular logging in Exchange and Exchange will handle truncation of the logs.

Benefits of Exchange DAG

Imagine having a failure of a host or a storage node that cripples your environment with everything that runs on it but you have a DAG on another storage node. This means your users experience a brief drop but can carry on working vs. being down while you try and bring the failed host online. SLA will be higher and recovery time quicker. Win-win, right?

Maintenance is much easier as you won’ need to take down users for running Windows patches or cumulative updates as one node will be in maintenance mode while the other one is operational. Once you are done, you can switch and perform the same on the other server. You will meet the requirements for auditors in your environment.

You can maintain your SLA of 99 percent uptime if one data center drops because the other one will kick in. Email is one of the most critical applications in business today and in some companies has to be online all the time.

Hyper-V replicas vs. Exchange DAG

Many believe that because their hosts are highly available it means Exchange cannot go down. Unfortunately, if Exchange is on a 2-node Hyper-V setup and, for whatever reason, the VM cannot failover, you will have downtime.

Snapshots

This is a very interesting topic and its one where admins feel they have a solution if something goes wrong, whether it is a server that fails or a Windows update that causes the server to blue screen or you have a corrupt operating system. They believe they can lean on snapshots. But this is where you are wrong. Exchange writes data real-time along with Active Directory. Restoring a snapshot of Exchange to a point back in time means you will have data loss. It might look like the easy way out, but snapshots are not supported by Microsoft.

Remember, snapshots require space as well for you. Keep that copy, but this is not a solution.

Lastly, yes you have more servers to patch and patching does take up a lot of time, but if you are running an Exchange DAG, you can take down one node at a time and perform patches during the day without affecting users. Just take note that if you have a problem on the main server then you won’ have a failover as you will be busy patching. Organizations that are large tend to have three or four copies as the databases are big and the recovery time of these is hours, maybe days. If you have one of four copies down, it is easier to rebuild and a whole lot less pressurized as the organization is not aware of a failure.

On a final note, plan your next Exchange servers so that you have resilience in the org and don’ have the attitude of “it will never happen to me.” The day after a disaster is when you will think back and wish you had set up an Exchange DAG. But by then it’s too late.