首页 > 代码库 > 【虚拟化实战】存储设计之六latency

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

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

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

一   怎样衡量Latency?

Latency或者respondingtime,指完毕一个IO请求所须要的时间。往往以milliseconds来衡量。

应用端发出的一个IO请求,大致要经过下面各层才干终于抵达存储设备。


使用esxtop能够得到下面的数据

Column

 Description

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过高原因分析:

存储设计不能满足需求,请參见我曾经的文章TBD一文

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

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

有非常多工具能够搜集分析数据和压力測试,从而帮助你了解眼下存储的能力。比方VMware I/O Analyzer IOmeterLoginVSISolarwinds

I/O 队列拥塞


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

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

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

 

先拿ESXi主机这一层来说,LUNQueue Depth决定了在同一时间能够对某个LUN发起的ActiveCommand 数量。ESXi缺省值是32. 全部虚拟机发起的ActiveCommands的总数最好不要持续超过LUNQueue Depth.     尽管LUNQueue Depth能够最大添加到64,但一般还是建议使用缺省值。

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

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

 

存储带宽饱和

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

 

參考:

PerformanceLinks

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