Devin on Earth: An Exchange 2013 AAP-less DAG cluster

Greetings, all!

One of the cool things you can do in Exchange 2013 SP1 and Windows 2012 R2 is create a DAG whose underlying cluster has no administrative access point (AAP). What’s an AAP? Well, that’s the combination of the cluster named object (CNO) and the IP address. Back in February 2014, the Exchange Team made a blog post about this and other new clustering features that Exchange 2013 can take advantage of — dynamic quorum and dynamic witness.

Many other bloggers have talked about the pros and cons of the AAP-less cluster, but let me summarize them:

• You can’t connect to the cluster to manage it via the Failover Cluster Manager GUI. You have to use cluster.exe or the PowerShell cmdlets.
• You can’t manage the cluster from a machine that’s not a member of the cluster. No more remote cluster management!
• You can’t specify the cluster name in your management commands.
• Third party utilities (like backup) that rely on the talking to the AAP will either need workarounds (such as HOSTS file entries) or need to be replaced entirely.

Knowing all of this, my customer decided to go with an AAP-less cluster for their DAGs, in part because they’re going to have stretched DAGs and want to avoid some of the potential networking issues that can come from the cluster IP address having to flip between subnets depending on which node holds quorum. What we found, however, is that when we went to modify specific properties of the cluster (to enhance the timeouts for the stretched DAG scenario) and the cluster network (to exclude the backup network from participating in the cluster or DAG replication at all), the lack of AAP was coming back to bite us. And once you create the DAG, you can’t flip it from AAP to no AAP and vice versa. You have to tear it down and build it back up. We were trying to avoid the scenario of having to rebuild the DAGs, mailbox databases, and extra database copies.

Thanks to some pointers from members of the Exchange Masters community, plus a little experimentation, what I found is that the key to getting this to work was two-fold:

1. Per the note’s in Scott’s blog, run the commands from a node in the cluster. I’d been trying this previously, but I only had half the solution.
2. Disable the DAG automatic network configuration feature in favor of manual network configuration.
3. Now run the desired commands.

Here’s how it looks in practice:

(From a member of DAG1)

(Configure the DAG for manual network configuration;

Set-DatabaseAvailabilityGroup -Identity DAG1 -ManualDagNetworkConfiguration $true

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\BadNetwork `

    -IgnoreNetwork $true `

    -ReplicationEnabled $false `

    -Description “DAG1 Bad network”

cluster /prop SameSubnetDelay=2000

cluster /prop SameSubnetThreshold=10

cluster /prop CrossSubnetDelay=4000

cluster /prop CrossSubnetThreshold=10

Now, the bad network shows up as replication disabled in Get-DatabaseAvailabilityGroupNetwork, the Get-ClusterNetwork role for the interface on that network is now 0 (ignore) instead of 1 (heartbeat only, which lets the DAG use it as a replication network) or 3 (full cluster communication), and the cluster is accepting the actual property updates.

The post An Exchange 2013 AAP-less DAG cluster appeared first on Devin on Earth.

from Exchange News Full Article