跳转到主内容

NetApp_Insight_2020.png 

“滞后”对 SnapMirror/SnapVault 意味着什么?

Views:
13
Visibility:
Public
Votes:
0
Category:
snapmirror
Specialty:
dp
Last Updated:

可不使用  

适用于

  • 集群模式 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 )中,这种情况可能会被夸大,在这些配置中,同一版本的文件系统会复制到许多控制器。 

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

其他信息