Lift and Shift Always On SQL Server Failover Cluster Instance (SQL FCI) to Azure VMs

Published Jul 06 2020 09:51 AM 19.6K Views


Today, we are announcing two new features enabling lift and shift of Always On SQL server Failover Cluster instances (SQL FCI) from on-premises to Azure Virtual Machines: Distributed Network Name (DNN) for SQL FCI and Azure Shared Disks for SQL FCI.


SQL FCI has been commonly used for years to protect SQL Server instance in case of a failure (hardware failures, operating system failures, application, or service failures), or a planned upgrade. With SQL FCI, SQL instance will be moved to an available Windows Server Failover Cluster (WSFC) node if the current node fails, transparent to the client or application connecting to SQL Server. SQL FCI protects from failures at the instance level through redundancy and automatic failover and fairly simplifies configuration and management for High Availability.


Azure offers many capabilities for SQL Server to maximize performance, optimize cost, reduce maintenance with SQL VM Resource Provider and achieve world class security. On Azure VMs, you can leverage these capabilities by keeping full control on the platform hosting SQL Server; including control on the VM family and size, storage configuration, SQL Server version and edition, deployment options and HADR architecture.


Previously, rehosting SQL FCI on Azure had some differences compared to on-premises as it required an Azure Load Balancer for automated failover and there was no representative of SAN (Storage Array Network) type storage on Azure. With today’s announcement, both differences are addressed by offering an exact representation of SQL FCI architecture on Azure VMs.


DNN support for SQL FCI


DNN for SQL FCI is supported with SQL Server 2019 CU2 on Windows Server 2016 and later and it enables faster failover, simplifies provisioning and maintenance, and improves robustness by removing the need for an Azure Load Balancer.


Traditionally, SQL Clients leveraged Windows Server Failover Cluster Virtual Network Name (VNN) and Virtual IP access points for SQL FCI connectivity. VNN for SQL FCI provided a unified connection point and allows applications to connect to the VNN without the need to know the current active node. Since Virtual IP works different in Azure environment, you are required to configure an Azure Internal Load Balancer for automated failovers through VNN. Azure Load Balancer distributes inbound flows that arrive at the load balancer's front end to backend pool instances which should be configured as the Azure Virtual Machines running SQL FCI nodes.


The DNN resource in Windows Server Failover Cluster provides an alternative way for SQL client to connect to the SQL FCI without an Azure Load Balancer. When a DNN resource is created, WSFC binds the DNN DNS name with the IP addresses of all nodes in the cluster. SQL client will try to connect each IP address in this list to find the active node. This connection process can be further accelerated by connecting all IP addresses in parallel with the SQL connection property "MultiSubnetFailover" is set to true, enabling SQL client to connect to the current running FCI instantly. DNN would be helpful in any environment including on-premises where IP Addresses are scarce, and you do not need to connect directly to the cluster group to manage the cluster.


You can configure DNN for SQL FCI connectivity basically in 5 simple steps as shown in the example below. First, create the DNN resource in WSFC for the resource group hosting SQL FCI (for default SQL instance group name is “SQL Server (MSSQLSERVER)”), then set the DNS Name of the DNN resource with “SQL FCI name”, and start the resource (verify owner node list for DNN resource only includes SQL FCI nodes ). At this point DNN resource will be ready to use, so restart SQL Server and update connection string to start using the DNN.  


1. Add DNN resource





Add-ClusterResource -Name dnn-demo -ResourceType "Distributed Network Name" -Group "SQL Server (MSSQLSERVER)"





2. Set DNS name of the DNN resource





Get-ClusterResource -Name dnn-demo | Set-ClusterParameter -Name DnsName -Value sqlfciname





3. Start the DNN resource





Start-ClusterResource -Name dnn-demo






4. Restart SQL Server


5. Update Connection String for parallel querying of FCI nodes with Multi Subnet Failover property

Add “MultiSubnetFailover=True” property to SQL connection string and set the Server Name as the DNS name of DNN property.


You can keep using the same name for an existing SQL FCI, to do that simply:


With .NET framework 4.6.1, MultisubnetFailover support is turned on by default; no client-side change is needed if you are using 4.6.1 and higher and same SQL FCI name is used.


DNN and Shared Disk.png


Azure Shared Disks for SQL FCI 


Second feature enabling lift and shift migrations of SQL FCI to Azure is Azure Shared Disks. Azure Shared disks can be attached to multiple VMs in the Windows Failover Cluster at the same time. The VM that can read or write to the disk is chosen by the Cluster service based on the SCSI Persistent Reservations (SCSI PR). SCSI PR is widely leveraged by SQL FCI running on Storage Area Network (SAN) on-premises, and Azure Shared disks enables migrating those to Azure VMs as is.


You should create the Azure Shared disks by setting “Max Shares = 2” for a 2 node SQL FCI, and then attach the disk to both SQL FCI nodes. You can use Failover Cluster Manager and present the shared disk to the cluster as Cluster Shared Volume (CSV) and then use it for SQL Server Data and Log files. Please follow this tutorial to deploy SQL FCI with Azure Shared Disks. You can use Premium SSD and Ultra Shared disks with all versions of SQL FCI as now it is generally available.


To access Azure Shared Disks, both FCI nodes should be placed on the same Availability Set and Proximity Placement Group. Using the same Availability Set guarantees 99.95% HA SLA at the VM level, when one VM is down for planned maintenance the other will be available. Proximity placement groups creates a logical grouping of Azure compute resources which assures that they are physically located close to each other to achieve the lowest network latency. SQL FCI configured with Azure Shared Disks on an availability sets and PPG offers a high-performance HA solution at the instance level for mission critical SQL Server workloads.


Use Azure Migrate to migrate SQL Server workloads to Azure SQL and leverage workload optimizations and total cost of ownership savings today! Get started with a free trial or pre-configured Azure SQL images.



I can see an advantage to a lift-and-shift of an on-prem MSSQL FCI to Azure. However, I don't want the hassle of managing all the VMs of the WSFC.


Can you comment on the advantages of "SQL FCI configured with Azure Shared Disks on an availability sets and PPG offers a high-performance HA solution at the instance level for mission critical SQL Server workloads." versus the other, standard Azure SQL offerings?


Thanks, Andy


Hi Andy, that's a great question, thanks for asking.

SQL FCI solution described above is an IaaS solution and is preferred by customers looking for the full control on the platform. With SQL FCI on Azure IaaS, customers get access to the VM, can choose any Azure VM family and size, customize storage configuration (ex: Premium SSD or Ultra Disk), install other apps that should run on the same VM with SQL Server, choose the SQL Server version and edition and also customize installation and configuration of SQL Server. if none of these are a requirement but you are looking for a high performance HA solution for SQL instance, then Azure SQL Managed Instance is the right deployment type, where you do not need to deal with clustering or any other aspect of platform management. Azure SQL MI is a PaaS service and Microsoft manages the platform hosting SQL instance, it offers much more benefits in addition to HA and performance at the instance level like patching service, automated backups, auto-failover groups for Geo-DR,  threat protection, vulnerability assessment and data masking and more, please refer here for full list. Thanks, 

Regular Visitor

Is this only supported in SQL 2019 or will it be also supported in SQL 2017?


Azure shared disk and DNN must be using together ?

Any SQL version required to support Azure shared disk ?


DNN and Shared Disks can be used separately.   DNN is only supported with SQL Server 2019 but shared disk is supported with all versions.


New Contributor

Does DNN work as a replacement for the listener name when deploying AlwaysOn Availability Groups in a hybrid scenario with one node on-premises and the other in Azure?

Version history
Last update:
‎Jul 17 2020 10:54 AM
Updated by: