The session, titled Simplify Hybrid SQL Server: Windows & Red Hat OpenShift Side By Side, is scheduled for 12:00 p.m. Eastern on Thursday, August 20. DH2i says Microsoft’s Amit Khandelwal, Red Hat’s Vivien Wang, and DH2i co-founder and CTO OJ Ngo will demonstrate operator-based deployment of a Kubernetes SQL Server AG cluster, zero-trust tunnels between replicas, and high-availability automation spanning Windows Server and OpenShift.
For organizations attempting to move SQL Server development, test, or selected production workloads into containers without a single cutover, that is a real operational problem. The announcement also packages together several separate functions—SQL Server data replication, cluster quorum and failover decisions, Kubernetes lifecycle management, client connectivity, and encrypted cross-network access—that are often mistaken for one product feature.
The webinar is a DH2i solution demonstration, not a new Microsoft SQL Server capability
DH2i’s event page describes a deployment that places one SQL Server replica on a Windows Server virtual machine and another inside Red Hat OpenShift, with DxEnterprise handling clustering and DxOperator automating the Kubernetes side. The company also says its built-in zero-trust network access tunneling can connect those nodes without the conventional approach of opening ports or maintaining a site-to-site VPN.
Microsoft’s own SQL Server documentation supports the key distinction. A standard cross-platform Availability Group containing Windows and Linux replicas can be configured with
CLUSTER_TYPE = NONE, but Microsoft documents that arrangement for migration, read-scale, or disaster-recovery use—not for true high availability. With no common cluster manager coordinating health, quorum, fencing, and automatic role changes, the native configuration does not provide automatic failover.
That constraint is not obscure documentation trivia. It is the dividing line between an environment that copies databases across operating systems and one that can safely decide which replica should become primary during a failure.
Microsoft separately documents DxEnterprise as a way to provide complete high-availability and disaster-recovery support for heterogeneous SQL Server replicas. Microsoft’s Kubernetes guidance also describes using the DH2i product to build container-based availability groups. The August 20 webinar is therefore best understood as a walkthrough of a third-party clustering and networking architecture that uses supported SQL Server AG data movement—not as an announcement that Windows Server Failover Clustering and OpenShift have become one native cluster.
Windows Server Failover Clustering cannot simply extend into OpenShift
The vendor pitch focuses on “cross-platform Availability Groups,” but administrators should not read that phrase as a claim that Windows Server Failover Clustering can directly manage Linux or container nodes. Microsoft is explicit: a Windows Server Failover Cluster cannot be extended by Linux Pacemaker nodes, and a Pacemaker cluster cannot be extended by WSFC nodes.
That leaves several broad architectural paths for a Windows-to-Linux SQL Server deployment:
- A
CLUSTER_TYPE = NONEAvailability Group can replicate across Windows and Linux, but Microsoft does not classify that as high availability. - A distributed Availability Group can connect separate Windows and Linux high-availability clusters, preserving separate WSFC and Pacemaker control planes.
- A third-party cluster manager such as DH2i DxEnterprise can supply its own health monitoring, quorum, virtual host, and failover orchestration across the participating platforms.
DH2i is selling the third path. Its Azure Marketplace listing says DxEnterprise can manage SQL Server AGs across Windows and Linux, automate failover for Kubernetes deployments, and establish secure inter-node communications across networks. Its OpenShift-oriented documentation describes a sidecar model: SQL Server runs in one container while DxEnterprise runs alongside it, managing the AG replica and cluster membership.
This has a practical consequence for operations teams: SQL Server support and cluster-manager support are separate support boundaries. Microsoft’s own Azure documentation says Microsoft supports SQL Server data movement, Availability Groups, and SQL Server components in this type of deployment, while DH2i handles support related to DxEnterprise clustering and quorum management. If a failover decision, node fencing event, virtual listener problem, or DxEnterprise operator issue occurs, the escalation path is not identical to that of a conventional WSFC-based Always On deployment.
“Kubernetes AG cluster” still needs conventional availability design
The webinar’s proposed use case—keeping production SQL Server workloads on Windows Server while using OpenShift for development and testing—sounds incremental, but it introduces more dependencies than a simple replication topology.
A SQL Server AG protects databases through transaction replication from a primary replica to secondary replicas. It does not, by itself, solve all application continuity requirements. Clients need a stable listener or routing mechanism; replicas need correctly designed synchronous or asynchronous commit modes; a cluster must make safe failover decisions; and the infrastructure must withstand a node, zone, or site failure without creating a split-brain condition.
On Linux-based AG deployments, Microsoft recommends at least three replicas for high availability, or two synchronous replicas plus a configuration-only replica, because the cluster must maintain quorum. The same underlying issue does not disappear inside Kubernetes. Deleting or losing the primary pod should trigger a controlled promotion only when the remaining cluster has enough information to determine that the prior primary is unavailable and cannot continue accepting writes.
DH2i’s published Kubernetes and OpenShift guidance includes a test that deletes the active primary pod, waits for another pod to become primary, and then expects the replaced pod to rejoin and synchronize. That is a useful demonstration of recovery automation. It is not a substitute for testing the conditions that cause the hardest failures: a partial network partition, storage latency, loss of a Kubernetes worker, loss of a Windows VM, DNS inconsistency, or a tunnel that remains reachable from one side but not the other.
The webinar announcement does not identify the exact SQL Server version, SQL Server edition, OpenShift version, DxEnterprise release, DxOperator release, replica count, storage class, network topology, recovery-point objective, or recovery-time objective used in its demonstration. It also does not say whether the Windows Server VM is on-premises, in Azure, or running under OpenShift Virtualization. Those details determine whether a design is a workable production pattern or only a useful modernization proof of concept.
The networking claim deserves careful evaluation
DH2i says the demonstration will use zero-trust network access tunneling to secure communications across platforms. The company describes DxOdyssey as an “unVPN” product designed to create application-level ZTNA tunnels and says its technology can avoid exposing external ports between sites.
For a SQL Server AG stretched between a Windows VM and OpenShift, reducing inbound firewall rules and avoiding broad network reachability can simplify deployment. It may also make a hybrid architecture easier to run where the Windows environment and OpenShift cluster sit in different networks, subscriptions, regions, or security domains.
But “zero trust” should not become shorthand for “no trust decisions remain.” Administrators still need to establish which identities can create or modify tunnels, where credentials and certificates are stored, how the AG endpoint and listener are exposed, how traffic is logged, what happens when a tunnel service fails, and whether monitoring can distinguish a database outage from a network-overlay outage. The cross-platform link becomes part of the production data path and must be monitored and patched accordingly.
A conventional VPN can be cumbersome, especially when Kubernetes services, pod addresses, and failover endpoints are involved. Replacing it with application-scoped tunneling may reduce blast radius. It also adds a vendor-operated control plane and another component whose availability governs the database service.
The target audience is modernization teams that cannot afford a flag day
DH2i frames the session around SQL Server online transaction processing workloads: teams want Kubernetes-based development and testing but continue to operate production databases on Windows Server. In many organizations, that is less a matter of preference than a recognition that SQL Server estates carry years of application dependencies, Windows authentication design, operational tooling, backup procedures, and licensing commitments.
A hybrid AG can offer a staged route to container operations. Teams can learn how SQL Server behaves in OpenShift, prove storage and backup workflows, integrate database deployment with a Kubernetes operator, and rehearse failover before choosing a full migration. The approach may also be useful for disaster recovery or a phased platform change.
The trade-off is that a staged design can last longer than expected. Once Windows replicas, container replicas, a third-party cluster manager, Kubernetes operators, secure tunnels, and possibly Azure Red Hat OpenShift are all in scope, the environment needs a clear ownership model. Database teams, Windows administrators, Linux and OpenShift platform teams, network security staff, and the vendor support organization may all have a role in an incident.
The August 20 presentation should be valuable for administrators evaluating that architecture, particularly because Microsoft and Red Hat speakers are participating alongside DH2i. But it should be treated as a technical demonstration of a commercial stack, not as a generic recipe for turning any Windows SQL Server AG into an OpenShift-based automatic-failover cluster.
Organizations considering the design should leave the session with a short list of answers: the exact supported version matrix, the minimum replica and quorum topology, who supports each failure domain, how clients reconnect after failover, how backups and restores work across platforms, and what licensing applies to every active and passive SQL Server replica. Without those answers, the “side by side” model remains a promising demonstration rather than an approved production architecture.