The TechNet article “What’s new in Failover Clustering in Windows 2012 R2” describes an “Active Directory-detached cluster“, which refers to a cluster deployed without the traditional dependencies on Active Directory. These dependencies are caused by the need to register computer objects representing the cluster in Active Directory and include the cluster name object (CNO). An example of a CNO for an Exchange 2013 cluster is shown below. The CNO requires an IP address (static or dynamic) and is registered in DNS.
Since its introduction in Exchange 2010, an Exchange Database Availability Group (DAG) has been firmly based on Windows Failover Clustering. Each DAG is a cluster and each DAG requires a CNO and an IP address. If the DAG members run on Windows 2012 servers, the CNO has to be pre-staged before any member node can join because Exchange doesn’t have the necessary permissions to create a computer object in Active Directory. A DAG also requires an IP address for every additional subnet that it uses.
DAGs have been around for four years now and we’ve become very accustomed to their vagaries. It’s fair to say that the introduction of native high availability capabilities in Exchange 2010 was an enormous success, largely because Exchange did such a good job of masking the complexities of failover clusters through its administrative interfaces. Exchange 2013 extends support to Windows 2012 clusters and takes advantage of features such as dynamic quorum while also easing administrative concerns by automating tasks such as collapsing the DAG networks required when multiple subnets are used. DAGs are great, but they are still firmly IP (v4) based and still need careful planning and attention to detail during deployment and operations to be successful.
Along comes Exchange 2013 SP1 and delivers radically more simple DAGs (or, as the TechNet documentation refers to it, "DAGs without a cluster administrative access point" - a simply horrible long-winded name that surely must have been designed by committee), which really means that Exchange has taken advantage of the ability to create failover clusters in Windows 2012 R2 without all the bits that they've needed previously, rather like the Active Directory-detached cluster described in TechNet - but different!
Simply put, if you run Exchange 2013 SP1 mailbox servers on Windows 2012 R2 servers, you can create a DAG that doesn’t need an IP address and doesn’t use a CNO or network name resource. In fact, Exchange goes a step further and doesn't require cluster information to be recorded in DNS. This is because Exchange takes responsibility for managing cluster information and uses the data held in its configuration container in Active Directory instead. The intention is to simplify the creation and management of DAGs by reducing some of the resource requirements and removing the need for Exchange to create computer objects in Active Directory.
Not requiring an IP address for a DAG is a very good thing. Traditional DAGs require IPV4 addresses and those addresses are becoming a scarce commodity that, despite the best efforts of those who manage the pool of available addresses, will eventually run out. The problem should go away once systems make a transition to use IPv6 everywhere but we have to cope with the shortage for now - or avoid the issue by not requiring an IPV4 address ar all.
The advent of simplified DAGs does not mean that every DAG created from now on will use the new model nor does it mean that traditional DAGs have to be upgraded. Assuming the presence of Windows 2012 R2, you have the choice as to which type of DAG to use. Remember that you cannot mix and match operating systems across the members of a DAG, so deciding on which operating system to use is a fundamental step in this journey. If you go with Windows 2012 (and there are many good reasons to do so), then a traditional DAG is the only high availability option for your deployment.
No supported method exists to convert a traditional DAG to an simplified DAG or vice versa. Once you opt to create a DAG of a certain type, it stays in that mode. That being said, Scott Schnoll has documented what happens if you update the properties of an existing DAG to use the new mode. As he notes, "this process will result in downtime." In reality, because these DAGs only run on Windows 2012 R2, an operating system that is only supported by Exchange 2013 SP1 (or later), no existing DAGs outside Microsoft are candidates for such a transformation. It's therefore a nice exercise in theory that should never be exposed in practice. If you want to move toward simplified DAGs, you really have to deploy new DAGs based on the Windows 2012 R2/Exchange 2013 SP1 combination and move mailboxes over. Time for planning caps to go on!
The new DAGs come with their own quirks. Exchange is very much the boss here and the Failover Cluster Manager console doesn’t get a look in. You can manage simplified DAGs and their underlying clusters through the Exchange Administration Center (EAC) or Exchange Management Shell (EMS) but these DAGs are invisible to Failover Cluster Manager. When Exchange runs the New-Cluster cmdlet in the background as part of the process of creating a DAG of the new type, it specifies that the administrative access point is "none", meaning that the application takes responsibility for the management of the cluster and no cluster network name (the administrative access point used by Failover Cluster Manager) is created. In turn, this means that PowerShell has to be used to view cluster details or resources. By comparison, an Active Directory detached cluster is created with its administrative access point set to "dns" and a normal failover cluster (created with Windows 2012 R2) sets its administrative access point set to "ActiveDirectoryAndDns." Traditional Exchange 2010 and 2013 DAGs don't return any value for the administrative access point, possibly for backward compatibility.
You can check the administrative access point for a cluster by running the Get-Cluster cmdlet (but only on Windows 2012 R2 servers). Note that you have to pass the name of a member server in the IP-less DAG rather than the cluster name.
(Get-Cluster -Name ExServer3).AdministrativeAccessPoint None
Creating a simplified DAG is easy and can be done through EAC or EMS. When you create a new DAG with EAC, you input an IP address of 255.255.255.255 (a way of saying that no IP address is to be allocated) to tell Exchange that you want to create a new-style DAG. If you look at the characteristics of the DAG later on, you’ll see that the only cluster resource that’s assigned is a file share witness (FSW). Compare that to the three cluster resources found in a traditional DAG (below).
Of course, you can create a new-style DAG with EMS. In this case, you pass "([system.net.ipaddress])::none" as the value to the DatabaseAvailabilityGroupIPAddresses parameter when you run the New-DatabaseAvailabilityGroup cmdlet. As in:
New-DatabaseAvailabilityGroup -Name DAG-No-IP -WitnessServer FileServer1 -DatabaseAvailabilityGroupIpAddresses ([System.Net.IPAddress])::None
Apart from not turning up in Failover Cluster Manager, simplified DAGs seem to behave in exactly the same way as their traditional counterparts. On a conceptual level, this is what you'd expect because Exchange has simply shifted some management responsibilities from Failover Clustering to itself. The mechanisms of log replication, monitoring, and activation don't change. Of course, this assessment is based on some early tests that don't extend to the more complicated and complex scenarios such as stretched DAGs across multiple datacenters. However, I anticipate that these DAGs will work well there too, if only because it's Exchange that does all the work. This isn't a reason to jump in and deploy simplified DAGs without first validating that they work in your own particular combination of operational environment and circumstances. As with all new features, the golden rule is to test, test, and then test again before deployment.
Reducing the work required to setup and manage a DAG as far as practicable is a logical evolution of the DAG model. It marks another step along the path to a point where Exchange will have full responsibility for its high availability features. I imagine that Exchange would like to jettison its dependency on failover clusters altogether if this was possible, but that is probably a step too far at present and so the developers have taken the pragmatic approach of reducing that dependency as much as possible. It is entirely possible that the new-style DAGs will become the norm in the future simply because they are easier to create and manage. At that point, traditional DAGs will only be used when a particular administrative regime is used. Exactly where the demarcation line will be drawn remains to be seen as it will depend on the experience gained with simplified DAGs in production as well as future developments within Exchange.
Some work might also be necessary on the part of software vendors to ensure that backup products work with the new configuration. No doubt we will hear more about this from software vendors at next month's Microsoft Exchange Conference in Austin.
Simplifying DAGs is good for customers and it’s good for Microsoft too. Take Office 365 for instance. Microsoft uses more DAGs than you’d care to imagine within its Exchange Online service. Each of those DAGs requires an IP V4 address. Exchange Online is continually rolling out new DAGs to take up the load of new customers. Those running the service will now be able to use new-style DAGs and eliminate the need for additional IP V4 addresses. Removing this requirement probably comes as a relief for those who run Exchange Online.
Simplified DAGs are probably the second most fundamental change made by Microsoft in Exchange 2013 SP1 (my top vote goes to MAPI over HTTP). Because no supported method exists to change traditional DAGs to the new model and the requirement to deploy Windows 2012 R2 servers to support the new feature, I think it will take some time before these DAGs become the norm. Given the attractiveness implict in any useful simplification, I might be wrong!
Follow Tony @12Knocksinna
