svc虚拟化性能问题？
我们公司有10多台存储如：ds3k、ds4700，ds5200，v3700、v5000、v7000 ，ds8100、ds8870等等，前两年购置了两台svc，目标是统一管理存储，并且对一些核心做容灾，但是实际上线后主机性能和没上svc的时候还慢。
如：之前bw本来数据量就大，把ds8k给svc之后，从svc给bw，感觉性能下降，坐上容灾之后发现慢的不能接受，原来早餐会是每天7点出报表，从上了svc之后每天7点报表只能跑完一半，导致负责报表的相关部门多次被点名。
我们的sap 核心r3也是很这个情况差不多，性能下降的厉害，是我们这里的设计问题，还是我们数据量太大，还是svc鸡肋？
有谁有相关经验，交流交流，因为现在我们svc当成废品放在库房了，有迁移存储的时候拿出来迁移一下还是很方便的。
6同行回答
楼主的环境，简单的看，是比较适合用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。
所以，最后要辩证的来看性能问题，梳理前后端性能数据，才能找到导致问题的原因。
以上内容仅供参考，仅代表个人意见。
- 董老师，其实你理解我们这边，一个20年的公司，东西太多了不可能重建啊
- 高端存储接svc肯定不行吧，人家DS87 cache 都300多G以上，接svc后总的都变小了，业务上来性能肯定受影响。
虽然你目前系统环境复杂，但是存储虚拟化技术便是致力于这一领域的，如果因为统一管理诉求导致更多副作用，我只能说该产品价值性不高。其次，如今弃用SVC，你们的决策者又如何给公司交待？- -！
上面七嘴八舌回复了很多内容如：是否设置得当，是否架构合理等等，楼主都说了厂商设计的，如果有这么多问题还花钱请厂商设计个毛线？或者直接结论产品缺陷？毕竟这是有“厂商”设计的。这么多回复没看到哪个有建设性。
楼主，你的问题很好解决，直接测试那台最高端DS8000性能，使用各种参数，如：随机百分比，读写百分比，outstanding，队列深度。然后让SVC接管同一台DS8000，同样的参数基准再测，然后出具两份成绩对比，成绩应该包含：各种基准下IOPS数量，每秒MB/s吞吐量，平均延迟ms。最终你获得了一份客观有利数据，一旦你发现SVC接管后各方面成绩均明显不如前者，那么你就直接可以找厂商让他们解决，然后义正言辞给他们一个解决问题的期限。很多人喜欢拿“感觉”说事，例如：觉得比原来慢了，比原来延迟大。但是具体慢多少又无法描述，因此，这个测试非常重要。
我也经常实施项目，但是上述写的成绩表(POC)会在我每次实施之后交给用户，而且由用户陪同下一起完成，这样才能预知问题，看来这次你要亲自做才是。
收起- 说到公司交代的问题，这个涉及到政治问题不谈。 测试这个我没做过，不过当时我是tpc上看到的，没加入svc之前ds8100最高可以达到42000左右iops，加入之后没看到操作40000，当然后期因为出问题了，也用了一些措施来保证业务进行，如把备份停了，把一些非必要查询改到历史库上去等等，但是每天出数据还是延迟
- 由衷建议你做一次我上述给测试，因为你这个结果太模糊。 然后拿着结果找厂商解决问题，无论问题发生在哪个环节，对你来说仅仅是你作为客户需要的一个交待，关键是先把问题解决了，环节问题是实施厂商该关注的问题。而且还有一个问题你想过没有？性能不足影响业务是厂商问题，但是由于你把备份停了，万一出现逻辑错误等问题，不能进行一个指定时间窗口的恢复，那这就是你的问题。意外宕机远远没有逻辑错误来的频繁，而SVC两边数据都是实时sync，又没有CDP，快照到时候是否可用还难说，总之你要斟酌。
- 当时是没办法的，我们公司每天早上早餐会前必须出来一些必须的数据高层要看，如果出不来，基本有事连带责任，罚款了，所以当时为了保数据按时出来 ，停了好多东西，包含一些抽数等等
- 虽然我也是乙方，请相信，你面临这种上有政策下有厂商矛盾我绝对能体会。而且越是在基层越是难以调和。
- 我们的目标就是不出事，用什么其实无所谓，所以最后经过讨论把svc干掉了，当然svc也没闲着，我们搬迁机房迁移存储迁移数据简直就是神器，嘿嘿
最好给出当时的的部署的方式和配置的模式。现在看的话有可能有以下几点：
1.SVC配置的容灾策略有问题。容灾可能使用的是同步模式。并且目标存储性能比源存储性能低。
2.前期规划没有做好。有可能没有把业务和存储做的更优化。你们做的时候需要提前做调研。
3.主机通道数量减少。由于你们增加的存储太多了主机通道数量不够。提供不了那么高的速度
收起- 肯定不是同步啊，目标存储是v7000，规划是ibm和代理厂商做的，对svc我们之前也不懂啊
- IBM估计就是做了实施，没有参与深度设计，目标存储V7000，做同步复制，数据量还是有影响的
- V7000的性能是多少。异步的策略也要看
请svc下挂的存储当中ds8870是否做为主存储，或者svc的参数设置是否妥当？是设置为冗余模式还是延迟模式？
收起- 当时也是ibm原厂做的，不是8870为主，应该是8100为主
- 最好确认清楚，主存储是哪个，svc的模式是哪种，会有很大影响
- 原主存储为ds8870，现在连了svc主存储是ds8100？把相关镜像关系搞清楚吧
- 两边都是8100
- 这个应该不会错的，ibm厂商规划实施的
- 当时是ibm厂商设计规划的，但是我们这边环境可能比较乱，各套系统本来资源就很忙，每天报警cpu 内存基本都是满的或者90%以上，我感觉除非把所有系统全部 重来一遍可能效果好的多。
- 容灾是同步模式吧。可能你们的系统没有分级，存储也没有分级，有的存储忙死，有的闲死，你说的每天报警cpu 内存基本都是满的或者90%以上，是说服务器吧。
- 基本就是是这种情况，本来就忙，加上一层svc，好多系统出数的到时间基本出不来，最后高层压下来，立马把svc去掉了，就好了，用了不到1个月
- 立马把SVC去掉,就好了，你们用的Image模式的？用了SVC开了某些特性功能吗?当初应该最好的办法就是找厂商抓数据分析，一般这种性能问题很容易解决，无非是不合理规划和热点等问题造成的
- 还分析，就那样高层领导都相当不满了，我们当时把备份停了，把查询业务改到历史库上去，减轻了起码30%的压力还是不能按时出数据，最后逼不得已把svc费了，没有他就好了