查找并解决vSphere存储性能问题需要管理员遵循一个简单的工作流以识别过载的数据存储，然后再识别出繁忙的虚拟机。工作繁忙的虚拟机可能会影响整个数据存储，应该将其放置在满足性能需求的数据存储上。本文介绍如何识别并解决vSphere存储性能问题。

管理员应该先查找负载过高的资源池。如果是单个用户导致资源过载，那么你应该给资源池分配更多的资源。如果由于用户过多导致资源过载，那么你必须给资源池分配更多的资源或者将用户拆分到多个资源池中。

存储资源池是一个数据存储，使用该数据存储的所有虚拟机共享I/O访问（数据存储可以是NFS或VMFS）。阵列的缓存决定了存储的性能，很多存储阵列使用相同的物理磁盘的集合实现NFS共享或者向主机提供LUN。多个数据存储在底层可能会共享同一个磁盘池。非虚拟工作负载也可能会使用该磁盘池，这会降低磁盘负载的能见度。

查找存储问题没有简单的方法

存储负荷很复杂，其性能受如下因素的影响：会话大小及速率、读/写比和随机访问/顺序访问比。数据存储性能与应用程序类型相关，因为不同应用程序访问存储的I/O类型有所不同。存储性能高往往意味着价格很高，而且存储的生命周期很长，为获得更好的性能进行付费升级的情况并不常见。通常管理存储性能需要对运行在多个数据存储之上的不同工作负载进行平衡。

I/O延迟基准值

存储过载的关键指标就是延迟。能够快速响应请求肯定不会过载。如果存储的响应时间比正常值高，那么很可能是过载了。存储的响应时间取决于底层的存储类型。SSD存储的响应时间应该在毫秒以内，如果SSD存储的响应时间达到了数毫秒，那么就太慢了。对于SAS或者FC存储，响应时间为5毫秒说明性能表现良好，响应时间达到50毫秒说明性能很差。SATA存储响应时间的正常值为10毫秒，超过100毫秒说明性能很差。

性能图表提供了故障诊断地图

检查存储性能的主要工具是vSphere性能图表，vSphere性能图表同样能够用来检查网络性能。请记住同一个数据存储通常会被集群中的所有ESXi主机共享使用，但共享数据存储的虚拟机通常不会运行在同一台ESXi主机上。所以在检查你怀疑存在性能瓶颈的数据存储时，要使用清单中的“数据存储及数据存储集群”视图而非ESXi服务器视图。

将虚拟机迁移到其他数据存储

识别出过载的数据存储后，你必须找出导致存储过载的原因。如果是单台虚拟机使存储达到了饱和状态，那么解决问题的方法只能是将该虚拟机迁移到性能更高的数据存储上。如果虚拟机对I/O要求高，通常底层存储会根据其I/O模型专门进行调优，然后再创建数据存储，最后将虚拟机迁移到该数据存储上。如果无法移动对I/O要求高的虚拟机，你可能会想到将其他对I/O要求低的虚拟机迁移到其他数据存储。如果数据存储过载是由多台虚拟机导致的，那么你可能能够将部分虚拟机迁移到负载较低的其他数据存储上。

在下面这个例子中，四台实验虚拟机正在使用数据存储NFS01。lab-01和lab-02的I/O负载一直很低。最初lab-03和lab-04的I/O请求较多，每台虚拟机的IOPS大约是85，这导致了该数据存储的延迟较高，大约为180毫秒。原因是两台虚拟机竞争数据存储上有限的I/O性能，同时底层的低性能存储过载。

 
两台虚拟机资源争用导致存储过载

在下午2点，lab-03虚拟机的I/O负载下降到与lab-01和lab-02虚拟机同一个级别。现在只有lab-04虚拟机的I/O负载很高，其IOPS攀升至150，这时由于不存在资源争用所以数据存储的性能还不错。这时延迟从180毫秒下降到了75毫秒，因为访问数据存储的等待时间大大降低了。数据存储仍旧过载，但只和一台虚拟机相关。

下午2:20，lab-04虚拟机的I/O负载降低了，数据存储不再处于I/O饱和状态。因为IOPS几乎下降为0，所以延迟同样减少了。请注意在数据存储的I/O处于饱和状态时，lab-01和lab-02虚拟机的延迟同样很高。即使这两台虚拟机只进行了很小的I/O操作，但数据存储的I/O性能仍旧受繁忙虚拟机的影响。

以上就是解决vSphere存储性能问题的基本思路。我并没有查看重要的指标比如I/O大小、读/写比以及随机访问/顺序访问比，也没有查看RAID设置、缓存、队列或者存储架构配置。存储设计及部署非常复杂，雇佣有经验的存储设计人员是避免性能问题的一个重要因素。其他关键因素包括了解部署在存储之上的工作负载，这样设计才能够满足工作负载的性能需求。