Getty Images/iStockphoto

DxEnterprise brings SQL Server AGs to Kubernetes

DxEnterprise for Containers enables SQL Server availability groups to work in Kubernetes, solving a problem that prevented SQL Server users from moving into production.

DH2i has enabled high availability for Microsoft SQL Server in Kubernetes, a move that could solve a vexing conundrum for users.

This week, the vendor launched DxEnterprise for Containers, which allows SQL Server availability groups to work in Kubernetes. Customers who rely on Microsoft's relational database manager to deploy their databases into stateful containers can gain reassurance they will still be available when a cluster or node goes down.

Availability groups provide replicas of SQL Server databases, allowing for automated and immediate failover if the environments hosting the database go down. However, Kubernetes doesn't support SQL Server availability groups. Customers would have to instead rely on Kubernetes' own recovery capabilities, which restore at the pod or node level.

Kubernetes' native recovery could take minutes, which in high-transaction environments isn't good enough, said Don Boxley, CEO of DH2i. By supporting SQL server availability groups, DxEnterprise for Containers enables database-level failover for SQL Server with near-zero recovery time objectives.

Availability groups are the high-availability standard for SQL Server, Boxley said. Customers have been able to put SQL Server databases into stateful containers, but they can't run them in production because they haven't been able to demonstrate that the critical data within is highly available.

For the big customers, they've just been stuck in test/dev. They haven't gone into production because they just don't have that safety net.
Don BoxleyCEO, DH2i

"For the big customers, they've just been stuck in test/dev. They haven't gone into production because they just don't have that safety net," Boxley said.

Furthermore, DxEnterprise for Containers allows customers to deploy availability groups in Kubernetes across availability zones and clouds using its proprietary secure micro-tunnel technology. This allows customers to be as geographically distributed as they need to be to maintain availability or account for customers' region preferences.

DxEnterprise for Containers is licensed separately from other DxEnterprise products (such as for Windows, Linux and Availability Groups in the Cloud) and do not require any other DH2i product to function. When purchased, customers will get a Dockerfile and Docker images for DxEnterprise and SQL Server in order to build their own Docker container running DxEnterprise for Containers.

DxEnterprise for Containers would be a lot easier to consume if it was part of SQL Server or if Microsoft resold it, and the way DH2i packages the product indicates a relatively loose partnership between the two companies, said Dave Raffo, an analyst at Evaluator Group.

Screenshot of DxEnterprise for Containers
DxEnterprise for Containers itself runs in a container.

Microsoft SQL Server users aren't running their production databases in stateful containers, and DH2i is banking on the notion that this is due to the lack of availability groups support in Kubernetes -- and not lack of customer interest, Raffo said. DH2i has to make the first move, and if this is all it takes to convince embedded SQL Server users to stay with the product instead of switching to a competing database such as Amazon RDS or Postgres for containers, then Microsoft will have incentive to integrate with DxEnterprise.

"DH2i could use a tighter partnership with Microsoft, but they have to first convince Microsoft it's worth a greater integration," Raffo said.

DxEnterprise for Containers does have a uniqueness advantage, Raffo said, as he isn't aware of any other third-party vendor products that allow for SQL Server availability groups usage in Kubernetes. There is an open source high-availability cluster manager called Pacemaker that could achieve what DxEnterprise for Containers does. However, due to its open source nature and its lack of guaranteed support, it's "dangerous" to run mission-critical production databases with it, Raffo said.

Dig Deeper on Cloud disaster recovery