Over the last four years, Microsoft SQL Server containers in Linux have become an even more important piece in the product roadmap. Microsoft has continued to improve upon and invest in these containers, and there’s no doubt that containers can help IT operations in many ways. Some of the best features of containers, besides the fact that they are stateful, include portability, security, and customization – not to mention the fact that there is no installation required. After locally downloading the image, IT can simply deploy the containers and have a full-fledged SQL Server running in their environment, whether with or without Kubernetes (K8s), in less than five seconds with a single command. These five benefits are among the reasons many companies rely on SQL Server containers – for example, in hybrid environments on Windows and Linux deployed in K8s environments.
But if you’re hoping to use Microsoft SQL Server or other containerized stateful workloads, there’s a problem to solve first: how you’ll effectively implement high availability (HA). Your first thought to address this challenge might understandably be turning to K8s, which are adept at automating everything from computer application management and deployment to scaling. Yet the native HA of K8s on its own is too slow to support the workloads of SQL Server. Kubernetes also traditionally have not been able to support the standard technology often used for SQL Server HA: SQL Server Availability Groups (AG) with automatic failovers.
What to Do?
A key obstacle to wider container adoption lies in HA implementation. You can overcome the HA dilemma – and achieve HA and business continuity with SQL Server containers – via a new class of smart high availability clustering software, which represents the convergence of HA and software-defined perimeter (SDP) solutions. The software:
- Supports SQL Server AG in Kubernetes with automatic failovers
- Creates hybrid SQL Server AG clusters on platforms like Azure Kubernetes Service (AKS) and Red Hat OpenShift without using virtual private networks (VPNs).
- Protects from node failures within containers/apps
- Offers fast database-level failovers
- Simplifies HA and disaster recovery (DR) networking and configuration with zero trust network access (ZTNA) tunnels
Here are three use cases for smart high availability clustering software:
Use Case 1: For SQL Server AG high availability at the database level, use K8s to provide pod-level HA for SQL Server containers and smart high availability clustering software without clunky VPN solutions.
This simplifies setting up SQL Server clustering and provisioning your SQL Server AG and can be offered as a clustering service installed on each SQL Server container that performs the core management, network management, fault detection, and failover automation for the SQL Server AG in Kubernetes.
Use Case 2: Use smart high availability clustering software to run, in the same SQL Server AG cluster, a Windows VM, some Linux nodes, and containers in Azure.
The flexible software enables mix-and-match since the clustering supports both Windows and Linux and can run both inside and outside of containers.
Use Case 3: When you need to migrate SQL Server from on-premises node to cloud nodes that are housed in isolated networks, leverage smart high availability clustering software’s built-in secure zero trust network access (ZTNA) tunneling feature to unlock hybrid cloud capabilities.
Smart high availability clustering software can assist in migrating from platform to platform. This also helps the container use case, handling the networking for cluster communication and SQL Server AG replication between nodes.
The HA You Need
Approaches like K8s alone likely won’t meet the production HA requirements that many enterprises have for SQL Server. But since smart high availability clustering software can be run inside or outside K8s, IT can set up SQL Server clusters in different locations using secure ZTNA tunneling.
Using smart high availability clustering software, organizations can overcome the challenges of implementing SQL Server AG for containers with automatic failover, safeguarding against node, container, and app failures.