Exchange 2010 Database Availability Group Installation
Thanks Paul Cunningham
Microsoft Exchange Server 2010 introduced a new high availability feature called the Database Availability Group (DAG). This tutorial describes how Database Availability Groups work in Exchange Server 2010, as well as demonstrating the steps for deploying a DAG using Exchange Server 2010 SP1 and Windows Server 2008 R2.
For example, a Database Availability Group may consist of three Exchange Server 2010 Mailbox servers, each configured with a single Mailbox database. Each server that is a member of the DAG can host either an active or passive copy of each of the three total mailbox databases.
The foundation of an Exchange Server 2010 Database Availability Group is Windows Failover Clustering. However unlike traditional Exchange server clusters which existed in an active/passive state, and in which the entire cluster group needed to failover to an alternative node together, with Exchange 2010 DAGs each mailbox database can failover (or switchover, if it is a deliberate move) to another DAG member independent of the other mailbox databases in the DAG.
This means that any given Mailbox server in the DAG can host all, some or none of the active mailbox copies at any given time. This capability provides two immediate advantages over previous clustering models:
For a cluster this means that an odd number of members must be involved in the voting process for a majority decision to be made. How this applies to an Exchange Server 2010 DAG is that if you deploy a DAG with just two Mailbox servers as members (or any even number up to 16), then neither server is able to determine by majority vote whether it should make its own copy of a given mailbox database active.
To achieve quorum for a DAG with an even number of member servers another server in the same site is designated as a File Share Witness for the cluster. This is typically a Hub Transport server though it can technically be any compatible Windows server.
In Exchange Server 2010 RTM “file mode” replication is used. With file mode replication as each transaction log is written and then closed off (once it reaches 1Mb in size) it is then copied to each member of the DAG that also holds a copy of that mailbox database. The other members receive the file into their replay queue, and then replay the transaction log file into their own passive copy of the database.
File mode replication works fine but has an obvious shortcoming in that any transaction logs that have not yet been shipped to other servers in the DAG can be lost if the Exchange server hosting the active database copy fails. In those cases one of the other DAG members is able to bring their copy of the mailbox database online and then request missing emails be resent from the transport dumpster of Hub Transport servers within the site.
In Exchange Server 2010 SP1 file mode replication is used to bring mailbox database copies into sync with each other (eg during the initial sync process when a new database copy is added). Once they are in sync the DAG members switch to “block mode” replication. In block mode replication each database transaction is written to the log buffer on the active server and also sent to the log buffer of DAG members hosting passive copies of the database.
When the log buffer becomes full each DAG member then builds their own transaction log files from their own log buffer. Block mode replication has an advantage over file mode replication in failure scenarios, because each DAG member is completely up to date with all changes to the active database.
Note that Public Folder databases can reside on Mailbox servers that are members of a Database Availability Group, however they are not replicated by the DAG itself. Instead you must use Public Folder replication to provide redundant copies of Public Folder databases.
For this tutorial the following Exchange servers have already been installed.
Each of the Mailbox servers has been configured with its own mailbox database.
Because the Mailbox servers are configured with dual interfaces it is important to make sure that the secondary interface is not configured to register itself in DNS.
Open the TCP/IPv4 properties for the secondary interface one each server, click the Advanced button, navigate to the DNS tab and untick Register this connection’s address in DNS.
Open the Properties of each DAG network and configure them with meaningful names. If you have configured your network to have a dedicated replication network for the DAG then you should disable replication on the DAG network that is intended for MAPI communications (ie client connections).
In the Exchange Management Console navigate to Organization Config/Mailbox and choose the Database Management tab. Right-click a mailbox database and select Add Mailbox Database Copy.
Click the Browse button and choose the Mailbox server to add the database copy to.
Click the Add button to add the mailbox database copy and then click Finish to close the wizard.
The Exchange servers will now commence seeding the replica servers with an up to date copy of the database and all of the current transaction log files. Depending on the amount of data to be replicated this may take some time.
Repeat the same process for any other mailbox databases you wish to add database copies for.
Configuration of the Exchange Server 2010 Database Availability Group is now complete.
Microsoft Exchange Server 2010 introduced a new high availability feature called the Database Availability Group (DAG). This tutorial describes how Database Availability Groups work in Exchange Server 2010, as well as demonstrating the steps for deploying a DAG using Exchange Server 2010 SP1 and Windows Server 2008 R2.
Exchange Server 2010 Database Availability Group Overview
A Database Availability Group is a group of up to 16 Exchange Server 2010 servers that are installed with the Mailbox server role. Each server that is a member of the DAG is capable of hosting active or passive copies of mailbox databases that reside on servers in the group.For example, a Database Availability Group may consist of three Exchange Server 2010 Mailbox servers, each configured with a single Mailbox database. Each server that is a member of the DAG can host either an active or passive copy of each of the three total mailbox databases.
The foundation of an Exchange Server 2010 Database Availability Group is Windows Failover Clustering. However unlike traditional Exchange server clusters which existed in an active/passive state, and in which the entire cluster group needed to failover to an alternative node together, with Exchange 2010 DAGs each mailbox database can failover (or switchover, if it is a deliberate move) to another DAG member independent of the other mailbox databases in the DAG.
This means that any given Mailbox server in the DAG can host all, some or none of the active mailbox copies at any given time. This capability provides two immediate advantages over previous clustering models:
- All of the Mailbox servers within the Exchange 2010 DAG can be active and in use at all times to some capacity
- Each mailbox database can failover/switchover when necessary without impacting the mailbox users connected to other mailbox databases within the DAG, for example when installing updates on DAG members
Understanding Quorum for Exchange Server 2010 Database Availability Groups
Because the Database Availability Group utilizes an underlying Windows Failover Cluster the concept of quorum applies. If you are not familiar with quorum consider it as basically a voting process in which a majority of voting members must be present to make a decision.For a cluster this means that an odd number of members must be involved in the voting process for a majority decision to be made. How this applies to an Exchange Server 2010 DAG is that if you deploy a DAG with just two Mailbox servers as members (or any even number up to 16), then neither server is able to determine by majority vote whether it should make its own copy of a given mailbox database active.
To achieve quorum for a DAG with an even number of member servers another server in the same site is designated as a File Share Witness for the cluster. This is typically a Hub Transport server though it can technically be any compatible Windows server.
Database Replication in Exchange Server 2010 Database Availability Groups
There are two ways that mailbox database replication occurs between Exchange Server 2010 DAG members.In Exchange Server 2010 RTM “file mode” replication is used. With file mode replication as each transaction log is written and then closed off (once it reaches 1Mb in size) it is then copied to each member of the DAG that also holds a copy of that mailbox database. The other members receive the file into their replay queue, and then replay the transaction log file into their own passive copy of the database.
File mode replication works fine but has an obvious shortcoming in that any transaction logs that have not yet been shipped to other servers in the DAG can be lost if the Exchange server hosting the active database copy fails. In those cases one of the other DAG members is able to bring their copy of the mailbox database online and then request missing emails be resent from the transport dumpster of Hub Transport servers within the site.
In Exchange Server 2010 SP1 file mode replication is used to bring mailbox database copies into sync with each other (eg during the initial sync process when a new database copy is added). Once they are in sync the DAG members switch to “block mode” replication. In block mode replication each database transaction is written to the log buffer on the active server and also sent to the log buffer of DAG members hosting passive copies of the database.
When the log buffer becomes full each DAG member then builds their own transaction log files from their own log buffer. Block mode replication has an advantage over file mode replication in failure scenarios, because each DAG member is completely up to date with all changes to the active database.
Note that Public Folder databases can reside on Mailbox servers that are members of a Database Availability Group, however they are not replicated by the DAG itself. Instead you must use Public Folder replication to provide redundant copies of Public Folder databases.
Other Advantages of Exchange Server 2010 Database Availability Groups
Before we proceed with an example of how to install an Exchange Server 2010 DAG I will also mention some of the other advantages of Database Availability Groups.- Unlike previous versions of Exchange Server (particularly Exchange Server 2007) Exchange Server 2010 has just one high availability feature for Mailbox servers for all high availability deployment scenarios
- When you create a Database Availability Group the underlying Windows Failover Cluster is automatically created and configured for you
- A Database Availability Group can be created at any time without requiring Exchange Server 2010 to be removed and reinstalled from the server, unlike previous versions that required that clusters be established first before Exchange was installed
- Exchange Server 2010 DAG members can host other server roles, unlike Exchange Server 2007 that prevented clustered Mailbox servers from hosting other roles
Exchange Server 2010 Installation Step by Step
In this tutorial I will demonstrate the installation of an Exchange Server 2010 Database Availability Group on Windows Server 2008 R2.For this tutorial the following Exchange servers have already been installed.
- EX1 – Exchange Server 2010 SP1 Mailbox server
- Primary interface: 192.168.0.32/24
- Secondary interface: 10.0.5.1/30
- EX2 – Exchange Server 2010 SP1 Mailbox server
- Primary interface: 192.168.0.33/24
- Secondary interface: 10.0.5.2/30
- EX3 – Exchange Server 2010 SP1 Client Access and Hub Transport server
- Primary interface: 192.168.0.34/24
Each of the Mailbox servers has been configured with its own mailbox database.
- EX1 – Mailbox Database 01
- EX2 – Mailbox Database 02
Because the Mailbox servers are configured with dual interfaces it is important to make sure that the secondary interface is not configured to register itself in DNS.
Open the TCP/IPv4 properties for the secondary interface one each server, click the Advanced button, navigate to the DNS tab and untick Register this connection’s address in DNS.
Creating the Database Availability Group
Log in to one of the Mailbox servers and launch the Exchange Management Console. Navigate to Organization Config/Mailbox and choose New Database Availability Group from the action pane.
When the New Database Availability Group wizard starts give the DAG a name, specify the Witness server, and also specify the file path for the Witness server to use.
Click on the New button to create the new Database Availability Group, and then click Finish to close the wizard.
Adding Database Availability Group Members
Right-click the newly created Database Availability Group and choose Manage Database Availability Group Membership.
Click the Add button and select the Mailbox servers that you wish to make members of the DAG.
Click the Manage button to commence adding
the Mailbox servers to the DAG. This involves installation and
configuration of Windows Failover Clustering on the servers, so it can
take a few minutes to finish.
After it has finished the next step is to configure the DAG networking.
Configure Database Availability Group Networking
Right-click the newly created Database Availability Group and choose Properties.
Select the IP Addresses tab, click the Add button and add a static IP address for the Database Availability Group.
You will notice that the Database Availability Group has been
automatically configured with DAG networks for the subnets that the DAG
members have network interfaces connected to.Open the Properties of each DAG network and configure them with meaningful names. If you have configured your network to have a dedicated replication network for the DAG then you should disable replication on the DAG network that is intended for MAPI communications (ie client connections).
Adding Mailbox Database Copies to DAG Members
With the Database Availability Group established and the networking configured you can now add mailbox database copies to other DAG members.In the Exchange Management Console navigate to Organization Config/Mailbox and choose the Database Management tab. Right-click a mailbox database and select Add Mailbox Database Copy.
Click the Browse button and choose the Mailbox server to add the database copy to.
Click the Add button to add the mailbox database copy and then click Finish to close the wizard.
The Exchange servers will now commence seeding the replica servers with an up to date copy of the database and all of the current transaction log files. Depending on the amount of data to be replicated this may take some time.
Repeat the same process for any other mailbox databases you wish to add database copies for.
Configuration of the Exchange Server 2010 Database Availability Group is now complete.
Comentarios
Publicar un comentario
Dime si la información de este blog te sirvio.