読者です 読者をやめる 読者になる 読者になる

自由人なエンジニアの備忘録

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

OS再起動時に Windows に設定しているIP アドレスが 169.254.x.x になる

ついこの間、Windows Server 2012 R2 で OS 再起動を実行後、
IP Address を固定に設定している環境でも、
169.254.x.x のアドレスに変わる事象に遭遇しました。

正直焦りました。

最初は同じネットワーク上に同じIP Address のマシンが存在するのか?
とか、いろいろ四苦八苦しましたが、そういうわけでもなく、違う要因でした。

 

[Environment]

OS: ESXi5.5
Guest OS : Windows Server 2012 R2


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

 

+ 環境で Ciscoバイスを使用していると、ESX/ESXi 上の Microsoft Windows Vista 以降の仮想マシンで重複した IP アドレスが誤って検出される
https://kb.vmware.com/kb/2092679

+ False duplicate IP address detected on Microsoft Windows Vista and later virtual machines on ESX/ESXi when using Cisco devices on the environment (1028373)

https://kb.vmware.com/kb/1028373


VMware KB に記載の内容になりますが、事象は以下の内容です。

  • Windows Vista 以降のバージョンで IP アドレスを割り当てるとき、重複した IP アドレスの競合が表示されます。
  • Windows Vista 以降のバージョンを再起動すると、169.254.x.x の IP アドレスが割り当てられます。
  • vSwitch 上のアップリンク ポートのない vSwitch 上に同じ仮想マシンをセットアップすると、IP アドレスは正常に割り当てられます。
  • 同じ vSwitch 上の Windows 2003 仮想マシンに同じ IP アドレスを割り当てると、IP アドレスは正常に割り当てられます。

 

私が遭遇したとき、Windowsのイベントログに以下のような記録がありました。

◆システムログ
Tcpip 4199 なし IP アドレス xxx.xxx.xxx.xxx とシステムのネットワーク
ハードウェア アドレス XX-XX-XX-XX-XX-XX が 重複しているのを、検出しました。
このシステムのネットワーク操作は 無効になる可能性があります。


この記録で私はなんとかVMware KB 2092679 にたどり着けました。

 

Ciscoのスイッチに影響を受けるみたいなので、
単純にESXiのログだけみたり、事象だけを見ていると解決には時間がかかります。

少し視野を広げる必要があります。

 

Ciscoのスイッチに影響するようなので、ESXi上のゲスト以外にもHyper-V上のゲストでも、物理ホストでも発生すると思うので、なかなか注意したい内容でした。

 

[補足]
関連情報としては以下のようなものがありました。

False duplicate IP address detected on Microsoft Windows Vista and later virtual machines on ESX/ESXi when using Cisco devices on the environment (1028373)
https://kb.vmware.com/kb/1028373

 

Duplicate IP Address 0.0.0.0 Error Message Troubleshoot
http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

 

日本語で情報を解説してくれている方もおられました。すごく有り難い。
http://rtaki.sakura.ne.jp/infra/?p=664

 

オワリ。

 

ESXi にSSH接続してパフォーマンスの情報を定期的に取得してcsv ファイルに出力。

ESXiのパフォーマンスを取得するとき、どうやったらいいの?

という内容です。

 

実際に取得したデータを見たいと思っても、見るデータがなければ始まりません。

きちんとしたデータを取って、現状を把握していきましょう。

本稿では主にコマンドの理解と流れを書きます。


ESXiにTeratermなどでSSH接続します。

f:id:japan-vmware:20170106003401p:plainf:id:japan-vmware:20170106004402p:plain

 

以下のコマンドを実行します。

# esxtop -a -b -d 60 -n 60 > ログ出力先


 ※SSH接続した画面は閉じてはいけない。

■コマンドの意味

ESXi のパフォーマンス情報を60秒毎に取得し、60回取得するという意味です。
全てのパフォーマンスカウンタを取得しています。
つまり1分に1度取得して60回取得するので、1時間分のパフォーマンスデータです。
ログ出力先のところはデータストア名を指定するとよいです。

例1)esxtop -a -b -d 60 -n 60 > /vmfs/volumes/Datastore1/perf.csv

 

仮に2秒おきに120回情報を取得する場合はこのようなコマンド引数です。

例1)esxtop -a -b -d 2 -n 120 > /vmfs/volumes/Datastore1/perf.csv

 

テスト的に10秒間隔で6回取得してみます。

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

終わるまでコマンド結果が返ってこないような状態になります。

 

CSVファイルが出力されているかをvSphere Web Client から確認してみます。

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

きちんとファイルが存在しています。

 

ダウンロードします。

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

 

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

 

CSVファイルを開きます。

テスト的に10秒間隔で6回取得するコマンドを実行したので、6回分だけ表示されています。

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

 

ファイル出力させる方法は以上になります。


VMware社の日本語KBだと以下が該当します。’

https://kb.vmware.com/kb/2097572

ですが、不親切ですので本稿を書きました。



本稿の取得方法であれば、すべてのパフォーマンスカウンタを取得し、
ファイル出力するので、情報の漏れがないため、後から追加で収集したりする手間を
省けると思います。



ガッツリパフォーマンスを見たい人はこのあたりを見ることが多いかと思います。

https://kb.vmware.com/kb/2001003

https://kb.vmware.com/kb/1008205

Using VisualEsxtop to troubleshoot performance issues in vSphere - Support Insider - VMware Blogs




以上になります。

 

 

Thin で作成された仮想ディスクの縮小方法(Guest : Linux) - 今更感ありますが。

こんにちは。

 

すごく今更感がありますが、ESXi上で動作する仮想マシンの仮想ディスクが
Thin(シンプロビジョニング)で作成されているとき、

使用していない仮想ディスクの領域を縮小させる方法について書きます。

 

Thin(シンプロビジョニング)の仮想ディスクでは、一度利用した(書き込んだ)領域は、ファイルを削除したあとも、そのまま回収されず、明示的にに回収させることで、
仮想ディスクを縮小させることができます。

 

ゲストOS上ではファイルを削除したあとも、書き込んだ領域とのひも付け(mappingとか言うみたいですが)を削除しているだけで、実態が残っていることがほとんどです。

 

残されたデータは他のデータで上書きされるまで、残ってしまうことがほとんどです。
そのため、ゲストOSとして未使用領域となっている部分に ゼロを書き込むことで、
ESXiは、対象の仮想ディスクに使われていない領域があることを認識し、
仮想ディスクサイズを縮小させることができます。

 

(説明下手ですみません)

 

順に進めていきます。

 

まずは現状確認です。
ゲストOSとしてRHELを利用しています。
現在は、root 領域 14% (約3GB)使用していることになっています。

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

 

しかし、vSphere Client からESXiホストに接続して、
データストアブラウザを開いて仮想ディスクのサイズを確認すると、13GBくらいあります。

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

 

実際の使用量は、ゲストOS上では約3GBで、ESXiからは約13GBくらいですので、
10GBくらいの容量差があります。これは非常にモッタイナイ。
ゲストOSであるRHELからは、ESXiが使っていると思っている領域は、
空き状態になっているように見えているということになります。

 

そのため、このゲストOSが空いていると思っている領域に ゼロ書き込みを行います。

 

今回はRHELのゲストOSですので、ddコマンドを使い、
ゼロ書き込みしたファイルがデスクトップに出ています。(オプションで指定したので)

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

 

ddコマンド完了後は、ゲストOS側では使用領域が+10GBされています。
ゼロ書きしたファイルが残っているためです。
f:id:japan-vmware:20161221044606p:plain

 

今回デスクトップにファイルを作成するように指定したので、削除します。
ファイル自体は不要なので削除しています。

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

 

データストアブラウザ上でも少し容量は増えていました。

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

 

次にESXi 側での操作を実施します。

ESXiにSSH接続して、
/vmfs/volumes/データストア/仮想マシンフォルダ
まで移動します。

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

-flat.vmdk ファイルが仮想ディスクファイルの実態です。

 

では、仮想ディスクを縮小させてみましょう。

(あらかじめ仮想マシンは停止しておきましょう)

コマンドを実行します。

> vmkfstools -K ./<仮想マシン名>.vmdk

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

100%になりました。

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

 

ls の結果を見てみましょう。作業前と容量に変化はありません。

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

 

仮想ディスクが縮小されました。
縮小後と縮小前を比較します。

【縮小後】
f:id:japan-vmware:20161222003627p:plain

【縮小前】

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

 

このように定期的にメンテナンスできる環境であれば、

知らぬ間にデータストアを圧迫していることもあるので、実施頂ければと思います。

 

以上になります。

 

【補足】

vmkfstools にはいろいろオプションがあります。
便利なものもあるので、見てみるのもいいかもしれません。

vmkfstools - 仮想ディスクのオプション

https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.storage.doc/GUID-0AC9C948-4D0A-4634-99B8-E10CC09EFE47.html

 

vmkfstools は現在ではesxcli コマンドに置き換えられている機能もあります。

 

たとえば、ESXi 5.1 では vmkfstools -y でUNMAP操作をしますが、

ESXi5.5以降は esxcli storage vmfs unmap を使います。

 

 

今回はこのへんで!

 

 

HPE ServerのiLO4 Web 管理画面からESXiにインストールしてあるDriverバージョンが見れる。

こんにちは、この間、HPE の 中古のProLiant DL320e Gen8 を買って、
いろいろいじってみました。

いろいろ画面を見ていると、ILO4 のWeb 管理画面からESXi上に
インストールされている Driver や Vib を見ることができる画面があったのでご紹介です。

HPE の ProLiant には iLO4 というマザーボードから独立した
ProLiant を管理する機能が備わっているとのことだったので、
どんなもんなのかと弄ってみた感想を綴ってみようと思います。

 

運用者の視点で記載していきます。

 

iLO4 はIP Address を設定して、ブラウザからアクセスして利用することになります。

iLO4  に IP Address を設定する方法については、公開ドキュメントを見ました。

https://h20628.www2.hp.com/km-ext/content-webapp/document?docId=emr_na-c03352387

iLO4 にはFirmware というものがあるようで、今回は Firmware 2.50 というバージョンのようでした。(結構新しいみたいです)
こちらがログイン画面です。

 

Administrator でログインしてみます。

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

 

ログイン後の画面です。

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

 

[Firmware] と [Software] というタブがあります。

[Firmware] をクリックしてみます。
f:id:japan-vmware:20161218184007p:plain

 

NICRAID コントローラーやHBAのFirmware などを一覧表示してくれます。
ここまでは、iLO4 はHPE のサーバーだし、Hardware 情報くらい取ってきてくれて当たり前な感じもします。

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

 

次に、[Software] タブをクリックします。
すると、ESXiにインストールされているDriverなどを見ることができます。
以下の画像では、[HPE Software]にチェックが入っているので、
HPEに関するツールやDriver 類が表示されています。なかなかいいんじゃない?

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

 

[Running Software ] のラジオボタンをクリックすると、
ESXi 上のプロセスが表示されます。

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

 

[Installed Software] のラジオボタンをクリックすると、
既にインストール済みのツール類が表示されます。
(ここではなぜか、バージョンは表示されないんですね…...)

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


表示されている内容を見るとほとんど、
esxcli software vib list  の結果を表示しているように見えました。

ILO4 Web 管理画面に表示されている情報はどこから取っているのかな?
と思って、ESXiにSSH接続してハードウェア監視のプロセスを止めてみました。

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

 

すると、やはり情報取れなくなりました。

ESXiから情報をもらっているみたいです。(あたりまえか)

 

運用監視の人であったり、ただのユーザーの人がESXiにSSH接続して、
Driver バージョンとか見るのは、少しハードルが高いようなときは、
結構使えるものではないかな、と思いました。

 

オワリ。

 

 

ディスク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 を使うほうがいいかもしれないです。