“滞后”对 SnapMirror/SnapVault 意味着什么?
不可不使用
适用于
- 集群模式 Data ONTAP 8
- ONTAP 9
- Data ONTAP 8 7-模式
- Data ONTAP 7 及更早版本
- SnapMirror
解答
"lag" 一词的定义只是 " 两个事件之间经过的时间 " 。 因此,“滞后”通常与性能相关联。 但是,在复制和 SnapMirror/SnapVault 关系的上下文中,“ LAG ”是一个被误解的术语。 滞后的典型理解是自上次成功更新以来的时间量。 虽然这并不完全不正确,但它不会考虑其他两个因素。
- 控制器上配置的时间
- 传输持续时间
配置时间非常重要,因为这是快照和文件系统继承的时间戳。 如果时间配置不正确、时间戳将不准确。 由于使用时间戳计算 LAG 、因此在这种情况下滞后也将不正确。
由于复制的性质,传输的持续时间也会被忽略。 从上一次传输完成后开始,系统不会测量 LAG 。
从在源 / 主控制器上首次创建快照的时间开始测量 LAG 。 这可能看起来类似,但差异可能很大。
考虑以下 SnapMirror 方案:
源 | 目标 |
Controllera : vol_1 | ControlLERB : vol_1_mir |
计划的更新在下午 12:00 开始。
在源卷上创建 SnapMirror 快照并启动传输。 传输过程需要 45 分钟才能完成。 现在的下午 12 点 46 分, 1 分钟前完成了转接。
问:这种关系的 " 滞后 " 应该是什么?
答:本场景中的“滞后”为 46 分钟(而不是 1 分钟)。
在目标控制器上、 LAG 是通过将快照的创建时间与控制器的当前时间进行比较来衡量的。
因此,如果在目标(或 src )控制器上未正确配置时间、则“滞后”时间可能不正确。
考虑以下 SnapVault 方案:
主云 | 二级 |
CIFS_SVM:VOL_1 | cifs_dr: vol_1_dr |
根据 vol_1 上的 Snapshot 策略,将在下午 5 点创建一个具有 snapmirror-label 的 snapmirror-label 为 "v_daily" 的快照。
为“ v_daily ”标签配置的 SnapVault 更新在第二天上午 1 点的预定时间触发。 传输过程需要 30 分钟才能完成。
问:在传输结束时,这种关系的滞后应该是什么?
答:对于此 SnapVault 方案,延迟时间为 8 小时 30 分钟。
同样,系统将使用在主卷上创建快照的时间计算 LAG ;而不是使用在辅助卷上完成传输的时间计算 LAG 。
这是因为在复制过程中、文件系统的版本非常重要。 Snapshot 副本是时间点引用,表示创建快照时的文件系统。
快照是受保护的数据、因此创建快照的时间是计算滞后时使用的时间点。
在其他配置(如 Cascades )中,这种情况可能会被夸大,在这些配置中,同一版本的文件系统会复制到许多控制器。
请记住,滞后只是一个指示符。 与所有指示符一样、如果在上下文中正确理解问题、它可以提醒您。
误解滞后可能导致错误地判断问题的正常操作。 就其本身而言,给定关系的大量滞后并不一定表示存在问题。
其他信息