How to Configure Database Availability Group for Exchange Server 2010
Overview
Because your end users rely so much on email not only for their day-to-day communications but also ultimately for your company’s daily operations, you need to make sure the services for Exchange are accessible and available practically all the time. In other words, they should exhibit High Availability.
In this article, we’ll talk about how Exchange 2010 offers High Availability, which is basically through Database Availability Groups. We’ll then come up with a sample scenario and then show you how to configure Database Availability Groups using that scenario. In the video lesson below you will learn about a real world scenario that will help you configure Exchange Server 2010 Database Availability Groups.
(Instructional video below provides a walkthrough of the steps contained in this article.)
If you’re already familiar with the concepts of Database Availability Groups and simply want to know how to configure them, just scroll down directly to the section A sample scenario.
High Availability in Exchange 2010
First of all, High Availability (HA) does not just mean that an Exchange server should be up. Rather, that server must also be available to serve. Simply put, users should be able to do all the things they expect to do through an Exchange service, e.g., send and receive emails, all the time.
Exchange 2010 provides HA using a feature known as Continuous Replication. In Continuous Replication, the database is copied first and then the log files are shipped and replayed constantly to ensure that the database stays up to date.
Figure 1: Shows System 1 and System 2
Database Availability Group and its main features
In Microsoft Exchange Server 2010, the base component of its high availability and site resilience framework is the Database Availability Group or DAG. DAG uses continuous replication, supports up to 16 copies of the database on 16 different servers, and employs some clustering features like heartbeats and a File Share Witness in order to make members of a DAG work together effectively.
Heartbeats
A heartbeat is a mechanism that enables servers to verify whether other servers in the same DAG are still alive. Let’s say you have two servers. One server has the active copy of the database, while the other one has a replica copy. If the second server no longer detects a heartbeat coming from the first server, it may have to take over and make its copy of the database the active copy.
File Share Witness
To help member servers of a DAG determine with certainty that a member has in fact gone down, Exchange Server 2010 uses what is known as a File Share Witness. A File Share Witness serves as the referee between DAG members whenever a server ceases to give off a heartbeat and hence appears to have gone down.
Thus, when the second server fails to receive a heartbeat from the first server, it checks with the File Share Witness to verify whether the first server has really gone down. Only after the File Share Witness confirms that the first server has gone down will the second server make its database the active copy.
This prevents an issue known as the “split-brain syndrome”, wherein two servers will be simultaneously providing the same services to end users.
The File Share Witness is a Hub Transport (HT) Server on the same DAG that shouldn’t reside on a Mailbox (MB) Server. That doesn’t mean that HT servers can’t be installed alongside MB servers. The restriction only applies to those HT Servers that will be used as a File Share Witness. All other HT Servers can reside on an MB Server.
Transport Dumpster
A typical DAG also employs what is known as a Transport Dumpster. It is a feature of the HT Server that allows it to retain copies of all emails in databases that have replicas in the DAG and provide an update to a replica copy whenever the need arises. An update to a replica copy of the data may be needed when a server holding the active copy of the database goes down.
So when the server holding the active copy goes down, the server assigned to take over checks with Transport Dumpster to see whether there are copies of mail that it doesn’t have. If there are any, those copies are added to what it already has.
Here’s a sample Database Availability Group containing two members, Mailbox1 (MB1) and Mailbox2 (MB2). MB1 holds the active copy of the data, while MB2 holds the passive copy. Also present is a Hub Transport Server that serves as the File Share Witness and Transport Dumpster.
Figure 2: Shows a Database Availability Group
What you need to know before creating a Database Availability Group
Having multiple Mailbox Servers and a Hub Transport Server that serves as a File Share Witness and a Transport Dumpster doesn’t automatically enable High Availability. You still need to carry out the following steps:
Step 1. Create the Database Availability Group
Step 2. Add members to the DAG
Step 3. Add copies of databases.
We’ll show you how this is done step-by-step later but in the meantime, here’s a figure showing a setup similar to what you may end up with after carrying out those steps:
Figure 3: Shows System 1, System 2, and System 3
In this setup, we have three Mailbox Servers (Systems 1, 2, and 3), each holding one database (DB1 resides on System 1, DB2, on System 2, and so on). Notice that each database is being replicated on the two other servers. So DB1 has a replica on System 2 and 3, DB2 has a replica on System 1 and 3, and so on.
So even if we lose two systems, the remaining system can take over; thus ensuring high availability. Note however, that it will be up to you to choose how many copies (and on which servers those copies should be) a database should have.
It is not necessary for all systems to have replicas of each database. It’s all up to you. Of course, the more copies your databases have, the greater your DAG’s capability of providing high availability will be.
Similarly, it is also up to you to decide how many mailbox servers should host a database. In the alternative design below, we again have three mailbox servers: EX2K10MB1, EX2K10MB2, and EX2K10CHMB. But notice that, while EX2K10CHMB has replicas of the databases hosted on EX2K10MB1 and EX2K10MB2 (DB1 and DB2 respectively), it is not hosting a database itself.
Figure 4: Shows No DB3 on Chicago site
Now that we’ve got the basic concepts covered, you’re now ready to learn how to configure DAGs.
A sample scenario
We’ll be using the following scenario as the basis for the configurations we’ll be setting later, so you should read this section first. Refer to the following figure:
Figure 5: Shows two sites: Site 1 in New York and Site 2 in Chicago.
Note: Those little light bulbs with a green leaf indicate virtual servers. So the Chicago site’s CHIDC1, EX2K10CHPRIME, and EX2K10CHMB are virtual servers running on a parent server through Hyper-V. Same is true with NYDC2, EX2K10PRIME, and EX2K10MB2.
In Chicago, EX2K10CHMB serves as that site’s Exchange Mailbox Server. In New York, there are two mailbox servers: EX2K10MB1 and EX2K10MB2. EX2K10PRIME is a Hub Transport Server. Notice that it doesn’t reside on a Mailbox server, so we can use it later on as our File Share Witness.
Our mailboxes are divided only between EX2K10MB1 and EX2K10MB2 (see the design on the fourth image above). The main function of EX2K10MB2 is to provide high availability as well as load balancing with EX2K10MB1, while the function of EX2K10CHMB (in Chicago) is to provide site resiliency for the New York servers in addition to providing HA.
If you notice, EX2K10MB1 is on a physical server, while EX2K10MB2 is on a virtual server. Had we placed EX2K10MB1 on another virtual server under the same parent server as EX2K10MB2, we would have only achieved disk resiliency but not server resiliency.
Server resiliency can only be achieved for EX2K10MB1 and EX2K10MB2 if they reside on separate physical boxes regardless whether they run on physical servers or virtual servers.
Moving forward, if all we want to achieve is server resiliency, then we would only need to add the two New York mailbox servers to the Database Availability Group that we will soon be creating. However, if we want to achieve site resiliency and high availability, the DAG should include all three mailbox servers, which is what we’ll be doing shortly.
Configuring Database Availability Groups
We’re now ready to start configuring our Database Availability Group. Just to see what you currently have, go to the Exchange Management Console, select the Mailbox node, and click the Database Management tab.
Figure 6: Shows if you select a database, you’ll see the Mailbox Server on which it is running off of.
Creating the Database Availability Group
Now let’s create our DAG. Go to the Database Availability Groups tab and, in the Actions panel, click the New Database Availability Group Wizard.
Figure 7: Shows were to click for the New Database Availabillity Group Wizard.
In the New Database Availability Group window, assign a name for the DAG (e.g. GloboHA). After assigning a name, you’re supposed to select a File Share Witness Server and Witness Directory. If you don’t select any, Exchange will try to find a server that can qualify. In our case we already have one that does: EX2K10PRIME.
So all we need to do is click on the New button and Exchange will do the rest. Do that now.
Figure 8: Click New.
Figure 9: Click Finish.
Navigate to the Database Availability Groups tab and scroll horizontally until you reach the column named Witness Server. You should be able to find your new Witness Server and Witness Directory in there.
Figure 10: Shows your new Witness Server and Witness Directory.
Since you now have a DAG, the next step is to add members to it.
Adding members to the Database Availability Group
On the same tab, scroll back to the left until you reach the column named Name. Under that column, find and right-click the name of the DAG you just created. When the context menu pops-up, click Manage Database Availability Group Membership.
Figure 11: Shows you where to click the Manage Database Availability Group Membership.
In the Manage Database Availability Group Membership window, click the Add button.
Figure 12: Click Add.
Select the servers you’d like to add to the DAG. In our case, because we want to achieve site resiliency and site High Availability, we would have to select all three servers (review the end of the Scenario section if you’re still wondering why). Click OK.
Figure 13: Click OK.
In the Manage Database Availability Membership window, you should see the servers you selected. Click the Manage button.
Figure 14: Click Manage.
Figure 15: Click Finish.
Back in the Database Availability Groups tab, you should now see a bunch of information under Networks.
Figure 16: Shows you’ve succeeded in adding members to your DAG.
You’re now ready for the final step, which is adding copies of your databases.
Adding copies of your databases
To start adding copies of your mailbox databases, go to the Database Management tab. Next, find a database you want to copy. In our example, the database is located in the EX2K10MB1 Mailbox Server.
Figure 17: Right-click on the database and, in the context menu, select Add Mailbox Database Copy
In the Add Mailbox Database Copy window, you should see the name of the Mailbox database you selected. Click the Browse button.
Figure 18: In the Add Mailbox Database Copy window click the Browse button.
Select a Mailbox Server you’d like to copy the database to. e.g. EX2K10MB2, then click OK.
Figure 19: You should see the Mailbox Server you just selected in the box labeled “Server name:”
Below that box, you’ll also see an Activation preference number. This number will be used by Exchange to determine when this particular copy should be activated. If the number is one, then it has top preference. 2 is the next, and so on. So if the copy with Activation preference number 1 goes down, the one with number 2 is next in line to take over.
Pick a number by using the spinner. In our example, we have 2. So that would mean EX2K10BM2 will only take over the reins once EX2K10MB1 goes down.
The moment we add a third copy and assign it a preference number of 3, that copy will only take over once EX2K10BM2 goes down as well.
Figure 20: Click Add.
If the screen says the wizard completed successfully, click Finish.
Figure 21: You will now see the newly added copy in the list of Database Copies for that particular database.
Figure 22: Click Finish.
You can do the same process all over again to create additional copies for the same database or create copies for another database. Again, you start by right-clicking the database you want to copy and then selecting Add Mailbox Database Copy in the context menu. In our case, we created another copy of the same database on the Chicago mailbox server (EX2K10CHMB), so this is what we have:
Figure 23: This is what it should look like so far.
If you scroll to the right, you’ll see the Activation preference numbers you assigned for those database copies.
To see what would happen if an active server goes down, you can simply go and shutdown your currently active mailbox server and monitor the entire event on one server’s Exchange Management Console.
Here’s how it looked like when we had two copies of the database (EX2K10MB2 and EX2K10CHMB) and we shut down EX2K10MB2, which initially had the active copy.
Figure 24: Shows how it looks when there are two copies of the database.
This happens so fast, that users would not experience any lack of availability. Well, that ends our discussion on High Availability and Configuring Database Availability Groups.
Summary
I’m sure you found this article quite long. Still, I hope you found it all worth the read. Ensuring High Availability for your Exchange Server is well worth the work.
See you again next time.