作者将本文同时发布到:EMC中文支持论坛 https://community.emc.com/docs/DOC-25624
介绍在做性能分析时,除了考虑常规因素包括:I/O负载、I/O类型、LUN的放置、SP的额外负载、其他的LUN造成的资源争用,还需要考虑类似SnapView snapshot这样的快照软件所施加的额外I/O负载。我们将分析SnapView Snapshot给能对性能造成性能的情况。
SnapView是基于指针和复制的设计,在读snapshot时,用户需要考虑到磁盘争用。例如,将snapshot呈现给备份主机用于备份,备份操作的【读】有很有可能影响到源LUN的i/o性能。另外,即便备份流本身是连续的,对reserved LUN的【读】也是随机的,因为无法保证目标chunk是被连续写入reserved LUN的。
另一个可能的性能影响发生在【生产主机】对【源LUN】执行大量【写】,同时源LUN上存在SnapView session的情况。这会对SP以及reserved LUN RAID Group造成更多的负载,因为需要对源LUN执行额外的【读】并【写】入reserved LUN,从而增加源LUN的【写】响应时间。
SnapView把源LUN分成64KB chunk,这意味着主机的4KB【写】会把对应的64KB chunk拷贝到reserved LUN。随着时间的推移,COFW(copy on first write)会减少,从而对生产LUN的影响会越来越小,因为针对snapshot的读写都会被导向至reserved LUN,由此可见,正确规划reserved LUN(容量、性能、可用性等)也是非常有必要的。下图显示了生产LUN由最初的没有snapview session时的快速响应时间 –> 启动snapview session造成响应的增加 -> 随着时间的推移,响应时间开始逐渐降低,因为COFW减少。
同样如下图,如果存在多个snapView session,每个session都会使得LUN经历响应时间上升,再逐渐下降的过程,并最终回到基线。
对MirrorView/S secondary p_w_picpath做snapshot也会影响性能,因为当host write to primary LUN时,primary array必须先write to secondary p_w_picpath,secondary p_w_picpath需要等待COFW之后才能ACK primary array,最后primary array 再ACK主机,增加了响应时间。
对于rollback,除了执行rollback的时段之外,【SnapView rollback驱动程序】总是处于【passive mode】,I/O将直接跳过它。一旦rollback开始执行,【rollback驱动程序】开始同时负责管理【后台复制进程】以及处理【对源LUN的I/O请求】。因为rollback操作影响源LUN的性能,后台复制进程为用户提供了复制速率调节选项,High、Median、Low。下图显示了Rollback吞吐量速率对SP CPU的资源消耗,可见,rollback速率越大,SP CPU利用率就越大。
rollback实际上也就是【写】源LUN,因此很有可能会触发其它session的COFW,尤其是在启动rollback之前创建了recovery session。通常,session会在开始的几分钟内执行大量的COFW,慢慢的开始下降并趋于停止。
<EMC CLARiiONSnapView Snapshots and Snap Sessions Knowledgebook – A Detialed Review>
SnapView snapshot