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 : {{192.165.65.0/24,Up}}
Interfaces : {{ExServer1,Up,192.165.65.50}, {EXSERVER2,Up,192.165.65.60}}
MapiAccessEnabled : True
ReplicationEnabled : True
IgnoreNetwork : False
Identity : DAG-Dublin\DAGNetwork01
IsValid : True
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.
|
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'
-DatabaseAvailabilityGroupIPAddresses 192.168.65.1, 192.168.66.1
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 10.0.0.0/8 -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'
-ReplicationEnabled:$True
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'
-IgnoreNetwork:$True
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'
Note:
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.
