KubeBlocks SQL Server(MSSQL) K8s Operator 高可用实现背景Microsoft SQL ServerMSSQL是由微软开发的一款关系型数据库管理系统。最初仅支持在 Windows 平台上运行自 2017 版本起开始支持 Linux 系统这一变化为 MSSQL 的容器化部署提供了可能。MSSQL 提供了名为 Availability Group可用性组下文简称AG 的多数据库复制管理特性该特性支持在多个节点上实现数据库的多副本冗余从而提升数据可靠性和服务连续性。在 Windows 平台上MSSQL 通过与 Windows Server Failover ClusterWSFC 集成实现了完整的高可用能力。在 Linux 平台上MSSQL 提供了基于 Pacemaker Corosync 的替代方案来构建高可用架构。然而在云原生和容器化场景下官方尚未提供对应的高可用方案目前推荐使用第三方商业方案 DH2I 来实现。KubeBlocks 在接入 MSSQL 时面临如何在其平台上构建高可用能力的选择问题。主要有两种实现路径第一种方案是基于 Pacemaker 构建“富容器”架构即将 Pacemaker、Corosync 和 MSSQL 等组件打包进同一个容器中运行。其优势在于可复用已有的开源组件无需额外开发工作但缺点是运维复杂度较高Pacemaker 和 Corosync 的配置较为繁琐且在容器化环境中由于 Pod 稳定性难以完全保障可能导致整体高可用系统的管理成本高且稳定性难以保证。第二种方案是自主研发一套轻量级、面向云原生的分布式高可用框架以模拟 WSFC 的核心功能。虽然该方案在前期开发成本和技术难度方面相对较高但具备更高的自主可控性并能避免对 Pacemaker 的依赖提供更加简洁一致的用户体验。考虑到 KubeBlocks 已经构建了一套统一的高可用管理框架 —— Syncer只需新引擎实现若干关键接口即可快速完成高可用能力的集成整体开发与维护成本均处于可控范围内。同时该方式还能为 MSSQL 提供与其他数据库如 MySQL、MongoDB 等一致的高可用体验。因此KubeBlocks 最终选择基于 Syncer 框架实现 MSSQL 的高可用能力。高可用概览Syncer 是一款为应对数据库在云原生环境中高可用挑战而自主研发的轻量级分布式高可用服务。它的核心目标非常明确让数据库在云原生环境下像其它有状态服务一样被统一调度和管理而无需开发者或运维人员深入理解其内部复杂的状态流转和数据同步机制。它不仅提升了系统的可观测性和可维护性还显著降低了数据库高可用功能研发的门槛。作为一款面向多数据库引擎的通用组件Syncer 抽象出一套标准化的高可用接口包括Promote将副本提升为主节点Demote将主节点降级为副本HealthCheck健康检查……这些接口使得不同类型的数据库只需实现少量适配逻辑即可快速接入 Syncer并获得一致的高可用能力支持。这也正是我们选择在 KubeBlocks for MSSQL 中采用自研方式的重要原因。借助 Syncer 提供的基础框架我们可以更灵活地适配 MSSQL 的特性避免依赖复杂的外部 HA 组件如 Pacemaker从而构建出一个更加轻量、可控且稳定的云原生高可用方案。下图中展示了 MSSQL 三节点的高可用结构图KubeBlocks for MSSQL最大支持 5 个同步节点节点数最高不超过 9 个与官方保持一致。Syncer 采用分布式架构设计以 Hypervisor 的方式运行在每一个数据库 Pod 上负责节点本地和集群维度的健康探测。不同集群之间的高可用服务相互独立各自通过内部选举机制管理副本角色。在 K8S 上Syncer 使用 ApiServer 作为分布式锁机制结合节点的心跳信息和状态对节点角色进行管理。当主节点发生异常时Syncer 会触发 Failover从现有的健康节点中选择状态最优的一个提升Promote为新主。旧主节点恢复正常后则自动降级Demote为备节点。更准更快的本地化探测Syncer 使用本地化探测方式可以更准确、更快速地发现异常不受容器网络波动的影响。同时它还能结合系统信息做出更可靠的判断当数据库连接异常时Syncer 可实时获取当前 CPU 和内存使用情况判断是否因负载过高导致若数据库写入异常Syncer 还可检查磁盘是否已满或文件系统是否变为只读。这种结合数据库状态与系统资源的综合探测机制显著提升了故障识别的准确性。自修复能力降低运维复杂度Syncer 还具备一定的自修复能力。当节点出现数据损坏等异常时在完成 Failover 后Syncer 可自动重建该节点的副本确保集群恢复到健康状态整个过程无需人工干预。安全可控的进程管理除了高可用能力Syncer 还提供进程托管和一些基础运维支持便于在云原生环境中进行精细化管理。例如数据库在关闭时通常需要等待事务结束并完成刷盘操作。而在 Kubernetes 中Pod 仅能设置终止等待时间超时后将强制关闭进程可能导致数据不一致问题。Syncer 在执行关闭操作时会等待数据库正常退出后再上报停止状态从而避免了直接强杀进程带来的风险保障了数据库的安全性与一致性。故障模拟接入 Syncer 后MSSQL 在 KubeBlocks 平台上获得了与 MySQL、PostgreSQL、MongoDB 等数据库接近的高可用能力并在统一框架下实现了一致的高可用体验。为了验证 MSSQL 的高可用机制是否符合预期我们进行了全面的故障模拟测试。为使测试环境更贴近真实业务场景我们在测试前导入了 90GB 的测试数据并在整个测试过程中保持一个服务对其进行持续写入以模拟实际负载。由于篇幅限制本文仅列出几种典型的故障场景进行说明完整的故障测试报告可从 KubeBlocks 官网 获取。主动切换在日常运维中如进行节点升级或维护时通常需要主动发起实例的角色切换Switchover以滚动方式操作节点从而最小化数据库不可用时间。Switchover 可以将非预期的故障转化成可控的运维事件是保障高可用性和系统可维护性的关键操作之一。Switchover 支持通过控制台界面操作也可通过下发OpsRequest的方式进行。通常情况下角色切换耗时约为 10 秒。新主节点恢复正常访问前需先完成 Availability Group 中所有数据库的恢复restore因此实际数据可访问时间会受到数据量和当前业务负载的影响。内存 OOM通过 Chaos Mesh 模拟主节点内存 OOM数据库无法访问主备切换15s 左右主节点切换成功。最开始节点 0 为主节点Chaos Mesh 模拟 OOM 故障kubectl create -f -EOF kind: StressChaos apiVersion: chaos-mesh.org/v1alpha1 metadata: generateName: test-primary-memory-oom- namespace: default spec: selector: namespaces: - kubeblocks-cloud-ns labelSelectors: app.kubernetes.io/instance: s4c16-6f6d9445b4 kubeblocks.io/role: primary mode: all containerNames: - mssql stressors: memory: workers: 1 size: 100GB oomScoreAdj: -1000 duration: 30s EOFPod 状态显示 OOMKilledkubectl get pod -w -n kubeblocks-cloud-ns s4c16-6f6d9445b4-mssql-0 NAME READY STATUS RESTARTS AGE s4c16-6f6d9445b4-mssql-0 3/4 OOMKilled 1 (56s ago) 151m s4c16-6f6d9445b4-mssql-0 2/4 OOMKilled 1 (65s ago) 151m s4c16-6f6d9445b4-mssql-0 2/4 CrashLoopBackOff 1 (11s ago) 151m s4c16-6f6d9445b4-mssql-0 3/4 Running 2 (11s ago) 151m s4c16-6f6d9445b4-mssql-0 4/4 Running 2 (17s ago) 151m故障发生后15s 时节点 2 切换为新主Pod 故障通过 Chaos Mesh 模拟主节点 Pod Failure致使数据库无法访问触发 Failover1s 左右主节点切换成功。初始状态节点 0 为主节点Chaos Mesh 模拟 Pod Failoverkubectl create -f -EOF apiVersion: chaos-mesh.org/v1alpha1 kind: PodChaos metadata: generateName: test-primary-pod-failure- namespace: default spec: selector: namespaces: - kubeblocks-cloud-ns labelSelectors: app.kubernetes.io/instance: s4c16-6f6d9445b4 kubeblocks.io/role: primary mode: all action: pod-failure duration: 2m EOF1s 后节点 1 选为新主节点 0 处于异常状态网络延迟模拟主节点网络延迟两分钟主节点服务无法访问触发主备切换15s 后发生切换。Chaos Mesh 模拟 Pod网络故障kubectl create -f -EOF kind: NetworkChaos apiVersion: chaos-mesh.org/v1alpha1 metadata: generateName: test-primary-network-delay- namespace: default spec: selector: namespaces: - kubeblocks-cloud-ns labelSelectors: app.kubernetes.io/instance: s4c16-6f6d9445b4 kubeblocks.io/role: primary mode: all action: delay delay: latency: 10000ms correlation: 100 jitter: 0ms direction: to duration: 5m EOFPod 内存服务访问异常kubectl describe pod -n kubeblocks-cloud-ns s4c16-6f6d9445b4-mssql-0 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal checkRole 5m43s lorry {event:Success,operation:checkRole,originalRole:waitForStart,role:{\term\:\1749106874646075\,\PodRoleNamePairs\:[{\podName\:\s4c16-6f6d9445b4-mssql-0\,\roleName\:\primary\,\podUid\:\c3a4f05f-cc25-48ca-9f16-30d4621b7393\},{\podName\:\s4c16-6f6d9445b4-mssql-1\,\podUid\:\b2014bb1-848e-4ebc-900b-e5849b9b0104\}]}} Warning Unhealthy 67s kubelet Readiness probe failed: Get http://10.30.237.94:3501/v1.0/checkrole: context deadline exceeded (Client.Timeout exceeded while awaiting headers)节点 0 选为新主旧主在网络故障恢复后角色恢复正常进程异常Kill 主节点 1 号进程模拟进程异常触发 Failover1s时主节点切换成功。Kill 1 号进程echo kill 1 | kubectl exec -it $(kubectl get pod -n kubeblocks-cloud-ns -l app.kubernetes.io/instances4c16-68bdc5d55d,kubeblocks.io/roleprimary --no-headers| awk {print $1}) -n kubeblocks-cloud-ns -- bashPod 事件显示 CrashLoopBackOffkubectl get pod -n kubeblocks-cloud-ns -w s4c16-68bdc5d55d-mssql-0 s4c16-68bdc5d55d-mssql-0 0/4 Error 16 15h s4c16-68bdc5d55d-mssql-0 0/4 CrashLoopBackOff 16 (4s ago) 15h s4c16-68bdc5d55d-mssql-0 3/4 Running 20 (27s ago) 15h s4c16-68bdc5d55d-mssql-0 3/4 Running 20 (31s ago) 15h s4c16-68bdc5d55d-mssql-0 4/4 Running 20 (33s ago) 15h旧主异常后1s 时节点 1 被选为新主Syncer vs PacemakerPacemaker 是 MSSQL on Linux 推荐使用的高可用解决方案它是一个开源且成熟的集群资源管理器广泛用于管理高可用性集群中的各类资源。Syncer 作为 KubeBlocks 默认提供的高可用方案在设计上参考了 Pacemaker但主要面向云原生场景。为了实现更高水平的高可用性Syncer 在集成方式上采用了 Plugin 模式而非 Pacemaker 所使用的 Agent 模式。同时Syncer 内置了集群节点管理逻辑使其在健康探测和角色切换方面更加轻量和高效。接下来将具体对比 Pacemaker 与 Syncer 的能力差异。两节点脑裂在仅部署两个节点的场景下Pacemaker 存在发生脑裂Split-Brain的风险。Pacemaker 通过 Quorum 机制来确保集群在节点故障时仍能做出一致性的决策当节点之间无法通信时仲裁机制用于判断哪些节点可以继续提供服务以保障数据一致性和可用性。在两节点配置中为了维持高可用性通常会启用two_node模式。然而这种模式下仍存在脑裂的可能性无法完全避免该问题。相比之下Syncer 采用“心跳 全局锁”的方式有效解决了两节点场景下的脑裂风险。当两个节点无法通信时可能出现以下两种情况其中一个节点成功获取全局锁则该节点保持为主节点另一节点自动降级为备节点两个节点均无法获取全局锁则集群维持原有状态不会触发重新选主。该机制不仅适用于两节点场景同样可扩展至多节点环境具备良好的通用性和稳定性。RPO 与 RTO当 MSSQL 主节点发生异常时高可用服务会触发 Failover从健康的备节点中选择最优节点提升为新主继续对外提供服务。备节点提升为主节点的过程可分为两个阶段第一阶段将副本replica角色变更为主primary角色。该阶段仅涉及角色状态的切换耗时主要取决于高可用服务的响应速度。第二阶段对 AG 内所有数据库执行restore操作使其进入可读写状态。该阶段时间与数据量大小和当前负载情况密切相关且不受高可用服务本身影响。由于本文重点在于对比不同高可用方案的切换能力因此测试中使用了 1 万条数据少量以降低第二阶段对整体结果的影响。关于高负载场景及更全面的测试结果可参考 KubeBlocks 官网发布的完整测试报告。分类测试内容pacemakersyncer连接压力连接数 Full不切换不切换CPU 压力主节点 CPU Full不切换不切换备节点 CPU Full不切换不切换主备节点 CPU Full不切换不切换内存压力主节点内存 OOMRPO0, RTO25sRPO0, RTO15s单备节点内存 OOM不切换不切换多备节点内存 OOM不切换不切换主备节点内存 OOM主先恢复不切换主先恢复不切换备先恢复RPO0, RTO56s备先恢复RPO0, RTO33sPod 故障主节点 Pod FailureRPO0, RTO24sRPO0, RTO1s单备节点 Pod Failure不切换不切换多备节点 Pod Failure不切换不切换主备节点 Pod Failure主先恢复不切换主先恢复不切换备先恢复RPO0, RTO54s备先恢复RPO0, RTO33sNTP异常主节点时钟偏移不切换不切换备节点时钟偏移不切换不切换主备节点时钟偏移不切换不切换网络故障主节点网络延迟短时间延迟不切换短时间延迟不切换长时间延迟RPO0, RTO37s长时间延迟RPO0, RTO15s单备节点网络延迟不切换不切换多备节点网络延迟不切换不切换主备节点网络延迟主先恢复不切换主先恢复不切换备先恢复主备切换RPO0, RTO28s备先恢复主备切换RPO0, RTO28s主节点网络丢包RPO0, RTO43sRPO0, RTO15s单备节点网络丢包不切换不切换多备节点网络丢包不切换不切换主备节点网络丢包主先恢复不切换主先恢复不切换备先恢复RPO0, RTO82s备先恢复RPO0, RTO65sKill 进程主节点进程 killRPO0, RTO40sRPO0, RTO1s单备节点进程 kill不切换不切换多备节点进程 kill不切换不切换主备节点进程 kill主先恢复不切换主先恢复不切换备先恢复RPO0, RTO74s备先恢复RPO0, RTO28s总结展望在云原生环境下MSSQL 面临着诸多挑战。由于其最初是为传统物理机或虚拟机环境设计的在架构上并未充分适配云原生场景下的资源调度与运维模式。尤其是在高可用架构方面受限于资源调度方式的差异以及 Pod 稳定性难以完全保障MSSQL 已有的高可用机制难以发挥出理想效果。KubeBlocks for MSSQL 正是在这样的背景下诞生的。它有效弥补了 MSSQL 在云原生场景下的能力短板显著提升了其部署效率与运维管理体验。通过集成 Syncer 这一轻量级分布式高可用服务KubeBlocks 成功实现了对 MSSQL 的云原生高可用支持在故障探测、角色切换、自修复等方面表现稳定且高效。当然由于 MSSQL 是闭源系统官方技术文档也较为有限导致其高可用机制的深度集成面临较大挑战。目前我们主要依赖用户手册和数据库运维经验进行推导并结合大量实验验证确保最终实现符合预期。同时MSSQL 的功能模块相对封闭对外暴露的配置项和状态信息较少如 SEED MODE 的配置参数和异常反馈使得系统集成和运维管理仍显“粗粒度”。我们期待未来 MSSQL 能够开放更多内部配置选项与运行状态指标以支持更精细化的控制与自动化管理从而更好地适配云原生平台的复杂需求。最后KubeBlocks Cloud 官网已开放 MSSQL 的免费试用同时还支持 MySQL、PostgreSQL、Redis 等多款主流数据库引擎。欢迎体验并提出宝贵建议