Windows Server 2025 Stretch Cluster 架构详解

主旨单独把 Stretch Cluster 这项技术讲透——它不是单一组件而是 Storage Replica Failover Cluster Asymmetric Shared Storage 的组合架构。本文以微软 Storage Replica Overview2025-08-22 更新原文为锚点。1. 一句话定义Stretch Cluster 一个 Failover Cluster跨两个 Site Storage Replica在两套独立存储之间做卷级复制它不是把两个集群拉成一个也不是简单的复制 VM。它是把同一个 Failover Cluster 的成员节点人为划分到两个 Site每个 Site 有各自的共享存储Storage Replica 在两套存储之间做 Volume 级镜像。2. 架构全景一张图┌─────────────────────── Site A ───────────────────────┐ │ │ │ Node 1Site A │ │ Node 2Site A │ │ │ │ │ ▼ │ │ SAS JBOD / FC SAN / iSCSI ──┐ │ │ Site A 本地共享存储 │ │ │ │ │ └───────────────────────────────┼───────────────────────┘ │ ┌─────── Storage Replica ──┘ │ SMB 3 通道TCP 445 或 5445 │ 可选 SMB Direct 通过 RDMA 加速 │ 同步模式平均 RTT 约 5 ms 或更低微软建议 │ 异步模式无硬性延迟要求 │ ┌──────┴─────────────────────── Site B ──────────────────┐ │ │ │ ┌─ SAS JBOD / FC SAN / iSCSI ──┐ │ │ Site B 本地共享存储 │ │ │ │ │ │ │ ▼ │ │ │ Node 3Site B │ │ │ Node 4Site B │ │ │ │ └───────────────────────────────────────────────────────┘ Failover Cluster 名SR-SRVCLUS一个 Cluster Site 标识logical siteRedmond / Bellevue关键事实一个 Failover Cluster不是两个两套共享存储每套只被对应 Site 的节点看到asymmetric storage节点不需要物理上不能共享存储——但每个 Site 只能看到自己 Site 的存储Storage Replica 在两套存储之间做 Volume 级复制节点间使用 SMB 3 作为复制通道官方原话SMB 3-based. Storage Replica uses the proven and mature technology of Server Message Block (SMB) 3。底层网络端口可以是 TCP 445 或 5445——微软 Storage Replica Overview 文档明确写Replication network port firewall requirements: Single IANA port (TCP 445 or 5445)二者是 SR 可选的两种监听端口SMB Direct 是基于 RDMA 的 SMB 传输可在 RoCE v2 / iWARP / InfiniBand 网卡上启用微软 overview 原话SMB direct support on RoCE, iWARP, and InfiniBand RDMA network cards, are available to Storage Replica用于降低 CPU 开销并提高吞吐它不是新端口协议3. 三种 Storage Replica 部署模式先把概念边界划清Stretch Cluster 不是 Storage Replica 的唯一形态。微软官方列了三种模式模式一个 Cluster 还是两个用不用 S2D故障切换典型场景Stretch cluster replication一个 Cluster跨两 Site不用 S2D用 SAS JBOD / FC SAN / iSCSI / Shared VHDX自动cluster 视角同城双活、SMB / Hyper-V 集群最小支持 2 节点但实际生产通常每站点至少 2 节点Cluster-to-cluster replication两个 Cluster可以用 S2D明确支持手动跨城灾备、两个独立集群之间复制Server-to-server replication无 Cluster不用手动最小化部署、文件服务器 DR本文主角是第一种Stretch Cluster。它对应的是一个 Cluster 两套不对称存储 一个 SR Partnership。⚠️对话里的常见混淆很多人把 Stretch Cluster 等同于 Storage Replica但 Storage Replica 是引擎Stretch Cluster 是部署模式之一。同一个 SR 引擎能跑出三种不同拓扑。3.1 最小部署 vs 典型生产部署Stretch Cluster 在节点数上弹性很大但最小部署与典型生产部署的故障容忍度差异显著最小部署2 节点每站点 1 节点Site A Site B ┌──────────────────────┐ ┌──────────────────────┐ │ Node 1Site A │ │ Node 2Site B │ │ │ │ │ │ │ │ ▼ │ Storage │ ▼ │ │ SAS JBOD / FC SAN │ Replica │ SAS JBOD / FC SAN │ │ Site A 存储 │ ────────► │ Site B 存储 │ │ │ ◄──────── │ │ └──────────────────────┘ └──────────────────────┘ 一个 Failover ClusterSR-SRVCLUS典型生产部署4 节点每站点 2 节点Site A Site B ┌──────────────────────┐ ┌──────────────────────┐ │ Node 1Site A │ │ Node 3Site B │ │ Node 2Site A │ │ Node 4Site B │ │ │ │ │ │ │ │ ▼ │ │ ▼ │ │ SAS JBOD / FC SAN │ Storage │ SAS JBOD / FC SAN │ │ Site A 存储 │ Replica │ Site B 存储 │ │ 2 节点可见 │ ◄───────► │ 2 节点可见 │ └──────────────────────┘ └──────────────────────┘ 一个 Failover ClusterSR-SRVCLUS两者的关键差异维度最小部署2 节点典型生产部署4 节点站点内冗余无每站点只有 1 节点有每站点 2 节点可站点内 failover单节点维护必须停机无可迁出目标可在站内维护Live Migration适合场景演示、概念验证、极小业务关键交易、生产双活微软文档示例as few as two nodes默认 4 节点示例SR-SRV01~044. 核心组件拆解4.1 Storage Replica复制引擎Storage Replica 是 Windows Server 自带的卷级块复制引擎关键特征跑在partition layer分区层所有 VSS snapshot 都会被复制同步复制保证两 Site 写入崩溃一致crash-consistentRPO 0异步复制跨更高延迟不保证两 Site 在故障时点一致RPO 0连续复制不是 checkpoint-baseddelta 比 snapshot-based 产品小得多替代品对照DFS Replication 是文件级、几小时延迟——SR 是块级、毫秒级延迟4.2 Failover Cluster集群层一个普通的 Failover Cluster节点人为按 Site 划分2~64 节点官方原话You can use only as few as two nodes, where one node each is in each site... You can use as many as 64 nodes——最小 2 节点即可组建 Stretch Cluster实际生产环境通常每站点至少 2 节点以提高站点内冗余QuorumFile Share Witness或Cloud Witness推荐 Cloud Witness用Set-ClusterQuorum -FileShareWitness \\SomeServer\SomeShare或Set-ClusterQuorum -CloudWitness4.3 Asymmetric Shared Storage不对称存储这是 Stretch Cluster 最容易误解的一点两个 Site各有各的存储两套存储互相看不到对方。SR 通过网络在两套存储之间复制数据。Asymmetric Storage 是 Stretch Cluster 的设计前提不是最佳实践。如果 Site A 的节点意外看到 Site B 的存储会引入三类风险Cluster Disk Arbitration 风险Failover Cluster 会发现两个 Site 的节点都能 reserve 同一个 LUN导致仲裁时谁也无法拿到独占权资源一直处于Pending状态SCSI Persistent Reservation 冲突两个集群对同一磁盘发起 PR 请求时第二个请求会被第一个持有者拒绝相关 VM 可能 I/O 挂起双活写入风险两个节点的 SR Filter Driver 都对同一逻辑卷发起写入破坏一致性因此微软 how-to 文档明文要求Servers in different sites must be able to communicate with the other servers via a network,but not have any physical connectivity to the other sites shared storage——这是硬性要求不是建议。维度要求存储类型SAS JBODs配 Storage Spaces/ FC SAN LUNs / iSCSI Target / Shared VHDX是否支持 S2D不支持原文This scenario doesnt make use of Storage Spaces Direct物理位置每个 Site 内独立机房Sector size两套存储的 data disk 和 log disk 必须各自相同Persistent Reservation应支持 SCSI Persistent ReservationPR机制——这是 Windows Failover Cluster 的硬性要求官方原文Windows Failover Clustering still relies on SCSI Persistent Reservations. Therefore, the storage must still be a Shared Storage type such as a SAN technology。大多数企业级 FC SAN、iSCSI SAN 和 SAS 共享存储均支持该能力但并非所有 Target 都默认开启GPT 初始化必需不能是 MBR文件系统NTFS 或 ReFS为什么不用 S2DS2D 的前提是每个节点都能看到本地所有磁盘构成一个统一的 Storage Pool。Stretch Cluster 的设计前提是两 Site 各自独立的存储这两个抽象层不兼容。想用 S2D 做跨站点复制用Cluster-to-cluster replication明确支持 S2D。5. 数据流写 IO 路径Storage Replica 的数据流不是简单的写本地 → 写远端 → 返回 ACK串行模型。它基于Log-First、Replay-Back的 PipelineApplication │ ▼ write SR Filter Driver │ ▼ Local Log Volume │ ←—— 同步复制同步模式——→ │ SMB 3TCP 445 / 5445 │ 同步模式需等远端 ACK ▼ ┌─────────┴─────────┐ ▼ ▼ Local Replay Remote Log 后台 │ │ ▼ ▼ Remote Replay Local Data 后台 Volume │ │ ▼ │ Remote Data │ Volume ▼ ACK 返回应用同步模式关键事实Log-First 机制每一次写先落入 Local Log Volume同步模式下还要在 Remote Log 落盘并收到 ACK 后才返回随后后台异步 Replay 到 Local Data Volume 和 Remote Data Volume微软原话Storage Replica operates at the partition layer——它在卷层面工作所有 VSS snapshot 都参与复制同步复制只保证 Log 落盘一致——Log 落盘后 ACK 返回应用Data Volume 的 Replay 是后台进行的Consistency groups一致性组SQL Server 这类应用写入多个卷时SR 保证写入顺序在远端也得到保持官方原话Write ordering guarantees that applications like SQL Server can write to multiple replicated volumes and the data is written on the destination server sequentiallyLog 卷必须比 Data 卷快——这是微软的明确建议官方原话Microsoft recommends that the log storage be faster than the data storage6. 同步 vs 异步6.1 同步Synchronous Replication维度要求RTT建议平均 RTT 约 5 ms 或更低微软官方原文an average of ~5ms round trip latency for synchronous replication——average、approximately 含义不要理解为硬性 ≤ 阈值带宽至少 1 GbE建议 RDMARPO0零数据丢失一致性崩溃一致crash-consistent适用距离同园区、同城、低延迟专线在平均 RTT 约 5 ms 的网络环境中部署6.2 异步Asynchronous Replication维度要求RTT无硬性延迟要求RPO 0取决于带宽 写负载RPO 不可保证一致性不保证两 Site 在故障时点一致适用距离跨城、跨地域、高延迟链路两者不是开关切换可以从同步降级到异步带宽不足时反之亦然。但异步模式任何时刻都可能丢数据不要为了追求看起来 OK而把同步硬塞到高延迟网络。7. 网络与防火墙Storage Replica不强制要求 RDMA可运行在普通 TCP/IP 网络azurelocal / RAC / S2D 同样不强制 RDMA但 RDMA 在 S2D 与 RAC 的存储栈中被强烈推荐。若采用SMB Direct则可利用 RDMARoCE v2 / iWARP / InfiniBand降低 CPU 开销并提升吞吐。Stretch Cluster 在同步复制场景下网络带宽必须能容纳完整 IO 写负载端口协议用途445SMB节点间存储复制、cluster heartbeat5445SMBSR Server InstanceStorage Replica 启用的独立 SMB Server Instance 监听端口与 TCP 445 二选一非 SMB Direct 协议本身的端口5985WS-MAN远程管理PowerShell / WACICMP—节点连通性对网络的要求至少 1 GbE同步复制带宽必须能容纳完整 IO 写负载不是平均负载是峰值负载同步模式建议平均 RTT 约 5 ms 或更低微软 Stretch Cluster 文档原文an average of ~5ms round trip latency for synchronous replication——average、approximately 含义非硬阈值异步模式无延迟要求但带宽要够节点间网络可达但存储不可达——这是关键物理约束8. Log 卷设计最容易踩坑的地方微软对 Log 卷的要求是非常硬性的维度要求容量建议至少 10 GB官方原话Your log volume must be at least 10 GB or larger based on log requirements and organizational needs实际部署常按写峰值与复制窗口放大至 16~64 GB介质必须比 Data 卷更快微软原文Microsoft recommends that the log storage be faster than the data storage用途只能给 SR 用不能承载其他工作负载原文Log volumes must never be used for other workloads数量每个复制组RG一套 Log 卷故障Log 卷故障 复制中断不会丢已复制数据但未复制数据会在源端堆积直到 Log 满实战经验用 NVMe 或 SSD 单独划一个 16~64 GB 卷做 Log实际容量按写峰值调整不要用 RAID-5 做 Log写延迟抖动太大不要在 Log 卷上放页面文件、临时文件、备份——任何额外 IO 都会拖慢复制关于 default 8 GB 的说明微软早期资料提到过该默认值但在当前文档中已统一为至少 10 GB按需扩大的表述方式9. Quorum 配置两个 Site 之间的谁说了算问题Site A2 节点 Site B2 节点 4 节点 cluster如果 A 和 B 之间网络断开两个 Site 各自只有 2 节点可能出现脑裂split-brain。Quorum 机制解决这个问题Witness 类型配置命令推荐场景File Share WitnessSet-ClusterQuorum -FileShareWitness \\FS\Share第三方数据中心、不在 AzureCloud WitnessSet-ClusterQuorum -CloudWitness有 Azure 订阅、跨云通常部署在独立故障域可避免单一 Site 故障影响仲裁——但 Azure Region 整体故障 / 网络全断时仍可能影响Disk WitnessSet-ClusterQuorum -DiskWitness不推荐增加 SPOF微软推荐 Cloud Witness——它通常部署在与两个 Site 都不同的故障域Azure Blob因此可避免单一 Site 的灾难波及但 Azure Region 整体故障或与 Azure 的网络全断仍会影响 Witness 可用性此时集群会失去仲裁但不会自动故障切换取决于剩余节点能否达成 quorum。10. 故障切换最关键的运维动作10.1 自动 vs 手动按部署模式模式故障切换机制Stretch ClusterFailover Cluster 自动 failoverVM / Role 在 Site A 挂了之后由 Site B 节点接管Cluster-to-cluster手动failover用Set-SRPartnership反转复制方向Server-to-server手动⚠️Stretch Cluster 的自动是 cluster 视角VM / Role 自动迁移。但Storage Replica 本身的复制方向不会自动反转——如果你要 Site B 接管并保持持续复制需要执行Set-SRPartnership。10.2 切换复制方向# 查看当前复制状态 Get-SRPartnership Get-SRGroup # 反转复制方向Site B 成为新 Source Set-SRPartnership -NewSourceComputerName SR-SRVCLUSB -SourceRGName rg02 -DestinationComputerName SR-SRVCLUSA -DestinationRGName rg0110.3 解除复制# 解除 partnership两个 cluster 各跑一次 Get-SRPartnership | Remove-SRPartnership Get-SRGroup | Remove-SRGroup11. Test-SRTopology上线前的强制动作微软提供Test-SRTopologycmdlet 做前置验证# 安装 Storage Replica Management Tools feature 后即可使用 # 不需要预先配置 SR 即可运行 Test-SRTopology -SourceComputerName SR-SRV01 -SourceVolumeName c:\ClusterStorage\Volume2 -SourceLogVolumeName f: -DestinationComputerName SR-SRV03 -DestinationVolumeName c:\ClusterStorage\Volume2 -DestinationLogVolumeName f: -DurationInMinutes 30 -ResultPath c:\temp它会模拟 30 分钟的实际复制流量告诉你带宽够不够同步复制环境的平均 RTT 是否在微软建议的约 5 ms 阈值附近Log 卷是否够大会不会丢数据强烈建议任何 Stretch Cluster / Cluster-to-cluster 上线前都跑一次避免上线后才发现 RTT 抖动超限。12. 微软明确不支持的场景重要避坑场景微软说法来源同一 cluster 的两个节点共享同一套存储违反 asymmetric storage 原则Stretch 配置指南两 Site 互相能看到对方的存储违反物理隔离Stretch 配置指南Stretch Cluster 用 S2DThis scenario doesnt make use of Storage Spaces DirectStretch 配置指南原文操作系统盘做复制The replicated storage cant be located on the drive containing the Windows operating system folderStretch 配置指南原文把 Log 卷给其他工作负载用Log volumes must never be used for other workloadsStretch 配置指南原文同步复制跨长距离网络平均 RTT 明显高于微软建议的 ~5 ms不推荐同步模式可跑但每增加 1 ms RTT 都会同步增加所有写 IO 的延迟RPO 0 的承诺仍成立但应用性能代价会显著上升超长距离应改用异步模式Storage Replica Overview13. 数据盘可选的 RAID 类型微软原文Data disks can use either mirrored or parity spaces or RAID 1 or 10, RAID 5 or RAID 50.方式说明Mirror Spaces性能最高适合高 IO 场景Parity Spaces容量利用率高适合大容量低 IO 场景RAID 1 / 10硬件 RAID 也可RAID 5 / 50硬件 RAID 也可注意写惩罚14. Stretch Cluster 与 RAC 的关键差异强化对比维度Stretch ClusterRack Aware ClusterCluster 数量一个 Cluster跨两 Site一个 Cluster同一数据中心存储两套不对称存储每 Site 一套一套统一存储S2D Pool复制Storage ReplicaVolume 级无复制S2D 副本槽分布网络要求同步建议平均 RTT 约 5 ms 或更低微软建议值非硬阈值异步无硬性≤ 1 ms RTT抽象层存储层集群 存储 调度全栈Azure Local 23H2不支持官方推荐azloc-2606Windows Server 2025✅ 支持✅ 支持主要客户传统企业双活银行、医院、政府数据中心内多机房多机柜15. Stretch Cluster 与 Azure Local Solution Stack 的关系回到../azure-local-rac-series/05-对比篇.md的核心论点——需要准确区分两层概念Storage Replica 引擎本身Windows Server 自带的块复制引擎与 Azure Local OS 同源。Azure Local 23H2并不禁用 SR但也不把 SR 作为跨站点方案使用Stretch Cluster 这种部署架构把 SR Failover Cluster Asymmetric Storage 组合成跨站点拓扑。Azure Local 23H2 的 Solution Stack 不支持采用传统 Windows Server Stretch Cluster 作为跨站点架构原因——Azure Local 23H2 的 Solution Stack 已经远超存储层Arc Resource Bridge 不在 CSV 上SR 复制不了AKS 的 etcd / API Server 不在 CSV 上Arc VM Inventory 在 Azure 控制面不在本地Network Controller 状态在 K8s API Server因此 Azure Local 更依赖Fault Domain / Site Awareness / Rack Awareness / Local Availability Zone等拓扑感知能力azloc-2606 官方术语而不是 Storage Replica 式跨站点卷复制。配套的灾备通过 ASR / 异地备份 / 异步复制等独立方案实现不把两个站点组成一个跨站点 cluster。注本文使用 RAC 一词时指Rack Aware ClusterAzure Local 的多机架高可用拓扑与 Oracle RACReal Application Clusters无关。15.1 Stretch Cluster 与 Azure Local 架构差异速查对比维度Windows Server Stretch ClusterAzure Local23H2含 RAC产品目标传统企业双活银行、医院、政府、制造与 Azure 一致的混合云平台存储子系统外部共享存储SAS JBOD / FC SAN / iSCSI / Shared VHDXS2D直连盘单一 Storage Pool副本机制Storage Replica卷级块复制S2D Mirror三向镜像 / 奇偶校验控制面Failover ClusterAzure Arc Arc Resource BridgeVM / 工作负载管理Failover Cluster ManagerAzure ArcVM Inventory Azure Portal跨站点能力Storage Replica同步 / 异步复制Site Awarenessazloc-2606——拓扑感知不做卷复制灾备模式站点级Site Failure → Storage Replica 切换独立 DR 方案ASR / 异地备份 / 异步复制对象复制范围只复制 VolumeCSV / Data Disk复制整个 Solution StackArc / AKS / Policy网络要求同步模式建议平均 RTT 约 5 ms 或更低RAC≤ 1 ms RTTazloc-2606 hard limit节点规模2~64 节点不对称存储RAC22 / 33 / 44成对扩展推荐 QuorumCloud Witness通常独立故障域Cloud WitnessAzure Local 默认与 SDN 关系可叠加 SDNSDN isnt supported on stretched (multi-site) clustersazloc-2606 software-defined-networking 原文状态Windows Server 2025 继续支持不作为跨站点方案RAC 是机架级高可用推荐16. 一句话总结Stretch Cluster 一个 Failover Cluster 跨两个 Site每个 Site 有独立的不对称共享存储Storage Replica 在两套存储之间做 Volume 级同步或异步复制。它是存储层的解决方案覆盖不了 Azure Local 23H2 的云管理面。所以 Windows Server 2025 保留它服务于传统企业双活Azure Local 则依赖 Fault Domain / Rack Awareness / Local Availability Zone 等拓扑感知能力azloc-2606配合独立的 DR 方案实现分层灾备。