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

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

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

VMSA-2017-0006 パッチを適用する - パッチの適用手順

こんにちは。

 

VMware製品から2017/03/28 にクリティカルな脆弱性が公開されており、
日本語でも情報が出回っているので、少し記事にしたいと思います。
脆弱性の内容よりもパッチ適用の手順にフォーカスした内容です。

 

今回対象の脆弱性VMware社から既にSecurity Advisory が公開されています。

 

VMware Security Advisories - VMSA-2017-0006】

+ VMware ESXi, Workstation and Fusion updates address critical and moderate security issues
http://www.vmware.com/us/security/advisories/VMSA-2017-0006.html

CVE-2017-4902 ,CVE-2017-4903,CVE-2017-4904,CVE-2017-4905

 

日本語の情報サイトでも一部されていました。

http://www.security-next.com/080075

 

手元にESXi6.5の環境 がありましたので、パッチを適用しておこうと思います。

■手元環境
[root@localhost:~] vmware -v

VMware ESXi 6.5.0 build-5146846

 

■作業

アップデートを行う為のファイルをダウンロードします。
ダウンロード先は下記となりますのでこちらをご使用ください。

https://my.vmware.com/group/vmware/patch#search

ESXiの6.5から検索します。青いダウンロードボタンよりダウンロード可能です。

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

 

ダウンロード後は、ESXiホストのデータストアにアップロードします。
データストアブラウザなどでアップロードしてください。

vSphere Client であれば対象のホストを選択し、[構成]タブより[ストレージ]を選択します。
 
空きのあるデータストアを選択し、右クリック、[データストアの参照]を選択し、
データストアブラウザ画面のメニューバーから上向きの矢印アイコンをクリックして、
アップロードするファイルの選択画面が出てきますので、ダウンロードしていたファイルを選択してください。アップロード完了後に×ボタンで終了してください。

 

Host Client でもvSphere Web Client でも同様のことができるので、好きなものを使ってデータストアにコピーしてください。

 

■ホストをメンテナンスモードにします。
右クリック、[メンテナンスモードへの切り替え]を選択します。
事前にESXi上で仮想マシンが稼働しないようにしておいてください。

(Host Client の例)

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

SSH接続して事前確認

SSHではなくDCUI(コンソール)からでも構いませんが、操作性からTeratermなどでSSH接続して作業するほうが楽だと思います。

 

まずはパッチファイルのプロファイルを確認します。

[root@localhost:~] esxcli software sources profile list --depot=/vmfs/volumes/LocalDisk900GB/patch-module/ESXi650-201703002.zip
Name Vendor Acceptance Level
------------------------------- ------------ ----------------
ESXi-6.5.0-20170304101-no-tools VMware, Inc. PartnerSupported
ESXi-6.5.0-20170304101-standard VMware, Inc. PartnerSupported

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

LocalDisk900GB はデータストア名です。
※現在のプロファイルは"esxcli software profile get"より確認できます。
※no-toolsはvmware-toolsを含まない形式です。 

 

■適用をする
[root@localhost:~] esxcli software profile update -d /vmfs/volumes/LocalDisk900GB/patch-module/ESXi650-201703002.zip -p ESXi-6.5.0-20170304101-standard

 

正常に適用されたら以下の結果が返ってきます。

===

[root@localhost:~] esxcli software profile update -d /vmfs/volumes/LocalDisk900GB/patch-module/ESXi650-201703002.zip -p ESXi-6.5.0-20170304101-standard
Update Result
Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
Reboot Required: true
VIBs Installed: VMware_bootbank_esx-base_6.5.0-0.15.5224529, VMware_bootbank_vsan_6.5.0-0.15.5224529, VMware_bootbank_vsanhealth_6.5.0-0.15.5224529
VIBs Removed: VMware_bootbank_esx-base_6.5.0-0.14.5146846, VMware_bootbank_vsan_6.5.0-0.14.5146846, VMware_bootbank_vsanhealth_6.5.0-0.14.5146846
VIBs Skipped: VMW_bootbank_ata-libata-92_3.00.9.2-16vmw.650.0.0.4564106, VMW_bootbank_ata-pata-amd_0.3.10-3vmw.650.0.0.4564106,

(略)

====

一応画像でも載せます。

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

 

適用後はきちんと再起動をお願いします。
SSH接続のまま、Reboot コマンドで問題ありません。

 

再起動後、Build No が変わっていることを確認できれば完了です。

メンテナンスモードを解除して、利用を開始してください。

 

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

細かく中身を見ていませんが、ESXi650-201703002 は容量から、差分のパッチのような気がしています。事前にそれまでのフルパッケージのパッチを適用しておくほうが安全です。

※ 

 

今回はこのへんで。

 

vSAN のコンポーネント分割はVMストレージポリシー以外にも分割されることがある

こんにちは。


今回はvmwareが推し推しのVSANに関する内容です。

皆様ご存知の通り、VSANは仮想マシンごとにストレージポリシーを割り当てて管理します。

vSphere Web Client でいうとホームの赤枠のところからポリシーを作成することができます。

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

 

このVMストレージポリシーでは、どの程度のESXiホストの停止を許容するのか、

であったり、各ノードにどの程度(数)のコンポーネントに分割してデータを保持するのか、などを定義できます。(他にも項目はあります)

今回はVMストレージポリシーを以下の設定にします。

 

・Failures To Tolerate = 1 → ESXiホストの障害許容台数
・Disk Stripes Per Object = 3  → コンポーネントをどれくらい分割するか

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

 

上記のVMストレージポリシー設定のとき、仮想マシンのデータはこのように配置されます。

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

 

障害許容が1であるため、RAID 1 (ミラー)の中に、Stripe 3 つまりコンポーネントが3分割されて配置されている図です。

さて、ここまでは普通のvSANです。これからもただのvSANですが…

 

vSANの検証環境で触る際、巨大なvmdkファイルを持つ仮想マシンを配置することはあまりないかと思います。しかし、注意したいのは、おおきなvmdkファイル(例えば300GBとか)をvSANDatastore上に配置しようとすると、自動的にコンポーネント分割されることはご存知でしょうか。

 

VMwareからはこんなKB が出ています。

+ Using small magnetic disks for vSAN might result in VM failures

https://kb.vmware.com/kb/2080503

 

大きなファイルは、KBに記載されているパラメータ、VSAN.ClomMaxComponentSizeGB を超える容量になると、コンポーネント分割されるようになっています。

デフォルト値は255です。(ESXi6.0, ESXi6.5はそうでした)
私は検証環境の都合上、一番最小値の180にしています。

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

 

では、すべてのvSANクラスタのESXiホスト3台にVSAN.ClomMaxComponentSizeGB=180 を設定し、200GBのvmdkファイルを所有する仮想マシンを作成し、vmdkファイルには 「Virtual SAN Default Storage Policy」を割り当てます。

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

 

「Virtual SAN Default Storage Policy」はその名のとおり、デフォルトて作成されるポリシーであるがゆえに、以下の値に設定されています。


・Failures To Tolerate = 1 → ESXiホストの障害許容台数
・Disk Stripes Per Object = 1  → コンポーネントをどれくらい分割するか

 

では、200GBのvmdkファイルのときはどのように配置されているのか。

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

 

ご想像のとおり、ESXiに設定したパラメータ VSAN.ClomMaxComponentSizeGB=180 を超えたため、1つのノード内で2つのコンポーネントに分割されました。
デフォルトとはいえ、VMストレージポリシーを設定していましたが、ESXiで設定していた容量を超えたため、パラメータ側を優先した格好になります。

 

ではあらためて、↓ この設定のVMストレージポリシーを200GBのvmdkファイルに適用します。

・Failures To Tolerate = 1 → ESXiホストの障害許容台数
・Disk Stripes Per Object = 3  → コンポーネントをどれくらい分割するか

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

 

VMストレージポリシーがきちんと反映され、Stripe 3 なので、コンポーネントが3つに分かれています。

 

一度、VSAN.ClomMaxComponentSizeGB の設定値によって分割されても、

再度、内容が異なるVMストレージポリシーを設定すると反映されるということを知りたいがためにこんな記事を書きました。

 

ただし、確認はしていませんが、あまりに巨大なファイルをコンポーネント分割したときに、Stripe = 1 のようなVMストレージポリシーを適用しても、それは無視され、

VSAN.ClomMaxComponentSizeGBの値で分割されると思います。(推測)

 

オワリ

Host Client に慣れましょう。そしてログバンドル(vmsupport)を取りましょう。

今後はどんどん新しいvSphere Web Client に慣れていくしかなさそうです。

そして、ESXi単体を管理するためのHost Client にも徐々に使いやすいものになってきています。

 

ESXi Embedded Host Client

新しいバージョンのものを開発しているので、盛り込まれてきていますね。

 

今回は、Host Client でログバンドル(vmsupport)を取ってみましょう。

(どれだけログとるねん、というツッコミはナシで)


VMwareにサポート依頼するとき、情報提供する際にはだいたい要求されますので。

 

それでは、Host Client にブラウザで接続してログインしましょう。

https://<ESXiのIP アドレス>/ui/#/login

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

 

ログインできました。

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

 

左のナビゲータの中から [監視] - [ログ]タブ をクリックし、[サポートバンドルの生成] をクリックします。

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

 

画面下の[最近のタスク] が表示されますので、完了するまで待ちます。

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

 

完了すると、いきなり、ダイアログが表示されます。

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

 

もし、間違えてこのダイアログを閉じてしまっても、タスクを見るとURLが書いているので大丈夫です。

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

 

実際のところ、このログの場所ですが、ESXiにSSH接続してみるとわかりますが、

↓ の場所にファイルが存在していました。

/scratch/downloads/vmsupport-52540efe-4de3-8b40-ad3c-e44fc5400bc2.tgz

 

あとは今まで通りのvm-supportですので、中身をみるのみです。

 

今回はこのへんで。

 

 

 

ESXi6.5のvm-support には reconstruct.sh が付属しなくなっている。

こんにちは。

 

今回は私が地味に困惑した内容です。


ESXiで調査するときにすごくお世話になるログバンドル(vm-support)ですが、
ESXi6.5には「reconstruct.sh」というシェルスクリプトが存在しなくなっています。

 

■ESXi6.0
f:id:japan-vmware:20170320002711p:plain

■ESXi6.5

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

 

この「reconstruct.sh」ですが、実行すると commands ディレクトリ配下の分裂しているファイルをまとめてくれたりするので、事前にログやコマンド結果を見る際には実行しておくと情報が見やすくなるものですが、ESX6.5 のvm-supportから無くなっていました。。

たとえば、「reconstruct.sh」を実行前だとバラバラのファイルですが。

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

 

「reconstruct.sh」を実行するとまとまってこのように見やすい情報になります。
スッキリ!

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

 

まだ、ESXi6.5をバリバリ使っている環境は少ない状況かなと思いますが、

私は、ESXi6.5のvm-supportをみるときは、ESXi6.0のvm-supportから

reconstruct.sh」を抜き取って、ESXi6.5のvm-supportに向けて実行しています。

 

いまのところ私は支障無しという状況です。

 

 

vExpert 2017 受賞しました。

個人的な話で恐縮ですが、vExpert 2017 受賞しました。

 

+vExpert 2017 Award Announcement

vExpert 2017 Award Announcement - VMTN Blog - VMware Blogs

 

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

 

本Blogをみてくださっている方のおかげです。本当に感謝感謝です。

 

私は製品を売る側の人間ではないので、技術情報が多めですが、

役立つ情報をいろいろ書いていくので、どうぞよろしくお願いいたします。

 

 

 

VMware Tools に含まれるDriver(vsepflt.sysとvnetflt.sys)でWindowsがBSODになることがあります。

こんにちは。

 

今回は地味に困ったときのネタです。

VMware Tools に含まれるDriver(vsepflt.sysとvnetflt.sys)でWindowsBSODになることがあるので、その考察や見解についてです。

 

ESXi上で動作する仮想マシンには、ほとんどの場合、
VMware Tools をインストールしているとおもいますが、仮想マシンで動作するOSがWindows の場合、VMware Tools に含まれるvSheild関連(現在だとNSX関連)のDriverの動作が起因し、WindowsBSODになってしまったり、クラスターリソース(主にクラスタディスク)が見えなくなってしまうなどの事象が起こることがあります。

 

そのため、既知事例ということで、VMware 社はVMware KB 2082204 を公開しています。


+  vShield Endpoint Thin Agent (vsepflt.sys) および vShield Endpoint TDI Manager (vnetflt.sys) ドライバを使用してインストールされた Windows 仮想マシンが応答しなくなるか、障害が発生して青色の診断画面が表示される (2082204)

https://kb.vmware.com/kb/2082204

 

上記のVMware KB の説明では、VMware Tools 5.1 に影響する既知の問題で、ESXi 5.1 および 5.5 に影響する場合があり、ESXi 5.5 Update 2 で修正されていると記述されています。

 

しかしながら、ESXi 5.5 Update 2 以降の環境でも事象が発生する模様です。


実際に、vsepflt.sysとvnetflt.sysが起因と考えられるBSODを複数回確認しています。

調べたところ、VMware Tools に含まれるvsepflt.sysとvnetflt.sysの相互の連携における問題があり、BSODなどの事象が発生することがあるようです。(細かいことは謎)

 

・vShield Endpoint シン エージェント ドライバ (vsepflt.sys)
・vShield Endpoint TDI Manager ドライバ (vnetflt.sys) 

 

BSODなどの事象が発生しないようにする回避策としては、
上記Driverのアンインストールもしくは、アンロードを実施します。

以下のVMware KBに方法は記載されています。
https://kb.vmware.com/kb/2082588 (英語)

https://kb.vmware.com/kb/2083369 (日本語)

vSheild やNSXを利用していない環境であれば、アンインストールしても支障はありません。

また、現在はデフォルトではインストールされないようになっています。

■参考画像

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

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

 

【その他の問題点1】

vShieldやNSXを使っていない環境であれば、上記Driverをアンインストールやアンロードを行えばいい話なのですが、もしvShield やNSXをばりばり使っている場合はそうもいきません。(NSX,vShieldは専門外ですが...)

vShield Endpoint シン エージェント ドライバ (vsepflt.sys)は、Windows ファイル システム フィルタ ドライバ で、その名のとおり、
ファイルシステムへのリクエストをフィルタリングするモジュールになっています。

フィルタドライバの説明はMicrosoft のBlogをご覧ください。

https://blogs.msdn.microsoft.com/jpwdkblog/2009/05/13/filesystem-filesystem-filter/

このフィルタドライバがその他のファイルシステムへのI/Oを阻害することが結構あり、BSODになることもあります。Windows は標準でディスクI/Oを60秒行えない状態が発生するとファイルシステムを守るために、BSODになるようレジストリで設定されています。
レジストリとしてはここです。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue

内容は異なりますが、似たVMWare KB もありました。

https://kb.vmware.com/kb/2080692

こういった事情もあり、アンインストールおよびアンロードできない場合はなかなか厄介です。

 

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


【その他の問題点2】

上記で、vShield Endpoint シン エージェント ドライバ (vsepflt.sys)のことを記載しましたが、vSphere 環境で動作するセキュリティ製品で vsepflt.sys が動作要件になっているものがあります。
例えば、トレンドマイクロのDeepSecurity は vsepflt.sysが動作要件になっているようで、明確な要件が書かれた文献はすぐみつけれませんでしたが、以下のサポートページには、「 vsepflt が正常に動作していること を確認してください。」と記載されています。
http://esupport.trendmicro.com/solution/ja-JP/1313647.aspx

セキュリティ対策製品でvsepflt.sysが要件になっている場合は簡単にアンインストールできないでしょうし、困りものです。

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

 

問題点1,2にぶち当たったときは結局のところ、最新のVMware Toolsにして様子をみるしかないという感じかと思います。

VMware Product Interoperability Matrixes から現在使用しているESXiで利用可能なVMware Tools をみて、https://packages.vmware.com/tools からVMwareToolsのインストーラーを入手して、バージョンアップすることがお勧めです。

 

文脈がぐちゃぐちゃですが、今回はこのへんで。

ESXi上にESXiをインストールして仮想ディスクをSSDとして認識させる。(Nested ESXi)

こんにちは。

 

今回はESXiがインストールされたサーバ上に仮想マシンとしてESXiをインストールします。
そしてその後、仮想マシンとして動作するESXiからみると、SSDが搭載されたホストにみえるよう設定してみようと思います。

短い言い方をすると、Nested ESXiに接続された仮想ディスクをSSDとして無理やり認識させる方法を紹介します。

情報元はこちらのBlogです。いわゆるパクリです。

Emulating an SSD Virtual Disk in a VMware Environment | virtuallyGhetto

細かいことはすっ飛ばして、イメージ図はこのような感じです。

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

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

◆使う環境
vCenter Server 6.5
物理ホスト:VMware ESXi 6.0 Update 2
Nested ESXiのOS:ESXi 6.0 Update 2
======================

では、Nested の ESXi6.0 Update 2 を作っていきます。

 

vSphere Web Client から普通に仮想マシンを新規作成していきます。

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

 

わかりやすい名前をつけました。

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

 

使用するデータストアも特にどれでもかまいません。

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


ここの選択は重要です。以下を選択します。
[Guest OS Family:]  → Other
[Guest OS Version] → VMware ESXi 6.0

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

 

ESXiの最小インストール要件を満たすためにメモリを8GBに増やし、vCPU 2にしました。

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

 

私はVMware Remote Console が好きなのでよく使っています。
仮想マシンをパワーオンし、画面を表示したあと、
ESXi6.0 Update 2 のISO イメージをマウントします。

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

 

手元にあった インストールメディアが以下のものでしたので、これを使います。
[VMware-VMvisor-Installer-6.0.0.update2-3620759.x86_64.iso]

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

 

iso イメージからブートさせました。
Enterキーを押してインストールを進めます。

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

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

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

 

警告がでますが、あとから修正するのでそのまま進み、インストールを完了させます。
インストール後はこの仮想マシンをパワーオフします。

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

 

パワーオフ後に仮想マシンの編集画面を開きます。
x64の仮想マシンをNested ESXi上で稼働させるために
[Expose hardware assisted virtualization to the guest] にチェックをいれます。
 ※必須ではないです。

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

 

Nested ESXiからSSDに見えるようにしたい仮想ディスクを追加します。
このとき、どのSCSIコントローラーのバスに接続したのかをメモするか
覚えておくようにしてください。
今回の環境は SCSI  0:1   につないでいます。

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

 

まだ仮想マシンはパワーオンせず、仮想マシンの構成ファイル(.vmx)を編集するためにvSphere Web Client から 構成ファイルをダウンロードします。

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

 

ダウンロードした . vmxファイルをテキストファイルで開き、
scsi0:1.virtualSSD = 1 を追記して保存します。
"scsi0:1"  の部分はSSDに見せたい仮想ディスクの場所を指します。
上記で記録した部分です。f:id:japan-vmware:20170216011330p:plain

 

編集したファイルを同じ場所にアップロードします。

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

 

仮想マシンをパワーオンして、IP Address を設定してください。
(私の環境はDHCPなので自動でIP Addressを取得しています)

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


ESXi6.0 Update 2 はvSphere Host Client がデフォルトでインストールされているため、
vSphere Host Client を開いてログインします。

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

 

では、指定した仮想ディスクがSSDに見えているか確認します。
[新しいデータストア] をクリックしてみます。

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

 

仮想ハードディスクのはずが、SSDに見えていますね!!
このまま進めてデータストアを作成してみます。

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

 

データストアとして作成してもきちんとSSDとして認識しています。
(当然性能はお察し...)

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

 

■考察

検証目的としてどうしてもESXiホストにSSDとして見せる必要があったり、

とりあえず、勉強や一時的な検証のためにVMware vSANを構築 しなければいけないときは、使うとよいと思います。

特にVMware vSAN は最低でもESXiホストが3台必要で、SSDがそれぞれのホストに1つは必須なので、お財布事情を考えると使うこともあると思います。

既に私はお世話になってしまいました...

 

今回はこのへんで。

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値 は 1 
が推奨となっていました。

 

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


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

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

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

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

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

このような動作で、負荷分散が動作しています。
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側としては、1つのパスから多くのI/Oを受け取ることになります。

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


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

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

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

 

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

 

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

 

おわり