这是一篇延伸材料。 主旨：从物理距离、协议开销、应用语义三个层面解释 Stretch Cluster 同步复制的工程门槛，以及它为什么在 AKS 时代显得越来越不合时宜。

术语声明（避免歧义）

• RAC：本文统一指 Rack Awareness Cluster（机架感知延伸集群），特指 Azure Local / Windows Server HCI 在多机架 / 多可用区拓扑下的延伸设计。
• 非 Oracle Real Application Clusters（数据库 RAC）。如文中出现 "RAC" 而未说明，皆指 Rack Awareness Cluster。
• Stretch Cluster：跨站点延伸故障转移集群（Windows Server / Azure Local）。现代实现可基于 Storage Replica；传统实现也可能基于存储阵列复制（SAN replication）。
• Storage Replica（SR）：Windows Server / Azure Local 提供的基于日志（log-based）的块级复制技术，通过复制写入日志实现卷级同步或异步复制。

---

1. 先把单位对齐：5 ms，不是 5 秒

一个常见误解：

"微软要求 Stretch Cluster 延迟不能超过 5 秒。"

这是错误的。

对于基于 Storage Replica 的 Windows Server Stretch Cluster，同步复制场景通常要求站点间 RTT 控制在 5 ms 以内。

5 ms 不是一个协议层面的硬性断点，而是微软根据同步复制性能、IO 延迟和一致性确认路径总结出的工程设计指标。

更准确地说：

模式	延迟要求	典型场景
同步复制（Synchronous Replication）	通常 RTT ≤ 5 ms	同城、同园区、双数据中心
异步复制（Asynchronous Replication）	不要求固定 RTT	跨城市、跨地域灾备

需要注意：

• 不是所有 Stretch Cluster 都必须使用 Storage Replica；传统 SAN Stretch Cluster 也可能依赖存储阵列复制技术（如 FC SAN 阵列级镜像）
• 5 ms 不是 Storage Replica 协议层强制拒绝的阈值
• 实际支持范围取决于整体设计（带宽、抖动、IO 模式、CPU 调度、SR 日志布局等）

实际设计通常需要为以下因素留出余量：

• 网络抖动
• 存储延迟
• CPU 调度
• SMB / Storage Replica 协议处理

因此：

"平均 5 ms"并不等于"稳定满足 Stretch Cluster"。

更重要的是：

P99 延迟比平均延迟更重要。

---

2. 为什么 5 ms 这么难：物理层只是开始

2.1 光纤传播速度

光纤中的传播速度约：

5 μs/km（单程）

注意：

• 这里是单程 latency
• 不包含设备处理

2.2 同城案例

例如：上海浦东 → 上海张江

距离：约 25 km

理论传播：
25 km × 5 μs/km = 125 μs = 0.125 ms

RTT：≈0.25 ms

从物理距离看：完全满足 5 ms。

但是这只是光速模型。

2.3 工程现实

实际 RTT 还包括：

网络设备

例如：

• DWDM
• OTN
• 光模块
• Router
• Switch

每跳：几十 μs 到数百 μs。

安全设备

例如：

• Firewall
• IPS
• 加密设备

可能增加：几十 μs ～ 数 ms。

存储复制协议

Storage Replica 的同步确认路径大致是：

Application Write
    ↓
Source Volume Log Record Creation
    ↓
Replication Stream
    ↓
Destination Volume Log Commit
    ↓
Acknowledgement
    ↓
Application Success

注意：

• "Source Volume Log Record Creation" 是由 Volume 层的日志子系统记录写入，不是 Application 直接调用
• "Destination Log Commit" 是目标卷日志落盘，不一定是目标卷数据已物理落盘
• Storage Replica 后续会在后台异步把日志应用到数据卷

因此真正影响同步复制性能的是写 IO 的同步确认路径（日志落盘 + 网络 + 对端确认）。

典型工程场景 RTT 区间：

场景	RTT
同机房	< 0.1 ms
同园区	0.5 ~ 1 ms
同城双中心	1 ~ 3 ms
接近支持边界	3 ~ 5 ms
跨城	20 ms+

所以微软给 5 ms，本质是给工程环境留下有限余量。

不是说 5.1 ms 马上不可用。

---

3. 同步复制的天然代价

同步复制最大的特点：

写延迟由两个站点中较慢的一方决定。

Application
    ↓
Source Volume Log Record Creation
    ↓
Replication Stream
    ↓
Destination Volume Log Commit
    ↓
Acknowledgement
    ↓
Application Success

关键点：Storage Replica 是基于日志（log-based）的块级复制，不是简单"写数据块 → 对端磁盘写完 → 返回"。

它保证的是：

• 写日志的顺序一致
• 目标卷与源卷的崩溃一致性
• 同步复制模式下、基础设施级的接近零数据丢失（RPO ≈ 0）

注意 RPO ≈ 0 的限定：

• Storage Replica 保证的是 replicated data consistency 和 crash consistency
• 但人为删除、应用错误、恶意修改会被同步复制一并复制到对端
• 这意味着同步复制 ≠ 数据逻辑正确性（详见 §10）

因此：

• 本地存储：0.5 ms
• 远端：3 ms
• 最终应用写延迟：≈ 3 ms+

而不是 0.5 ms。

这不是 Storage Replica 的问题。

这是分布式一致性保证 RPO ≈ 0 必须付出的代价。

---

4. 为什么很多企业最后不用 Stretch Cluster

不是因为 Stretch 不可靠，而是：

很多工作负载不值得承担同步复制成本。

工作负载	Stretch 同步复制适配
金融交易数据库	✅ 非常适合
核心 ERP 数据库	✅
关键业务文件系统	✅
普通 VM	⚠️ 价值有限
OA、邮件	❌
高事务写数据库（SQL OLTP 类）	⚠️ 需要测试（commit latency / write IOPS / transaction frequency 敏感）
Kubernetes 控制组件	⚠️ 需要谨慎评估

Kubernetes 控制面需要单独说明：

Kubernetes 控制组件通常包含大量小事务写入（etcd、API Server、Operator reconcile），同步复制可能放大延迟，因此需要谨慎评估。

这并不是说"不可接受"，而是需要根据业务对延迟与一致性的容忍度，做针对性测试后再决定。

---

5. Hyper-V Replica 为什么通常更容易接受

Windows Server Hyper-V Replica：

• 默认复制间隔约 5 分钟（具体数值随 Windows Server 版本与配置变化）
• 可配置较短或较长间隔（如 30 秒、5 分钟、15 分钟等档位，取决于 Windows Server 版本与场景）
• 支持**扩展复制（Extended Replication）**至第三站点

复制流程：

VM Write
    ↓
Local Storage
    ↓
Application Continue   ← 无需等待远端确认

后台异步：
    ↓
Replication
    ↓
Remote Site

优势：

• 应用无同步等待
• 网络要求低
• 更适合普通 VM DR

代价：

• RPO > 0
• Failover 需要恢复流程

---

6. Stretch Cluster 与 Hyper-V Replica 不是替代关系

维度	Stretch Cluster	Hyper-V Replica
复制层级	Storage Volume	VM
一致性	Storage-level synchronous	VM-level asynchronous
RPO	0（同步）	非 0
性能影响	写路径增加延迟	后台复制
切换粒度	Cluster / Site	VM
典型用途	关键系统连续运行	灾备

---

7. Azure Local 为什么弱化 Stretch Cluster

不是 Azure Local 放弃 Stretch，而是它的核心架构方向已经不再把 Stretch Cluster 作为默认跨站点保护模型。

微软官方限制（明确说明）：

Stretch Cluster 不能保护整个 Azure Local Solution。

原因包括：

Azure Local 包含一组平台级管理组件（具体名称随版本演进），例如：

• Arc Resource Bridge
• AKS on Azure Local 编排组件
• Azure Local management components（含云管理代理、Marketplace 集成、Identity 集成等）
• Cluster 资源桥与控制平面代理
• 监控 / 更新 / 计费 / 许可相关的云服务链路

这些组件不是简单 VM，也不都以"独立 Volume"形式承载业务数据。

因此：

• Stretch 可以保护某些 workload volume
• 但不能让整个 Azure Local 平台获得 Site-level HA

---

8. AKS 时代为什么进一步改变设计

更准确的表述是：

云原生架构降低了同步存储复制作为主要 DR 手段的价值。

8.1 Kubernetes 自带故障恢复模型

Kubernetes 最大的问题不是"写多"，而是它已经具备自己的故障恢复语义：

传统 VM 模式：

VM Failure
    ↓
Storage Replica 同步复制
    ↓
Recover VM on peer site

Kubernetes 模式：

Node Failure
    ↓
Control Plane Detect
    ↓
Scheduler 重新调度
    ↓
Recreate Pod on healthy node

因此：

对 Kubernetes 工作负载而言，基础设施层同步复制并不等价于应用可用性。

Kubernetes 的故障恢复主要围绕 Workload（Pod / Deployment / StatefulSet）调度展开，而不是单纯依赖基础设施 Volume 故障转移。

注意：StatefulSet 场景下 Volume 仍然重要（如 PostgreSQL / Kafka / Elasticsearch StatefulSet），但恢复路径是应用层副本重建 + 持久卷重新挂载，而不是"依赖底层 SR 把整个卷搬过去"。

8.2 应用层复制取代基础设施复制

Kubernetes 本身采用：

• controller reconciliation
• desired state
• workload rescheduling
• application-level replication

例如：

数据库：AlwaysOn / PostgreSQL replication / MongoDB replica set

消息：Kafka replication

而不是依赖底层 Storage synchronous replication。

8.3 现代架构的拆分

Infrastructure HA
    ↓
Local Cluster HA
（Cluster / Rack Awareness Cluster / Fault Domain）

Application HA
    ↓
Kubernetes / Database native replication

DR
    ↓
Async replication / Backup

---

9. 数据点修正

注意：100 m 光纤的理论传播 ≠ "实际 RTT"

• 单程：100 m × 5 μs/km = 0.5 μs
• RTT：≈ 1 μs（理论传播）

但交换机、NIC 的处理延迟通常远大于传播时间本身，所以工程上同房间几乎都是 < 0.1 ms，而不是用 μs 来度量。

修正后的速查表：

距离	理论传播（光速）	工程 RTT（典型）	同步复制可用性
同机柜	纳秒级 ~ 微秒级	< 0.1 ms	✅
同机房	几微秒	< 0.1 ms	✅
同园区	几十 μs	0.5 ~ 1 ms	✅ Cluster / HCI 范畴
同城双中心	0.25 ~ 0.5 ms（理论）	1 ~ 5 ms	⚠️ 需要严格工程验证
跨城	数 ms（理论）	20 ~ 50 ms	❌ 同步无意义，用异步
跨国	几十 ms（理论）	100 ms+	❌ 异步 + 接受 RPO

---

10. 同步复制 ≠ 完整灾备策略

这是本文的关键观点之一。

很多企业误认为：

"Stretch Cluster = DR。"

实际上：

Stretch Cluster 解决的是：

Site Failure
    ↓
保持 Cluster Service Continuity

Stretch Cluster 不能解决：

• 误删除
• 勒索病毒
• 数据逻辑损坏
• 应用错误写入

原因很直接：同步复制会同步错误。

例如：

数据库误删除
    DELETE TABLE
        ↓
    同步复制
        ↓
    灾备站点同时删除

同步复制保护的是"基础设施层的一致性"，不是"数据逻辑层的正确性"。

真正的灾备需要：

• Backup（备份）
• Immutable Backup（不可变备份）
• ASR（Azure Site Recovery）
• Application-level replication（应用层复制）

这一点与 Azure 公有云架构思想一致：

HA 解决"机器坏了怎么办"，DR 解决"数据/逻辑坏了怎么办"——这是两套机制。

全文总结性认知：

Stretch Cluster 解决的是"站点故障下基础设施连续性"，而 Backup / Application Replication 解决的是"数据状态正确性"。

---

11. 最终关键认知

Stretch Cluster 没有失败，而是在云时代重新定位。

核心认识：

1. 5 ms 是同步复制工程边界，不是 5 秒，也不是简单距离限制，更不是协议层硬性断点。
2. 同步复制最大的成本不是网络带宽，而是写路径延迟。
3. Storage Replica 是基于日志的块级复制，保证同步复制模式下、基础设施级的接近零数据丢失（RPO ≈ 0），而不是块级数据同步。
4. Storage Replica 适合真正需要 RPO ≈ 0 的关键系统，而不是所有 VM。
5. Azure Local 的设计越来越强调 HA 与 DR 分离：
   1. 本地 HA：Cluster / Rack Awareness Cluster / Fault Domain
   2. 应用 HA：Kubernetes / Database native replication
   3. 异地 DR：ASR / Backup / Async replication
6. Kubernetes 的故障恢复单位是 Workload（Pod / Deployment / StatefulSet）调度，基础设施层同步复制并不等价于应用可用性。
7. 同步复制 ≠ 完整 DR——误删、勒索、逻辑损坏需要 Backup / ASR / Application-level replication 解决。
8. 现代云架构不是消灭 Stretch，而是不再让 Stretch 承担所有问题。