【虛擬化實戰】儲存設計之六latency

標籤：des   style   class   blog   code   java   

在【虛擬化實戰】儲存設計之五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 ，IOmeter，LoginVSI，Solarwinds等

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