SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • Products
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • News and Events
  • Clustering Simplified
  • Success Stories
  • Contact Us
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Fix Azure ILB Connection In SQL Server Alwayson Failover Cluster Instance

June 19, 2018 by Jason Aw Leave a Comment

Troubleshooting Azure ILB Connection Issues In A SQL Server Failover Instance Cluster Connection

Troubleshooting Azure ILB Connection Issues In A SQL Server Failover Instance Cluster Connection

I use the following tools to help me deal with troubleshooting SQL Server Failover Cluster Instance Connectivity issues. Especially those pesky Azure ILB Connection Issues. I’ll try to update this article whenever I find a new tool.

NETSTAT

The first tool is a simple test to verify whether the SQL Cluster IP is listening on the port  it should be listening on. In this case, the SQL Cluster IP address is 10.0.0.201. But it is using the default instance which is port 1433.

Here is the command which will help you quickly identify whether the active node is listening on that port. In our case below everything looks normal.

C:\Users\dave.SIOS>netstat -na | find "1433"
TCP    10.0.0.4:49584         10.0.0.201:1433        ESTABLISHED
TCP    10.0.0.4:49592         10.0.0.201:1433        ESTABLISHED
TCP    10.0.0.4:49593         10.0.0.201:1433        ESTABLISHED
TCP    10.0.0.4:49595         10.0.0.201:1433        ESTABLISHED
TCP    10.0.0.201:1433        0.0.0.0:0              LISTENING
ESTABLISHED
TCP    10.0.0.201:1433        10.0.0.4:49592         ESTABLISHED
TCP    10.0.0.201:1433        10.0.0.4:49593         ESTABLISHED
TCP    10.0.0.201:1433        10.0.0.4:49595         ESTABLISHED

Once I can be sure SQL is listening to the proper port, I use PSPING to try to connect to the port remotely.

PSPING

PSPing is part of the PSTools package available from Microsoft. I usually download the tool and put PSPing directly in my System32 folder so I can use it whenever I want without having to change directories.

Now, assuming everything is configured properly from the ILB, Cluster and Firewall perspective, you should be able to ping the SQL Cluster IP address and port 1433 from the passive server. You will get the results shown below…

C:\Users\dave.SIOS>psping 10.0.0.201:1433
PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 10.0.0.201:1433:
5 iterations (warmup 1) connecting test:
Connecting to 10.0.0.201:1433 (warmup): 6.99ms
Connecting to 10.0.0.201:1433: 0.78ms
Connecting to 10.0.0.201:1433: 0.96ms
Connecting to 10.0.0.201:1433: 0.68ms
Connecting to 10.0.0.201:1433: 0.89ms
If things are not configured properly you may see results similar to the following…
C:\Users\dave.SIOS>psping 10.0.0.201:1433
TCP connect to 10.0.0.102:1433:
5 iterations (warmup 1) connecting test:
Connecting to 10.0.0.102:1433 (warmup): 
This operation returned because the time out period expired.
Connecting to 10.0.0.102:1433 (warmup): 
This operation returned because the time out period expired.
Connecting to 10.0.0.102:1433 (warmup): 
This operation returned because the time out period expired.
Connecting to 10.0.0.102:1433 (warmup): 
This operation returned because the time out period expired.
Connecting to 10.0.0.102:1433 (warmup): 
This operation returned because the time out period expired.

If PSPing connects but yet your application is having a problem connecting, you may need to dig a bit deeper. I have seen some application like Great Plains also want to make a connection to port 445. If your application can’t connect but PSPing connects fine to 1433. Then you may need to do a network trace and see what other ports your application is trying to connect to. Your last step would be to add load balancing rules for those ports as well.

NAMED INSTANCES

Planning to use a named instances? You need to make sure you lock down your TCP service to use a static port. At the same time, you also need to make sure you add a rule to your load balancer to redirect UDP 1434 for the SQL Browser Service. Otherwise you won’t be able to connect to your named instance.

FIREWALL

Opening up TCP ports 1433 and 59999 should cover all the manual steps required. But when troubleshooting connection issues, I generally turn the Windows Firewall off to eliminate the firewall as a possible cause of the problem. Don’t forget. Azure also has a firewall called Network Security Groups. If anyone changed that from the default that could be blocking traffic as well.

NAME RESOLUTION

Try pinging the SQL cluster name. It should resolve to the SQL Server cluster iP address. Although I have seen on more than a few occasions, the DNS A-record associated with the SQL Cluster network name mysteriously disappear from DNS. If that is the case, go ahead and read-ad the SQL Custer name and IP address as an A record in DNS.

SQL CONFIGURATION MANAGER

In SQL Configuration Manager, you should see the SQL Cluster IP Address listed and port 1433. If by chance you installed a Named Instance, you of course will need to go in here and lock the port to a specific port and make your load balancing rules reflect that port. Because of the Azure ILB limitation of only on ILB per AG, I really don’t see an valid reason to use a named instance. Make it easier on yourself and just use the default instance of SQL. (Update: as of Oct 2016 you CAN have multiple IP addresses per ILB, so you CAN have multiple instances of SQL installed in the cluster.)

 

Reproduced with permission from Clustering For Mere Mortals.

Filed Under: Clustering Simplified Tagged With: AZURE ILB CONNECTION, Failover Cluster Instances, SQL SERVER ALWAYSON FCI CLUSTER

Azure ILB In ARM For SQL Server Failover Cluster Instances

June 15, 2018 by Jason Aw Leave a Comment

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

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.

Azure ILB In ARM For SQL Server Failover Cluster Instances

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.

Azure ILB In ARM For SQL Server Failover Cluster Instances

  • 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.

Azure ILB In ARM For SQL Server Failover Cluster Instances

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.

Azure ILB In ARM For SQL Server Failover Cluster Instances

  • 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.

Filed Under: Clustering Simplified Tagged With: SQL Server Failover Cluster

Join My Session On Deploying Highly Available SQL Server in Azure

March 31, 2018 by Jason Aw Leave a Comment

@Sqlsatnash Deploying Highly Available SQL Server In #Azure Session At SQL Saturday Nashville, Jan 16th

I’ll be heading to Nashville to share about deploying highly available SQL server. While there, there is a couple of things that I can’t wait to catch up on  – Technology and music. While I’m there, I certainly hope I am able to have some good music at The Station Inn.

Come By My Session On Deploying Highly Available SQL Server in Azure

Jan 16th is going to be a great day of learning and networking. Hang out with my #SQLPass family and join my session. This hour long session is great for those who are keen in learning about deploying SQL Server in Azure.

On Cloud Database/Application Development & Deployment

As we are already aware, Windows Azure is an excellent IaaS platform to deploy SQL Server. There is a need to plan for high availability and disaster recovery even as Microsoft manages the infrastructure. In this session, learn how to leverage Azure Fault Domains, Upgrade Domains, and Internal Load Balancers to ensure high availability of SQL Server deployments within the Azure cloud. You will learn to see the difference between Azure Classic and Azure Resource Manager. And at the same time, how it would affect your SQL Server availability. While Microsoft Azure offers SLA’s of 99.95%, make sure your SQL Server deployment qualifies. Again, this session is best suited for those with intentions to move or have already moved your SQL Servers instances to Azure. By the way, participants for this session should have a basic knowledge of SQL Server AlwaysOn Failover Clustering as well as Availability Groups. But if you don’t, no fear because you should be able to catch up pretty fast with a little bit of practice and experimenting.

Reproduced with permission from https://clusteringformeremortals.com/2015/12/21/sqlsatnash-deploying-highly-available-sql-server-in-azure-session-at-sql-saturday-nashville-jan-16th/

Filed Under: Clustering Simplified Tagged With: Azure, Clustering, Highly Available SQL Server, SQL Server

Advantages of Azure Resource Manager You Must Know

March 31, 2018 by Jason Aw Leave a Comment

Advantages Of Azure Resource Manager And Highly Available SQL Server Deployments In Azure

Azure Resource Manager (ARM) is the latest and greatest way to work with Microsoft Azure IaaS. The advantages of Azure Resource Manager is plenty – template deployments, grouping, simplified billing and many more. This new model promises new features and more interaction.

Catch The Webinar

Microsoft Cloud and Datacenter Management MVP David Bermingham will introduce ARM and take a closer look at how to make use of ARM to enable highly available and scalable SQL Server deployments in the cloud.

Sign up for this webinar here… https://www.mssqltips.com/webcastSignupPage.asp?id=480&src=sios

Reproduced with permission from https://clusteringformeremortals.com/2015/12/15/key-benefits-of-working-with-azure-resource-manager-and-highly-available-sql-server-deployments-in-azure/

Filed Under: Clustering Simplified Tagged With: advantages of azure resource manager, Azure Resource Manager, David Bermingham, SQL Server Deployments, Webinar

Azure Resource Manager And Highly Available SQL Server Webinar

March 31, 2018 by Jason Aw Leave a Comment

Keen To Know How To Leverage ARM For Highly Available And Scalable SQL Server Deployment?

Well, if your answer is yes, then I’ve a great recommendation for you. Especially, if you’re interested to understand why Azure Resource Manager (ARM) is the latest and easiest way to work with Microsoft Azure IaaS, there’s a webinar happening on Dec 15 which would be perfect for you. It’s pretty great to work with ARM. First up, there is template deployments, grouping, simplified billing and much more. You have to try for yourself some of these new features, and the different new interaction ways with this new model.

See What Azure Resource Manager Can Do

Join Microsoft Cloud and Datacenter Management MVP David Bermingham as he introduce ARM. Take a close look at how you can use the power of ARM to deploy highly available and scalable SQL Server deployments in the cloud.

When: December 15th

Time: 1:00 PM EST/10:00 PST

Sign up here – https://www.mssqltips.com/webcastSignupPage.asp?id=480&src=sios

Reproduced with permission from https://clusteringformeremortals.com/2015/11/16/azure-resource-manager-and-highly-available-sql-server-webinar-sqltips/

Filed Under: Clustering Simplified Tagged With: Azure Resource Manager, SQL server deployment

  • « Previous Page
  • 1
  • …
  • 84
  • 85
  • 86
  • 87
  • 88
  • …
  • 105
  • Next Page »

Recent Posts

  • Streamlining External Communication for Emergency Procedures
  • Avoiding the Disaster You Don’t See Coming: Building a Resilient DR Plan
  • The Best Rolling Upgrade Strategy to Enhance Business Continuity
  • How to Patch Without the Pause: Near-Zero Downtime with HA
  • SIOS LifeKeeper Demo: How Rolling Updates and Failover Protect PostgreSQL in AWS

Most Popular Posts

Maximise replication performance for Linux Clustering with Fusion-io
Failover Clustering with VMware High Availability
create A 2-Node MySQL Cluster Without Shared Storage
create A 2-Node MySQL Cluster Without Shared Storage
SAP for High Availability Solutions For Linux
Bandwidth To Support Real-Time Replication
The Availability Equation – High Availability Solutions.jpg
Choosing Platforms To Replicate Data - Host-Based Or Storage-Based?
Guide To Connect To An iSCSI Target Using Open-iSCSI Initiator Software
Best Practices to Eliminate SPoF In Cluster Architecture
Step-By-Step How To Configure A Linux Failover Cluster In Microsoft Azure IaaS Without Shared Storage azure sanless
Take Action Before SQL Server 20082008 R2 Support Expires
How To Cluster MaxDB On Windows In The Cloud

Join Our Mailing List

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in