“滞后”对 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 ）中，这种情况可能会被夸大，在这些配置中，同一版本的文件系统会复制到许多控制器。 

请记住，滞后只是一个指示符。  与所有指示符一样、如果在上下文中正确理解问题、它可以提醒您。  
误解滞后可能导致错误地判断问题的正常操作。  就其本身而言，给定关系的大量滞后并不一定表示存在问题。

其他信息