本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。
VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。
原文を参照したい方はVMware SCSI Controller Optionsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。
今回の記事ではVMware ESXi内の様々なSCSIコントローラについてと、なぜ最終的に他のものよりこのオプションが優れるのか、ということを解き明かして行きたいと思います。私は現職で様々なお客様と、どういう状況においてはLSI Logis SASやParallelがParavirtualized(準仮想化) SCSIアダプタ(PVSCSI)に対して優れるのかという様々な議論を交わしてきました。そしてその結果、私の考える本当の理解とその違いについて上手く説明しているブログの記事やKBが無いということに気が付きました。殆どの環境ではOS標準のアダプタが選択されており、多くの場合、それで良く、上手く動いています。問題が起きるのはどこかに制限があったときであって、どのようにそれを見つけるかではありません。でははじめていきましょう。現在のESXi 6.0のヴァージョンでは5つのSCSIコントローラを選ぶことが出来ます。それをまとめたのが以下のテーブルです。
SCSIコントローラの比較
|
アダプタタイプ
|
OSタイプ
|
最低要件
|
最大SCSIアダプタ数
|
|
|
BusLogic Parallel
|
サーバ
|
-
|
4
|
|
|
サーバ/デスクトップ
|
-
|
4
|
||
|
サーバ/デスクトップ
|
HWv7
|
4
|
||
|
PVSCSI
|
サーバ
|
HWv7
|
4
|
|
|
サーバ/デスクトップ
|
HWv10
|
4 (既存のSCSIコントローラ上で)
|
アダプタタイプ
見るとおり、AHCI SATAコントローラはさほど大きなメリットを産んでいません。このコントローラは追加ディスクを大量に必要とするような場合を想定しており、パフォーマンスについては問題としていないのです。AHCI SATAコントローラは既に利用しているSCSIコントローラ上に追加することが可能です。
それぞれのアダプタがいつからサポートされているのか、ということを知るのも重要ですので、以下のテープルにまとめました。
|
機能
|
ESXi 6.0
|
ESXi 5.5
|
ESXi 5.1
|
ESXi 5.0
|
ESXi 4.x
|
ESXi 3.5
|
|
ハードウェアヴァージョン
|
11
|
10
|
9
|
8
|
7
|
4
|
|
サポートされるSCSIアダプタ
|
BusLogic
LSI Parallel
PVSCSI
|
BusLogic
LSI Parallel
PVSCSI
|
BusLogic
LSI Parallel
PVSCSI
|
BusLogic
LSI Parallel
PVSCSI
|
BusLogic
LSI Parallel
PVSCSI
|
BusLogic
LSI Logic
|
x86アーキテクチャ
さて、もっとも面白そうなアダプタはLSI Logic SASとPVSCSIであるということに疑問はなくなりましたか? この｢Paravirtual(準仮想化)｣という言葉は一体どういうことを意味するのでしょうか?これについてお話する前に、ドライバがスタックのどこに位置しているのかを見ていきましょう。x86アーキテクチャでは常に4つのレベルもしくは特権を目にします。それらはリングまたは、CPUモードと呼ばれており、リング 0～3に分けられます。従来からのWindowsのようなOSはリングを2つだけ利用してきました。これはその時に利用できるプロセッサが2つ以上のモードをサポートしていなかったからです。あらゆるアプリケーションが利用する最低限の特権しか有しないリング3とすべての権限を利用できるリング0です。ですから、ユーザーアプリケーションがハードウェアを利用しようとする度にCPUはユーザーモードへと切り替わる必要があります。もし、もっと詳しく知りたいということであればカーネル vs ユーザーモードという記事を読んでみてください。次の図はx86アーキテクチャでの従来型のモードを顕しています。
VMMを利用したバイナリトランスレーション
仮想化された環境ではハイパーバイザ自身が物理ハードウェア上で動作します。ゲスト仮想マシンOSがリング 0で動作することは非常に難しくなります。これはリング 0をハイパーバイザー自身が利用しているからです。更に複雑なことに、特定の操作はリング 0で実行しなければ完了できないというものが有ります。では、どうやっているのでしょうか? VMwareはバイナリトランスレーションと呼ばれる手法を利用して、仮想マシンモニタ(VMM)をリング 0で動作させています。これによって仮想マシンがこうした操作を行う際にリング 0で動作しているVMMの力を借りて実行することが出来るようになります。アプリケーション自身にとっては何も変わってはいません。次の図にこれを顕します。
OSのリクエストでバイナリ変換
ESXi内のParavirtual(準仮想化)実装
Paravirtual SCSIアダプタという名前は意味合いで言うとちょっと間違っています、これは全てのゲスト仮想マシン内のすべての仮想化ハードウェアはparavirtual(準仮想化)だからです。全く同じことがVMXNET3ドライバという固有のVMwareのドライバについても当てはまります。いずれの場合もゲストOS内にドライバをインストールして、このアダプタを利用できるようにしなくてはなりません。VMXNET3ドライバについてはこれはVMwareツールがインストールされた際に既に完了しています。
paravirtualドライバを利用するとESXiカーネルへアクセスすることが出来るようになり、システムハードウェアと通信する際にVMMを経由しなくても良くなります。ESXiに対して｢ハイパーコール｣を実行し、スケジューリング、割り込み、メモリ管理などの重要な操作を実現します。ですから、これはドライバの観点からはカーネルとのダイレクトチャンネルのようなものです。PVSCSIアダプタは他のSCSIコントローラのオプションに比べ一般的には優れたパフォーマンスを低いCPU利用率で提供することが出来ます。ですが、全ては時と場合次第です。次のセクションではLSI Logic SASとPVSCSIをもっと比較します。以下の図は一般的な｢ハイパーコール｣を利用するparavirtualアダプタの実装を顕しています。
ESXi内のParavirtual(準仮想化)実装
合成
合成(Coalescing)は融合(merge)、結合(join)、assemble(組み上げ)の類義語ですが、ゲスト仮想マシン内のSCSIコントローラではどういう意味を持つのか?とても簡単で、I/Oを非常にうまいやり方で最適化します。少しだけ合成がどういう意味を持つのかを挙げてみます。
- ストレージドライバを効率化する手法
- 合成はある種のバッファで、複数のイベントが同時実行の待ち行列していると考えると良い
- 効率と割り込みを改善しますが、そのためにはI/Oは大きなバッチリクエストとして生成出来るようにある程度高速な流れでなくてはならない
- もしも流入するI/Oがおそすぎて、タイムアウト期間まで待たなければいけない場合、I/Oは不必要に遅延が起きることになる
- LSI Logic SASとPVSCSIの両方は合成に割り込みをかけるために2つの異なる方法を用いています:
- 行われるI/O数(outstanding I/O) : 仮想マシンのI/O要求数
- IOPS : ストレージシステムが提供できるI/O
では、この2つが双方のアダプタでどのように動作するのかを比較してみましょう。
- LSI SAS : ドライバは行われるI/O数(Outstanding I/O:OIO)とIOPSが増加するに連れて合成を増やし、OIOが殆ど無い場合やスループットが低い場合には合成を行いません。ですから、OIOとI/Oスループットが小さい際には非常に効率的です。
- PVSCSI : ドライバはOIOベースでのみ合成を行い、スループットは考慮しません。仮想マシンが多くのI/Oを行っているときでも、ストレージにそれがすぐに伝わるということはなく、PVSCSIドライバが合成の割り込みを行います。ストレージに一定の流量のI/Oが無い場合、もちろん合成のための割り込みは必要ありません。結果として、わずかばかりですが、レイテンシが上がることになり、PVSCSIコントローラではスループットの低い環境では得るものは無いということになります。
- CPUコスト : LSI Logic SASとPVSCSIコントローラの違いはIOPSが低い場合にはその差は図ることが出来ない程度ですが、多くの数のIOPSであればPVSCSIではCPUサイクルを劇的に削減することが出来ます。
VMwareによると、2,000IOPSのピークパフォーマンス、または4OIOあたりでの切り替えがよいということがKB107652に記載されています。さらに新しいヴァージョンのESXiに於いてはもっと低いIOPSやOIO要件においてもPVSCSIを利用することを推奨しています。
キューデプス(Queue Depth)
パフォーマンスを最大化するためには仮想化ディスクが出来る限り多くのvSCSIアダプタに分散しているのが良いということになります。最大で4つのvSCSIアダプタが仮想マシンに対して構成でき、一つのvSCSIアダプタ毎に最大で15の仮想化ディスクが利用できます。複数のvSCSIアダプタを利用することでより多くのI/Oキューを利用することが出来るということです。以下のテーブルはPVSCSIアダプタを利用したときと、LSI Logic SASアダプタを利用したときのキューデプスを比較したものです。
|
キュー
|
PVSCSI
|
|
|
アダプタのキューデプスの標準値
|
256
|
128
|
|
アダプタのキューデプスの最大値
|
1024
|
128
|
|
仮想ディスクのキューデプスの標準値
|
64
|
32
|
|
仮想ディスクのキューデプスの最大値
|
254
|
32
|
PVSCSIのチューニング
とてもよいKBがあります : VMware KB 2053145 理解すると仮想マシンだけでなく、ESXi自身の様々なパラメータを変更しながらチューニングを行えるようになります。2つの設定項目がチューニングできます:
注意 : 標準のリングのページは8つで、それぞれが4KBのサイズとなっています。一回のI/Oのキューに関しては128バイトが必要とされます。つまり、32回で単一ページの4096バイトを利用することになり、結果として256回のIOができることなります(8x32)。WindowsのPVSCSIドライバアダプタのキューは以前のリリースではハードコーディングされていましたが、VMwareツールで提供されるヴァージョン以降では最大で32ページまで調整して増やすことが可能です。
ここにKBから抜き出した注意書きを書きましたが、これはどういう意味なのでしょうか?リングページとキューデプスが本当はどういう意味で、どのように誤解されているかを説明していきます。
リングページ :
128バイトと言う単位はI/Oのことを指しますが、これはI/Oが直接入出力される実際のメモリのことではありません。ページは実際のI/O操作を行うためのリングバッファによって利用されるメモリのことを指しています。実際のI/O自身にはこれは利用されません。これはDMA操作で利用されるポインターを格納しているページだと考えてください。ページのうちの一部分(非リングページ)があるI/Oに使われる場合がありますし、残りの部分(もちろん、かぶる場合もあります)が別のI/Oで利用される可能性があります。ですから、これ以降の操作が可能になるのです。
キューデプス :
キューデプスの数はPVSCSIの場合にはアダプタの制限を反映したものになります。アダプタは8つのリングページを利用するので、256のキューデプスをサポートします。PVSCSIは実際のデバイスではなく、VMwareの準仮想化SCSIデバイスですから、これは自然にはありえない値になっています。しかしながら、他のデバイス(実際のアダプタ)では、実際のハードウェア上の制限です。リングはハードウェア内にあり、制限を受けますので、そこでキューデプスです!キューデプスはアダプタ毎に存在します。ですから、もしもPVSCSIや他のLSIアダプタであれ、4倍の数のキューデプスを利用することが出来ます。つまり、それぞれ4つのリングページが有るのです。
LSI Logic :
構造は良く似ています。唯一の違いはハードウェアコントローラに実際のHBAのキューリソースによって上限が設定されていることです。ですが、ドライバーは恣意的にハードウェアが利用できる値よりも低い値で動作するようにします。もし、HBAが言う以上の高い値を設定したとすると、ESXi SCSI mid-layerのキューに行列するのではなく、ドライバ内に行列することになります。この場合、キューの遅延を考慮しなくてはなりません。
結論
さて、ここまででの結論はどうなるでしょうか? 人生における他のすべてと同じように、何を望んでいるかによってマチマチだ、ということになります。私が考えるには出来る限りはPVSCSIコントローラを利用するのが良いということになります。以前の会社では1500台以上の仮想マシンを動作させていました。あるとき、確か2010年だったと思いますが、既に80～90%の仮想化を終え、どこでLSIを利用すべきで、どこでPVSCSIを利用すべきなのかを環境の中で行っていくことは地獄のような作業になるということに気が付きました。加えて、当時のモニタリングツールは今日のものに比べとてもひどいものだったということもお伝えしておきます。結果として私はインフラストラクチャのアーキテクトとして3VMしか起動しないような小さな単独のESXiサーバであれ、集中管理されたデータセンタ内の巨大なERPシステムであれ例外なく全てのテンプレートで同じ構成のPVSCSIを利用するということにしました。既存で稼働していた仮想マシンについてもメンテナンス時間のタイミングで既存のSCSIコントローラからPVSCSIアダプタへの置き換えを行いました。おそらくはI/Oをほとんどしないような小さな仮想マシンにとっては全くメリットはなかったはずですが、I/O要件の高い仮想マシンにとってはもちろん、助けになったはずです。もちろんこれは私の過去の決断です。仮想マシン内のSCSIコントローラを変えるということは大きな労力となりますので、ダウンタイム時に変更するというのは正しい選択だったと思っています。
チューニングを行う一方で、注意しておきたいのは、利用しているストレージシステムのパフォーマンスがどんな様子なのかということです。もしもそうでないのであればこうしたパラメータを変更しても全く変化はありません。数年前まで、私はコントローラもしくはSCSIコントローラのキューデプスを調整することで常にパフォーマンスが改善できると考えていましたが、実際にはストレージシステムとサーバとストレージの間のスタックに依存することがわかりました。もしもキューから溢れてしまったI/Oを処理するものがなければ、多くのI/Oでキューを埋めるということは全く意味をなしませんが、もしもストレージがそれでも高速に動くのであればボトルネックとなっている仮想マシン側の問題にはこれで対処が可能です。ストレージシステムのパフォーマンスが良いとはどういうことか? これは検証や調整の末に見つけ出さなければなりません。もっとも簡単な方法はWindowsのパフォーマンスモニタなどのローカルOSのツールを利用して、平均ディスクキューの長さがアダプタの制限に張り付いていないかを確認することです。さらに、PVSCSIアダプタの数を増やすことで効果があるのはストレージがその取り回しに苦労しているときだけです。以前出来る限り多くのディスクとコントローラにまたがって構成を行い、負荷を可能な限り分散しようとする同僚がいたのを思い出します。ですが、結局はストレージがボトルネックになり、単に構成が複雑になっただけでした。ですから、出来る限り増やすのが良いということではなく、98%のシステムにおいては出来る限りシンプルにしておくのが良いと思います。残った2%はその必要があれば集中して調整を掛けていくのが良いと思います。
もし、ご質問があればどうぞ。
情報ソース、インスピレーション:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1017652
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010398
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1037959
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1267
ブログ:
https://blogs.vmware.com/vsphere/2014/02/vscsi-controller-choose-performance.html
https://pelicanohintsandtips.wordpress.com/2015/09/23/vmware-paravirtual-scsi-adapter-pvscsi/
https://clearwaterthoughts.wordpress.com/2011/05/06/virtual-scsi-adapters-vs-para-virtual-scsi-pvscsi-adapters-vs-vm-direct-path-io/
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)
さて、前回はカーネルの中のお話でしたが、今回はVMwareが提供している準仮想化ドライバを利用して仮想マシンのI/Oをチューニングしていくと言う話です。結果としてはPVSCSIに落ち着くということなのですが、SCSIドライバの中の話(リングページやキューデプス、またはIOの合成)などは特に理解せずに利用していた方が多いのではないかと思います。
この話を翻訳しようとしたのは｢カーネル vs ユーザーモード｣の話を宗教戦争ではなく掘り下げて理解していただきたかったことと、例えば、途中のPVSCSI(準仮想化ドライバ)の図のように、PVSCSIを利用すればVMMを経由せずにダイレクトにI/Oを実行できることなどを知った上で、議論に参加してほしいからです。VSANやPernixData(今はNutanix) FVPはVMMからコンテキストチェンジを発生させずにI/Oをフラッシュ(FVPの場合はメモリにも)に届けることでデータパスを短くしていますし、NutanixのCVMは今回ご紹介したようなテクニックを利用してデータパスを短くしています。どっちがいいのか? Guidoさんが言うように人生における他の全てと同じく、目指しているもの次第なわけです。
3回に渡ってGuidoさんの記事を翻訳し、カーネル vs ユーザーモードの話、特にI/O周りのアーキテクチャの話をしてきましたが、次回はI/O周りだけではなく、ソリューション全体での比較を取り上げたいと思います。
