SnapView Snapshot的性能考虑

作者将本文同时发布到：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时的快速响应时间 �C> 启动snapview session造成响应的增加 -> 随着时间的推移，响应时间开始逐渐降低，因为COFW减少。

     同样如下图，如果存在多个snapView session，每个session都会使得LUN经历响应时间上升，再逐渐下降的过程，并最终回到基线。

     对MirrorView/S secondary image做snapshot也会影响性能，因为当host write to primary LUN时，primary array必须先write to secondary image，secondary image需要等待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 �C A Detialed Review>

应用于

SnapView snapshot