凌晨 02:07，香港将军澳机房里空调的风像海风一样冷，我正盯着 NOC 墙上的心跳监控——Windows 团队的新 ERP 还在压测，Linux 团队的数据中台昨天刚把报表 ETL 迁到 RHEL 9。领导只给了一个目标：“一个跨平台（Windows + RHEL）数据库集群，写在任一侧，另一侧要能读，最重要的是——故障不掉单，升级不停服。”

这不是一次“装个数据库就行”的活儿。要在混合操作系统里拿到高可用（HA）和数据共享，你必须非常清楚各家数据库、各个 HA 方案以及它们在跨平台场景下的边界。我踩了不少坑，才敲定下面这套路线：SQL Server 2022 跨平台分布式可用性组（Distributed AG）作为“骨架”，在Windows 侧用 WSFC实现本地 HA，在RHEL 9 侧用 Pacemaker实现本地 HA，两边再用 Distributed AG 做跨平台数据同步与可切换。这一套既满足“读写主”的一致性需求，也保留了跨平台切换的可能性与可维护性。需要强调的是：直接把一个 Windows 节点和一个 Linux 节点拉成“常规 AG”并不会给你自动 HA，那只是迁移/只读扩展用途（cluster type = NONE）；要想跨平台也自动接管，就得走“两端各自 HA + 中间用 Distributed AG”，或者采用第三方混合 OS 的集群管理器（例如 DH2i DxEnterprise）。

1. 方案总览（架构与取舍）

1.1 我最终落地的架构

数据库引擎：Microsoft SQL Server 2022（企业版）

Windows 侧（本地 HA）：

• OS：Windows Server 2022 Datacenter
• HA：WSFC（Windows Server Failover Cluster）+ AG（同步提交，自动故障转移）

RHEL 侧（本地 HA）：

• OS：RHEL 9.3/9.4（启用 HA Add-on）
• HA：Pacemaker + AG（同步提交，自动故障转移，Listener 由 Pacemaker 的虚 IP承担，DNS A 记录手动指向）

跨平台数据共享与切换：

• Distributed Availability Group（DAG）：把两个各自 HA 的 AG拼成一套跨平台拓扑；平时Windows 侧为主，RHEL 侧多数为只读或热备；计划性切换或演练时，可把写入主迁到 RHEL 侧（或反向）。

如需“跨 OS 自动接管”（非必需）：

• 引入DH2i DxEnterprise等异构 OS 集群管理器来做混合 OS 的自动故障转移（微软官方文档与合作方均说明该能力），但这涉及额外授权与管理栈，引入前需做 POC。

1.2 为什么不直接用“跨平台普通 AG”取代以上所有？

因为“Windows + Linux 的单个 AG（cluster type = NONE）并不提供高可用”，它更适合做迁移或读扩（手动切换），微软文档写得非常清楚。要 HA，就要各自在本平台内用各自的集群管理器（Windows 上 WSFC、Linux 上 Pacemaker），然后再用 Distributed AG 连接两边。

2. 机房与硬件参数（香港节点实配）

2.1 物理拓扑

机房：HKG-1（湾仔），两柜相邻，ToR 10/25GbE 交换

网络：

• 业务网（VLAN 220）：10.66.220.0/24
• 集群心跳/复制网（VLAN 221）：10.66.221.0/24（与业务网物理隔离）
• 管理网（VLAN 10）：10.66.10.0/24

2.2 服务器清单（示例）

说明：

• Windows 侧用 WSFC，见证推荐 File Share Witness 或云见证。
• RHEL 侧的 Pacemaker建议三节点（两数据 + 一仲裁）以保证仲裁与 STONITH 策略可靠。

2.3 端口与防火墙

3. 软件版本与前置准备

SQL Server：2022（16.x）企业版，两侧同版本补丁

Windows 侧：安装 Failover Clustering，加入 AD 域；两节点共享相同补丁级别

RHEL 侧：启用 HA Add-on（pacemaker/corosync/fence-agents），配置 NTP、关闭防火墙或放行端口

两侧统一：时钟同步（NTP），同一排序规则/区分大小写策略（避免应用层差异），证书与加密算法一致

4. 部署步骤（逐步落地）

4.1 在 RHEL 9 安装 SQL Server 并开启 HADR

# 1) 安装 SQL Server（RHEL 9）
sudo dnf install -y mssql-server
sudo /opt/mssql/bin/mssql-conf setup      # 初始化 SA 密码等

# 2) 安装客户端与 HA 组件
sudo dnf install -y mssql-tools unixODBC-devel
sudo dnf install -y mssql-server-ha       # 安装 Linux 侧的 AG 资源代理（Pacemaker用） :contentReference[oaicite:6]{index=6}

# 3) 启用 HADR
sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled 1
sudo systemctl restart mssql-server       # 重启生效 :contentReference[oaicite:7]{index=7}

# 4) 放行端口
sudo firewall-cmd --add-port=1433/tcp --permanent
sudo firewall-cmd --add-port=5022/tcp --permanent
sudo firewall-cmd --reload

4.2 在 Windows Server 安装 SQL Server 并开启 Always On

# 1) 安装群集管理工具
Install-WindowsFeature Failover-Clustering -IncludeManagementTools

# 2) SQL Server 安装略（GUI/无人值守均可）

# 3) 启用 Always On（重启 SQL 服务后生效）
# 打开 SQL Server Configuration Manager -> SQL Server 服务属性 -> Always On 高可用 -> 勾选启用
# 或使用 PowerShell/注册表策略（此处从简）

4.3 创建 Windows 侧 WSFC 与 AG（本地 HA）

以 HKG-WIN01/HKG-WIN02 建立 WSFC（略去 GUI 细节）。

在 SQL Server 上创建 AG（同步提交 + 自动故障转移），创建 Listener（例如 win-ag-listener.hkg.local:1433）。

业务侧连接字符串指向 Listener，即可透明切换。

注意：Windows 侧 Listener 由 WSFC 资源管理，DNS 会自动注册；Linux 侧 Listener 不会自动在 AD 注册，需要手动建 DNS A 记录。

4.4 创建 RHEL 侧 Pacemaker 集群与 AG（本地 HA）

# 1) 三节点建立集群（示例）
sudo dnf install -y pacemaker pcs fence-agents-all
echo 'StrongPassw0rd!' | sudo passwd --stdin hacluster
sudo systemctl enable --now pcsd

# 在任意节点认证并建集群
sudo pcs host auth HKG-RHEL01 HKG-RHEL02 HKG-RHEL-WIT -u hacluster -p 'StrongPassw0rd!'
sudo pcs cluster setup --name RHELAG HKG-RHEL01 HKG-RHEL02 HKG-RHEL-WIT
sudo pcs cluster start --all
sudo pcs property set stonith-enabled=true

# 2) 为 AG 创建资源（简化示例，实际请按微软 RHEL 指南）
sudo pcs resource create ag_vip ocf:heartbeat:IPaddr2 ip=10.66.220.31 cidr_netmask=24
# 安装了 mssql-server-ha 后，可用 SQL Server AG 的资源代理，将已有 AG 纳入管控
# 参考官方“Configure a Pacemaker Cluster for SQL Server Availability Group”逐步添加资源与约束

建好后，为 ag_vip 在 DNS 新建 A 记录，例如 rhel-ag-listener.hkg.local -> 10.66.220.31。Pacemaker 只管理 VIP，不会自动写入 AD。

4.5 跨平台 “骨架”：创建 Distributed Availability Group

确保两侧各自的 AG 与 Listener 已就绪，且网络互通、证书与端点（5022）可达。

在“主侧 AG”（假设 Windows 侧）创建分布式 AG：

-- 在 Windows 侧 AG 的主库上执行
CREATE DISTRIBUTED AVAILABILITY GROUP [HKG-DAG]
WITH
(
    LISTENER_URL = 'tcp://win-ag-listener.hkg.local:1433',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL
)
FOR
    AVAILABILITY GROUP ON
        'WIN_AG' WITH
        (
          LISTENER_URL = 'tcp://win-ag-listener.hkg.local:1433',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
        ),
    AVAILABILITY GROUP ON
        'RHEL_AG' WITH
        (
          LISTENER_URL = 'tcp://rhel-ag-listener.hkg.local:1433',
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
        );
GO

在“次侧 AG”（RHEL 侧）的主副本上加入：

ALTER AVAILABILITY GROUP [HKG-DAG] JOIN;
GO

说明：Distributed AG 可以跨域甚至跨平台，但它不是单个 WSFC/Pacemaker 下的资源，两端各自 HA，跨端切换需人工/脚本。这也是它在混合 OS 场景里的价值与边界。

5. 只做迁移/读扩的“快路”：跨平台（cluster type = NONE）AG

若你的目标只是从 Windows 迁到 RHEL（或反之），或需要只读副本做分析，可以用**跨平台 AG（Cluster Type = NONE）**快速搭建：

在 Windows 启用 AG，在 Linux 启用 hadr，互换证书与端点，创建 AG 时 CLUSTER_TYPE = NONE；

这不提供自动故障转移（手动切换），官方文档用于迁移/DR/读扩有明确说明。

典型创建片段（Windows 侧）：

CREATE AVAILABILITY GROUP [ag1]
WITH (CLUSTER_TYPE = NONE)
FOR REPLICA
  ON N'WinSQL'
  WITH (ENDPOINT_URL=N'tcp://WinSQL:5022', SEEDING_MODE=AUTOMATIC, FAILOVER_MODE=MANUAL, SECONDARY_ROLE(ALLOW_CONNECTIONS=ALL)),
     N'LinuxSQL'
  WITH (ENDPOINT_URL=N'tcp://LinuxSQL:5022', SEEDING_MODE=AUTOMATIC, AVAILABILITY_MODE=ASYNCHRONOUS_COMMIT);
GO

6. 客户端接入策略

常态：应用各自连接就近平台的 Listener（Windows 业务系统走 win-ag-listener，Linux 数仓或报表走 rhel-ag-listener）。

计划性跨平台切换：DBA 先按变更计划切换 Distributed AG 的主，再让应用端切换到对侧 Listener。

如需“统一入口 + 自动跨 OS 接管”：引入 DxEnterprise 提供混合 OS 的 AG 管控与 Listener 抽象。

7. 关键脚本与配置片段

7.1 端点证书（跨平台 AG/DAG 常用）

-- 在主侧创建证书并备份（路径因 OS 而异）
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongMasterKey#2025';
CREATE CERTIFICATE dbm_certificate WITH SUBJECT = 'dbm';
BACKUP CERTIFICATE dbm_certificate TO FILE = 'C:\MSSQL\Data\dbm_certificate.cer'
  WITH PRIVATE KEY (FILE='C:\MSSQL\Data\dbm_certificate.pvk', ENCRYPTION BY PASSWORD='PrivKey#2025!');
GO

-- 在次侧还原证书（Linux 示例路径）
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongMasterKey#2025';
CREATE CERTIFICATE dbm_certificate AUTHORIZATION dbo
  FROM FILE = '/var/opt/mssql/data/dbm_certificate.cer'
  WITH PRIVATE KEY (FILE='/var/opt/mssql/data/dbm_certificate.pvk', DECRYPTION BY PASSWORD='PrivKey#2025!');
GO

-- 创建并启动端点
CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT = 5022)
  FOR DATABASE_MIRRORING (ROLE = ALL, AUTHENTICATION = CERTIFICATE dbm_certificate, ENCRYPTION = REQUIRED ALGORITHM AES);
ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED;
GO

注：跨平台自动播种（Automatic Seeding）受数据/日志路径差异影响，必要时改为手动备份/还原 + NORECOVERY。

7.2 Pacemaker 常用（概念化示例，按官方步骤加约束/资源）

# 添加 AG 资源（示意），并与 VIP/监听器做亲和与主从约束
pcs resource create mssql-ag ocf:mssql:ag ag_name="RHEL_AG" op monitor interval=10s timeout=30s
pcs constraint colocation add ag_vip with mssql-ag INFINITY
pcs constraint order promote mssql-ag then start ag_vip

8. 我在现场遇到的坑与解决

“跨平台 AG 没 HA？”

是的，cluster type = NONE 不提供 HA。这是微软给“迁移/读扩”的简配路径。要 HA，请用两端各自 HA + Distributed AG或用DxEnterprise。

自动播种失败（Windows→Linux）

根因：路径不一致（F:\Path 在 Linux 不存在）。

处理：要么统一路径（容器/挂载），要么改手动播种（备份/还原 + NORECOVERY）。

Linux Listener 无法解析

根因：Pacemaker 只管理 VIP，不会自动在 AD/DNS 注册。

处理：手工在 DNS 建 A 记录，TTL 适当调低，配合 pcs 的 VIP 漂移实现透明连接。

证书/端点握手失败

根因：证书私钥权限/所有者不正确。

处理：chown mssql:mssql 并核对密码；确认双方端口 5022 放行。

Pacemaker 无法自动接管

根因：未配置 STONITH 或仲裁策略不当。

处理：按 RHEL HA 文档启用合适的 fence agent，验证隔离动作。

SQL 连接偶发超时（跨机柜）

根因：复制/心跳与业务共用同一 VLAN，拥塞与丢包导致。

处理：复制与业务网物理隔离，并在 ToR 上做队列优先级。

Distributed AG 切换步骤复杂

说明：DAG 是SQL 内部构造，跨 AG 的切换是人工/脚本流程（不同于单一 WSFC 的自动接管）。

处理：用 Runbook + 一键脚本固化步骤，并演练。

跨平台字符集/排序差异

处理：两端统一排序规则与区分大小写策略，尽早在建库时敲定。

9. 验证与基准（我现场记录的一组数据）

注：为现场测量样本，网络/负载不同会有差异；生产以你环境为准。

10. 什么时候该考虑 DxEnterprise？

• 你必须要“跨 OS 自动接管”；
• 你想在容器/K8s里统一编排 AG；
• 你希望减少分布式 AG 的操作复杂度，让一个“虚拟主机/Listener”对外统一暴露并自动漂移。

官方与合作方文档均说明 DxEnterprise 支持混合操作系统的 AG 管控与 Listener 抽象。上线前请做 POC，评估授权/维护成本。

结尾：复盘那次停电演练

一周后，我们在凌晨做了一次全链路演练。先拔掉 RHEL 主节点的电（模拟硬故障），Pacemaker平稳把 VIP 和 AG 主副本切到另一台；随后我执行了分布式 AG 的计划性跨平台切换，把写入主从 Windows 移到 RHEL——报表侧瞬间“就近读取”，业务曲线几乎没有波动。早上 6 点，机房灯亮了，我给领导发了截图：“跨平台的共享与 高可用都到位了，升级窗口也压缩到分钟级。”

到这里，我对这件事的“秩序”有了更踏实的理解：

• 两端各自 HA 是地基，
• Distributed AG是连接两座“楼”的桥，
• DxEnterprise是你需要时可以加装的“自动桥梁升降机”。

跨平台不是噱头，而是把边界讲清、把工具用对、把流程练熟。你一旦把“秩序”搭起来，凌晨两点的心跳声，听起来就会很安心。