SQL Server Availability Groups have been around for a while. A lot of organizations are still in the process of implementing them as they upgrade their database platforms to the latest version of SQL Server. As more and more organizations move away from older versions and into the newer ones, Availability Groups will become much more common. And with the Basic Availability Groups feature made available starting with SQL Server 2016 Standard Edition, it will eventually become a viable replacement for the already deprecated Database Mirroring feature.
In the first installation in this series, I talked about how Active Directory Domain Services (ADDS) authentication and replication affect a SQL Server Availability Group (AG) implementation in a disaster recovery (DR) site. The second installation in this series is about Domain Name System (DNS.) The third installation was all about the Windows Server Failover Cluster (WSFC) heartbeat and how intra-node communications affect the overall health of the WSFC. The fourth one covered how quorum and the voting members in a WSFC affects the overall availability.
We’ve managed to setup and configure Active Directory Domain Services (ADDS,) DNS, the networking, the Windows Server Failover Cluster (WSFC) heartbeat and quorum for a SQL Server Availability Group that stretches across data centers. The one final piece that we need to consider is the client application connectivity. Besides, there’s no sense in preparing a party without inviting any guests. Your databases need to be available to any client application in order to perform transactions, especially during a disaster recovery (DR) situation.
Client Application Connectivity in a Single Data Center Deployment
In a single data center deployment, we barely paid attention to this (well, by now we’ve pretty much proved the point that we barely paid attention to any of the five things we covered in this series.) The developers write the application code, provide the database instance name and connect the application. If you ask any application developer how much time they spend thinking about and connecting the application to the database, I bet the common response would be “less than an hour.” That’s because when they start learning about database programming, they only need to know these things in order to connect to the database:
- – Database driver (needed to connect to the specific database platform – be it Oracle, SQL Server, DB2, etc.)
- – Database server name
- – Database name
- – Credentials
So long as they can connect to the database, they immediately forget about it. In fact, I bet they will tell you that they probably spend more time trying to make the database drivers work – like installing the correct version, 32-bit versus 64-bit, conflicts with other existing database drivers, etc. – than writing the connection string. Same thing goes when dealing with a third-party, off-the-shelf application.
Even systems and database administrators barely paid attention to this. They spend more time making sure that the client application can connect to the database server – opening firewall ports, guaranteeing server name resolution, proper network routing, permissions, etc.
I should know. I was on both sides of the camp in my previous life. And, yes, I didn’t even bother thinking about connection strings. I let the developer tool do that for me.
Client Application Connectivity in a Multi-Data Center Deployment
In a multi-data center deployment, we need to make sure that the client application can still connect to the database when a failover needs to happen, especially in a DR situation. In the past, the typical architecture involved using a DNS alias that points to the database server. The IP address of the database server in the production data center is used to map to the DNS alias. When a failover occurred, the DNS alias is updated with the IP address of the database server in the DR data center. This then required updating the client application’s DNS time-to-live (TTL) value to meet the recovery objective. If the client application connects to a middle-tier, the middle-tier’s DNS TTL value is also updated. Imagine the amount of work that goes into that if you need to deal with thousands of client applications and several other middle-tier servers. This was one of the driving motivations behind moving applications to a more web-based architecture and eventually towards a software-as-a-service (SaaS) one.
Only in the past decade did support for multi-subnet, geographically dispersed clusters were introduced. Windows Server 2008 was the first version of Microsoft’s server operating system that introduced support for multi-subnet WSFC. The OR logic dependency in the WSFC allowed the use of multiple virtual IP addresses for a network name resource, allowing client application to connect to any available IP address.
The Feature Was There All Along
When I got my Samsung S20 phone last year, I didn’t know that there was a feature called Do Not Disturb. So, I ended up leaving my phone in my home office before going to bed. I did not want to get “disturbed” by notifications and messages that came in while I was sleeping. After almost a year of using my phone, I discovered the Do Not Disturb feature. I wish I would have known about it earlier. Now, I just enable the feature between 10:00 PM and 8:00AM and leave it beside my bed instead of in my home office.
If you’re running SQL Server 2012 or higher failover clustered instances (FCI) and Availability Groups, you already have the multi-subnet WSFC feature available to you. But just because the feature is there doesn’t mean you’re already using it. Sure, you can configure the DNS TTL value and modify the RegisterAllProvidersIP property value of the Availability Group Listener Name but that won’t guarantee that the client application will know how to respond. You need to tell it to.
Configuring Client Applications to Support Multi-Subnet Connectivity
By default, when a client application queries the DNS for the Availability Group Listener Name, it will try to connect to the first virtual IP address available. Legacy client applications may not have reconnection logic to try all of the virtual IP addresses assigned to an Availability Group Listener Name and, therefore, will not be able to establish connectivity to the database server. This translates to system unavailability from the client application’s point of view even when the Availability Group is online and available. In order for client applications to support handling multiple virtual IP addresses for an Availability Group Listener Name and eventually be automatically redirected during a failover to a DR data center, they need to be using at least any of the following database drivers.
• – the SQL Server Native Client 11.0
• – the Data Provider for SQL Server in .NET Framework 4.02
• – the Microsoft JDBC Driver 4.0 for SQL Server
A new connection string attribute named MultiSubnetFailover is made available to allow client applications to try all the virtual IP addresses assigned to an Availability Group Listener Name and connects to the first one that responds. In a DR situation, if the virtual IP address assigned to the production database server is unavailable, the client application can try to connect to the virtual IP address assigned to the DR database server, assuming that it is already online. This improves client applications’ connectivity after a failover and, therefore, reduce overall system downtime. No more updating of DNS aliases and client application’s DNS TTL values. As a SQL Server DBA, you can even use the MultiSubnetFailover attribute when connecting to your Availability Groups via SQL Server Management Studio.
Legacy client applications need to update their client libraries to support the MultiSubnetFailover attribute. The downside to this is that your application developers might not speak to you for a while because you have just given them additional work to do – updating the database driver, rewriting database connection strings to include the MultiSubnetFailover attribute and testing the application. But don’t worry about it because they’ll get over it soon because their managers will probably give them more work than you did.
Summary
If you are working with a SQL Server Always On Availability Group that spans multiple data centers, check if you already have your database drivers and client applications’ connection strings updated. If not, plan to get them updated. You want to make sure that your client applications can still connect to the databases in the event of a DR situation.
Schedule a Call
