【虚拟化实战】存储设计之六latency

作者：范军 （Frank Fan）新浪微博：@frankfan7

在【虚拟化实战】存储设计之五IOPS中我们讲了评估存储性能的三个关键指标。也就是Throughput，IOPs和latency。以及三者之间的关系。本文深入介绍Latency过高的原因和一些建议。

Latency过高直接导致在该存储上运行虚拟机以及其应用的性能降低。最终用户可能抱怨程序打不开，运行慢，响应时间长等等。

一如何衡量Latency？

Latency或者responding time，指完成一个IO请求所需要的时间。往往以milliseconds来衡量。

应用端发出的一个IO请求，大致要经过以下各层才能最终抵达存储设备。

使用esxtop可以得到以下的数据

CMDS/s:   在大多数情况下这个值就是IOPS的值。指的是每秒钟发出的IO请求。

DAVG/cmd(Device Average Latency) :  每个请求经过物理硬件，HBA和存储设备所需的平均响应时间。以毫秒计算。一般20-30ms可以接受.

KAVG/cmd(Kernel Average Latency) : 平均每个请求经过VMkernel层处理所需的时间。一般为0.如果超过2ms，可能会影响性能

QAVG(Queue Average latency):  平均每个请求经过vSphere存储堆栈所需的时间。当队列很长时，每个请求等待的时间也较长。

GAVG/cmd(Guest Average Latency) :平均每个请求最终所得到响应时间，也就是虚拟机操作系统所得到值  DAVG + KAVG = GAVG

一般20-30ms可以接受。这对于latency Sensitive很高的应用，要求这个值尽可能低。比如有些关键的数据库操作，大于5ms可能都不能保证Transaction的成功完成。

二    latency过高原因分析：

存储设计不能满足需求，请参见我以前的文章【虚拟化实战】存储设计之二LUN Sizing

一个常见的误区是仅仅考虑所需容量，没有充分考虑到IOPS/Latency/Throughput等影响性能的因素。比如应用需要10T的容量，有可能需要购买20T甚至更多的存储来满足性能需求。应该与存储厂商充分讨论一个合理的方案及细节。比如采用什么RAID，阵列中DiskSpindle的个数，什么类型的存储硬盘。

设计充分考虑该存储所支持的应用。很多应用都有不同的特性，比如I/O Size，读写操作的比例等等。应针对其特性来设计适当的存储方案。

有很多工具可以搜集分析数据和压力测试，从而帮助你了解目前存储的能力。比如VMware I/O Analyzer ，IOmeter，LoginVSI，Solarwinds等

I/O 队列拥塞

从上图可以看到从上到下的四层都有队列。队列中等待执行的任务越长，意味着更长的响应时间。

在ESXi主机层的队列过长，直接导致KAVG数值过高。

在HBA和存储阵列的队列过长，导致DAVG数值过高

先拿ESXi主机这一层来说，LUN Queue Depth决定了在同一时间可以对某个LUN发起的ActiveCommand 数量。ESXi缺省值是32. 所有虚拟机发起的ActiveCommands的总数最好不要持续超过LUN Queue Depth.     虽然LUNQueue Depth可以最大增加到64，但一般还是建议使用缺省值。

比如有多个I/O intensive的虚拟机在同一个LUN的时候，需要考虑把部分虚拟机转移到其他LUN以避免ActiveCommands的总数持续超过LUNQueueDepth，从而造成延时。

HBA这层也有队列，通常4,000 commandsper port 或者更高。所以一般瓶颈不在HBA层。

存储带宽饱和

考虑HBA卡的支持的带宽，以及采用多路径来对负载分流。避免请求经过物理硬件，HBA和存储设备所需的平均响应时间过高。

参考：

Performance Links

VMUG Presentation - Troubleshooting StoragePerformance

TroubleshootingStorage Performance in vSphere – Part 1 – The Basics

http://www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf

本文转自frankfan751CTO博客，原文链接：http://blog.51cto.com/frankfan/1411753 ，如需转载请自行联系原作者