📚 课程目录第4章 SnapMirror跨云复制实战

4. SnapMirror跨云复制实战

SnapMirror 是 ONTAP 数据保护体系中的核心复制引擎，在混合云场景下，它承担着本地集群与 Cloud Volumes ONTAP、FSx for ONTAP 等云端实例之间的数据同步任务。与同集群 Snapshot 不同，SnapMirror 跨越了网络边界，因此策略设计、传输链路、断点处理和角色切换都需要更细致的规划。本节围绕一条完整的跨云复制链路，从策略定义到回切收尾，逐步展开可落地的操作过程。

一、策略设计：先定 RPO，再定规则

SnapMirror 策略（policy）决定了“保留多少份 Snapshot、多久传一次、失败后如何重试”。跨云场景中，网络带宽和出站费用是硬约束，因此策略不能照搬本地。一个典型的跨云策略包含三类规则：mirror（仅保留用于传输的基线快照）、mirror-vault（镜像加归档，保留多份历史）、vault（仅归档，不参与镜像）。跨云复制通常选择 MirrorAllSnapshots 或自定义 mirror-vault 策略。

假设业务要求 RPO 为 15 分钟，且云端需保留 7 天恢复点。可定义如下策略：

snapmirror policy create -policy CrossCloud_15min \
  -type mirror-vault \
  -comment "RPO 15min, retain 7d" \
  -retention-classic-count 4

snapmirror policy add-rule -policy CrossCloud_15min \
  -vserver svm_prod \
  -rule-type snapmirror-vault \
  -schedule 15min \
  -snapmirror-label daily -keep 7

这里 -schedule 15min 对应 RPO，-keep 7 表示保留 7 份 daily 标签快照。注意：策略中的 schedule 只决定“何时创建快照并触发传输”，实际传输是否成功还取决于链路状态。跨云链路建议启用 -transfer-priority 与带宽限速，避免复制流量挤占业务。

二、初始化：基线传输与关系建立

初始化（initialize）是 SnapMirror 关系的第一次全量传输。跨云初始化往往耗时最长，也最容易因网络抖动中断。推荐做法是：先在源端创建基线 Snapshot，再通过 snapmirror initialize 启动传输。若数据量极大，可考虑使用 SnapMirror 的“种子”（seed）机制，将基线数据离线拷贝到云端后再做增量同步。

snapmirror initialize -source-path svm_prod:vol_data \
  -destination-path svm_cloud:vol_data_dr

snapmirror show -destination-path svm_cloud:vol_data_dr -fields state,status,lag-time

初始化期间，目标卷处于 snapmirrored 状态，不可直接挂载读写。判断初始化是否完成，关键看 state 变为 snapmirrored 且 status 为 Idle，同时 lag-time 开始正常刷新。若长时间停留在 Transferring，应检查 snapmirror show -instance 中的 Transfer Snapshot 与 Total Bytes 进度。

三、增量更新与断点续传

初始化完成后，SnapMirror 进入增量更新阶段。每次调度触发时，源端创建新 Snapshot，目标端只传输差异块。跨云链路的断点续传依赖 ONTAP 的 checkpoint 机制：传输中断后，已传完的块被记录，下次从断点继续，而不是从头重传。

判断断点续传是否生效，可观察 snapmirror show -instance 中的 Restart Checkpoint 字段。若该字段存在且 Transfer State 为 Transferring，说明正在续传。若发现每次中断后都从 0 开始，通常是因为目标端卷被删除或关系被 break 后未保留检查点。

跨云复制建议开启 -throttle 限速，并监控 snapmirror show -fields lag-time。lag-time 持续增长说明复制跟不上 RPO，需要调整调度或带宽。

四、故障切换与回切

当源端集群故障时，需要执行故障切换（failover）。标准操作是 snapmirror break，将目标卷转为可读写，业务切换到云端。切换前务必确认最后一次成功传输的 Snapshot 时间点，避免丢失过多数据。

snapmirror break -destination-path svm_cloud:vol_data_dr

snapmirror resync -source-path svm_cloud:vol_data_dr \
  -destination-path svm_prod:vol_data

回切（failback）时，原源端恢复后，先执行 snapmirror resync 反向同步，再 snapmirror break 切回。注意：resync 会以当前目标端为源，因此必须确认哪一侧数据最新。若两侧都有写入，需要人工比对或使用 SnapMirror 的 snapmirror restore 做选择性恢复。

五、关键判断与常见问题

跨云复制最容易出问题的三个点：一是 lag-time 持续增长，说明带宽不足或调度过密，应降低频率或启用限速；二是 resync 方向搞反，导致旧数据覆盖新数据，操作前务必用 snapmirror show -instance 确认 Source Path 与 Destination Path；三是 策略保留份数不足，故障切换后无法回滚到更早时间点。建议在切换前手动创建一份带标签的 Snapshot，作为回切锚点。

阶段	关键命令	观察指标	异常处理
初始化	snapmirror initialize	state=snapmirrored, status=Idle	检查网络与 MTU
增量	自动调度	lag-time 稳定	调整 schedule 或限速
断点续传	自动 checkpoint	Restart Checkpoint 存在	避免 break 后重传
故障切换	snapmirror break	卷可读写	确认最新 Snapshot
回切	snapmirror resync	反向同步完成	核对数据方向

最后强调一点：跨云 SnapMirror 不是“设好就不管”的组件。建议将 lag-time、Transfer State、Last Transfer Size 纳入日常监控，并在每次故障切换演练后记录实际 RPO 与恢复耗时，作为策略调优的依据。只有把策略、链路、切换和回切串成闭环，跨云复制才能真正成为可信赖的数据保护手段。