存储性能瓶颈分析
数据存储瓶颈的四个常见场景：
以下是储瓶颈发生最常见的四种典型情况：
-
当多个用户同时访问某一业务应用，无论是邮件服务器，企业资源规划（ERP）系统或数据库，数据请求会累积在队列中。单个 I/O 的响应时间开始增长，短暂延时开始转变成为漫长的等待。
这类响应时间敏感型应用的特征是，很多随机请求，读取比写入更多，I/O 较小。最好的方法是：将负载分布在多块磁盘上，否则可能造成性能瓶颈。
如果应用增加了更多用户，或应用 IOPS 请求增加，则可能需要在 RAID 组中添加更多磁盘，或数据可能需要跨越更多磁盘，在更多层级做条带化。
存储在这样的情况下往往首先被怀疑，但大多数情况下并非存储引发，原因可能在于网络、应用或服务器。 -
带宽敏感型应用——如数据备份，视频流或安全登录，这类应用当多个用户同时访问大型文件或数据流时可能造成瓶颈。
定位这一问题存储管理员应当从备份服务器开始一路向下检查至磁盘，原因可能存在于这一通路的任何地方。
问题不一定发生在存储，可能是由于备份应用创建的方式或是磁带系统的工作方式引起的。如果瓶颈定位于存储，那么可能是由于服务 I/O 的磁盘数量不足，在控制器造成争用，或是阵列前端口带宽不足。
性能调优需要针对不同应用程序负载来完成。针对大型文件和流数据的调优并不适合于小型文件，反之亦然。这也就是为什么在大多数存储系统中往往做一个平衡，需要用户尝试并找出系统的折中。用户通常需要优化吞吐量或 IOPS，但并不需要对两者同时优化。 -
RAID 组中的磁盘故障。特别是在 RAID 5 中会造成性能的下降，因为系统需要重建校验数据。相比数据读写操作，重建会对性能造成更大影响。
即便坏盘是造成故障的根源，但控制器还是可能成为瓶颈，因为在重建过程中它需要不停地服务数据。当重建完成时，性能才会恢复正常。 -
部署了一种新的应用，而卷存在于处理繁忙邮件系统的同一磁盘。如果新的应用变得繁忙，邮件系统性能将会遭受影响。额外的流量最终会将磁盘完全覆盖。
存储瓶颈常发区域:
存储区域网络（Storage-area network, SAN）/ 阵列前端口
存储部署于集中化 SAN 环境时，需考虑服务器和 SAN 之间的潜在网络瓶颈。例如，运行多部虚拟机的整合服务器可能不具备支持工作负载要求的足够网络端口。添加网络端口或转移网络密集型工作负载至其他服务器可解决这一问题。如前所述，对于带宽集中型应用，需考虑 NFS 有多少 Fiber Channel 端口, or iSCSI 端口 or Ethernet 端口，需要用户站在带宽的角度来考量整个架构。
可能发生的问题包括：
- 如果阵列中端口数量不够，就会发生过饱和 / 过度使用。
- 虚拟服务器环境下的过量预定
- 端口间负载不均衡
- 交换机间链路争用 / 流量负荷过重
- 如某一 HBA 端口负载过重将导致 HBA 拥塞。使用虚拟机会导致问题更加严重。
存储控制器
一个标准的主动——被动或主动——主动控制器都有一个性能极限。接近这条上限取决于用户有多少块磁盘，因为每块磁盘的 IOPS 和吞吐量是固定的。
可能出现的问题包括：
- 控制器 I/O 过饱和，使得从缓存到阵列能够处理的 IOPS 受到限制
- 吞吐量 “淹没 “处理器
- CPU 过载 / 处理器功率不足
- 性能无法跟上 SSD
Cache
由于服务器内存和 CPU 远比机械磁盘快得多，需为磁盘添加高速内存以缓存读写数据。例如，写入磁盘的数据存储在缓存中直到磁盘能够跟上，同时磁盘中的读数据放入缓存中直到能被主机读取。Cache 比磁盘快 1000 倍，因此将数据写入和读出 Cache 对性能影响巨大。智能缓存算法能够预测你需要查找的数据，你是否会对此数据频繁访问，甚至是将访问频繁的随机数据放在缓存中。
可能发生的问题包括：
- Cache memory 不足
- Cache 写入过载，引起性能降低
- 频繁访问顺序性数据引起 cache 超负荷
- Cache 中需要持续不断地写入新数据，因此如果 cache 总是在 refill，将无法从 cache 获益。
磁盘
磁盘瓶颈与磁盘转速有关, 慢速磁盘会引入较多延时。存储性能问题的排查首先考虑的因素就是磁盘速度，同时有多少块磁盘可进行并发读写。而另一因素是磁盘接口。采用更快的接口能够缓解磁盘瓶颈，但更重要的是在快速接口与相应更大的缓存大小以及转速之间取得平衡。同样，应避免将快速和慢速磁盘混入同一接口，因为慢速磁盘将会造成快速接口与快速磁盘的性能浪费。
可能引发的问题包括：
- 过多应用命中磁盘
- 磁盘数量不足以满足应用所需的 IOPS 或吞吐量
- 磁盘速度过慢无法满足性能需求及支持繁重工作负荷
- Disk group 往往是 classic 存储架构的潜在性能瓶颈，这种结构下 RAID 最多配置在 16 块磁盘。Thin 结构通常每个 LUN 拥有更多磁盘，从而数据分布于更多 spindle，因增加的并发性而减少了成为瓶颈的可能。
需要监控的指标：
曾经一度存储厂商们强调的是 IOPS 和吞吐量，但现在重点逐渐转变成为响应时间。也就是说，不是数据移动的速度有多快，而在于对请求的响应速度有多快。
正常情况下，15,000 rpm Fibre Channel 磁盘响应时间为 4ms，SAS 磁盘响应时间约为 5ms 至 6ms，SATA 为 10ms，而 SSD 少于 1ms。如果发现 Fibre Channel 磁盘响应时间为 12ms，或 SSD 响应时间变成 5ms，那么就说明可能产生了争用，可能芯片发生了故障。
除了响应时间，其他需要监控的指标包括：
- 队列长度，队列中一次积累的请求数量，平均磁盘队列长度；
- 平均 I/O 大小千字节数；
- IOPS （读和写，随机和顺序，整体平均 IOPS）；
- 每秒百万字节吞吐量；
- 读写所占比例；
- 容量（空闲，使用和保留）。
数据存储性能最佳实践：
性能调优和改进的方式有很多种，用户当然可以通过添加磁盘，端口，多核处理器，内存来改善，但问题是：性价比，以及对业务是否实用。本文建议的方式是在预算范围内找寻性能最大化的解决方案。另外一个需要考虑的方面是环境并非一尘不变，系统部署方案要能够适应环境的改变需求。
首先需要考虑刷数据的性能特征，需要了解 IO 工作情况是怎样的。是否是 cache 友好型？是否是 CPU 集中型？业务数据很大数量很少，还是很小但数量很多？另外一方面就是构成存储环境的组件。包括应用，存储系统本身，网络。。。瓶颈可能在哪里，改善哪里最有效？
以下是一些常规建议：
- 不要仅仅根据空闲空间来分配存储，而需要结合考虑性能需求，确保为吞吐量或 IOPS 分配足够多的磁盘。
- 在磁盘间均衡分布应用负载，以减少热点地区的产生。
- 理解应用负载类型，并针对负载选择匹配的 RAID 类型。例如，写密集型应用建议使用 RAID 1 而不是 RAID 5。因为当写入 RAID 5 时，需要计算校验位，需耗费较多时间。而 RAID 1，写入两块磁盘速度快得多，无需计算。
- 磁盘类型（Fibre Channel, SAS, SATA）与期望性能相匹配。对于关键业务应用部署高性能磁盘，例如 15,000 rpm Fibre Channel。
- 对于 I/O 密集型应用考虑采用 SSD，但并不适用于写性能重要型应用。只要没有达到控制器瓶颈，SSD 对读性能提升显著，但对写性能提升并没有明显效果。
- 采用端对端的监控工具，特别是虚拟服务器环境。虚拟端与物理端之间有一道防火墙，所以，需要穿透防火墙进行端到端的监控。
- 有些性能分析工具涵盖从应用到磁盘，有些仅局限于存储系统本身。由于性能是一个连锁反应包含很多变量，所以需要全面地分析数据。
- 以数据仅写入磁盘外部扇区的方式格式化磁盘。因减少数据定位时间而在高 I/O 环境下提升性能。负面作用是相当一部分磁盘容量未能得以使用
