这是一篇延伸材料。 主旨从物理距离、协议开销、应用语义三个层面解释 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 ReplicaSRWindows 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 还包括网络设备例如DWDMOTN光模块RouterSwitch每跳几十 μs 到数百 μs。安全设备例如FirewallIPS加密设备可能增加几十 μ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 0Failover 需要恢复流程6. Stretch Cluster 与 Hyper-V Replica 不是替代关系维度Stretch ClusterHyper-V Replica复制层级Storage VolumeVM一致性Storage-level synchronousVM-level asynchronousRPO0同步非 0性能影响写路径增加延迟后台复制切换粒度Cluster / SiteVM典型用途关键系统连续运行灾备7. Azure Local 为什么弱化 Stretch Cluster不是 Azure Local 放弃 Stretch而是它的核心架构方向已经不再把 Stretch Cluster 作为默认跨站点保护模型。微软官方限制明确说明Stretch Cluster 不能保护整个 Azure Local Solution。原因包括Azure Local 包含一组平台级管理组件具体名称随版本演进例如Arc Resource BridgeAKS on Azure Local 编排组件Azure Local management components含云管理代理、Marketplace 集成、Identity 集成等Cluster 资源桥与控制平面代理监控 / 更新 / 计费 / 许可相关的云服务链路这些组件不是简单 VM也不都以独立 Volume形式承载业务数据。因此Stretch 可以保护某些 workload volume但不能让整个 Azure Local 平台获得 Site-level HA8. AKS 时代为什么进一步改变设计更准确的表述是云原生架构降低了同步存储复制作为主要 DR 手段的价值。8.1 Kubernetes 自带故障恢复模型Kubernetes 最大的问题不是写多而是它已经具备自己的故障恢复语义传统 VM 模式VM Failure ↓ Storage Replica 同步复制 ↓ Recover VM on peer siteKubernetes 模式Node Failure ↓ Control Plane Detect ↓ Scheduler 重新调度 ↓ Recreate Pod on healthy node因此对 Kubernetes 工作负载而言基础设施层同步复制并不等价于应用可用性。Kubernetes 的故障恢复主要围绕WorkloadPod / Deployment / StatefulSet调度展开而不是单纯依赖基础设施 Volume 故障转移。注意StatefulSet 场景下 Volume 仍然重要如 PostgreSQL / Kafka / Elasticsearch StatefulSet但恢复路径是应用层副本重建 持久卷重新挂载而不是依赖底层 SR 把整个卷搬过去。8.2 应用层复制取代基础设施复制Kubernetes 本身采用controller reconciliationdesired stateworkload reschedulingapplication-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 / Backup9. 数据点修正注意100 m 光纤的理论传播 ≠ 实际 RTT单程100 m × 5 μs/km 0.5 μsRTT≈ 1 μs理论传播但交换机、NIC 的处理延迟通常远大于传播时间本身所以工程上同房间几乎都是 0.1 ms而不是用 μs 来度量。修正后的速查表距离理论传播光速工程 RTT典型同步复制可用性同机柜纳秒级 ~ 微秒级 0.1 ms✅同机房几微秒 0.1 ms✅同园区几十 μs0.5 ~ 1 ms✅ Cluster / HCI 范畴同城双中心0.25 ~ 0.5 ms理论1 ~ 5 ms⚠️ 需要严格工程验证跨城数 ms理论20 ~ 50 ms❌ 同步无意义用异步跨国几十 ms理论100 ms❌ 异步 接受 RPO10. 同步复制 ≠ 完整灾备策略这是本文的关键观点之一。很多企业误认为Stretch Cluster DR。实际上Stretch Cluster 解决的是Site Failure ↓ 保持 Cluster Service ContinuityStretch Cluster 不能解决误删除勒索病毒数据逻辑损坏应用错误写入原因很直接同步复制会同步错误。例如数据库误删除 DELETE TABLE ↓ 同步复制 ↓ 灾备站点同时删除同步复制保护的是基础设施层的一致性不是数据逻辑层的正确性。真正的灾备需要Backup备份Immutable Backup不可变备份ASRAzure Site RecoveryApplication-level replication应用层复制这一点与 Azure 公有云架构思想一致HA 解决机器坏了怎么办DR 解决数据/逻辑坏了怎么办——这是两套机制。全文总结性认知Stretch Cluster 解决的是站点故障下基础设施连续性而 Backup / Application Replication 解决的是数据状态正确性。11. 最终关键认知Stretch Cluster 没有失败而是在云时代重新定位。核心认识5 ms 是同步复制工程边界不是 5 秒也不是简单距离限制更不是协议层硬性断点。同步复制最大的成本不是网络带宽而是写路径延迟。Storage Replica 是基于日志的块级复制保证同步复制模式下、基础设施级的接近零数据丢失RPO ≈ 0而不是块级数据同步。Storage Replica 适合真正需要 RPO ≈ 0 的关键系统而不是所有 VM。Azure Local 的设计越来越强调 HA 与 DR 分离本地 HACluster / Rack Awareness Cluster / Fault Domain应用 HAKubernetes / Database native replication异地 DRASR / Backup / Async replicationKubernetes 的故障恢复单位是 WorkloadPod / Deployment / StatefulSet调度基础设施层同步复制并不等价于应用可用性。同步复制 ≠ 完整 DR——误删、勒索、逻辑损坏需要 Backup / ASR / Application-level replication 解决。现代云架构不是消灭 Stretch而是不再让 Stretch 承担所有问题。
这是一篇延伸材料。 主旨从物理距离、协议开销、应用语义三个层面解释 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 ReplicaSRWindows 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 还包括网络设备例如DWDMOTN光模块RouterSwitch每跳几十 μs 到数百 μs。安全设备例如FirewallIPS加密设备可能增加几十 μ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 0Failover 需要恢复流程6. Stretch Cluster 与 Hyper-V Replica 不是替代关系维度Stretch ClusterHyper-V Replica复制层级Storage VolumeVM一致性Storage-level synchronousVM-level asynchronousRPO0同步非 0性能影响写路径增加延迟后台复制切换粒度Cluster / SiteVM典型用途关键系统连续运行灾备7. Azure Local 为什么弱化 Stretch Cluster不是 Azure Local 放弃 Stretch而是它的核心架构方向已经不再把 Stretch Cluster 作为默认跨站点保护模型。微软官方限制明确说明Stretch Cluster 不能保护整个 Azure Local Solution。原因包括Azure Local 包含一组平台级管理组件具体名称随版本演进例如Arc Resource BridgeAKS on Azure Local 编排组件Azure Local management components含云管理代理、Marketplace 集成、Identity 集成等Cluster 资源桥与控制平面代理监控 / 更新 / 计费 / 许可相关的云服务链路这些组件不是简单 VM也不都以独立 Volume形式承载业务数据。因此Stretch 可以保护某些 workload volume但不能让整个 Azure Local 平台获得 Site-level HA8. AKS 时代为什么进一步改变设计更准确的表述是云原生架构降低了同步存储复制作为主要 DR 手段的价值。8.1 Kubernetes 自带故障恢复模型Kubernetes 最大的问题不是写多而是它已经具备自己的故障恢复语义传统 VM 模式VM Failure ↓ Storage Replica 同步复制 ↓ Recover VM on peer siteKubernetes 模式Node Failure ↓ Control Plane Detect ↓ Scheduler 重新调度 ↓ Recreate Pod on healthy node因此对 Kubernetes 工作负载而言基础设施层同步复制并不等价于应用可用性。Kubernetes 的故障恢复主要围绕WorkloadPod / Deployment / StatefulSet调度展开而不是单纯依赖基础设施 Volume 故障转移。注意StatefulSet 场景下 Volume 仍然重要如 PostgreSQL / Kafka / Elasticsearch StatefulSet但恢复路径是应用层副本重建 持久卷重新挂载而不是依赖底层 SR 把整个卷搬过去。8.2 应用层复制取代基础设施复制Kubernetes 本身采用controller reconciliationdesired stateworkload reschedulingapplication-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 / Backup9. 数据点修正注意100 m 光纤的理论传播 ≠ 实际 RTT单程100 m × 5 μs/km 0.5 μsRTT≈ 1 μs理论传播但交换机、NIC 的处理延迟通常远大于传播时间本身所以工程上同房间几乎都是 0.1 ms而不是用 μs 来度量。修正后的速查表距离理论传播光速工程 RTT典型同步复制可用性同机柜纳秒级 ~ 微秒级 0.1 ms✅同机房几微秒 0.1 ms✅同园区几十 μs0.5 ~ 1 ms✅ Cluster / HCI 范畴同城双中心0.25 ~ 0.5 ms理论1 ~ 5 ms⚠️ 需要严格工程验证跨城数 ms理论20 ~ 50 ms❌ 同步无意义用异步跨国几十 ms理论100 ms❌ 异步 接受 RPO10. 同步复制 ≠ 完整灾备策略这是本文的关键观点之一。很多企业误认为Stretch Cluster DR。实际上Stretch Cluster 解决的是Site Failure ↓ 保持 Cluster Service ContinuityStretch Cluster 不能解决误删除勒索病毒数据逻辑损坏应用错误写入原因很直接同步复制会同步错误。例如数据库误删除 DELETE TABLE ↓ 同步复制 ↓ 灾备站点同时删除同步复制保护的是基础设施层的一致性不是数据逻辑层的正确性。真正的灾备需要Backup备份Immutable Backup不可变备份ASRAzure Site RecoveryApplication-level replication应用层复制这一点与 Azure 公有云架构思想一致HA 解决机器坏了怎么办DR 解决数据/逻辑坏了怎么办——这是两套机制。全文总结性认知Stretch Cluster 解决的是站点故障下基础设施连续性而 Backup / Application Replication 解决的是数据状态正确性。11. 最终关键认知Stretch Cluster 没有失败而是在云时代重新定位。核心认识5 ms 是同步复制工程边界不是 5 秒也不是简单距离限制更不是协议层硬性断点。同步复制最大的成本不是网络带宽而是写路径延迟。Storage Replica 是基于日志的块级复制保证同步复制模式下、基础设施级的接近零数据丢失RPO ≈ 0而不是块级数据同步。Storage Replica 适合真正需要 RPO ≈ 0 的关键系统而不是所有 VM。Azure Local 的设计越来越强调 HA 与 DR 分离本地 HACluster / Rack Awareness Cluster / Fault Domain应用 HAKubernetes / Database native replication异地 DRASR / Backup / Async replicationKubernetes 的故障恢复单位是 WorkloadPod / Deployment / StatefulSet调度基础设施层同步复制并不等价于应用可用性。同步复制 ≠ 完整 DR——误删、勒索、逻辑损坏需要 Backup / ASR / Application-level replication 解决。现代云架构不是消灭 Stretch而是不再让 Stretch 承担所有问题。
