Using SQL Server Availability Groups in Kubernetes environments

Ensuring high availability for your databases is essential for today’s businesses. Always on availability groups, first introduced in Microsoft SQL Server 2012 and enhanced in later versions, provide a mechanism for supporting failover environments for discrete sets of user databases. The result is that when an availability group (AG) fails over, it does so at the level of an availability replica without the need for database mirroring. AGs can be implemented for both high availability or simply for read-scale to increase workload efficiency. Until recently, AGs have not been supported in Kubernetes. This has hindered some organizations from deploying SQL Server in containers despite the benefits of doing so. Now, however, everything has changed, and to learn more about the exciting new developments in this area I recently had a talk with Don Boxley, CEO and co-founder of DH2i.

Don Boxley DH2i CEO
Don Boxley

MITCH: Don, what’s the driving need behind wanting to provide support for SQL Server availability groups (AGs) in containers orchestrated by Kubernetes?

DON: Customers’ need for tier-1 failover performance for cloud-native stateful container workloads is a main driver. Kubernetes (K8) built-in pod/node-level cluster high availability (HA) is fine for stateless container workloads, but it’s too slow for stateful container workloads like SQL Server.

MITCH: What does DH2i’s new DxEnterprise (DxE) for Availability Groups in Containers solution provide in this area?

DON: DxE for AGs in Containers gives SQL Server container users the tier-1 database-level failover performance of always-on availability groups (AG) they’re used to when running SQL Server in VMs or bare-metal. This makes DxE for AGs in Containers the perfect complement to Kubernetes’ pod/node-level cluster HA. This capability enables customers to deploy stateful containers to create new and innovative applications with confidence while improving IT operations.

MITCH: What kinds of difficulties or challenges did DH2i face in bringing support for SQL Server AGs to Kubernetes environments?

DON: The architecture choices made by the development team (they’re really good!) years ago made supporting Kubernetes fairly straightforward. But that being said, the biggest challenge was passing Microsoft’s evaluation for the solution. We had a very high bar to hurdle.

MITCH: How does DxEnterprise for AGs in Containers work exactly?

DON: The diagram below shows the use case of SQL Server AGs for Kubernetes in the cloud:

How DxEnterprise for AGs in Containers works

In this example, the user has created two Kubernetes clusters — one in Azure Region 1 and one in Azure Region 2 using the Azure Kubernetes Service. Each cluster has two SQL Server+DxE containers for a total of four containers. After this, the customer uses DxE to create an AG with automatic failover across the four containers the spans Availability Zones and Regions. DxE automatically builds the Micro Express-Tunnels required for cluster communication and AG replication. Users are left with a strong layer of high availability added to their containerized SQL Server environment.

Here’s the link to DxEnterprise 21.0 Software SQL Server Availability Groups for Kubernetes StatefulSets on Azure Quick Start Guide (PDF). We also have a free Developer Edition version, so users can get started.

MITCH: What sort of experience can SQL Server admins who work in traditional enterprise environments expect when they work with DxEnterprise for AGs in Containers once they’ve migrated their databases to Kubernetes environments? Will there be much they’ll need to relearn for managing SQL Server instances running in containers?

DON: Running SQL Server in Kubernetes is the same as running SQL Server in a traditional environment. The same is true for using DxE to create and manage AGs. It’s the same experience for users.

MITCH: What additional benefits can enterprises anticipate from using DxEnterprise for AGs in Containers compared with existing approaches to providing high availability for SQL Server instances, for example, by using Pacemaker for HA Linux clusters running in containers?

DON: First, I want to say that DxE is the only solution on the market that provides SQL Server AG support in Kubernetes. Not Pacemaker, not WSFC, not anything else. Additionally, DxE for Containers uses its built-in secure multi-subnet Express Micro-Tunnel technology to support distributed Kubernetes AG clusters across availability zones/regions, hybrid cloud, and multicloud environments without VPNs or other network connectivity technologies. This enables customers to rapidly adapt to changes in market conditions and consumer preferences. Again, no one else can do this. Aside from the setup/management complexities of Pacemaker and other clustering solutions that set DxE apart, customers can also mix and match support for Windows and Linux, bare metal, virtual, cloud servers, and containers with fully automatic AG support to maximize IT budget ROI. Nothing else on the market can do this as well.

MITCH: Don any final words you’d like to add on this subject?

DON: We know customers are wanting to leverage stateful containers in Kubernetes. They’ve been developing and testing. Now they can move them into production to accelerate their digital transformation (DX) projects.

MITCH: Thanks for sharing some of your valuable time with our readers.

DON: My pleasure.

Featured image: Shutterstock

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top