Azure shared disks – Failover Clustered Instances

Luke Campbell — Tue, 01 Sep 2020 13:00:00 +0000

Azure offers a large array of options when it comes to high availability and disaster recovery. Failover clustered instances (FCIs) is a well known option, for SQL Server, that’s been available for years on premises. However, FCIs traditionally required shared storage. New versions of the Windows OS and SQL Server now support other options such as file shares and storage spaces direct. Each of these options have their pros and cons. As of July 27th, 2020 Azure Shared Disks are generally available. We’ll focus on this option for both SQL Server 2016 and SQL Server 2019 over the next couple blog posts.

Why should I care about shared disks?

Azure shared disk enable the ability to utilize FCIs and reduce storage consumption. Previously, if you created an FCI instance and didn’t want to use a file share, storage spaces direct was required and doubled the amount of space needed. Another option was to set up Availability Groups. Again, doubling the space and possibly requiring Enterprise editions of SQL Server (prior to basic availability groups being introduced). If you’re needing to migrate to Azure, and utilize IaaS vs PaaS and retain high availability, this is a great addition to the array of available options. Plus, unless you specifically need Enterprise edition features, you may be able to keep Standard edition further reducing costs.

What type of disks do I need to use?

Shared disks are currently available on two disk types; ultra and premium. Each type has there own list of limitations. Rather than listing those here, and the information becoming out of date, review the following links for the most up to date information;

Which regions are shared disks currently available in?

Shared ultra disks are available within all regions which currently support ultra disks. See here for the latest list of regions. Premium shared disks are available in the regions listed here. If you’re using premium shared disks, you’ll need to request access using the form located at https://microsoft.qualtrics.com/jfe/form/SV_cMCj3LBlv47M6xL.

How do I get started?

This is an exciting option for those looking to migrate on-premises failover clustered instances to Azure with little modification. To get started, review Microsoft’s latest announcement, and the links provided above, to determine if this is the right option. We’ll be creating additional posts over the next few weeks detailing how to setup two node clusters using Windows Server 2019, SQL Server 2016, and SQL Server 2019. There are some major differences when using SQL Server 2016 and SQL Server 2019 which will be explained throughout the posts. SQL Server 2016 FCIs requires the use of an Azure load balancer and we’ll provide examples of a complete setup. SQL Server 2019 CU2 introduces a new feature, distributed network name, which further simplifies setup. You can read more on this feature here.

How can we help?

We’d be more than happy to discuss your move to Azure FCIs or any upcoming migration projects. Contact us here to schedule a call.

Be sure to check back soon! Better yet, go ahead and subscribe to get notified when new posts are available 😄.

Thanks!

The post Azure shared disks – Failover Clustered Instances appeared first on The SERO Group.

How to Create SQL Server 2019 Failover Clustered Instances in Azure

Luke Campbell — Sun, 30 Aug 2020 17:33:55 +0000

Most of what you see in this post is similar to our prior post in the series – Azure shared disks – Failover Clustered Instance – SQL Server 2016. The key difference when setting up Failover Clustered Instances with SQL Server 2019 in Azure is we’re not going to utilize an Azure Load Balancer to provide access to the failover clustered instance. We’re going to focus on the Distributed Network Name access point.

Distributed Network Name access point

In SQL Server 2019 CU2 (or later) failover clustered instances, the listener was enhanced to work with the Windows Server Failover Cluster DNN access points. Prior to supporting DNN access points, a virtual IP access point was used but wasn’t supported in Azure without creating a load balancer. DNN access points reduce the complexity of FCIs in Azure by allowing the SQL client to connect without the need for a load balancer.

Create the cluster and failover clustered instance

Creating the cluster, using Azure Shared Disks, was covered in our previous post here. The difference is that we’re installing a SQL Server 2019 FCI and then applying CU 7 to ensure distributed network names are supported. Go ahead and create your Windows failover cluster and then create the SQL Server 2019 FCI. You won’t be able to connect to the FCI instance just yet because we’re not setting up an Azure load balancer. Failover the clustered role to all nodes within the cluster just to ensure there’s no issues.

Create the DNN

After the FCI has been created, we’ll need to rename the virtual network name resource. However, this isn’t required if you’re planning to use a different name for the DNN and access the instance using a different DNS name than you specified when setting up the FCI. I renamed mine to SEROSQLFC_VNN (shown below). To rename, right click on the Server Name resource in Failover Cluster Manager, and choose properties. I appended the existing name with “_VNN”. Don’t delete this resource as it is a required component of the FCI infastructure.

Next, create the DNN. I’ll be using SEROSQLFC to access the instance and used the powershell script below to create it.

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

Get-ClusterResource -Name SEROSQLFC_DNN | Set-ClusterParameter -Name DnsName -Value SEROSQLFC

Once created, you should see a new resource within the cluster role.

Bring the DNN online. The instance must be restarted before accessing. I typically failover to the other node, attempt to access the instance from a remote server using SSMS, and then failback to ensure the instance can be accessed when hosted on either node.

IP conflicts and how to avoid them

When using a distributed network name access point there’s no longer a load balancer reserving virtual IP address in Azure and there’s a risk that another resource on the virtual network will be assigned the same IP address as the virtual IP address used by the FCI. This can lead to an IP conflict. The powershell script below was used to create an APIPA address to avoid this issue. Another option is to create a dedicated network adapter in Azure and reserve the IP address used by the virtual IP address resource. Both of these options can be seen here.

Retrieve the virtual IP resource name by opening Failover Cluster Manager and right clicking on the IP address resource (example below). Choose properties and note the resource name.

Get-ClusterResource "SQL IP Address 1 (SEROSQLFC)" | Set-ClusterParameter –Multiple @{"Address”=”169.254.1.1”;”SubnetMask”=”255.255.0.0”;"OverrideAddressMatch"=1;”EnableDhcp”=0}

Take the IP Address resource offline and back online for the changes to take effect. This will also take SQL Server offline so these resources will need to be restarted as well.

Additional resources for Creating Failover Clustered Instances

Distributed network names and shared disks simplify the usage of FCIs in Azure. However, there a few issues to watch out for. This post is not meant to provide an in depth review but a quick overview of what is possible using these new features available in Azure, Windows OS (since 2016), and SQL Server 2019 (cu2 or later). The resources below provide additional detail on the use of DNNs.

FCI DNN & SQL Server features

Rename a SQL Server Failover Cluster Instance

Create DNN for FCI