Exchange Server 2010 : Day-to-day DAG management and operations (part 4) - DAG networks

10/3/2011 9:19:20 AM

4. DAG networks

A simple DAG composed of two or three mailbox servers such as the one that we have discussed so far has relatively basic network requirements. The DAG has to be able to replicate transaction logs between the mailbox servers and the network has to be able to carry the replication load as well as any other network load generated by other activities such as message transport. A single NIC could be capable of handling the load, albeit with the understanding that a single NIC might also represent a potential single point of failure for the DAG. However, for test and other environments that do not need to operate at the level required for large production systems, a single NIC is often sufficient. At one point in the development of Exchange 2010, Microsoft considered making multiple NICs mandatory for DAG member servers. They pulled back from this position because it meant that low-end servers might not be able to participate within a DAG. Instead, the position is that you can deploy servers equipped with a single NIC as long as you are happy that the solution is robust enough for your purpose.

Figure 11 shows a basic DAG made up of two mailbox servers, each of which has one NIC. The details of the networks assigned to the DAG are exposed in the lower pane. Each network used by a DAG must have a subnet. Exchange creates the initial subnet automatically when the DAG is created. We can also see the IP addresses for the NICs used by the two servers. The preferred approach for larger DAGs is to split network traffic across two networks:

  • The MAPI network takes care of client connections. This network is also used for database seeding. There is always a MAPI network within a DAG.

  • The replication network is used for database seeding and transaction log replication. You don’t have to run a replication network. On the other hand, high-end Exchange mailbox servers that have to handle a substantial replication load can be configured with multiple replication networks.

You can also use the Get-DatabaseAvailabilityGroupNetwork cmdlet to view the network information for a DAG. For example:

Get-DatabaseAvailabilityGroupNetwork -Identity 'DAG-Dublin' | Format-List

Name : DAGNetwork01
Description :
Subnets : {{,Up}}
Interfaces : {{ExServer1,Up,}, {EXSERVER2,Up,}}
MapiAccessEnabled : True
ReplicationEnabled : True
IgnoreNetwork : False
Identity : DAG-Dublin\DAGNetwork01
IsValid : True

Figure 11. Viewing the network used by a simple DAG.

When you use two NICs, the MAPI network is assigned to one network and the replication network is assigned to the other NIC. As you add more NICs, you increase the network capability for the replication network. When a server is configured with more than one replication network, Exchange attempts to direct traffic across the least used network to maximize available network resources. Microsoft recommends that you use Gigabit Ethernet NICs in production Exchange 2010 mailbox servers.

If you elect to use multiple networks, the same configuration must be used for every server in the DAG. Using multiple NICs provides better resilience against failure: If the replication network becomes unavailable for some reason, Exchange will automatically revert to using the MAPI network for both sets of network traffic and you won’t have to deal with a server outage. Once the replication network is restored to health, Exchange will automatically start to use it again. However, the server won’t be able to function as a member of the DAG if the MAPI network fails and, in this case, Exchange will failover the active databases from the server to other members of the DAG.

As previously discussed, when we created the DAG with the New-DatabaseAvailabilityGroup cmdlet, we specified an IP address to use to identify the Windows cluster resource that underpins the DAG (we could also have leased an address using DHCP). This IP address is registered in DNS and is the one used by the MAPI network. Assigning a single IP address to the DAG is sufficient as long as all the mailbox servers within the DAG share the same subnet. However, if the DAG spans several IP subnets, you must specify an IP address in each subnet for the cluster resource to allow servers in that subnet to participate in the DAG. Apart from MAPI communications, the IP address is needed to allow the cluster group to move between the servers within the DAG. This cannot happen if the cluster doesn’t know about all of the IP subnets used by DAG members.

INSIDE OUT: A note about latency

The existence of multiple subnets implies different geographic locations and the sole requirement is that the round-trip network latency between member servers in the DAG must be less than 250 milliseconds. This isn’t a difficult requirement in that your DAG will immediately fail once latency exceeds the limit. Instead, if your latency exceeds 250 milliseconds, you can expect that queues of transaction logs will accumulate during peak production hours and that any network outage or other operation that generates a lot of network activity will result in even larger queues that Exchange has to clear to bring database copies up to date. In some instances, large queues can build up even when latency is less than 250 milliseconds and you might need to increase network capacity so that logs are replicated quickly.

Multiple subnets are also required if you deploy a DAG across multiple Active Directory sites. This is not an issue providing that the network requirements are met and that Active Directory replication is functioning normally. After you create the DAG, make sure that its object has been replicated to the domain controllers in the remote site before you attempt to add subnets or servers in that site.

A default gateway must exist for all networks if you specify an IP address for the DAG. In addition, if you use Microsoft Internet Security and Acceleration Server (ISA) or a similar solution to control traffic between the two subnets, turn off strict RPC for the publishing rules to ensure that log replication traffic can flow between the two sites. If you’re unsure about connectivity between two sites, it’s a good idea to run the Exchange Best Practices Analyzer (ExBPA) on a server in one site and attempt to analyze a server in the other. If ExBPA works, it’s a good indication that sufficient connectivity is in place to allow the DAG to function.

As a practical example, let’s assume that we want to add a second server to our DAG. This server is in subnet 192.168.66.x. Code similar to that shown here will add the new server to the DAG and specify the IP addresses for all of the subnets now in use for the DAG.

Add-DatabaseAvailabilityGroupServer -Identity 'DAG-Dublin' -MailboxServer 'ExServer2'
Set-DatabaseAvailabilityGroupServer -Identity 'DAG-Dublin'

If you then went on to add a third server in yet another subnet to the DAG, you would have to provide a third IP address. In effect, you build up a complete picture for the DAG across all of the involved subnets as you build out the DAG by adding servers. It is conceivable that a DAG might be composed of 16 servers, each in a different subnet. If this is the case, you would have to specify an IP address for each of the 16 subnets when you added the last server to the DAG.

Every network used in a DAG has a unique name of up to 128 characters, a descriptive name of up to 256 characters that you can use to indicate the purpose and use of the network, one or more subnets defined in IP address/bitmask format, and a flag indicating whether the network is dedicated to log replication. An example of using the New-DatabaseAvailabilityGroupNetwork cmdlet to create a DAG network is:

New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup 'DAG-Dublin'
-Name 'DAG-Dublin LS' -Description 'Network used for log shipping in the Dublin DAG'
-Subnets -ReplicationEnabled:$False

You can use the Get-DatabaseAvailabilityGroupNetwork cmdlet to view the networks that are available to a DAG. If, as in our previous example, you had added servers from multiple subnets to the DAG, you will see the IP addresses specified for those subnets in the information returned here. Use the Set-DatabaseAvailabilityGroupNetwork cmdlet to change parameters for a DAG network. In this case, we change the properties of the network to restrict it to log replication.

Set-DatabaseAvailabilityGroupNetwork -Identity 'DAG-Dublin\DAG-Dublin LS'

The –IgnoreNetwork parameter is available to instruct a DAG not to use a network, usually on a temporary basis. For example:

Set-DatabaseAvailabilityGroupNetwork -Identity 'DAG-Dublin\DAG-Dublin LS'

The Remove-DatabaseAvailabilityGroupNetwork cmdlet is available to remove a network from a DAG. If you remove a network, traffic will flow across the remaining networks that are available to the DAG. You aren’t able to run this cmdlet to remove the last remaining network in a DAG.

Remove-DatabaseAvailabilityGroupNetwork -Identity 'DAG-Dublin\DAG-Dublin LS'


Windows Failover Clustering seems to require IPv6 to be enabled and the DAG uses components of Windows Failover Clustering for functions such as tracking membership. Can you therefore implement a DAG using only IPv6 networks and move away from IPv4? The answer is no, not yet. Microsoft has built Exchange 2010 to use IPv4 but acknowledge the existence of IPv6. This means that the DAG uses IPv4, so it must be available on all servers that participate in a DAG and a DAG is not supported in pure IPv6 environments. You’ll certainly see IPv6 addresses reported for a DAG but you cannot use IPv6 for management of a DAG.

Exchange 2010 has several other restrictions in other areas that prevent the operation of a pure IPv6 environment, including Unified Messaging (UM) where the server must have an IPv4 address to function, and Exchange Web Services and the Autodiscover feature, both of which depend on Windows Communications Framework (WCF), which doesn’t support IPv6.

  •  Exchange Server 2010 : Day-to-day DAG management and operations (part 3) - Investigating DAG problems & Managing DAG properties
  •  Exchange Server 2010 : Day-to-day DAG management and operations (part 2) - Building the DAG
  •  Exchange Server 2010 : Day-to-day DAG management and operations (part 1)
  •  SharePoint 2010 : Security - Secure Store Service & Using SSS with BCS
  •  SharePoint 2010 : Security - Claims Based Authentication
  •  Exchange Server 2010 : Unique database names
  •  Exchange Server 2010 : Transaction log replay: The foundation for DAG replication
  •  Exchange Server 2010 : Active Manager - Automatic database transitions & Best copy selection
  •  Exchange Server 2010 : Breaking the link between database and server
  •  SharePoint 2010 : PerformancePoint Services (part 2) - Using PerformancePoint
  •  SharePoint 2010 : PerformancePoint Services (part 1) - PerformancePoint Central Administration Settings
  •  Windows System Programming : Example: Listing File Attributes & Setting File Times
  •  Windows System Programming : File Attributes and Directory Processing
  •  Windows System Programming : File Pointers & Getting the File Size
  •  SharePoint 2010 : Business Intelligence - Excel Services (part 2) - Accessing Excel Services Over SOAP
  •  SharePoint 2010 : Business Intelligence - Excel Services (part 1) - Accessing Excel Services Over REST
  •  SharePoint 2010 : Business Intelligence - Visio Services
  •  Exchange Server 2010 : Perform Essential Database Management (part 3) - Manage Database Settings
  •  Exchange Server 2010 : Perform Essential Database Management (part 2) - Manage the Transaction Log Files
  •  Exchange Server 2010 : Perform Essential Database Management (part 1) - Manage the Database Files
    Top 10
    Exchange Server 2010 : Day-to-day DAG management and operations (part 4) - DAG networks
    Exchange Server 2010 : Day-to-day DAG management and operations (part 3) - Investigating DAG problems & Managing DAG properties
    Exchange Server 2010 : Day-to-day DAG management and operations (part 2) - Building the DAG
    Exchange Server 2010 : Day-to-day DAG management and operations (part 1)
    Windows 7 : Windows Driver Foundation Architecture (part 4) - Tools for Development and Testing
    Windows 7 : Windows Driver Foundation Architecture (part 3) - Driver Frameworks
    Windows 7 : Windows Driver Foundation Architecture (part 2) - Integrated I/O Queuing and Cancellation
    Windows 7 : Windows Driver Foundation Architecture (part 1)
    SharePoint 2010 : Security - Secure Store Service & Using SSS with BCS
    SharePoint 2010 : Security - Claims Based Authentication
    Most View
    iPhone 3D Programming : HelloCone with Fixed Function
    Programmatic Security (part 1) - The Permission Classes
    Performing a typical Exchange Server 2010 install
    Using SharePoint Central Administration for Backup and Restore
    SQL Server 2008 : What Is the Base Class Library?
    Designing a Windows Server 2008 R2 Active Directory : Understanding the Multiple Domain Model
    Business Intelligence in SharePoint 2010 with Business Connectivity Services : External Content Types (part 1)
    The ASP.NET AJAX Infrastructure
    Windows Phone 7 Development : Using a WebBrowser Control to Display Web Content
    SQL Server 2008 : Performance Tuning - Working with Database Tuning Advisor
    Defensive Database Programming with SQL Server : TRY...CATCH Gotchas (part 1) - Re-throwing errors
    Deploying the Client for Microsoft Exchange Server 2010 : Planning Considerations and Best Practices
    Windows 7: Customizing Menus and the Control Panel (part 2) - Navigating and Customizing the Control Panel
    Exchange Server 2007: Create Mail-Enabled Contacts and Mail-Enabled Users
    A First Silverlight Example: Creating a Web Site
    Implementing Client Access and Hub Transport Servers : Understanding the Client Access Server (part 2)
    Managing Exchange Server 2010 : The Exchange Control Panel (ECP)
    Windows Server 2008 : DHCP/WINS/Domain Controllers - Installing and Configuring WINS
    iPhone 3D Programming : Holodeck Sample (part 3) - Handling the Heads-Up Display
    Algorithms for Compiler Design: RIGHT LINEAR AND LEFT LINEAR GRAMMAR