VMware製品はこう使うのよ。

好きなことを好きに描く、ん~のびしろですね!

ディスクI/Oが遅い、不安定、esxtopを見てみるのもいいかもしれません。


スポンサードリンク

今回はストレージに関するパフォーマンスのヒントになりそうな

内容を書こうかと思います。ほぼほぼ未来への自分へのメモです。

 

ESXi ではほとんどの場合、共有ディスクを複数のESXiホストと共有しているため、
共有ディスクへのアクセスに問題が発生したり、ストレージ障害が発生すると
大きいトラブルに発展することがほとんどかと思います。

 

しかし、一方で、ストレージ障害は発生していないが、
ディスクI/O遅延が発生するなどは、原因が顕著化しないため、
ずるずると問題が長期化したり、気づいたときには大きな問題になっていることも
多くあります。

 

そこで、1つのアプローチとしてですが、ディスクI/O遅延を調査するとき、
ESXi観点から問題を切り分けたいときは、esxtop を用いて、
大まかに切り分けを行うことがあります。

ディスクのI/O遅延では、どの段階でコマンドの待ち時間が多く発生しているかを
見ていくことが正攻法になります。

f:id:japan-vmware:20161215014637p:plain

 

図の説明をします。

■Kernel command wait time
日本語だと カーネルコマンド待ち時間 です。
仮想マシン上のDriverからESXiが管理しているファイルシステムまでの待ち時間です。
一般にKAVGと言われます。

 + esxtop(ex.)
 \Physical Disk(vmhba1:vmhba1:C0:T1:L0)\Average Kernel MilliSec/Command


■Physical Device command Wait time
ESXi自身のDriverからStorageアクセスまでの待ち時間です。
一般にDAVGと言われます。

+ esxtop(ex.)
 \Physical Disk(vmhba1:vmhba1:C0:T1:L0)\Average Driver MilliSec/Command

 

■Total command wait time(guest wait time)

Kernel command wait time と Physical Device command Wait time の合計です。
一般に
GAVGと言われます。

+ esxtop(ex.)
 \Physical Disk(vmhba1:vmhba1:C0:T1:L0)\Average Guest MilliSec/Command

 

DAVG + KAVG = GAVG です。


【どこで待ち時間の値が高くなっているか?】

コマンド待ち時間(GAVG)の値が高くなっている場合、
次にDAVGの値が高くなっているのか、もしくはKAVGの値が高くなっているのかを確認します。
ハイパーバイザーで遅延が発生しているのか、それともESXiのDriverからストレージまでの間で遅延が発生しているのかを切り分けます。

・Kernel command wait timeの値が高い場合(KAVG)
 →ESXiホスト側でリソース不足が発生していないか確認する。
 (CPU負荷などが多い)
  しかし経験上、vSphere Client から見たら多くがわかるため、
  この値が高いことは少ない傾向にある。

 

・ Physical Device command Wait timeの値が高い場合(DAVG)
 →ストレージ自体になんらかの問題が発生している。
  例えばコントローラのFirmware動きがよくないであったり、
  ストレージ側のディスクのパフォーマンスがよくないこともあります。

 →SCSI コマンドのリトライやSCSIコマンドのAbort が多く発生している場合
  経路やストレージ側を怪しむべき(だいたいログからわかります)

 →Reservation Conflict (SCSI 予約競合)などが多く発生しているようであれば、
  VMFS上のVMの数を減らしてみるなど。


 →HBA, NIC, などのFirmware やDriverがボトルネックになっている可能性。

このあたりを怪しむべきです。

 

【KAVGもDAVGも高い!】
ゲストOSが想定よりも膨大なディスクI/Oリクエストをストレージに向けて行っている可能性があります。サイジングのミスである可能性もあります。
たとえば、1つのVM上でデータベース, Webサーバー,リアルタイム処理, 分析処理などが一気に動作していたりすると、サーバーとストレージ間の処理の限界近くに達していることもあるとおもいます。

このような場合は、esxtopだけでは判別つきませんが、少なくとも
ゲストOSもESXiもいっぱいいっぱいの処理をしている可能性が高いことはわかります。

処理の分散化を検討するのも1つの手かもしれません。実際にいろいろ試して切り分けしていくしかないでしょう。

 

私の手元でストレージに定期的に高負荷を書けたときのサンプル資料を載せます。
定期的にゲストOS上で高負荷をかけているので、均等に値が高いわけではなく
負荷が上がったときに値が高くなっています。

 

(Sample)

f:id:japan-vmware:20161216001243p:plain

 

 この値の指標ですが、VMwareの書籍には参考基準値の記載がありました。
====================================================

■Kernel command wait time(KAVG)

 参考基準値:5ms 


■Physical Device command Wait time(DAVG)
参考基準値:20~50ms

 

■Total command wait time(guest wait time)

参考基準値:20~50ms

 

しかし、あくまで目安なので一概に言えないところが難しいです。

====================================================

 

私がサンプルしたデータはFC接続のストレージでの結果となりますが、

25.0を超えたあたりから体感で遅くなっていることを感じました。

 

 

ネットサーフィンしていると、あまり存じ上げない会社から、
私が個人的に好きなまとまった資料が公開されています。


+ esxtop 6.0
http://www.running-system.com/wp-content/uploads/2015/04/ESXTOP_vSphere6.pdf

+ esxtop 5.5

http://www.running-system.com/wp-content/uploads/2012/08/esxtop_english_v11.pdf

 

【補足】

忘れそうなので、ほぼほぼ自分へのメモのために書きましたが、
見てくれる方がいると嬉しいなと思ったり。

 

今回はこのへんで。