Configuring The #AZURE ILB In ARM For SQL Server Failover Cluster Instance Or AG Using AZURE Powershell 1.0

In an earlier post I went into some great detail about how to configure the Azure ILB in ARM for SQL Server Failover Cluster or AG resources. The directions in that article were written prior to the GA of Azure PowerShell 1.0. With the availability of Azure PowerShell 1.0 the main script that creates the ILB needs to be slightly different. The rest of the article is still accurate. However if you are using Azure PowerShell 1.0 or later the script to create the ILB described in that article should be as follows.

#Replace the values for the below listed variables
$ResourceGroupName ='SIOS-EAST' # Resource Group Name in which the SQL nodes are deployed
$FrontEndConfigurationName = 'FEEAST' #You can provide any name to this parameter.
$BackendConfiguratioName = 'BEEAST' #You can provide any name to this parameter.
$LoadBalancerName = 'ILBEAST' #Provide a Name for the Internal Local balance object
$Location ='eastus2' # Input the data center location of the SQL Deployements
$subname = 'public' # Provide the Subnet name in which the SQL Nodes are placed
$ILBIP = '10.0.0.201' # Provide the IP address for the Listener or Load Balancer
$subnet = Get-AzureRMVirtualNetwork -ResourceGroupName $ResourceGroupName | 
Get-AzureRMVirtualNetworkSubnetConfig –name $subname
$FEConfig=New-AzureRMLoadBalancerFrontendIpConfig -Name $FrontEndConfigurationName 
-PrivateIpAddress $ILBIP -SubnetId $subnet.Id
$BackendConfig=New-AzureRMLoadBalancerBackendAddressPoolConfig 
-Name $BackendConfiguratioName
New-AzureRMLoadBalancer -Name $LoadBalancerName -ResourceGroupName $ResourceGroupName 
-Location $Location -FrontendIpConfiguration $FEConfig 
-BackendAddressPool $BackendConfig

The rest of that original article is the same, but I have just copied it here for ease of use…

Using GUI

Now that the ILB is created, we should see it in the Azure Portal in Resource Group. See pic below.

The rest of the configuration can also be completed through PowerShell, but I’m going to use the GUI in my example.

If you want to use PowerShell, you could probably piece together the script by looking at this article. Unfortunately, this article confuses me. I’ll figure it out some day and try to document it in a user friendly format. As of now, I think the GUI is fine for the next steps.

Let’s Get Started

Follow along with the screen shots below. If you get lost, follow the navigation hints at the top of the Azure Portal to figure out where we are.

First Step

• Click Backend Pool setting tab. Selects the backend pool to update the Availability Set and Virtual Machines. Save your changes.

• Configure Load Balancer’s Probe by clicking Add on the Probe tab. Give the probe a name and configure it to use TCP Port 59999. I have left the probe interval and the unhealthy threshold set to the default settings. This means it will take 10 seconds before the ILB removes the passive node from the list of active nodes after a failover. Your clients may take up to 10 seconds to be redirected to the new active node. Be sure to save your changes.

Next Step

• Navigate to the Load Balancing Rule Tab and add a new rule. Give the rule a sensible name (SQL1433 or something). Choose TCP protocol port 1433 (assuming you are using the default instance of SQL Server). Choose 1433 for the Backend port as well. For the Backend Pool, we will choose the Backend Pool we created earlier (BE). For the Probe that we will also choose the Probe we created earlier.

We do not want to enable Session persistence but we do want to enable Floating IP (Direct Server Return). I have left the idle timeout set to the default setting. You might want to consider increasing that to the maximum value. Reason is that I have seen some applications such as SAP log error messages each time the connection is dropped and needs to be re-established.

• At this point the ILB is configured. There is only one final step that needs to take place for SQL Server Failover Cluster. We need to update the SQL IP Cluster Resource just the exact same way we had to in the Classic deployment model. To do that you will need to run the following PowerShell script on just one of the cluster nodes. Make note, SubnetMask=“255.255.255.255” is not a mistake. Use the 32 bit mask regardless of what your actual subnet mask is.

One Final Note

In my initial test I still was not able to connect to the SQL Resource name even after I completed all of the above steps. After banging my head against the wall for a few hours I discovered that for some reason the SQL Cluster Name Resource was not registered in DNS. I’m not sure how that happened or whether it will happen consistently, but if you are having trouble connecting I would definitely check DNS and add the SQL cluster name and IP address as a new A record if it is not already in there.

And of course don’t forget the good ole Windows Firewall. You will have to make exceptions for 1433 and 59999 or just turn it off until you get everything configured properly like I did. You probably want to leverage Azure Network Security Groups anyway instead of the local Windows Firewall for a more unified experience across all your Azure resources.

Good luck and let me know how you make out.

Head over here to see how SIOS helped companies across the globe with creating SQL Server Failover Cluster.

Reproduced with permission from Clustering For Mere Mortals.