DH2i Adds Operator to Simplify SQL Server High Availability on Kubernetes
DH2i today made generally available an Operator that makes it simpler to deploy a platform for ensuring high availability of instances of the Microsoft SQL Server database running on Kubernetes clusters.
Operators are extension to Kubernetes custom resources that use a standard set of application programming interfaces (APIs) that have emerged as a primary method for automating the deployment of software on Kubernetes clusters.
DH2i CEO Don Boxley said DxOperator makes it simpler to deploy a DxEnterprise platform that orchestrates multiple instances of a database to ensure high availability. In the event of a failure, DxEnterprise ensures another instance of a database is available to service a workload in a matter of minutes. DH2i achieves that goal by automating the networking tunnel setup required for cluster communication and replication across availability groups (AGs) without requiring IT teams to manually open ports to provision a virtual private network (VPN). IT teams can mix and match instances of Microsoft SQL Server running on Windows or Linux platforms as they see fit, regardless of whether they are deployed on virtual machines, bare metal servers or in the cloud.
Other capabilities that can be automatically implemented via DXOperator include custom pod naming, node selection and affinity, SQL availability group customization and load balancing along with support for custom annotations, specific container specifications and quality of service (QoS) parameters.
Operators are playing a major role in reducing the complexity of Kubernetes environments. In addition to the Operators provided by various vendors, some IT teams are creating their own Operators to simply the deployment of an entire stack of software. As more stateful applications are deployed on Kubernetes clusters, the need to be able to simplify the deployment of multiple software components is becoming a more pressing issue.
It’s not clear how frequently IT organizations are deploying stateful applications on Kubernetes clusters, but the pace has increased considerably over the last few years. Some organizations still prefer to deploy stateless applications on Kubernetes that access external storage, but there is an increasing number of instances of applications being deployed where there are no existing storage resources to access. The more mission-critical those applications are, the greater the imperative to ensure high availability.
At this juncture, there are a lot more containerized applications running on Linux than on Windows platforms. However, ever since containers were made available on Windows, the number of containerized applications running on Windows has steadily increased. It may still be a while before Windows catches up to Linux in terms of the number of containerized applications deployed, but that gap has narrowed considerably in the last few years.
Regardless of the platform employed, the one thing that is certain is tolerance for outages has declined as more organizations appreciate how dependent they are on software to function. While high availability may have once been a capability reserved for only the most critical applications, it’s now become a much more important requirement for a wider range of applications. The challenge, as always, is finding the least expensive way to ensure it.
