Failover cluster instances with SQL Server on Azure Virtual Machines

APPLIES TO: SQL Server on Azure VM

This article introduces feature differences when you're working with failover cluster instances (FCI) for SQL Server on Azure Virtual Machines (VMs).

Overview

SQL Server on Azure VMs uses Windows Server Failover Clustering (WSFC) functionality to provide local high availability through redundancy at the server-instance level: a failover cluster instance. An FCI is a single instance of SQL Server that's installed across WSFC (or simply the cluster) nodes and, possibly, across multiple subnets. On the network, an FCI appears to be a single instance of SQL Server running on a single computer. But the FCI provides failover from one WSFC node to another if the current node becomes unavailable.

The rest of the article focuses on the differences for failover cluster instances when they're used with SQL Server on Azure VMs. To learn more about the failover clustering technology, see:

Note

It's now possible to lift and shift your failover cluster instance solution to SQL Server on Azure VMs using Azure Migrate. See Migrate failover cluster instance to learn more.

Quorum

Failover cluster instances with SQL Server on Azure Virtual Machines support using a disk witness, a cloud witness, or a file share witness for cluster quorum.

To learn more, see Quorum best practices with SQL Server VMs in Azure.

Storage

In traditional on-premises clustered environments, a Windows failover cluster uses a storage area network (SAN) that's accessible by both nodes as the shared storage. SQL Server files are hosted on the shared storage, and only the active node can access the files at one time.

SQL Server on Azure VMs offers various options as a shared storage solution for a deployment of SQL Server failover cluster instances:

Azure shared disks Premium file shares Storage Spaces Direct (S2D)
Minimum OS version All Windows Server 2012 Windows Server 2016
Minimum SQL Server version All SQL Server 2012 SQL Server 2016
Supported VM availability Availability sets with proximity placement groups (For Premium SSD)
Same availability zone (For Ultra SSD)
Availability sets and availability zones Availability sets
Supports FileStream Yes No Yes
Azure blob cache No No Yes

The rest of this section lists the benefits and limitations of each storage option available for SQL Server on Azure VMs.

Azure shared disks

Azure shared disks are a feature of Azure managed disks. Windows Server Failover Clustering supports using Azure shared disks with a failover cluster instance.

Supported OS: All
Supported SQL version: All

Benefits:

  • Useful for applications looking to migrate to Azure while keeping their high-availability and disaster recovery (HADR) architecture as is.
  • Can migrate clustered applications to Azure as is because of SCSI Persistent Reservations (SCSI PR) support.
  • Supports shared Azure Premium SSD and Azure Ultra Disk storage.
  • Can use a single shared disk or stripe multiple shared disks to create a shared storage pool.
  • Supports Filestream.
  • Premium SSDs support availability sets.

Limitations:

  • It is recommended to place the virtual machines in the same availability set and proximity placement group.
  • Ultra disks do not support availability sets.
  • Availability zones are supported for Ultra Disks, but the VMs must be in the same availability zone, which reduces the availability of the virtual machine.
  • Regardless of the chosen hardware availability solution, the availability of the failover cluster is always 99.9% when using Azure Shared Disks.
  • Premium SSD disk caching is not supported.

To get started, see SQL Server failover cluster instance with Azure shared disks.

Storage Spaces Direct

Storage Spaces Direct is a Windows Server feature that is supported with failover clustering on Azure Virtual Machines. It provides a software-based virtual SAN.

Supported OS: Windows Server 2016 and later
Supported SQL version: SQL Server 2016 and later

Benefits:

  • Sufficient network bandwidth enables a robust and highly performant shared storage solution.
  • Supports Azure blob cache, so reads can be served locally from the cache. (Updates are replicated simultaneously to both nodes.)
  • Supports FileStream.

Limitations:

  • Available only for Windows Server 2016 and later.
  • Availability zones are not supported.
  • Requires the same disk capacity attached to both virtual machines.
  • High network bandwidth is required to achieve high performance because of ongoing disk replication.
  • Requires a larger VM size and double pay for storage, because storage is attached to each VM.

To get started, see SQL Server failover cluster instance with Storage Spaces Direct.

Premium file share

Premium file shares are a feature of Azure Files. Premium file shares are SSD backed and have consistently low latency. They're fully supported for use with failover cluster instances for SQL Server 2012 or later on Windows Server 2012 or later. Premium file shares give you greater flexibility, because you can resize and scale a file share without any downtime.

Supported OS: Windows Server 2012 and later
Supported SQL version: SQL Server 2012 and later

Benefits:

  • Only shared storage solution for virtual machines spread over multiple availability zones.
  • Fully managed file system with single-digit latencies and burstable I/O performance.

Limitations:

  • Available only for Windows Server 2012 and later.
  • FileStream is not supported.

To get started, see SQL Server failover cluster instance with Premium file share.

Partner

There are partner clustering solutions with supported storage.

Supported OS: All
Supported SQL version: All

One example uses SIOS DataKeeper as the storage. For more information, see the blog entry Failover clustering and SIOS DataKeeper.

iSCSI and ExpressRoute

You can also expose an iSCSI target shared block storage via Azure ExpressRoute.

Supported OS: All
Supported SQL version: All

For example, NetApp Private Storage (NPS) exposes an iSCSI target via ExpressRoute with Equinix to Azure VMs.

For shared storage and data replication solutions from Microsoft partners, contact the vendor for any issues related to accessing data on failover.

Connectivity

You can configure a virtual network name, or a distributed network name for a failover cluster instance. Review the differences between the two and then deploy either a distributed network name or a virtual network name for your failover cluster instance.

The distributed network name is recommended, if possible, as failover is faster, and the overhead and cost of managing the load balancer is eliminated.

Most SQL Server features work transparently with FCIs when using the DNN, but there are certain features that may require special consideration. See FCI and DNN interoperability to learn more.

Limitations

Consider the following limitations for failover cluster instances with SQL Server on Azure Virtual Machines.

Lightweight extension support

At this time, SQL Server failover cluster instances on Azure virtual machines are supported only with the lightweight management mode of the SQL Server IaaS Agent Extension. To change from full extension mode to lightweight, delete the SQL virtual machine resource for the corresponding VMs and then register them with the SQL IaaS Agent extension in lightweight mode. When you're deleting the SQL virtual machine resource by using the Azure portal, clear the check box next to the correct virtual machine to avoid deleting the virtual machine.

The full extension supports features such as automated backup, patching, and advanced portal management. These features will not work for SQL Server VMs registered in lightweight management mode.

MSDTC

Azure Virtual Machines support Microsoft Distributed Transaction Coordinator (MSDTC) on Windows Server 2019 with storage on Clustered Shared Volumes (CSV) and Azure Standard Load Balancer or on SQL Server VMs that are using Azure shared disks.

On Azure Virtual Machines, MSDTC isn't supported for Windows Server 2016 or earlier with Clustered Shared Volumes because:

  • The clustered MSDTC resource can't be configured to use shared storage. On Windows Server 2016, if you create an MSDTC resource, it won't show any shared storage available for use, even if storage is available. This issue has been fixed in Windows Server 2019.
  • The basic load balancer doesn't handle RPC ports.

Next steps

Review cluster configurations best practices, and then you can prepare your SQL Server VM for FCI.

To learn more, see: