Requirements

The following requirements are needed. More information on how to setup a domain controller in Azure can be found here.

1. Visual Studio Code – Not a requirement, but provides intellisense for Azure CLI. The following extensions were installed as well.
   1. Azure Account
   2. Azure CLI Tools
2. Azure account
3. Resource group
4. Virtual Network
5. Virtual machine as the domain controller
6. Storage account which can be used as the cloud witness for the FCI
7. Two Azure VMs running Windows Server 2019
8. Azure availability set
9. Proximity group

We’ll assume the resource group, virtual network, domain controller, and storage account (to be used as the cloud witness), are already in place within a region which currently supports premium shared disks. Check here for a list of regions which currently support premium shared disks. You’ll also need to request access to try premium shared disks. (https://aka.ms/AzureSharedDiskGASignUp)

Proximity placement group

My demo virtual network and domain controller currently reside within the West Central US region. Placing the clustered virtual machines within a proximity placement group achieves the lowest possible latency between the two. This is a logical grouping to make sure Azure compute resources are located close to each other. For more information, see here.

After logging into your account, using Azure CLI (https://bit.ly/3ib2I2F) and setting your subscription using “az account set”, create the proximity group.

az ppg create --name SERO_FCI_PPG --location westcentralus --type standard --resource-group SERO_FCI_RG --tags "Purpose=FCI Demo"

Availability Set

Next, we need to create an availability set. An availability set is a logical group in Azure to ensure VM resources are isolated from each other and utilize separate physical servers, compute racks, storage units, and network switches. By using an availability set and FCI, we can ensure one node will be online during typical maintenance, such as patching, and reduce impact of single points of failure. However, an availability set does not provide data center redundancy. For more information, see here and here. The script below creates an availability set which uses 1 platform fault domain and 1 platform update domain.

az vm availability-set create --name SERO_FCI_AvailabilitySet --resource-group SERO_FCI_RG --location westcentralus --platform-fault-domain-count 1  --platform-update-domain-count 1 --tags "Purpose=FCI Demo" --ppg SERO_FCI_PPG

Virtual Machines

With the proximity group and availability set in place, we’re now ready to create our virtual machines. I’m using the Standard_D2s_v3 VM size and a few variables to avoid repeating them for each vm creation script. You could use a loop here as well. Be sure to update the values to match your environment.

availabilityset="SERO_FCI_AvailabilitySet"
adminusername="yourAdminUserName"
resourcegroup="SERO_FCI_RG"
imagevar="Win2019Datacenter"
vnetname="SERO_FCI_WESTCENTRALUS_NETWORK"
subnetvar="Internal"
sizevar="Standard_D2s_v3"
tagvar="Purpose=FCI Demo"
proximitygroup="SERO_FCI_PPG"
az vm create --name SEROFC1 --admin-username $adminusername --resource-group $resourcegroup --image $imagevar --vnet-name $vnetname --nsg '' \
--subnet $subnetvar --size $sizevar --tags $tagvar --availability-set $availabilityset --public-ip-address '' --ppg $proximitygroup
az vm create --name SEROFC2 --admin-username $adminusername --resource-group $resourcegroup --image $imagevar --vnet-name $vnetname --nsg '' \
--subnet $subnetvar --size $sizevar --tags $tagvar --availability-set $availabilityset --public-ip-address '' --ppg $proximitygroup

Add VMs to your domain

At this stage, go ahead and add the virtual machines to the domain and apply the latest updates. If your network restricts port access between machines on the same network, you may need to adjust your network security groups and the windows firewall. For this demo, I’ve disabled the windows firewall (disclaimer: not best practice and should be avoided in a real world scenario).

Create the premium shared disk

Now the exciting part :). Save the following json and modify to match your environment and the size of disk you wish to use. I saved the file as ShardDiskConfig.json.

{ 
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "dataDiskName": {
      "type": "string",
      "defaultValue": "SEROFCI_SharedDisk"
    },
    "dataDiskSizeGB": {
      "type": "int",
      "defaultValue": 256
    },
    "maxShares": {
      "type": "int",
      "defaultValue": 2
    }
  },
  "resources": [
    {
      "type": "Microsoft.Compute/disks",
      "name": "[parameters('dataDiskName')]",
      "location": "[resourceGroup().location]",
      "apiVersion": "2019-07-01",
      "sku": {
        "name": "Premium_LRS"
      },
      "properties": {
        "creationData": {
          "createOption": "Empty"
        },
        "diskSizeGB": "[parameters('dataDiskSizeGB')]",
        "maxShares": "[parameters('maxShares')]"
      }
    }
  ] 
}

Next, create the shared disk using the “az deployment group create” command and the config saved within the json file.

az deployment group create --resource-group SERO_FCI_RG --template-file /Users/lukecampbell/OneDrive/Lab/SharedDiskConfig.json

Attaching the shared disk

Next, we’ll need to attach the newly created shared disk to both of the virtual machines. Modify the values below to match your environment.

resourcegroup="SERO_FCI_RG"
location="westcentralus"
proximitygroup="SERO_FCI_PPG"
diskId=$(az disk show -g $resourcegroup -n SEROFCI_SharedDisk --query 'id' -o tsv)

az vm disk attach --resource-group $resourcegroup --vm-name SEROFC1 --name $diskId 
az vm disk attach --resource-group $resourcegroup --vm-name SEROFC2 --name $diskId 

Format shared disk

Now we’ll need to initialize the attached disk as a GPT partition and format using NTFS. This can be done using the Azure CLI or Powershell commandlets. I opted to remote into each VM and format using the disk management utility. No need to assign a drive letter at this step.

Create the failover cluster

We’re ready to create the failover cluster. If you’re familiar with creating clusters on premises, this is no different. However, since we’re setting up a SQL Server 2016 FCI, we’ll need to create a Azure internal load balancer (ILB) to hold the IP address of the virtual network name in which the SQL Server instance listens on. I won’t cover the cluster creation in detail here but the following is a summary of the steps required:

1. Install the failover cluster feature and management tools on both VMs.
2. Create the cluster
3. Add the shared disk to the cluster. I’ve assigned drive letter F to this disk.

One important note. The cluster will be created using a Distributed Network Name by default. SQL Server 2016 does not support DNN access points. By using the powershell statement below, you can create the cluster and a virtual network name instead.

New-Cluster -Name <FailoverCluster-Name> -Node ("<node1>","<node2>") –StaticAddress <n.n.n.n> -NoStorage -ManagementPointNetworkType Singleton

The new switch, ManagementPointNetworkType, allows you to specify either of the following values:

• Singleton: Use the traditional method of DHCP or static IP address.
• Distributed: Use a Distributed Network Name using node IP addresses.
• Automatic: Use detection. If running in Azure, use Distributed; if running on-premises, use Singleton (the default).

SQL Server 2016 install

Install SQL Server 2016 using the failover cluster installation wizard on both VMs. Assign an IP address for the virtual network name. Again, these steps are the same as when creating a FCI on premises. Below is a screenshot of the end result for my installation.

Load balancer

At this point, you should have a fully functional FCI. However, you won’t be able to connect remotely yet. We need to configure an Azure Load Balancer to hold the IP address assigned to the virtual network name of the FCI. The load balancer will route traffic to the primary node in the FCI. These steps could be achieved using the Azure CLI if needed. I opted to use the Azure portal following the steps provided here and create a basic ILB.

1. Frontend IP configuration (IP Address should match the IP address of the FCI virtual network name).

2. Backend pool – Contains the virtual machines hosting the FCI.

3. Health probes

4. Load balancing rules

After the load balancer has been configured, be sure to modify and run the powershell script here. The probe port must match the port provided when creating the health probes for the ILB. In this example, we used port 59999. If you have any issues with failovers, check all firewalls (both windows and the network security group rules in Azure). The script below is what I used when creating the demo. This only needs to be executed on one of the cluster nodes. Once completed, take the FCI offline and online again for the settings to take effect.

$ClusterNetworkName = "Cluster Network 1"
$IPResourceName = "SQL IP Address 1 (SQLSERVERFC1)" 
$ILBIP = "10.3.1.10" 
[int]$ProbePort = 59999

Import-Module FailoverClusters

Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName"
;"EnableDhcp"=0}

Connecting to the FCI

I verified connectivity to the FCI by installing SQL Server Management Studio on a third VM.

Failover to test connectivity.

Conclusion

I’m excited to see shared disks as an available option in Azure. We’ll build on this series next week by creating a SQL Server 2019 FCI and utilize the new distributed network name feature vs the load balancer. Let us know your thoughts regarding this option for high availability and if it’s something you may be interested in leveraging in the future.

Thanks for reading!

The post Azure shared disks – Failover Clustered Instance – SQL Server 2016 appeared first on The SERO Group.

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;

1. Using Azure Ultra Disks
2. Premium SSDs

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.

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

Conclusion

Let us know your thoughts regarding this option for high availability and if it’s something you may be interested in leveraging in the future.

Thanks for reading!

The post How to Create SQL Server 2019 Failover Clustered Instances in Azure appeared first on The SERO Group.