ESXiのマルチパスのポリシーとIOPS値はストレージベンダーの推奨になっていますか？

こんにちは。

今回はESXiを外部ストレージに接続するときのパスの設定についての備忘録です。

私は仕事柄、いろいろな環境におかれたESXiを見ます。

その中で気になったのが、ESXiを外部ストレージと接続する際、
パスの設定を考慮していない環境をちらほら見かけます。
パスの設定はある程度ストレージベンダー毎に推奨値を公開しており、
意外にも推奨値に設定していないケースがあります。

そのため、今回はパスの設定について少し記載してみようと思います。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

今回着目する設定値は、パス選択プラグイン (PSP) ポリシーと、IOPS値の設定です。
VMware KB でいうと以下の 2098075 が該当します。

【ラウンド ロビンの IOPS 制限をデフォルトの 1000 から 1 に調整する (2098075)】

https://kb.vmware.com/kb/2098075

ここでいうポリシーというのは、ストレージと接続されたESXiの複数のパスをどのように扱うのかという設定で、IOPS値というのは、どれだけのIOを行ったら次のパスからI/Oするのか、を定義する設定になります。

この部分の設定は各ストレージベンダーで推奨値がドキュメントで公開されています。

公開ドキュメントによると、DELL EMCのVMAX, Hewlett Packard Enterpriseの3PARでは、
パス選択プラグイン (PSP) ポリシーは、”ラウンドロビン”
IPOS値 は　１　
が推奨となっていました。

”ラウンドロビンとはなにか？”　ですが、ラウンド ロビン (RR)　は
使用可能なすべてのパスを順次回転させ、構成された複数のパスにまたがる負荷分散を可能にするポリシーです。例えば３パス使用できる接続になっているようであれば、
３つのパスをすべて活用して分散しながらアクセスするということになります。

ポリシーについてもう少し理解を深めたい場合はVMware KB を見るのもいいかと思います。

【ESXi 5.x および ESXi/ESX 4.x のマルチパス ポリシー (2019882)】
https://kb.vmware.com/kb/2019882

　
”IPOS値 とはなにか？”　ですが、例えばポリシーをラウンドロビンで "IOPS=１" に設定している場合は、I/O操作を1回行ったら、次のパスを使うという動作をするようになります。
IOPS=1にすることで、1回のI/O毎に別のパスに切り替わるような動作になります。
複数のパスからI/O処理が流れるため、負荷分散されるということになります。

■流れ（２パスのとき）
I/Oを1回実施→次のパスを使う→I/Oを1回実施→元のパスに戻ってIOする→繰り返し

このような動作で、負荷分散が動作しています。
VMware KB にも記載があります。
https://kb.vmware.com/kb/2098075
抜粋
==========================================================
1回の I/O の後にパスを切り替えることで、パス全体の I/O のバランス、ひいてはストレージ プロセッサのバランスが改善されます。パス全体で均等な I/O バランスが得られます。
==========================================================


これらの設定について、推奨していることをDELL EMC のVMAXのドキュメントにかかれていました。

 【Using EMC VMAX Storage in VMware vSphere Environments】

https://www.emc.com/collateral/hardware/solution-overview/h2529-vmware-esx-svr-w-symmetrix-wp-ldv.pdf

→Page 86

また、Hewlett Packard Enterpriseの3PARでは以下のドキュメントに記載があります。
【HPE 3PAR StoreServ Storage and VMware vSphere 6 best practices】
http://h20195.www2.hpe.com/V2/getpdf.aspx/4AA4-3286ENW.pdf

→Page10

パスのポリシー設定ですが、デフォルトでは、PSP = MRU、IOPS ＝ 1000　になっています。

MRUというのは Most Recently Used の略です。
最近一番使われたパスです。
IOPS=1000 という設定は1000回 I/O を行ったら次のパスへ移動するということです。

デフォルトの設定だと、片方のパスに1000回  I/O が一気に流れてくるため、
Storege側としては、１つのパスから多くのI/Oを受け取ることになります。

これらの推奨設定値から推測できることは、DELL EMCのストレージもHPEのストレージも、１つのパスから多くのI/Oを受け取ることは好まず、なるべく複数のパスから分散してI/Oを受け取りたいのであろう、という推測がたちます。

試しにHPEのStorageのアーキテクチャの資料を軽く検索してみるとこのような図がありました。
Storage が専門ではないので正直この部分で見解が合っているかは怪しいですが、Storage側としてはどのパスからI/Oを受け取ってもStorageのコントローラーが
フルメッシュでつながっているので大丈夫であるため、ラウンドロビンにしてほしい？のではないかなと思いました。

https://www.hpe.com/h20195/v2/GetPDF.aspx%2F4AA3-2542ENW.pdf

今回は忘れそうだったので、覚えている内容を書きました。

間違っていなければいいのですが…

おわり

ESXi のインストールメディアからVMware Toolsの ISO ファイルを抜き取る。

既に知られている内容かもしれないことを堂々と書こうかと思う。

ESXi上に仮想マシンを作成し、OSをインストールしたあと、
ほとんどの場合、ゲストOSにVMware Tools をインストールすると思います。

vSphere Client での操作だと、この部分の操作である。

[VMware Toolsのインストール/アップグレード] をクリックすると、
ゲストOSにインストールメディアがマウントされます。

Windows Server 2012 R2のゲストではこのようなアイコンになります。

ここまではごく当たり前の操作であるが、このVMware Tools メディアは、
ESXiのインストールメディアにも含まれていることはご存知でしょうか。

今回は、VMware Tools のISO ファイルをESXiのインストールメディアのどこにあるかをメモするための記事です。

私はHewlett-Packard Enterpriseのサーバーをよく使うため、HPEのESXi6.5のインストールメディアをもっているので、それで試します。

ISOファイルをWindowsでマウントして中身を見る。
最近のWindowsであればISOファイルをダブルクリックで中身が見れます。
メディアの中に「TOOLS.T00」というファイルがあります。

「TOOLS.T00」を別の場所にコピーします。

このファイルを「TOOLS.T00」から「TOOLS.tgz」に名前を変えます。

「TOOLS.tgz」になったので、解凍します。

フォルダが１つ出現します。開きます。

フォルダが２つ出現します。「vmtools」フォルダを開きます。

ここまでのディレクトリの場所はここです。
「\TOOLS\6.5.0\vmtools」
１つ挙げると、「windows.iso」ファイルこれはWindows用のVMwareToolsのISOメディアです。

「windows.iso」をマウントして、開いてみます。
中身はこのようになっています。

Setup64.exe が64bitのOS用です。
ダブルクリックするとインストーラーのウィザードが開きます。

インストール当時のVMwareTools を保存しておきたい場合などは、
インストールメディアから抜き取っておくといいかもしれません。

【補足】

ここまで、長々と書きましたが、VMware社はVMwareToolsの各種バージョンをWeb上に公開しています。こちらを見るとよいかと思います。

https://packages.vmware.com/tools/esx/index.html

一番最新のバージョンからESX3.5まで取り揃えてあります。

入手先に困ったときは見てみるとよいかもしれません。

オワリ

「親なし」になったマシンをvSphere Web Clientの画面上から削除しようとしたら、削除するメニューを見つけれなかった。

おひさしぶりです。

今日たまたま、ESXiホストやvCenter Serverを再起動したとき、vCenter から見みると、
「親なし」の不要な仮想マシンができてしまったので、対処をしていこうと思った次第です。

【環境】
vCenter Server 6.5
ESXi6.0 Update 2

vSphere Web Client　のインベントリではこのようになっています。
英語環境なので、 (orphaned)  となっています。

従来からある vSphere Client （C#版）であれば サクっと削除できるのですが、
vSphere Web Client で対象の仮想マシンを右クリックすると、このような表示です。

昔からある　「インベントリから削除」 のメニューは見受けられません…

画面からは消せない！？

とおもったら、すごい場所にインベントリから削除する項目がありました。
ツイッターでご指摘頂き、すごく助かりました。

私は、上記メニューを見つけられず、vSphere PowerCLI　を使って、
インベントリ一覧からVMを削除していました。情けない。。

こんなことをしていたので、ただのご紹介です。

vSphere PowerCLIはvmwareが出している管理ツールの１つです。

Microsoft のPowerShellをベースに作られているCLIツールです。

起動直後はこのようなモジュールの読み込みが始まります。

使えるようになると、このような画面になります。

では、まず、vCenter Server に接続します。
以下のコマンドを実行します。
> Connect-VIServer –Server XXXXX –User XXX –Password XXX

※警告は無視して大丈夫です。

本当にvCenter に接続されているかどうか確認するため、特に害がないGet-VMコマンドでVMの一覧を取得します。
すると、きちんとvCenterの情報をとれました。

上記が、親なし　のVMですが、そのような雰囲気は出ていませんね。

では、この　"RHEL7.2"  というVMを削除しようと思います。

Remove-VM -VM "<仮想マシン名>"   
つまり、

Remove-VM -VM "RHEL7.2"

を実行します。

削除していいか聞かれます。　ｙ　を入力してEnterを押します。

すると、vSphere Web Client のインベントリから対象のVMを削除してくれます。

画面をすぐに見てもらえるとわかりますが、即時反映です。

画面をリフレッシュしなくてもよいです。

結構、私は検証とかをしていると知らぬ間に親なしの不要な仮想マシンが存在したりします。

vSphere Web Client からできることがわかったので安心しました。

せっかくなので、PowerCLIの方法も書いたままにするとします…笑

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

+ 環境で 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接続します。

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

＃　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回取得してみます。

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

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

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

ダウンロードします。

CSVファイルを開きます。

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

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

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）使用していることになっています。

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

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

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

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

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

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

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

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

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

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

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

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

コマンドを実行します。

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

100%になりました。

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

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

【縮小後】

【縮小前】

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

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

以上になります。

【補足】

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 を使います。

今回はこのへんで！