SQL Server Availability Group Configurations With NO Domain Requirement
You may have noticed that Windows Server 2016 Technical Preview 3 was released today. For the full announcement from Microsoft on the Server & Cloud blog, click here. There is one important line that all SQL Server folks should pay attention to:
Increase flexibility by removing domain-specific constraints for SQL Server clusters
Yes, kids. That means you can create a Windows Server Failover Cluster (WSFC) with NO – I repeat NO – domain required. This will not work for clustered instances (FCIs) since they still require domain-based service accounts, but it will work and be supported with SQL Server 2016 for AlwaysOn Availability Groups (AGs). I would not expect Microsoft to go back and certify this configuration with SQL Server 2014 (or 2012 for that matter), but you never know. If you try and want to use 2012 or 2014 in this configuration, as of the posting of this blog post, it would be considered unsupported – don’t do that as it is the antithesis of mission critical.
This is huge and for many, will simplify AG configurations. No more CNOs and VCOs (although this was possible in Windows Server 2012 R2, you still needed the nodes to be domain joined). I have been testing this configuration with SQL Server 2016 CTP 2.2 and the builds of Windows Server 2016, but due to NDA, have not been able to talk about it until today because it had not been publicly announced. For everyone who has been complaining how DBM was better, you got your wish – this allows you to have an AG configuration which is the same as the one that you had using database mirroring (DBM) with certificates.
The demo configuration I will show below is multi-subnet to simulate two different data centers. Node One (SYLVESTER) is in subnet one and Node Two (TWEETY) is in subnet two. These are not joined to any domain as shown in Figures 1 and 2.
So far, so good. My WSFC’s name is PUDDYTAT. The entire configuration can be seen in Figure 3.
I have an AG named AG1 with a Listener named GRANNY. Its info is in Figure 4.
While you can see that the AG is up and running in Figure 4, Figure 5 shows it working in SSMS. Viola!
If you don’t believe me yet, to further drive the point home, I left the accounts running the SQL Server instances as local accounts (NT Service\MSSQLSERVER and NT Service\SQLSERVERAGENT). This can be seen in Figure 6. Figure 6 also shows the properties of SQL Server where the ability to use AGs is enabled. This is very real and works as advertised. I’m excited about this.
As always, there are some caveats to this configuration that you should be aware of:
- At least in TP3, you cannot create or administer the WSFC via Failover Cluster Manager. Everything must be done in PowerShell. This may not change between now and RTM of Windows Server 2016, so if you are uncomfortable administering clusters via PowerShell, this is not a configuration you should be using. If you try to use Failover Cluster Manager, you will see the message in Figure 7.
- This will make using the AG Wizard to do your backups a bit trickier since shared directories usually use domain-based accounts. You may have to manually deal with them if you are not using domains or do not have trusted domains.
- There are some flags that get tripped during Cluster Validation (namely, no domain) that should be fixed by RTM. This is a known issue in TP3.
- With no domain requirement, this also means no Kerberos however, if each node is in a different domain (i.e. one in Site, another domain in Site B) but crosses boundaries, you should be able to have Kerberos. I have not tested this configuration yet (it is on my list). This should even enable cross-domain migrations – again a scenario I have yet to test. There are more, but hey, first blog post and all of that.
- You will need to add the DNS suffix manually otherwise the WSFC will not come online
- Networking is clearly crucial here, and things like DNS replication will be important.
- File Share Witness is not supported, so you will need to use asymmetric disk (which defeats the purpose of AGs with no shared storage) or Cloud Witness.
The good news is now that this is public, this bit will most likely make it into the book. I wanted to do a quick blog on it, and if I get time, I will show how I created this in a blog post soon. Also, with this now public, I may make this one of the labs for my PASS Summit 2015 preconference session Advanced SQL Server Availability Architectures and Deployments. Sign up now!
UPDATE: I just saw that Subhasish of the Cluster team on Windows just blogged a bit more about the Windows side of this.
Also, due to the fact that the AG configuration is standalone with no storage and there was an error during validation (TP3 known issue I mention above) due to the fact these are not domain joined, I used the -Force and -NoStorage options of New-Cluster.
Pingback: The Setup Experience in Windows Server 2016 Technical Preview 3 | SQLHA | Ready When You Are
More flexibility in configurations is always a good thing. Do you know if it is possible to have 3 FCIs in a single cluster and then do an availability group in that same cluster?
Yes, you can have multiple FCIs in the same WSFC and have an AG. However, you should not mix standalone instances on the same nodes with FCIs and if the FCIs are participating in the AG, they can never have the ability to fail over to the same node. That would be invalid. So it’s a complex architecture. I’ll be discussing it in my PASS Precon. http://sqlha.com/events/25/pass-summit-2015-preconference-advanced-sql-server-availability-architectures-and-deployments/
Pingback: Database Mirroring Isn’t Going Anywhere