Windows Server 2025 RAC vs Stretch Cluster 技术定位

主旨：把 RAC 和 Stretch Cluster 放回"故障域建模"的语境里，看清它们为什么不是替代关系，而是在不同的故障域层级上互补。

修订记录：

v2（2026-07-09 夜间）：第二轮重写核心定位、四层故障域模型、CSV 多卷数描述、Shared Storage Stretch 拓扑、Fault Domain vs Replication Domain 区分、Azure Local 限定措辞。

v1.bak 已保留（5.7 KB）。

1. 一句话概括（v2 重写）

复制代码

RAC（Rack Aware Cluster / S2D Campus Cluster）
   → 解决 Rack-level Resiliency（机柜级故障）
   → 在同一物理区域内，通过 S2D Fault Domain Awareness 控制副本布局

Stretch Cluster（Storage Replica）
   → 解决 Site-level Disaster Recovery（站点级灾难恢复）
   → 在独立存储系统之间做卷级同步 / 异步复制

二者不是替代关系，而是在不同故障域层级上的互补技术。

为什么不能简单写"HA vs DR"：

RAC 也属于 HA ，但它不是传统意义的 WSFC HA（应用 / VM 故障切换），而是 Fault Domain aware HA------在副本布局层面接受 Rack 级别的故障，不在应用 / VM 接管层面
Stretch 也是 HA，但它的 DR 含义更重：牺牲 RTO / RPO 换取跨站点能力
简化为 "HA vs DR" 会让读者觉得 RAC 不能跨站点、Stretch 只能做跨站点，两边都失去精度

微软对两类技术的官方称呼：

Windows Server 2025 ：Storage Spaces Direct campus cluster（跨机柜的同集群）
Azure Local ：rack aware cluster
文档原文："Storage Spaces Direct campus cluster is also known as rack-aware cluster for Azure Local"------技术基础相同

2. 微软设计的四层故障级别（v2 修订）

v1 是三层（Server → Rack → Site）；v2 加入 Disk 作为最底层，与全文 §7 的四层模型对齐：

复制代码

Disk       ←  物理介质（NVMe / SSD / HDD）
   ↓
Node       ←  单台服务器
   ↓
Rack       ←  整柜故障（PDU / ToR / 整柜掉电）
   ↓
Site       ←  园区级灾难（机房失火 / 园区市电中断）

对应的故障场景与方案：

复制代码

故障范围              推荐方案                          技术机制
───────────────────────────────────────────────────────────────
Disk Failure        S2D 自身 mirror / parity        副本槽在同一 Node 内
Node Failure        S2D mirror / parity            跨 Node 副本
                    + Failover Cluster             + VM 故障切换
Rack Failure        RAC / Campus Cluster            S2D Rack Fault Domain
                                                  + RLNM（Rack Level Nested Mirror）
Site Failure        Stretch Cluster（Windows Server）  独立存储 + Storage Replica
                    Azure Site Recovery（Azure Local） 主机级 / 应用级复制

注意分层之间的差异：

Disk / Node 层是 副本槽机制（在数据写入路径上的容错）
Rack 层是 副本布局策略（Fault Domain Awareness）
Site 层是 完全独立的复制引擎（Storage Replica 把卷视作对象）

3. RAC 到底解决什么（v2 修订）

微软官方定义：

"This direct connection between racks supports a single storage pool , with rack aware clusters guaranteeing data copy distribution evenly between the two racks."（azloc-2606 L49）

3.1 RAC 的物理结构

复制代码

同一个 Failover Cluster
   ├── Rack A（机房 / 房间 1）
   │     ├── Node 1
   │     ├── Node 2
   │     └── （可选 Node 3）
   │
   └── Rack B（机房 / 房间 2）
         ├── Node 4
         ├── Node 5
         └── （可选 Node 6）

注意 RAC 不是一个 Cluster（failover cluster）以外的多 cluster 架构------仍然是单一 Failover Cluster：

一个 Failover Cluster
一个 S2D Storage Pool
多个 CSV Volume（不是只有一个）

Cluster
└── S2D Pool
├── Volume 1（CSV）
├── Volume 2（CSV）
├── Volume 3（CSV）
└── ...

⚠️ v1 错误修正：v1 写 "一个 CSV" 不准确------RAC 下的 CSV 数量由 workload 决定，多卷共存才是常态。

3.2 副本如何布局

RAC 不是复制技术，而是在已有 S2D 副本机制上叠加 Rack Fault Domain Awareness。S2D 知道每个 Node 属于哪个 Rack：

复制代码

Node 1 ∈ Rack A
Node 2 ∈ Rack A
Node 5 ∈ Rack B
Node 6 ∈ Rack B

然后 S2D 在写副本时根据 Volume 配置选择布局。常见的 RAC 副本布局（azloc-2606 post-deployment L93-L116 描述）：

2-way mirror with RLNM（Rack Level Nested Mirror）：

复制代码

Rack A                Rack B
├── Copy 1            ├── Copy 2

4-way mirror with RLNM：

复制代码

Rack A                Rack B
├── Copy 1            ├── Copy 3
└── Copy 2            └── Copy 4

RLNM 是 S2D 在 Volume 上启用 Rack Fault Domain 后的强制约束------每对副本至少跨两个 Rack。一旦某 Rack 整体掉电：

复制代码

Rack A  ✗（掉电）
Rack B  ✓（仍在线）

VM 数据仍然可读（取决于 S2D 副本保留度），VM 可继续在 Rack B 节点的 Host 上运行。

3.3 RAC 的本质

RAC 是 Fault Domain（故障域）优化，不是复制。

RAC 没有引入新引擎 ------它只是让 S2D 在副本布局时感知 Rack。Storage Replica、Journal、Log 这些组件 RAC 一个都没有。

4. Stretch Cluster 解决什么（v2 修订）

Stretch 与 RAC 在故障域层级上完全错开：

复制代码

Site A                              Site B
┌────────────────────┐              ┌────────────────────┐
│ ...                │  Storage     │ ...                │
│                    │  Replica     │                    │
│                    │  ────────►   │                    │
└────────────────────┘              └────────────────────┘

它关注的是"整个 Site 没了怎么办"。但 v1 把 Stretch 直接画成 S2D Stretch 是不完整的------Stretch 实际上有两种典型形态：

4.1 Shared Storage Stretch（外部共享存储）

复制代码

Site A                              Site B
┌────────────────────┐              ┌────────────────────┐
│  Failover Cluster  │              │  Failover Cluster  │
│  ├─ Node 1         │              │  ├─ Node 3         │
│  └─ Node 2         │              │  └─ Node 4         │
│         │          │              │         │          │
│         ▼          │   Storage    │         ▼          │
│    SAS JBOD /      │   Replica    │    SAS JBOD /      │
│    FC SAN LUNs     │ ────────►  │    FC SAN LUNs     │
│   （Site A 存储）  │ ◄────────  │   （Site B 存储）   │
└────────────────────┘              └────────────────────┘

一个 Cluster 跨两个 Site

这是 Stretch Cluster 文档里的默认形态。每站点有独立的不对称存储（FC SAN / SAS JBOD / iSCSI / Shared VHDX），SR 在两个 Site 的存储之间复制卷。

4.2 S2D Stretch（每站点内部跑 S2D）

复制代码

Site A                              Site B
┌────────────────────┐              ┌────────────────────┐
│  Failover Cluster  │              │  Failover Cluster  │
│  ├─ Node 1         │              │  ├─ Node 3         │
│  └─ Node 2         │              │  └─ Node 4         │
│         │          │              │         │          │
│         ▼          │   Storage    │         ▼          │
│   S2D Pool (A)     │   Replica    │   S2D Pool (B)     │
│   (本机直连盘)      │ ────────►  │   (本机直连盘)      │
│                    │ ◄────────  │                    │
└────────────────────┘              └────────────────────┘

一个 Cluster 跨两个 Site，每 Site 内部各跑 S2D

这是历史 HCI 22H2 / 当前部分文献里出现的形态。需要强调：Azure Local 23H2+ 不再采用传统 Windows Server Stretch Cluster 架构（详见 §8）。S2D Stretch 在 Azure Local 上不被官方支持。

⚠️ v1 错误修正：v1 只画了 S2D Stretch 路径，容易让读者把 Stretch 等同于 S2D Stretch。实际上 Shared Storage Stretch 才是文档化的"默认"形态。

4.3 Stretch 的独有组件

Storage Replica（SR 引擎本身）
Replication Log（卷级复制日志，每个 Site 各一份）
Journal
Sync / Async 模式（同步模式建议平均 RTT 约 5 ms 或更低；异步模式无延迟要求但带宽需够）

这些RAC 一个都没有。

5. 为什么不能拿 RAC 替代 Stretch

v2 这段精简了：因为 RAC 没有复制。

复制代码

Rack 1（机房 1）
   ├── Node 1
   ├── Node 2
   └── Node 3

Rack 2（机房 2）
   ├── Node 4
   ├── Node 5
   └── Node 6

实际上是一个 S2D Storage Pool。数据本来就在同一个 Pool 内不同 Rack 的副本槽里。

没有：

Storage Replica
Journal
Recovery Point

如果整个 Site 没了：

复制代码

Site A  ✗
Site B  ✗

Pool 也没了

RAC 结束。

6. 为什么不能拿 Stretch 替代 RAC（v2 修订措辞精度）

反过来也一样。Stretch：

复制代码

Site A
  │
  │  Storage Replica
  ▼
Site B

Site 内部：

复制代码

Site A
  ├── Rack 1
  └── Rack 2

v1 表述："Storage Replica 不知道 Rack"------这个说法过于简化。

v2 准确表述 ：RAC 与 Stretch 工作在不同的抽象层级，不是相互"不知道"：

|---------|-------------------------------------------|-------------------------|
| 抽象层 | RAC | Stretch |
| 数据布局层 | ✅ S2D Pool Placement（含 Rack Fault Domain） | ❌ 不参与 |
| 卷复制层 | ❌ 不参与（S2D 内部） | ✅ Storage Replica 卷级块复制 |
| 故障介入点 | 副本槽写入路径 | 卷级提交路径 |

因此：

Stretch 不会把 Replica 1 放 Rack 1、Replica 2 放 Rack 2------因为它根本不工作在数据布局层
如果 Rack 1 掉电，Stretch 不会自动重新布局副本（它根本不感知 Rack），但 RAC / S2D Pool Placement 会感知并保证副本在 Rack B 可用

RAC 的核心价值正在这里：它在 S2D 数据布局层面感知 Rack，而 Stretch 不知道。

7. 四层 Fault Domain 模型（与 §2 对齐）

复制代码

Site
 └── Rack
      └── Node
           └── Disk

对应方案：

复制代码

Site Failure  →  Stretch Cluster（Windows Server）/ Azure Site Recovery（Azure Local）
Rack Failure  →  RAC / Campus Cluster
Node Failure  →  S2D 自身 mirror / parity + Failover Cluster
Disk Failure  →  S2D 自身 mirror / parity

这是 Windows Server 2025 架构的优势：它保留了对不同故障域的组合建模能力。

8. RAC + Stretch 可以组合吗（v2 降级语气）

⚠️ v2 重要修订：这一节是全文最大的措辞风险点。

v1 表述："理论上可以。Windows Server 2025 支持如下拓扑......这个组合仅 Windows Server 2025 支持。Azure Local 23H2+ 因为 Stretch 已被官方不支持，这种组合也不再可选。"

问题：

"Windows Server 2025 支持如下拓扑"------太绝对。微软文档没有"Windows Server 2025 支持 RAC + Stretch 组合"这一明文确认
RAC + Stretch 的组合在工程上有诸多边界条件（复制链叠加、PR 风险、Cluster Disk Arbitration、四节点可观察性等），不是简单叠加
Azure Local 不支持 Stretch Cluster 是产品定位，不是 RAC + Stretch 技术组合本身不存在

v2 准确表述：

8.1 架构层面的可能性

复制代码

Site A
  ├── Rack 1（Rack Aware）
  └── Rack 2（Rack Aware）
─────────────
Site B
  ├── Rack 3（Rack Aware）
  └── Rack 4（Rack Aware）

架构思想上是可组合的------上层的跨站点用 SR，下层每站点内部用 RAC。但官方支持矩阵需要单独确认，不建议作为通用部署模式。

8.2 微软现在的方向

Windows Server：重点推进 Campus Cluster + Stretch Cluster 的产品矩阵
Azure Local：采用 Rack Aware Cluster + Azure Site Recovery（ASR）等独立 DR 方案
微软正在弱化 Azure Local Stretch 的产品定位------这是产品策略，不等于技术组合本身不存在

8.3 一段通用规则

Windows Server 平台可以构建多级 Fault Domain 架构，但微软是否支持某种组合，需要以具体版本和产品矩阵为准。本文不主张把任意组合泛化为"标准做法"。

9. 决策速查（v2 按故障范围分类）

|------------------------------|----------------------------------------|----------------------------|
| 故障范围 | 推荐方案 | 技术基础 |
| Disk Failure | S2D Mirror / Parity | 副本槽 |
| Node Failure | S2D Mirror / Parity + Failover Cluster | 跨节点副本 + VM 故障切换 |
| Rack Failure | RAC / Campus Cluster | S2D Fault Domain + RLNM |
| Site Failure（Windows Server） | Stretch Cluster | Storage Replica 卷级复制 |
| Site Failure（Azure Local） | Azure Site Recovery（ASR）或应用级 DR | 主机级 / 应用级复制，不采用 Stretch 架构 |

10. Fault Domain 与 Replication Domain 的关键区分（v2 新增）

这是理解 RAC 与 Stretch 的根本钥匙。

10.1 Fault Domain（故障域）

关注数据副本应放在哪里：

复制代码

RAC
 ├── 关注问题：Where should copies live?
 │
 ├── 数据布局：
 │    Rack A
 │    ├── Copy 1
 │    │
 │    Rack B
 │    └── Copy 2
 │
 └── 抽象层：S2D Storage Pool Placement + Fault Domain Awareness

10.2 Replication Domain（复制域）

关注如何在独立存储系统之间复制数据：

复制代码

Stretch
 ├── 关注问题：How to replicate between independent storage systems?
 │
 ├── 复制：
 │    Storage System A
 │       │
 │       │  Block-level Sync / Async
 │       ▼
 │    Storage System B
 │
 └── 抽象层：Storage Replica 卷级块复制

10.3 二者的区别

|--------|----------------------------|------------------------------|
| 维度 | Fault Domain | Replication Domain |
| 关注问题 | 数据副本应放在哪里 | 如何在独立存储系统之间复制 |
| 抽象层 | S2D Storage Pool Placement | 卷级块复制 |
| 对应微软技术 | S2D Fault Domain + RLNM | Storage Replica |
| 工作模式 | 单 Pool + Rack Awareness | 跨 Site / 跨 Cluster 复制 |
| 故障介入点 | 副本槽写入路径 | 卷级提交路径 |
| 节点关系 | 同 Cluster、跨 Rack | 同 Cluster 跨 Site / 跨 Cluster |

结论：RAC 和 Stretch 不在同一个抽象层------把 RAC 视为 "Fault Domain HA"，把 Stretch 视为 "Replication DR"，二者解决的问题维度不同，因此可以共存（详见 §8 的限定）。

11. 关键认知（v2 重写）

RAC 和 Stretch 不是替代关系 ------它们解决不同故障域层级的故障：RAC 在 Fault Domain 层，Stretch 在 Replication Domain 层
RAC 是 Fault Domain HA ------通过 S2D Fault Domain Awareness 在 Rack 层面感知故障，不是传统意义的 WSFC HA
Stretch 是 Replication DR------在独立存储系统之间做卷级同步 / 异步复制；它本身可以提供 HA，但产品定位偏 DR
二者没有相互否定------但 RAC + Stretch 的组合是否被某具体产品版本支持，需要单独查官方支持矩阵
不要把 RAC 简化为 "HA"------会丢掉 Fault Domain Awareness 这层精度；也不要简单把 Stretch 描述为 "DR"------会丢掉 SR 卷级 HA 的语义