主旨把 RAC 和 Stretch Cluster 放回故障域建模的语境里看清它们为什么不是替代关系而是在不同的故障域层级上互补。修订记录v22026-07-09 夜间第二轮重写核心定位、四层故障域模型、CSV 多卷数描述、Shared Storage Stretch 拓扑、Fault Domain vs Replication Domain 区分、Azure Local 限定措辞。v1.bak已保留5.7 KB。1. 一句话概括v2 重写RACRack Aware Cluster / S2D Campus Cluster → 解决 Rack-level Resiliency机柜级故障 → 在同一物理区域内通过 S2D Fault Domain Awareness 控制副本布局 Stretch ClusterStorage Replica → 解决 Site-level Disaster Recovery站点级灾难恢复 → 在独立存储系统之间做卷级同步 / 异步复制 二者不是替代关系而是在不同故障域层级上的互补技术。为什么不能简单写HA vs DRRAC也属于 HA但它不是传统意义的 WSFC HA应用 / VM 故障切换而是Fault Domain aware HA——在副本布局层面接受 Rack 级别的故障不在应用 / VM 接管层面Stretch也是 HA但它的 DR 含义更重牺牲 RTO / RPO 换取跨站点能力简化为 HA vs DR 会让读者觉得 RAC 不能跨站点、Stretch 只能做跨站点两边都失去精度微软对两类技术的官方称呼Windows Server 2025Storage Spaces Directcampus cluster跨机柜的同集群Azure Localrack aware cluster文档原文Storage Spaces Direct campus cluster is also known as rack-aware cluster for Azure Local——技术基础相同2. 微软设计的四层故障级别v2 修订v1 是三层Server → Rack → Sitev2 加入 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 RLNMRack Level Nested Mirror Site Failure Stretch ClusterWindows Server 独立存储 Storage Replica Azure Site RecoveryAzure Local 主机级 / 应用级复制注意分层之间的差异Disk / Node 层是副本槽机制在数据写入路径上的容错Rack 层是副本布局策略Fault Domain AwarenessSite 层是完全独立的复制引擎Storage Replica 把卷视作对象3. RAC 到底解决什么v2 修订微软官方定义This direct connection between racks supports asingle storage pool, with rack aware clusters guaranteeing data copy distributionevenly between the two racks.azloc-2606 L493.1 RAC 的物理结构同一个 Failover Cluster ├── Rack A机房 / 房间 1 │ ├── Node 1 │ ├── Node 2 │ └── 可选 Node 3 │ └── Rack B机房 / 房间 2 ├── Node 4 ├── Node 5 └── 可选 Node 6注意 RAC不是一个 Clusterfailover cluster以外的多 cluster 架构——仍然是单一 Failover Cluster一个 Failover Cluster一个 S2D Storage Pool多个CSV Volume不是只有一个Cluster └── S2D Pool ├── Volume 1CSV ├── Volume 2CSV ├── Volume 3CSV └── ...⚠️v1 错误修正v1 写 一个 CSV 不准确——RAC 下的 CSV 数量由 workload 决定多卷共存才是常态。3.2 副本如何布局RAC不是复制技术而是在已有 S2D 副本机制上叠加 Rack Fault Domain Awareness。S2D 知道每个 Node 属于哪个 RackNode 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 RLNMRack Level Nested MirrorRack A Rack B ├── Copy 1 ├── Copy 24-way mirror with RLNMRack A Rack B ├── Copy 1 ├── Copy 3 └── Copy 2 └── Copy 4RLNM 是 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 VHDXSR 在两个 Site 的存储之间复制卷。4.2 S2D Stretch每站点内部跑 S2DSite 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 ReplicaSR 引擎本身Replication Log卷级复制日志每个 Site 各一份JournalSync / Async 模式同步模式建议平均 RTT 约 5 ms 或更低异步模式无延迟要求但带宽需够这些RAC 一个都没有。5. 为什么不能拿 RAC 替代 Stretchv2 这段精简了因为 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 ReplicaJournalRecovery Point如果整个 Site 没了Site A ✗ Site B ✗ Pool 也没了RAC 结束。6. 为什么不能拿 Stretch 替代 RACv2 修订措辞精度反过来也一样。StretchSite A │ │ Storage Replica ▼ Site BSite 内部Site A ├── Rack 1 └── Rack 2v1 表述Storage Replica 不知道 Rack——这个说法过于简化。v2 准确表述RAC 与 Stretch工作在不同的抽象层级不是相互不知道抽象层RACStretch数据布局层✅ 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 ClusterWindows Server/ Azure Site RecoveryAzure 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 1Rack Aware └── Rack 2Rack Aware ───────────── Site B ├── Rack 3Rack Aware └── Rack 4Rack Aware架构思想上是可组合的——上层的跨站点用 SR下层每站点内部用 RAC。但官方支持矩阵需要单独确认不建议作为通用部署模式。8.2 微软现在的方向Windows Server重点推进 Campus Cluster Stretch Cluster 的产品矩阵Azure Local采用 Rack Aware Cluster Azure Site RecoveryASR等独立 DR 方案微软正在弱化 Azure Local Stretch 的产品定位——这是产品策略不等于技术组合本身不存在8.3 一段通用规则Windows Server 平台可以构建多级 Fault Domain 架构但微软是否支持某种组合需要以具体版本和产品矩阵为准。本文不主张把任意组合泛化为标准做法。9. 决策速查v2 按故障范围分类故障范围推荐方案技术基础Disk FailureS2D Mirror / Parity副本槽Node FailureS2D Mirror / Parity Failover Cluster跨节点副本 VM 故障切换Rack FailureRAC / Campus ClusterS2D Fault Domain RLNMSite FailureWindows ServerStretch ClusterStorage Replica 卷级复制Site FailureAzure LocalAzure Site RecoveryASR或应用级 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 Awareness10.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 DomainReplication Domain关注问题数据副本应放在哪里如何在独立存储系统之间复制抽象层S2D Storage Pool Placement卷级块复制对应微软技术S2D Fault Domain RLNMStorage 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 HAStretch 是 Replication DR——在独立存储系统之间做卷级同步 / 异步复制它本身可以提供 HA但产品定位偏 DR二者没有相互否定——但 RAC Stretch 的组合是否被某具体产品版本支持需要单独查官方支持矩阵不要把 RAC 简化为 HA——会丢掉 Fault Domain Awareness 这层精度也不要简单把 Stretch 描述为 DR——会丢掉 SR 卷级 HA 的语义