DAG is a very useful technology, we can all agree on that. It is, in fact, so simple and useful that I’d say that everyone who can afford an extra Exchange-server license and storage, should use it. And that is, frankly, pretty much everyone.
Best case scenario, you have nodes on completely separate hardware and cover both database, server and storage failure; worst case you’re on the same virtualized host and cover database failure. Either way you’ll sleep better at night.
Now, there are plenty of guides on the web on how to set up a DAG. It’s pretty straight forward; like a cluster for dummies. So I’m not going to cover that.
There is howere the aspect of networks. DAG network traffic is roughly three things:
- Client traffic
- Replication traffic
- Backup
To keep it simple, you could jam all of these into a single network, but you’d likely not want to. Odds are you’ve probably set up a network for replication allready, but just in case you havent:
New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup ILoveExchangeDAG -Name DAGRepl -Description “Replication network” -Subnets 192.168.2.0/24 -ReplicationEnabled:$True
A backup network is pretty much the same; and it goes like this:
New-DatabaseAvailabilityGroupNetwork -DatabaseAvailabilityGroup ILoveExchangeDAG -Name DAGBck -Description “Backup network” -Subnets 172.120.10.0/24 -ReplicationEnabled:$False -ignorenetwork:$ True
The -ignorenetwork parameter basically tells the DAG not to use it. We’re going to use it for backup, so we don’t want any other traffic there.
Of course you’d need to set NICs with static IP’s on the servers on these networks.
Cool!
Now, normally, you’d point you backup software to the DAG-address, and it would contact the DAG and get information on which server to backup the databases from. That would use DNS and DNS lookups on the servers would point you to the primary address of the server, which is….not the IP of the backup NIC.
Solution: add entries for the Exchange servers in the backup servers host file. That might seem strange, but it’s simple technology really, and this is the only way we can manipulate it.
Right. So now what happens is that your backup server queries DNS for the DAG name, the DAG returns the server names, which the backup server uses the host file to resolve to the backup IP. You are now using the backup IP for backups.
Mission accomplished!
Except; what if you want to add an IP on the backup network to the DAG itself?
First of all: you’re a moron. Microsoft specifially states that you CANNOT separate traffic to the DAG on separate network. And there is no Exchange function to do so.
That isn’t to say that your backup guys aren’t morons, so you may have to do it anyway.
Here be unsupported dragons:
- Stop the Microsoft Exchange Replication service on all nodes.
- Start Cluster Failover Manager on one of the servers
- Under networks, find the backup network and check “Allow clients to connect through this network”
- Under Cluster Core Resources (top level on the cluster); click properties on the cluster and add another IP on the backup network.
- Start Microsoft Exchange Repliaction services again.
You are officially in unsupported territory, but it usually works!