块存储相对而言比较简单，选择的方式也比较简单，不看场景，只看性能。性能指标总体就三个， IOPS、吞吐量和访问时延。IOPS，这个需要看比较细节的场景，分为随机读、随机写和顺序读吞吐量，这边重点关注高吞吐量的场景，比如大数据的海量数据计算和传输访问时延，重点关注数据库使用场景...
业务系统的性能上不去（具体表现在吞吐量低，响应时间长）等现象，不少是应用中间件导致的。例如系统的处理能力上不去，加了WAS并发也不管用，cpu利用率上不去。然后仔细一问，加了什么并发，回答说“负责去MQ队列读消息的应用进程数”，我问“连数据库的jdbc连接池数量呢”，回答说“不知道...
如果后期还要加入灵活的调整，满足扩容或者容灾的需求。建议可以试试云平台呗，底层分布式存储利用SSD加速来提升IOPS，多节点聚合满足吞吐量的需求。通过qos来限制各个应用的阈值。不过还是要做好规划。...
一个系统支持3-15个节点，IBM可以把144个系统整合成一个集群。
我谈谈自己的想法，需要高吞吐量的业务一般是清算批量业务在不增加设备配置的情况下（这其实是最方便的）一般可以从以下角度入手：1.存储调优：增加缓存、增大存储端颗粒度、优化ＲＡＩＤ与ＬＵＮ的组合，使用更多的前端卡等。2.主机优化：适当增加LUN的个数，增加adapter/lun的queue depth，增加VG，优化...
我觉得不太可能，存储的布局不能只看眼前。最少要往后看5年左右的估算量，技术支持，可扩展性等等。随着大数据时代的来临，数据将迎来爆炸式的增长，也许5年会从T到P，所以建议是存储这种东西不要去尝试新东西，稳定第一。就连IBM的存储，用了几年都出现性能问题了，你拿什么保证这种新技...
方法论其实就是通过表象看本质，首先通过系统和数据库工具结合起来看瓶颈所在，分析具体的报告结果，来确定问题原因。如果不想做应用调整，那么升级问题所在的硬件是有效果的。
IOPS是存储每秒完成IO读写请求的次数。吞吐量是存储每秒完成读写的数据传输量，也就是带宽。 IOPS * I/O size = BandwidthIOPS和吞吐量的数值越大说明存储性能越好。
iops，Bandwidth，持续吞吐，Burst I/O
