By: Allan Hirt on August 19, 2015 in Active Directory, AlwaysOn, Availability Groups, Book, Domain, Failover Clustering, FCI, Mission Critical SQL Server, SQL Server 2012, SQL Server 2014, SQL Server 2016, Technical Preview 3, Windows Server 2016
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:
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.