“滞后”对 SnapMirror/SnapVault 意味着什么？
不可不使用
适用场景
- ONTAP 9
- Data ONTAP 8 7-模式
问题解答
- SnapMirror 或 SnapVault 关系的滞后时间计算方法如下：
- 快照时间戳
- 目标系统上的时间
- 从中传输快照所需的时间量 源到目标
- 术语 " 滞后 " 通常与性能相关，通常认为滞后是自上次成功更新以来经过的时间
- 虽然这并非完全不正确，但它不会考虑其他 2 个因素：
- 源和目标存储控制器上的时间，取决于时钟和时区
- 传输的持续时间
- 源和目标上的时间非常重要，因为这决定了文件系统和快照上的时间戳。
- 如果时间配置不正确，则时间戳将不准确
- 由于滞后是根据快照时间戳计算的，因此，如果时间不正确，滞后将不正确
- 由于 复制的性质，传输持续时间也会被忽略
- 不 会仅根据传输开始和完成的时间来衡量滞后
- 滞后的衡量标准是从在源上创建快照的时间加上传输的持续时间开始
- 考虑以下 SnapMirror 方案：
源 目标 Controllera ： vol_1 ControlLERB ： vol_1_mir
- 计划内更新从中午 12 ： 00 开始
- 此时将在源卷上创建 SnapMirror 快照，并开始传输
- 完成传输需要 45 分钟
- 目标系统上的时间现在为中午 12 ： 46
- 传输已在 1 分钟前完成
如果在 步骤 5 中测量， 则滞后为 46 分钟，因为：
- 自在源上创建快照以来已过 46 分钟
- 自快照成功传输到目标之后经过 46 分钟
- 在目标上，通过找出以下各项之间的差异来计算滞后：
- 快照创建时间戳
- 目标上的时间，取决于目标存储控制器的时钟
- 如果未在目标或源上正确配置时间，则滞后时间将不正确
- 请考虑以下情形：
主云 二级 CIFS_SVM:VOL_1 cifs_dr: vol_1_dr
- 根据 vol_1 上的 Snapshot 策略，将在下午 5 点创建一个快照
- 快照将使用 snapmirror-label sv_daily 创建
- 在第二天早晨 1 点触发计划的 SnapMirror 更新，并将其配置为复制任何标记为 sv_daily 的快照
- 完成传输需要 30 分钟
此场景中的滞后时间为 8 小时 30 分钟，因为：
- 在计划的 SnapMirror 更新时，自创建快照并将其标记为 sv_daily 以来已过了八个小时
- 已将快照从源传输到目标 30 分钟
总结
- 滞后是指快照时间戳与之间的差值 目标系统上的时间
- 滞后包括传输所需的时间量 从源到目标的 Snapshot
- 在 Snapshot 时间戳和传输持续时间的上下文中检查时，通常会发现 " 长 " 滞后时间正常
追加信息