Skip to Content

Solved: Do I need to create separate Windows Server Failover Cluster for SQL Server Always On and Availability Groups?


We are re-visiting the topic of purchasing SQL Server 2019 Enterprise but are first configuring a Proof-of-Concept setup to get a feel of how well it works within our environment and how to migrate DBs to it. One thing we’re stuck on is that reading through the documentation it mentions Windows Server Failover Clustering and the SQL Servers are Nodes. We have an existing Failover Cluster that houses all of our VMs that have storage connected via 10GbE iSCSI to our SAN, Quorum, etc. all setup.

Do I need to create a totally separate Failover Cluster for SQL Server Always On and Availability Groups? Or can the SQL Servers that are going to be part of the Availability Groups be part of the existing Failover Cluster used for standard DEV/PROD VM environment and be normal “Roles” like other VMs, using the existing iSCSI Volumes within the Cluster and Quorum?

Since SQL Always On and Availability Group documentation mentions the servers must be “Nodes” in a Failover Cluster. If this means they must be a node then sounds like they will not be able to join our existing Cluster and be “Roles” and we’ll need to create a separate Cluster. Is that correct?

I was hoping that would be a possibly to have a Cluster nested within our main Cluster. Then as far as the disks, I would have them setup as iSCSI to our main Cluster like normal, then put the necessary disks on the 2 SQL Servers, and then add them into the nested Cluster as Clustered Disks with quorum, etc.?


I have a cluster of three Hyper-V hosts. Those hosts support VMs for web, Exchange, SQL, AD, etc. My Exchange and SQL servers have their own clusters – that only their respective VMs participate in, so they can manage their own resources.

I’m having trouble wrapping my head around letting the SQL Servers be right on the hosts themselves. I’m sure it would work, but I expect it would steal resources from Hyper-V, and make the SQL resources difficult to manage.

You’ll have a Failover Cluster of VM hosts. On that cluster you’ll have some VMs that are SQL Servers. These VMs don’t really know they’re VMs, or that they’re running on a Failover Cluster. If you log in to one of the SQL Server VMs, you can create a Failover Cluster with your SQL Servers. This cluster will not know it’s running on top of another cluster, it will just manage the resources for the SQL Server cluster. Once the SQL Servers are clustered, you can set up Always-On, to replicate the databases among the SQL Servers.

The disks with the SQL VMs will be resources in the Hyper-V Failover Cluster. These will obviously be the “C:” drives of the various SQL Servers. If each SQL Server is going to store its databases and log files on something other than its “C:” drive, you should arrange for storage to be provided to each SQL Server. In our case we map LUNs from inside each SQL Server to our iSCSI SAN, so each SQL Server has its own data drive and log drive. In this scenario, neither the Host cluster nor the SQL cluster “know about” these drives because they’re not resources in either cluster.

Alex Lim is a certified IT Technical Support Architect with over 15 years of experience in designing, implementing, and troubleshooting complex IT systems and networks. He has worked for leading IT companies, such as Microsoft, IBM, and Cisco, providing technical support and solutions to clients across various industries and sectors. Alex has a bachelor’s degree in computer science from the National University of Singapore and a master’s degree in information security from the Massachusetts Institute of Technology. He is also the author of several best-selling books on IT technical support, such as The IT Technical Support Handbook and Troubleshooting IT Systems and Networks. Alex lives in Bandar, Johore, Malaysia with his wife and two chilrdren. You can reach him at [email protected] or follow him on Website | Twitter | Facebook

    Ads Blocker Image Powered by Code Help Pro

    Your Support Matters...

    We run an independent site that is committed to delivering valuable content, but it comes with its challenges. Many of our readers use ad blockers, causing our advertising revenue to decline. Unlike some websites, we have not implemented paywalls to restrict access. Your support can make a significant difference. If you find this website useful and choose to support us, it would greatly secure our future. We appreciate your help. If you are currently using an ad blocker, please consider disabling it for our site. Thank you for your understanding and support.