所有系统都存在限制，而其中的某些元素不可避免地成为了永远的痛。限制因素的存在阻碍了组织充分利用IT功能。十几年来，在绝大多数虚拟化部署环境中存储子系统一直都是瓶颈。

虚拟化的核心资源是CPU、RAM、磁盘以及网络。除某些极个别的工作负载外，CPU早已不再是虚拟环境的瓶颈了。增加RAM容量的成本很低，通常服务器支持增加更多的内存，因为正常情况下使用的内存容量只有服务器在理论上支持的内存容量的一半。磁盘子系统的速度从未快到需要配置最大容量内存的地步。

取决于磁盘与虚拟集群的连接方式，网络可能会成为存储出现瓶颈的原因之一。但网络也可能和CPU一样空闲，处于待命状态。

然而，更常见的情况是存储子系统拖了后腿。解决存储I/O瓶颈是一个复杂的过程，与物理基础设施选择、配置变更相关。让我们一起了解下如何识别并搞定存储子系统存在的问题。

基准测试

在着手解决存储子系统存在的存储I/O问题前，首先需要发现存在的问题究竟是什么。例如，如果问题是不能向虚拟主机交付足够好的性能，那么调整虚拟机以试图更多地使用存储性能不会提供任何帮助。类似地，试图通过简单地调整虚拟机配置文件解决问题也不现实。

基准测试是一种很棒的发现问题的方法。基准测试可以在物理主机、虚拟机（包括运行在不同虚拟主机之上的虚拟机）上运行相同的配置。能够使用完全相同的I/O配置文件生成完全相同的工作负载，使我们能够定位问题所在。

使用基准测试定位存储I/O问题，需要建立存储在正常情况下的性能指标基准。由于确定正常值是一个相当主观的过程，所以你需要牢记一些原则。首先，存储是不是只是在一个地方出问题？可能出现的情况是有两个存储系统，一个运行速度慢，而另一个没问题。或者可能有一个存储系统，当虚拟机在当前主机上运行时性能存在瓶颈，但在另一台主机上运行时却没问题。在虚拟机执行各种不同任务时进行全面的基准测试是一个不错的主意。

务必保存基准测试记录。你使用的是什么配置？IOPS是多少？吞吐量有多大？最大延迟以及平均延迟是多少？

进行各种测试。四线程50%读/50%写完全随机测试是一种很棒的、多数人都能接受的通用性能基准测试方法。但不同组织针对不同工作负载的读写混合比例可能存在显著差异。如果存储产品可以统计读写比，那么采用该读写比进行基准测试是一种不错的选择。

尝试一些100%读以及100%写的基准测试。如果存储问题是无法交付所要求的性能，那么基准测试的目的是把问题找出来。可能有必要为基准测试虚拟机提供多块虚拟磁盘，还需要部署多台基准测试虚拟机。

一旦完成了基准测试，就要进行后台工作测试了。使用I/O测量工具Iometer确定100%读、100%写以及读写各占一半条件下的IOPS峰值。将存储系统的负载调整到IOPS容量的25%、33%、50%以及75%，然后运行各种常见的管理任务并记录时间。

第一个任务是使用备份软件对虚拟机进行完整备份。然后尝试执行快照以及克隆操作、从模板克隆虚拟机。接下来，尝试同时运行多个特定工作负载，比如Exchange Server Jetstress以及其他类似的测试项目，进行基准测试。模拟多个并发的工作负载操作，同时使用Iometer进行压力测试。

分析基准测试结果

分析所有数据是个不小的挑战，但并非没有解决方法。有时数字将问题交代的一清二楚。读IOPS值合理但写IOPS值非常糟糕？这可能是因为存储层没有开启写缓存—你应该打开写缓存，假定可以使用电池备份技术搞定上述问题。

如果存储产品允许的话，你可以尝试增加一个闪存层。或者如果正在使用某种网络存储，那么可以在服务器端增加缓存。在峰值时使用虚拟主机的闪存记录写入操作，并在间歇期将数据写入到存储中。

读写端的数字非常糟糕吗？可能是存储产品不符合使用要求，或者是在虚拟主机与存储之间存在瓶颈。

如果存储基于网络，那么存储性能不佳与网络负载相关，问题有可能出在网卡上。如果你确定阵列应该提供更好的性能，但网卡负载并没有达到饱和，那么问题可能出在虚拟主机与存储之间的网络连接或者网卡驱动上。

不要低估分析中延迟的重要性。IOPS以及吞吐量数字非常好，但应用性能非常糟糕，这是完全有可能的。因为有问题的应用对延迟非常敏感。对很多应用而言，延迟比存储性能的任何其他指标都要重要。

不要把基准分析视为真理。它无法揭示所有问题。基准分析更类似于按照顺序详细测试链中的所有链接。基准分析往往需要使用不同的参数执行新测试。没有指南告诉你需要做什么，或者能够针对所有可能性进行分析。需要研究可用的数据并设计虚拟基础设施，当看到没有意义的数字时，需要对测试进行改进。

谈到识别并消除存储子系统的瓶颈，基准测试以及结果分析仅仅是第一步。一旦有充分的信息对问题进行了定位，接下来就需要制定计划解决配置或极端的存储问题。