我们公司有10多台存储如:ds3k、ds4700,ds5200,v3700、v5000、v7000 ,ds8100、ds8870等等,前两年购置了两台svc,目标是统一管理存储,并且对一些核心做容灾,但是实际上线后主机性能和没上svc的时候还慢。
如:之前bw本来数据量就大,把ds8k给svc之后,从svc给bw,感觉性能下降,坐上容灾之后发现慢的不能接受,原来早餐会是每天7点出报表,从上了svc之后每天7点报表只能跑完一半,导致负责报表的相关部门多次被点名。
我们的sap 核心r3也是很这个情况差不多,性能下降的厉害,是我们这里的设计问题,还是我们数据量太大,还是svc鸡肋?
有谁有相关经验,交流交流,因为现在我们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。
所以,最后要辩证的来看性能问题,梳理前后端性能数据,才能找到导致问题的原因。
以上内容仅供参考,仅代表个人意见。
虽然你目前系统环境复杂,但是存储虚拟化技术便是致力于这一领域的,如果因为统一管理诉求导致更多副作用,我只能说该产品价值性不高。其次,如今弃用SVC,你们的决策者又如何给公司交待?- -!
上面七嘴八舌回复了很多内容如:是否设置得当,是否架构合理等等,楼主都说了厂商设计的,如果有这么多问题还花钱请厂商设计个毛线?或者直接结论产品缺陷?毕竟这是有“厂商”设计的。这么多回复没看到哪个有建设性。
楼主,你的问题很好解决,直接测试那台最高端DS8000性能,使用各种参数,如:随机百分比,读写百分比,outstanding,队列深度。然后让SVC接管同一台DS8000,同样的参数基准再测,然后出具两份成绩对比,成绩应该包含:各种基准下IOPS数量,每秒MB/s吞吐量,平均延迟ms。最终你获得了一份客观有利数据,一旦你发现SVC接管后各方面成绩均明显不如前者,那么你就直接可以找厂商让他们解决,然后义正言辞给他们一个解决问题的期限。很多人喜欢拿“感觉”说事,例如:觉得比原来慢了,比原来延迟大。但是具体慢多少又无法描述,因此,这个测试非常重要。
我也经常实施项目,但是上述写的成绩表(POC)会在我每次实施之后交给用户,而且由用户陪同下一起完成,这样才能预知问题,看来这次你要亲自做才是。
收起最好给出当时的的部署的方式和配置的模式。现在看的话有可能有以下几点:
1.SVC配置的容灾策略有问题。容灾可能使用的是同步模式。并且目标存储性能比源存储性能低。
2.前期规划没有做好。有可能没有把业务和存储做的更优化。你们做的时候需要提前做调研。
3.主机通道数量减少。由于你们增加的存储太多了主机通道数量不够。提供不了那么高的速度
收起请svc下挂的存储当中ds8870是否做为主存储,或者svc的参数设置是否妥当?是设置为冗余模式还是延迟模式?
收起使用svc怎么规划的,灾备使用的同步模式吧,出现性能问题没找厂商抓数据分析吗,到底是热点造成的还是设计问题,
收起