VMware / Microsoft 製品はこう使う。

好きなことを好きに描く.

ディスク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

 

【補足】

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

 

今回はこのへんで。

 

 

 

ESXi upgrade From ESXi5.5 build 2403361 to ESXi6.5 build 4564106 Conflicting vibs Error (net-mst)

ESXi upgrade From ESXi5.5 build 2403361 to ESXi6.5 build 4564106 Conflicting vibs Error(net-mst) (hpe customized Image)

 

【Envrionment】
Server: BL460cGen9
OS: ESXi5.5 Update2 (build 2403361) --> ESXi6.5 (build 4564106)

I had an issue now.
when trying to upgrade BL460c Gen9 from 5.5u2 to 6.5
where I showed an error message.

The upgrade on Scanning system lator show this screenshot.

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

message:
<CONFLICTING_VIBS ERROR: Vibs on the host are conflicting with vibs in metadata.
Remove the conflicting vibs or use Image Builer to create a custom ISO providing newer
versions of the conflicting vibs.
['Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560',
'Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560']>

 

■Resolution
1. Check VIBs with net-mst in name
~# esxcli software vib list | grep net-mst

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

 

2. Remove net-mst VIB/offline bundle driver
~# esxcli software vib remove -n net-mst

----- I'm sorry, lost picture......

 

3. Restart host.

 

4. Boot to HPE Custom ESXi6.5 Image.

 

5. select to Upgrade(F11)

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

 

 6. Upgrade was Complete!!!!

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

 

Memo:

I used Custom Image file name bellow.
VMware-ESXi-6.5.0-OS-Release-4564106-HPE-650.9.6.0.28-Nov2016.iso

 

Thanks.(^ω^)

ESXi5.x以降で運用中にデータストアをアンマウントするときはきちんとした手順でお願いします。

ESXiを運用していると、Storage 側で仮想ボリュームを切り出したり、
コピーしたり、スナップショットを取得したり、
いろいろなことをしながら運用すると思います。

あるあるかなと思います。

その中でたまにオペレーションミスか勘違いなのかはわかりませんが、
データストアをきちんとアンマウントせずに、Storage側でボリュームを削除したり、
アンマウントする前にStorage側からESXi ホストにボリュームを
見せないように設定変更してしまったりして、人為的ミスによって障害が起こることが少なくありません。

 

そのため、今回はきちんとアンマウントする方法をご紹介します。

 

「40GB-Store」をアンマウントしたいと思います。

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

 

データストアを右クリックし、「アンマウント」をクリックします。

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

 

チェックが入ります。「OK」をクリックします。

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

 

タスクが完了するとグレーアウトします。
ここまででオワリと思いがちですが、まだ作業は残っています。

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


「デバイス」をクリックします。

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


上記でアンマウントしたデータストアと対応する デバイスを右クリックし、
「分離」をクリックします。

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

 

チェックが入ります。

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

 

グレーアウトしました。

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

 

ここまでがきちんとしたESXiアンマウント作業になります。

このあと、Stoarge側からESXiに対してボリュームを見せないように設定変更しすることになります。

 

■きちんとした作業をしないといけない理由

きちんとESXiからボリュームをアンマウントせずにStorage側から、
ボリュームを見せないようにしたり、ボリュームを削除してしまったりすると、
ESXiホストは、存在しないLUN(ボリューム)を探し続けている状況になります。

ESXiホストは、存在しないLUNを探し続けている状況が続くと、
APD(All Path Down)やPDL(Permanent Device Loss)が起き、
いずれはすべてのデータストアが見れない状況となったりします。


この状況は、VMware KB 2081089 の内容が該当します。

 

vSphere 5.x での永続的なデバイスの損失 (PDL) と全パス ダウン (APD) (2081089)
http://kb.vmware.com/kb/2081089

私が書いた過去のエントリだと ↓ になります。

ESXi の APD(All-path-Down)はご存知でしょうか。 - 自由人なエンジニアの備忘録

 
APDになるとvmkernel.log にこんなログが出たりします。
2015-XX-XXT1X:01:38.488Z cpu2:329XX)ScsiDevice: 4195: Device naa.6000eb3XXXXXXXXXXXXXXXXXX is Out of APD; token num:1
2015-XX-XXT1X:01:38.489Z cpu2:329XX)StorageApdHandler: 912: APD Exit for ident [naa.6000eb3XXXXXXXXXXXXXXX]!

また、ESXiホストが存在しないLUNを探し続けると連携している
その他のプロセスにも影響が出てきたりもします。

そのため、ESXi上にはvCenter とやり取りを行う vpxa というプロセスが存在しますが、きちんと動作しなくなり、vCenterから見ると [応答なし] になったり、
SSHログインができなくなったり、いろいろなところで不可解な挙動が発生します。

 

このような自体にならないよう注意を払って作業をしてほしいところです。

 

もし、間違えて何もESXi側で操作をしないままStorage 側でボリュームを削除してしまったら、
早い段階でESXiの再起動を実施することをお勧めします。
存在しないLUNを探し続けている状況は、ESXiホストを再起動することで解消するためです。再起動時に存在しないパス(正常に接続されないパス)はクリアされます。

 

障害がなくなることを祈ります!

 

vSphere 6.0のvSphere FTはイマイチなので使わない方がいいかも。

vSphere 6.0 になって vSphere FT の機能が拡張されたのは、
ご存知の方が多いと思います。

よく耳にするのは、ESXi5.5 以前の vSphere FT はLegacy FT と言い、
6.0 の vSphere FT をNew FT とか言っているのを耳にします(汗

 

たしかに Performance Best Practices for VMware vSphere® 6.0 にも
"Legacy FT"  ,  "new version of FT"  と記載があるのであながち間違いではないのかなと思います。

 

このvSphere 6.0の New version のFTですが、Legacy FTのときと異なる仕組みで
動作しているらしく、仮想マシンのパフォーマンスがすごく良くないようです。

参考としてはこのあたりの記事になります。

 

Fault Tolerance Performance in vSphere 6 - VMware VROOM! Blog - VMware BlogsPerformance Best Practices for VMware vSphere® 6.0

vSphere 6.0 Documentation Center

 

 

もし、Legacy FT (vCPU 1) のときに動作の遅くなくて、
マルチvCPU だと明らかに遅いと感じた場合は、仕組みの違いによるものである可能性が高いです。

ドキュメントとか見てても、ある程度のネットワーク遅延は避けられない、という意味合いにも読み取れます。


Legacy FT  も New FT  も異なるESXi間にある仮想マシンを同期する必要があるので、primary 側のVMと secondary 側のVMで常に同期をとる必要があるため、
Network のトラフィックが多く発生するのは同じです。

 

ドキュメント類をいろいろ見ていると、新FT の仕組みとしては、

Legacy FT では record/replay という方式で動作しているようで、
新 FT では、Fast checkpointing という方式になっていると書かれています。
record/replay 方式ではprimary 上で発生した処理の情報(input)をSecondaryのVMに流して、
流された内容を secondaryのVMでも処理を行うことで、同期させていたようですが、
新FT で新しく実装された Fast checkpointing という方法では、Primary のVMのメモリ,ストレージなどの情報を
seconcary 側に送信し、送信された情報を適用することで、同期を取るということが書かれています。
公開されてる情報では、Storage vMotion の技術を使って、データ転送しているみたいです。

 

Blog側にこんな記載が。
>This technology is similar to Storage vMotion, which copies the virtual machine state (storage, memory, and networking) to the secondary ESXi host.
>Fast Checkpointing keeps the primary and secondary virtual machines in sync.

処理情報だけではなくて、ディスクの変更点やメモリの情報を流すので要件として10 Giga Network が必要と記載されていそうです。
たしかに常にStorage vMotionみたいなことをすると帯域はかなり使いそうです。そして遅そう…。


ここまで書いてからなんとなく思ったのですが、
2015年のvForumでは、vSphere 6.0 の目玉機能としてvSphere FTがすごく
フォーカスされて紹介されていたのに、
最近ではあまりvSphere FTのことを聞きません。
やはり、VMwareとしてもあまり使ってほしい機能ではないのかもしれません。。

 

実際に使った人の話を聞いてもディスクI/Oがかかったときに極端に遅いということを聞いたことがあります。

vSphere FT でパフォーマンスが出ないときは、
要件を考え直して、vSphere HA を使うほうがいいかもしれないです。

 

 

 

ESXi5.1~5.5がインストールされたマシンでNICの交換は大丈夫なの?

今回はあるあるネタを綴ります。

 

ESXi5.1~5.5を運用していると、当然ながらハードウェア障害に遭遇することがあります。
CPU,マザーボード,NIC,HDD,SSD 挙げだすと、山ほどあるわけですが、
今回はNIC を交換したときの影響について書きたいと思います。

ESXiでは、物理NICのことを 「vmnic」と言います。

 

まず始めに、結論から申し上げるとESXiはハードウェア的にNICを交換しても、
基本は影響を受けません。一部例外もありますが、順に記載してきます。

NICの交換でハードウェア的に変更されるものは、ESXi観点からは
MAC Address、SerialNo , デバイス ID あたりかと思います。
(同じNICと交換することを想定しています)

Windows であったりLinuxでは、NICを交換すると別の新しいNICという扱いになるため、再設定が必要です。

特にMAC Addressが変更されると、ロードバランサーを使っている環境や、
ファイアーウォールを使っている環境では、MAC Addressで識別して動作させていることも少なくありません。そこでまずはMAC Address観点で影響を受けない理由から記載していこうと思います。


【影響を受けない理由1】
ESXi 上で稼働する仮想マシンに装着されているvNIC はそれぞれ固有に
MAC Addressを保持しています。そのため、物理NIC(vmnic)のMAC Addressを利用していないため、仮想マシンは、物理NIC交換の影響を受けません。

vSphere Web Client から仮想マシンの編集画面を見ると確認できます。
もちろん vSphere Client からでも確認ができます。
(私の環境がvCenter6.5なので見れませんが)

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

 

◆vmkernel ポートすらMAC Addressを持っている
仮想マシンが固有のMAC Addressを保持しているのは上記の画像でお分かりいただけると思います。

そして、ESXi とって重要なvmkernel ポート もそれぞれMAC Addressを保持しています。
(vmkernelポートは HA,iSCSI接続,vMotion等で使われる仮想ポートです) 

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

 

◆つまり
ESXiは、物理NIC(vmnic)のMAC Address を使用して外部と通信していないため、
物理NIC 交換後に物理NICMAC Addressが変更されてしまっても、影響を受けず、
外部と通信することが可能です。
イメージとしては、vmnicは通信をパススルーさせてるだけという感じです。

 

【影響を受けない理由2】
ESXi 5.1、5.5 のvmnic番号の割り振り動作について理解してみるといいと思います。
ESXi はOS起動毎にvmnic番号を割り振っていて、
サーバーが認識したPCI IDから順にESXi は自動的にvmnic 番号を割り振ります。
そして、割り振られたvmnic番号は/etc/vmware/esx.conf ファイルに書かれます。
ポート数が同じNICとの交換、そして同じ PCIスロット上にあると認識されれば(同じスロットに挿せば)、基本的には同じvmnic番号で認識されます。
vmnic番号が変更されなければ、従来通りのvSwitchに接続されます。
そのため、影響を受けないということになります。
(参考)
+ESXi/ESX host loses network connectivity after adding new NICs or an upgrade
https://kb.vmware.com/kb/2019871

esx.confにはこんな感じで記録されています。
--------------------------------------------
/device/00000:002:00.1/vmkname = "vmnic1"
/device/00000:002:00.0/vmkname = "vmnic0"
--------------------------------------------

※4ポートのNICを2ポートのNICに交換した場合は、
 vmnic番号が歯抜けになります。番号を振り直したい場合は、
 KBの通り、BIOS からvmnic0以外のNICを全て無効化し、
 サーバーを再起動したあと、認識したい順にBIOSから有効化していきます。
 vmnicの数だけ再起動していきます。

 

NICのベンダーが変わっても同じ動作になります。

 

ESXi6.0以降は実際に試したことがないので、なんとも言えませんが、
おそらく同じ動作になるのではないかと思っています。(推測)

 

参考になると幸いです。

 

 

 

 

VMware KB 2147739 (ESXi 5.5 and 6.x hosts hang after running for 85 days.)

Hi, everyone.

 

VMware vSphere has also new released vmware kb 2147739 .

This is very Critical Issue.However , This is not a VMware issue.

+ ESXi host or virtual machine hangs after approximately 85 days
https://kb.vmware.com/kb/2147739

 

This issue is caused by a QLogic HBA Adapter Firmware problem introduced in Firmware v8.01.00 causing Read Diagnostic Parameters (RDP) between FC Switch and HBA adapter to fail.
By default, the RDP routine is initiated by the FC Switch and occurs once every hour. After 2048 (~85 days)

consecutive RDP failures the HBA Adapter will become stalled which causes the virtual machine and\or ESXi host to fail.

 

My Customer was all ESXi hosts is down and a few VMs is no responsed.
Be careful.


Thanks,