Occasionally, customers that deploy highly available Mailbox servers use a dedicated or secondary network for backup operations. The way in which you do this in Exchange 2010 has changes, and it’s important that when you implement such a configuration that you don’t use the methods or instructions designed for previous versions of Exchange.
In Exchange 2003 and Exchange 2007, we leveraged the Windows Cluster service and used the cluster resource model. To implement a dedicated backup network, you would create a virtual IP address resource in the Exchange resource group corresponding to the network on which you wanted to perform backups. The network associated with the IP address would then be configured as follows:
· Allow cluster network communication on this network and Allow clients to connect through this network enabled (Windows 2008 and Windows 2008 R2)
· All Communications (Windows 2003 and Windows 2003 R2).
On the backup server a hosts file would be used to resolve the name of the Exchange Virtual Server (Exchange 2003) or Clustered Mailbox Server (Exchange 2007) using this dedicated IP address. Because each database was associated with a single server name this would allow the backup server to connect to the Exchange server name on the private network and leverage the backup agent installed on the node hosting those resources.
In Exchange 2010, there have been several changes that no longer allow this type of implementation to function. Exchange 2010 still leverages the Windows Cluster service for some of its high availability functionality, but it no longer uses the cluster resource model. Exchange 2010 includes a form of application level high availability known as the Database Availability Group (DAG). When an administrator creates a DAG they must provide a name and one or more IP addresses. The DAG name and the list of IP addresses are used when forming the DAG’s underlying cluster – these will become the Cluster Name Object (CNO) and the list of IPs will be associated with the cluster network name. All IP addresses assigned to a DAG must be on the MAPI network. This network is automatically configured to allow cluster network communications on this network and allow clients to connect through this network.
Exchange 2010 implements tightly coupled network integration with the Cluster service. This integration manages the settings of all networks found on the DAG members – for example Replication and backup networks. By default, Exchange 2010 sets these networks to allow cluster network communication on this network but does not set allow clients to connect through this network. When the setting allow clients to connect through this network is not enabled, virtual IP addresses cannot be bound to this network.
There is no straightforward way to create a dedicated backup network in Exchange 2010 using the legacy Exchange implementation. There are no application and service groups in which to create the IP address resources, ancillary networks do not support the settings necessary for a virtual IP address, and the integrated Exchange cmdlets do not allow you to assign an IP address to the DAG on a backup network.
Despite these challenges, some administrators have been semi-successful at implementing a variation of the solution (semi-successful as in, it works for a little while, but not for the long term). For example, administrators will find a way to change the network roles to allow virtual IPs to be created and will then update the Cluster core resources with the virtual IPs. This works, but only until Exchange reconfigures the network settings automatically, or until the administrator runs one of the integrated DAG cmdlets which removes the additional IP addresses being created.
So if that is the case how does one implement a dedicated backup networks, and what are some backup vendors doing? Unlike previous versions of Exchange where databases were associated with a server name, Exchange 2010 does not associated databases with a single server name per se. Instead, copies of a database are associated with a server. These database copies can exist across multiple members of the DAG with one member having an “active” database and one or more other members having “passive” databases. In order for backup vendors to determine database locations and status, some make a call to the DAG name to essentially perform a topology discovery. Remember that the DAG name is the name of the cluster, should have valid IP addresses for all subnets on which DAG members exist, and should be dynamically updating in DNS so that the DAG name always resolves correctly. Once this topology discovery is completed the backup server then initiates individual backup sessions to the DAG members themselves (via the DAG member names).
When implementing a dedicated backup network for an Exchange 2010, do not modify the cluster core resources. The backup servers should be allowed to do topology discovery over the MAPI network. This requires that the backup server has an interface that can query DNS, determine the IP address currently resolving to the cluster name, and establish a connection to that address.
Next, modify the hosts file on each backup server. In this configuration, each DAG member has a backup network interface with an IP address locally assigned to that interface. The hosts file entries on the backup server are used to resolve DAG member names.
How does this accomplish the task? Let’s take a look.
Here is an example 3-member DAG. The DAG has two networks, a MAPI network and a Backup network. Each member has an IP address statically assigned to each NIC..
When the backup software attempts to perform a backup operation, it queries DNS and determines that the IP address associated with the DAG is 10.0.0.100. The backup software connects to the DAG and performs a topology discovery.
The backup software determines that a database that needs to be backed up resides on NodeA. Normally the backup software would access the backup agent by querying DNS for the IP address associated with NodeA. If this happens, the backup would occur over the MAPI network and not the Backup network. To prevent this from happening, the administrator edited the hosts file of the backup server and added an entry for NodeA.company.com with an IP address of 10.1.1.1. The backup server uses this information and establishes a connection to the backup software agent running on NodeA via the Backup network.
In some scenarios, customers want to stop cluster heartbeat and continuous replication from using the Backup network. To do this, you can use the Set-DatababaseAvailabilityGroupNetwork cmdlet with the–IgnoreNetwork:$true and –ReplicationEnabled:$false parameters for the Backup network.
When implemented as described above, this configuration enables most backup applications to operate using a dedicated network without changing DAG settings that might be automatically disabled by the system.
================================
10/25/2011
Corrected location of host file entry change.
================================
================================
12/18/2011
This weekend I reviewed a configuration that was using Backup Exec to protect their Exchange 2010 deployment. It was pointed out to me that on the properties of the job, on the network and security selection, there is an option to select which network / subnet could be utilized for backup operations. Some may find this helpful when configuring their jobs. I would defer to Symantec on specifics of establishing this configuration.
================================
TIMMCMIC 