Deploying a SQL Server 2012 Multi-Subnet Cluster

I’ve been wanting to write a series of articles on deploying a SQL Server 2012 on a multi-subnet cluster for quite some time now. This was driven by the fact that my series of articles on SQL Server 2008 Failover Clustering had been in the Top 10 Tips for more than 2 years since being published three years ago. I guess more and more systems administrators and SQL Server DBAs are being tasked with deploying failover cluster instances. Ever since I had my hands on the beta version of Denali (codename for SQL Server 2012) last year,  I’ve been testing some configurations for the multi-subnet clustering feature. I think I’ve built like 3 test environments prior to Denali going RTM just so I can wrap my head around the concepts (plus the fact that Windows Clustering Experts like Microsoft MVP Allan Hirt (blog | Twitter) have been gracious enough to answer questions.)  Check out this first of a series of articles on how to deploy a SQL Server 2012 Multi-Subnet Cluster on

And if you’re in New York City or the nearby cities and want to see this whole process in action, catch me at SQL Saturday #158 this coming 4-Aug-2012.

[UPDATE:] Part 2 of the series has been published on 26-July-2012. Stay tuned for the rest of the series.

[UPDATE:] Part 3 of the series has been published on 13-Aug-2012. Stay tuned for the rest of the series.

[UPDATE:] Part 4, the last of the series has been published on 06-Sep-2012.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published.

8 thoughts on “Deploying a SQL Server 2012 Multi-Subnet Cluster

  1. Love the article. I’ve been looking for a good “How-to” article on clustering with screen shoots. Now I just have to convince our Operations team and my manager to give us some time to test this out. Any tips there? 🙂

  2. Feel free to ask your questions any time.

    There are some things to keep in mind when moving your mirroring solutions to geoclustering. While mirroring will eventually be replaced by AlwaysOn Availability Groups, it is important to evaluate the pros and cons of moving from one solution to the other, particularly the complexities of implementing it. I’ve parroted the concept of RPO, RTO and SLAs every time an HA/DR project is being considered. Being a clustering guy, I’m all for implementing it but will not recommend it any time if it doesn’t meet those recovery and availability objectives. You can check out the webcast I did on disaster recovery and the importance of the non-technical aspects involved

  3. “You can provide client connectivity to the primary replica of a given availability group by creating an availability group listener. An availability group listener provides a set of resources that is attached to a given availability group to direct client connections to the appropriate availability replica.

    An availability group listener is associated with a unique DNS name that serves as a virtual network name (VNN), one or more virtual IP addresses (VIPs), and a TCP port number. For more information, see Availability Group Listeners, Client Connectivity, and Application Failover (SQL Server).”

    If I’m understanding this correctly, you can actually have your clients (websites, applications, etc) connect directly to the Availability group. So it could technically be a replacement for Mirroring that in the event of fail-over would provide automatic client redirection. This might be another option to consider with our GeoClustering proposal. I’m going to try to carve some time out to take a look at your webcast.

    Thanks again.

    • That is correct. Think of the Availability Group listener as the virtual server name for a failover cluster instance. Clients can simply connect to the virtual network name instead of the instance name. Then, you no longer have to worry about the client redirection after the failover process, especially for those clients who are not using the .NET Framework (the .NET Framework 2.0 and higher provides the Failover Partner parameter in the connection string to allow client redirection in cases where the database has failed over to the mirror partner) like Java, etc. Plus, you can have different SQL Server instances as Availability Group replicas that sit on different network subnet without having to worry about storage replication. You can use SSD as your local storage for all instances which is still way cheaper than implementing storage replication. Keep in mind that Availability Groups are for database protection only (just like database mirroring) while failover clusters are for an entire instance protection