Windows Server 2025 Stretch Cluster 架构详解

主旨：单独把 Stretch Cluster 这项技术讲透------它不是单一组件，而是 Storage Replica + Failover Cluster + Asymmetric Shared Storage 的组合架构。本文以微软 Storage Replica Overview（2025-08-22 更新）原文为锚点。

1. 一句话定义

Stretch Cluster = 一个 Failover Cluster（跨两个 Site）+ Storage Replica（在两套独立存储之间做卷级复制）

它不是把两个集群拉成一个，也不是简单的"复制 VM"。它是把同一个 Failover Cluster 的成员节点人为划分到两个 Site，每个 Site 有各自的共享存储，Storage Replica 在两套存储之间做 Volume 级镜像。

2. 架构全景（一张图）

复制代码

                     ┌─────────────────────── Site A ───────────────────────┐
                     │                                                       │
                     │   Node 1（Site A）                                    │
                     │   Node 2（Site 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 3（Site B）                │                   │
                     │   Node 4（Site B）                │                   │
                     │                                                       │
                     └───────────────────────────────────────────────────────┘

                          Failover Cluster 名：SR-SRVCLUS（一个 Cluster）
                          Site 标识（logical site）：Redmond / 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 1（Site A）   │            │   Node 2（Site B）   │
│         │            │            │         │            │
│         ▼            │   Storage  │         ▼            │
│   SAS JBOD / FC SAN  │   Replica  │   SAS JBOD / FC SAN  │
│   （Site A 存储）    │ ────────► │   （Site B 存储）     │
│                      │ ◄──────── │                      │
└──────────────────────┘            └──────────────────────┘

一个 Failover Cluster（SR-SRVCLUS）

典型生产部署（4 节点，每站点 2 节点）：

复制代码

Site A                              Site B
┌──────────────────────┐            ┌──────────────────────┐
│   Node 1（Site A）   │            │   Node 3（Site B）   │
│   Node 2（Site A）   │            │   Node 4（Site B）   │
│         │            │            │         │            │
│         ▼            │            │         ▼            │
│   SAS JBOD / FC SAN  │   Storage  │   SAS JBOD / FC SAN  │
│   （Site A 存储）    │   Replica  │   （Site B 存储）     │
│   2 节点可见         │ ◄───────► │   2 节点可见         │
└──────────────────────┘            └──────────────────────┘

一个 Failover Cluster（SR-SRVCLUS）

两者的关键差异：

|--------|-----------------------|---------------------------|
| 维度 | 最小部署（2 节点） | 典型生产部署（4 节点） |
| 站点内冗余 | 无（每站点只有 1 节点） | 有（每站点 2 节点，可站点内 failover） |
| 单节点维护 | 必须停机（无可迁出目标） | 可在站内维护（Live Migration） |
| 适合场景 | 演示、概念验证、极小业务 | 关键交易、生产双活 |
| 微软文档示例 | "as few as two nodes" | 默认 4 节点示例（SR-SRV01~04） |

4. 核心组件拆解

4.1 Storage Replica（复制引擎）

Storage Replica 是 Windows Server 自带的卷级块复制引擎，关键特征：

跑在 partition layer（分区层），所有 VSS snapshot 都会被复制
同步复制：保证两 Site 写入崩溃一致（crash-consistent），RPO = 0
异步复制：跨更高延迟，不保证两 Site 在故障时点一致（RPO > 0）
连续复制（不是 checkpoint-based），delta 比 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 节点以提高站点内冗余）
Quorum：File Share Witness 或 Cloud Witness（推荐 Cloud Witness）
用 Set-ClusterQuorum -FileShareWitness \\SomeServer\SomeShare 或 Set-ClusterQuorum -CloudWitness

4.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 site's shared storage"------这是硬性要求，不是建议。

|------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 维度 | 要求 |
| 存储类型 | SAS JBODs（配 Storage Spaces）/ FC SAN LUNs / iSCSI Target / Shared VHDX |
| 是否支持 S2D | 不支持（原文："This scenario doesn't make use of Storage Spaces Direct"） |
| 物理位置 | 每个 Site 内，独立机房 |
| Sector size | 两套存储的 data disk 和 log disk 必须各自相同 |
| Persistent Reservation | 应支持 SCSI Persistent Reservation（PR）机制------这是 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 |

为什么不用 S2D：

S2D 的前提是"每个节点都能看到本地所有磁盘，构成一个统一的 Storage Pool"。Stretch Cluster 的设计前提是"两 Site 各自独立的存储"，这两个抽象层不兼容。

想用 S2D 做跨站点复制？用 Cluster-to-cluster replication（明确支持 S2D）。

5. 数据流（写 IO 路径）

Storage Replica 的数据流不是简单的"写本地 → 写远端 → 返回 ACK"串行模型。它基于 Log-First、Replay-Back 的 Pipeline：

复制代码

                    Application
                        │
                        ▼ write
                  SR Filter Driver
                        │
                        ▼
                  Local Log Volume
                        │ ←------ 同步复制（同步模式）------→
                        │       SMB 3（TCP 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 sequentially"）
Log 卷必须比 Data 卷快------这是微软的明确建议（官方原话："Microsoft recommends that the log storage be faster than the data storage"）

6. 同步 vs 异步

6.1 同步（Synchronous Replication）

|--------|-------------------------------------------------------------------------------------------------------------------------------------------------|
| 维度 | 要求 |
| RTT | 建议平均 RTT 约 5 ms 或更低（微软官方原文："an average of ~5ms round trip latency for synchronous replication"------average、approximately 含义，不要理解为硬性 ≤ 阈值） |
| 带宽 | 至少 1 GbE，建议 RDMA |
| RPO | 0（零数据丢失） |
| 一致性 | 崩溃一致（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，则可利用 RDMA（RoCE v2 / iWARP / InfiniBand）降低 CPU 开销并提升吞吐。Stretch Cluster 在同步复制场景下，网络带宽必须能容纳完整 IO 写负载：

|--------|-------------------------|------------------------------------------------------------------------------------|
| 端口 | 协议 | 用途 |
| 445 | SMB | 节点间存储复制、cluster heartbeat |
| 5445 | SMB（SR Server Instance） | Storage Replica 启用的独立 SMB Server Instance 监听端口（与 TCP 445 二选一，非 SMB Direct 协议本身的端口） |
| 5985 | WS-MAN | 远程管理（PowerShell / WAC） |
| ICMP | --- | 节点连通性 |

对网络的要求：

至少 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 A（2 节点）+ Site B（2 节点）= 4 节点 cluster

如果 A 和 B 之间网络断开，两个 Site 各自只有 2 节点，可能出现脑裂（split-brain）。Quorum 机制解决这个问题：

|------------------------|--------------------------------------------------|-----------------------------------------------------------------------------------|
| Witness 类型 | 配置命令 | 推荐场景 |
| File Share Witness | Set-ClusterQuorum -FileShareWitness \\FS\Share | 第三方数据中心、不在 Azure |
| Cloud Witness | Set-ClusterQuorum -CloudWitness | 有 Azure 订阅、跨云（通常部署在独立故障域，可避免单一 Site 故障影响仲裁------但 Azure Region 整体故障 / 网络全断时仍可能影响） |
| Disk Witness | Set-ClusterQuorum -DiskWitness | 不推荐（增加 SPOF） |

微软推荐 Cloud Witness------它通常部署在与两个 Site 都不同的故障域（Azure Blob），因此可避免单一 Site 的灾难波及；但 Azure Region 整体故障或与 Azure 的网络全断仍会影响 Witness 可用性，此时集群会失去仲裁但不会自动故障切换（取决于剩余节点能否达成 quorum）。

10. 故障切换（最关键的运维动作）

10.1 自动 vs 手动（按部署模式）

|------------------------|--------------------------------------------------------------------|
| 模式 | 故障切换机制 |
| Stretch Cluster | Failover Cluster 自动 failover（VM / 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 rg01

10.3 解除复制

复制代码

# 解除 partnership（两个 cluster 各跑一次）
Get-SRPartnership | Remove-SRPartnership
Get-SRGroup | Remove-SRGroup

11. Test-SRTopology：上线前的强制动作

微软提供 Test-SRTopology cmdlet 做前置验证：

复制代码

# 安装 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 用 S2D | "This scenario doesn't make use of Storage Spaces Direct" | Stretch 配置指南原文 |
| 操作系统盘做复制 | "The replicated storage can't be located on the drive containing the Windows operating system folder" | Stretch 配置指南原文 |
| 把 Log 卷给其他工作负载用 | "Log volumes must never be used for other workloads" | Stretch 配置指南原文 |
| 同步复制跨长距离（网络平均 RTT 明显高于微软建议的 ~5 ms） | 不推荐（同步模式可跑，但每增加 1 ms RTT 都会同步增加所有写 IO 的延迟，RPO 0 的承诺仍成立但应用性能代价会显著上升；超长距离应改用异步模式） | Storage Replica Overview |

13. 数据盘可选的 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 Cluster | Rack Aware Cluster |
| Cluster 数量 | 一个 Cluster（跨两 Site） | 一个 Cluster（同一数据中心） |
| 存储 | 两套不对称存储（每 Site 一套） | 一套统一存储（S2D Pool） |
| 复制 | Storage Replica（Volume 级） | 无复制（S2D 副本槽分布） |
| 网络要求 | 同步建议平均 RTT 约 5 ms 或更低（微软建议值，非硬阈值）；异步无硬性 | ≤ 1 ms RTT |
| 抽象层 | 存储层 | 集群 + 存储 + 调度全栈 |
| Azure Local 23H2+ | 不支持 | 官方推荐（azloc-2606） |
| Windows 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 Cluster（Azure Local 的多机架高可用拓扑），与 Oracle RAC（Real Application Clusters）无关。

15.1 Stretch Cluster 与 Azure Local 架构差异（速查对比）

|-------------|-------------------------------------------------|-----------------------------------------------------------------------------------------------------|
| 维度 | Windows Server Stretch Cluster | Azure Local（23H2+，含 RAC） |
| 产品目标 | 传统企业双活（银行、医院、政府、制造） | 与 Azure 一致的混合云平台 |
| 存储子系统 | 外部共享存储（SAS JBOD / FC SAN / iSCSI / Shared VHDX） | S2D（直连盘，单一 Storage Pool） |
| 副本机制 | Storage Replica（卷级块复制） | S2D Mirror（三向镜像 / 奇偶校验） |
| 控制面 | Failover Cluster | Azure Arc + Arc Resource Bridge |
| VM / 工作负载管理 | Failover Cluster Manager | Azure Arc（VM Inventory）+ Azure Portal |
| 跨站点能力 | Storage Replica（同步 / 异步复制） | Site Awareness（azloc-2606）------拓扑感知，不做卷复制 |
| 灾备模式 | 站点级（Site Failure → Storage Replica 切换） | 独立 DR 方案（ASR / 异地备份 / 异步复制） |
| 对象复制范围 | 只复制 Volume（CSV / Data Disk） | 复制整个 Solution Stack（Arc / AKS / Policy） |
| 网络要求 | 同步模式建议平均 RTT 约 5 ms 或更低 | RAC：≤ 1 ms RTT（azloc-2606 hard limit） |
| 节点规模 | 2~64 节点（不对称存储） | RAC：2+2 / 3+3 / 4+4（成对扩展） |
| 推荐 Quorum | Cloud Witness（通常独立故障域） | Cloud Witness（Azure Local 默认） |
| 与 SDN 关系 | 可叠加 SDN | "SDN isn't supported on stretched (multi-site) clusters"（azloc-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 方案实现分层灾备。