svc虚拟化性能问题？

楼主的环境，简单的看，是比较适合用SVC做整合实现资源的统一管理。这是纯架构层面的考虑。

问题是，上了SVC后，性能感觉下降了，看上去好像SVC要背锅呀。。。因为没有看到具体的数据，很难推测哪方面出了问题。原厂实施不是万能的，这是我个人的看法。

从回复中看到用原DS8100时IOPS达到42000，加入SVC后变成40000。这是从IOPS角度看到的结果，主机端读写I/O的平均响应时延的变化呢？

之前跑在DS8100时，有没有做异步复制？上SVC后，异步复制到V7000上，距离又是多少？目标V7000的性能是否能承载生产发送过来的写I/O数据？这些都需要在做之前进行充分的调研分析后才能给出合理的配置。如果是SVC引入后还增加了异步容灾复制，那么性能下降是符合预期的，尤其SVC的Global Mirror模式接近Metro Mirror的复制效率。

在谈加入SVC虚拟化会降低性能的问题时，我想这也不是第一天也不是最后一天会遇到这个问题。从架构上看，引入SVC做带内虚拟化，中间SAN延时会增加0.2ms左右，加上I/O在SVC层做处理（读I/O不命中、写缓存不足做destage等），都会增加一些延时。但不是所有场景都会性能下降，要看来自应用的I/O是否是cache affinity。如果不是，性能有下降是正常的，下降到多少，则要看I/O的压力。之后会谈这个问题。

谈SVC端的性能是否存在瓶颈，可以参考2012年SVC 8个CF8节点+16个V7000做的SPC-1测试，IOPS在52万时，响应时间是8ms左右。现在的DH8节点接口数量和CPU性能比CF8至少高3-4倍，那么推算为150万/每集群，每对SVC节点可达到37万IOPS左右。这是比较理想化的SPC-1测试结果，在生产中打个五折也可以达到18万左右。单台8870配1536个磁盘的SPC-1性能是45万，平均每个磁盘约300个IOPS。楼主可以拿这些数据来推算一下生产中所有后端存储的总盘数可达到的IOPS能力。

我们做过很多性能测试可以证明，OLTP高读命中的业务，增加SVC后，如果不是把读写I/O都爆掉的化（15万IOPS内），虚拟化前后的性能差距不大，甚至在对低端存储类似DS4300/DS4700时还有提升）。SVC后端接DS8870/VMAX/VSP/G1000的案例都有很多。

回到DS8100的42000个IOPS数据上。这个数据看上去像小块I/O处理类型的应用，且有很高的读命中率，否则低配的DS8100很难达到4万多的IOPS。对应高读写命中的应用，增加SVC后，尽管有I/O转发延时，但SVC的读缓存可以看做整体缓存的扩展，大部分读I/O在SVC端得到回应，因此对主机I/O的平均延时并不会产生很大的贡献。已知的读命中延时在0.3-0.5ms之间。那么看起来42000到40000的差距，可能是写I/O要复制到V7000时产生的延时，需要看V7000在那个时刻的mdisk的平均写I/O延时。异步不是完全对生产没有性能影响的，千万别看一个原理图就认为挂上异步复制对生产没有性能影响。

由于楼主的SVC已经下线了，没有办法再分析造成应用慢的原因。从过往的经验看，在BW类跑吞吐的应用，大部分大块I/O都很难有高的读命中，因此需要SVC大量的从后端读数据，容易产生吞吐不足的情况，从而导致性能下降。这种场景是从原理上可以得到解释的。其次，50%以下的读I/O命中场景或写缓存不足的场景，需要SVC频繁的操作缓存数据做stage/destage，也会引起性能下降。最后，还有一种场景是不合理的数据部署导致主机端的顺序I/O到SVC变成随机I/O，这种会引起性能的大幅下降，毕竟后端的物理磁盘不善于处理大块随机读写I/O。

所以，最后要辩证的来看性能问题，梳理前后端性能数据，才能找到导致问题的原因。

以上内容仅供参考，仅代表个人意见。