本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。
VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。
原文を参照したい方はVMware ESXi Storage I/O Pathをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。
当社のNutanix社製品についてはこちら。
私にとってESXiの中をIOがどのように流れていくのは長い間謎に包まれたものでした。もちろん、私はパス選択ポリシー(PSP)がどういうもであるのかや、ストレージアレイタイププラグイン(SATP)がどういうものかということは知っていましたし、vSCSI statsについても聞いたことが有りましたが、それでもI/Oのフローについて深く説明するということは出来ませんでした。仮想マシンから出たI/Oがどうにかしてカーネルに入っていく、というぐらいしか知らないようなものだったのです。それでもESXTOPのようなstatsコマンドで特定のパフォーマンスの値を監視したり、PSPのレベルでベンダーが推奨する通りの設定を行い、パフォーマンスを監視するということは出来ます。そして、そう、RAWデバイスです。これはまた別のストレージプロトコルやキューが登場します。ですが、これは全体でどのようになっているのでしょうか?
このブログの記事はストレージ IO パスについて一定のレベルでの詳細をご説明します。エンジニアリング(製品開発部門)と緊密に動くことの良い点は日々非常に多くの事を知ることが出来ますが、それを自分のものにしていくことが難しくなるのです。ですから、この多くの情報をより深く調べ、最終的にはブログの記事にまとめることにしました。もちろん、ESXi 6 U1にはVAIO(vSphere API for IO Filtering)フレームワークが追加されていますが、これについては別の記事に後でまとめたいと思います。VAIOを利用すればベンダーはユーザーワールドのコンテキストで動作するフィルタドライバーを経由してしっかりとVMwareのコントロール下に置かれたやり方でI/Oに割り込む方法で開発を行うことが出来ます。今日の時点ではVAIOはまだ新しすぎて、殆どのベンダーはVAIOを利用する製品をリリースすることが出来ていません。どうしてこんなことを書くのかって? それはPernixDataの(そして、今はNutanixの)フラグシッププロダクトであるFVPとストレージ分析ソフトウェアであるArchitectはESXiのプラガブルストレージアーキテクチャ(PSA)で統合されています。更にVVOLによってストレージの管理は著しく簡単になろうとしています。ですが、私はテクニカルサポートエンジニアとして日々過ごす中で、VVOLについて考えはじめ、もしくはさらに次のインフラストラクチャが登場するのではないかと考え始めています。VMwareは既にVVOL以前にポリシードリブンストレージマイグレーションで素晴らしい結果を上げており、私の対峙している顧客は十分満足しています。結果として、VVOLについて考えるのが後回しになっているのです。
仮想マシンからの全てのIOはユーザーワールドのコンテキストでvCPU、VMX、MKS、SVGAなどのそれぞれから、異なるスレッド(ワールド)で開始します。ユーザーとカーネルモードのち我について理解するためには私の最初の記事カーネル vs. ユーザーモードをご参照ください。仮想マシン自身のマネージャーはVMM(仮想マシンモニタ)です。
それからIOは基本的にはVMkernelを通じてどんなアクションが行われるか、そのストレージ実装が利用されているかによって様々なジャンクションを通っていきます。
- Block Storage(ブロックストレージ):
- File Storage(ファイルストレージ):
- Network File System (NFS)
すべてのI/OはVMMレベルで開始されるため、ここまではスキップしてvSCSIフロントエンドからのI/Oフローをご説明していきます。I/OがユーザーワールドからvSCSIフロントエンドへ流れていく部分は非常に面白いです。そして、VMXNETやPVSCSI実装などの準仮想化実装とどう違うのかがわかります。
ESXi I/O フロー
- vSCSI フロントエンド:
- フラットバックエンド(VMDK)またはRDMバックエンドのIOの両方が流れてきます。
- それからI/OはFSS(ファイルシステムスイッチ)へと流れ、その後、DevFS(スナップショット関連のI/O)、VMFSレイヤ、NFSレイヤのいずれかへと導かれます。
- NFSの場合、その後、ESXiのSUNRPC実装とTCP/IPスタックを経由してVMカーネルインターフェイス(vmk)へとI/Oが進んでいきます。
- VMFSの場合、道はFDS(ファイルデバイススイッチ)へと続き、そこで、ディスク(通常のスナップショットのないI/O)、スナップショットドライバ、またはLVM(ロジカルヴォリュームマネージャー)へと分岐します。
- ディスク : 通常のVMDKのI/O。
- スナップショットドライバ : 仮想マシンがスナップショットを発行するか、スナップショット上で動作している場合、すべてのI/Oは再度FSSへと送られ、スナップショットの連鎖はDevFSの実装を通してマウントされます。
- LVM : ディスクが作成、拡張、結合された場合。
- I/OはPSA(プラガブルストレージアーキテクチャ)へと進んできます
以下の図はI/Oフローの詳細をそれぞれのパーツを結合して顕したものです。
ESXiのストレージ実装
VMM:
仮想マシンモニタ(x86 CPU、SCSIコントローラをエミュレーション、等)
共有リング:
共有リングはVMMとVMカーネルの間の共有キューで、VMMもしくはVMカーネルの両者はパフォーマンスのペナルティなくこの共有リングへアクセスが可能です。共有リングのサイズは発生させられるI/Oの数を決めてしまいます。VMカーネルが共有リング内のI/Oを見つけるとすぐに、このI/Oをキューから取り出し、vSCSIフロントエンドへと送ります。もっと詳しく知りたい方は以下のKBを参考にしてください。
vSCSI:
VMカーネルのSCSIフロントエンドで、SCSIリクエストと仮想化されたファイルへのI/Oリクエストを送信します。
Flat Backend(フラットバックエンド):
ファイルをエミュレーションします。
RDM Backend(RDMバックエンド):
RAWのLUNへのポインタ/シンボリックリンクです。リンク内に識別子が埋め込まれます。
FSS (ファイルシステムスイッチ):
ファイルシステムのドライバを実装する際に利用できます。APIは公開されていません。
DevFS:
殆どのUNIXベースのファイルシステムと非常によく似ており、実デバイス、非実デバイスをエミュレーションします。
VMFS:
VMFSの3と5の両方を実装した単独モジュール。
NFS:
FDS (ファイルデバイススイッチ - ブロックストレージ):
ディスク、スナップショット、そしてLVMの切り替えに利用されます。
ディスク:
すべてのディスクベースのブロックデバイスをエミュレーションします。ストレージスタックと直接やり取りします。
スナップショットドライバ:
フィルタドライバとして実装されています。フィルタドライバによって、FSSへとIOが戻るため、ディスクが再帰的にDevFSへとマウントされます。
LVM (ロジカルヴォリュームマネージャ):
削除、結合、作成などが発生した場合にはLVMへと司令が送られます。LVMはヴォリュームの結合を行い、論理領域としてヴォリュームを上のレイヤへ見せます。VMFSとしてデータストアをフォーマットすると以下のように動作します:
- はじめにLVMに論理ボリュームが作成される
- それから、そのヴォリュームがVMFSでフォーマットされる
このようになる理由はディスクが異なるLUNをまたがって拡張、結合される可能性があるからです。もちろん、再署名 例えば、スナップショットされたLUNでは同一のUUIDが利用されているので、LVMによって再署名される可能性があります。
PSA (プラガブルストレージアーキテクチャ):
SCSI デバイス:
すべてのローカル、そしてリモートのデバイスはSCSIデバイス構造になっています。(ターゲットあたり256以上のLUNは存在し得ない)
SCSI スケジュールキュー:
ストレージスタックは比例型の共有スケジューラ(シェア)を実装しています。SIOC(ストレージ I/Oコントロール)はこれをクラスタベースで行うものですが、SCSIスケジューラーキューを利用しています。シェアの値には全てのSCSIディスクの数が利用されます。
SATP (ストレージアレイタイププラグイン - コントロールプレーン):
ベンダー固有の機能を有しています。例: Trespass : LUNで利用可能なSP(サービスプロセッサ - ストレージシステムのコントローラ)のアクティブ-パッシブを制御します。また、I/Oが異なるSPから流れ込み、そのためにその異なるSPへと接続してI/Oを受けたなどを状態を理解することも可能です。SATPは障害時にもストレージとのコミニュケーションを行います。
PSP (パス選択ポリシー - データプレーン):
PSPはバックエンドのストレージにどのようにReadとWriteを提供するかを司ります。PSPには3つのフレーバがあります : MRU(もっとも直近で利用したパス)、Fixed(固定)、そしてRR(ラウンドロビン)。
- Most Recently Used (MRU): VMW_PSP_MRUポリシーは利用可能な最初のパスを選択します。このパスはシステムのブート時に検知されます。パスが利用できなくなった場合、ESXi/ESXホストは別のパスへとスイッチし、新しいパスが利用できる限りはそのパスを利用し続けます。これはアクティブ/パッシブのストレージ装置において論理ユニット数(LUNs)の標準ポリシーです。ESXi/ESXは万一、パスが復帰したとしても以前のパスへと復帰しようとはしません。利用している障害が起きないかぎりは、です。
- Fixed (Fixed): VMW_PSP_FIXEDポリシーは指定された場合にはそのフラグが立っているパスを固定的に利用します。もし指定がない場合、システムのブート時に検知したパスの最初の利用可能なものを利用します。ESXi/ESXがその選択したパスを利用できない、もしくは出来なくなった場合、ESXi/ESXホストは別のパスを選択します。ホストは自動的に事前に定義されたパスが復帰するとすぐさまそのパスへと復帰します。このポリシーはアクティブ/アクティブのストレージ装置を接続したときのLUNsの標準ポリシーです。
- Round Robin (RR): VMW_PSP_RRポリシーは自動的にパスを選択し、利用可能な全てのパスの中で負荷を分散しながら設定されたパスを利用します。
このブログの記事が少しでもあなたのお役に立てば。もちろん質問があれば、いつもどおり気軽にコンタクトください。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw) 今後は (@Networld_NTNX)
さて、前回に引き続き、Guidoさんの記事です。VMwareのカーネルの中(といっても、ストレージ部分だけですが･･･)をこんなに解説してくださっている記事はなかなか無いと思いましたので、前回のものと合わせて翻訳させていただきました。前回とは異なって、I/OがESXiの中をどう流れていく?ということを順を追って解説してくれています。さすが、カーネルの中でI/Oを捕まえてぶん回している会社(PernixData/今はNutanix)のサポートチーム･･･詳しい!もちろん、VSANについてはまた上の図の中に別の枝が出て実装されていますし、今後はVAIOでもっと面白い実装も出てくるのではないかと思いますが、あくまでベーシックということで。技術的に深すぎてNutanixもPernixDataもVSANも違いがなくなってきています･･･そんな技術を組み合わせてソリューションを生み出していく各社･･･。そして、我々はそれを理解した上で、お客様に最適なソリューションをご紹介するソリューションディストリビュータです。
次回もGuidoさんのふかーい記事を翻訳予定です。まだまだ続きます。
