ESXiを通過する物理ディスクとHBAを通過する物理ディスクはどのように機能しますか？
コンテキスト：
ESXiで実行されるSANオペレーティングシステム（Nexenta）があります。 VT-dを介してすでにいくつかのHBAが渡されています。 SAN OSのすべてのHBAがいっぱいです（空きコネクタがありません）。最近、Nexenta用のSATA SSDをいくつか購入し、マザーボードのオンボードSATAコントローラーに直接接続しました。
VSphereのVMプロファイルに「物理ディスク」を追加することで、これらの新しいSSDをNexenta VMに追加できます。または、HBAの1つに接続することもできますが、既存のディスクを切断/移動する必要があり、かなりの手間がかかります。
質問：
私の質問は、HBAが派手なキャッシングなどを行わず、オンボードコントローラー（新しいSSDに接続されているコントローラー）と同じ使用可能なバス帯域幅とSATA仕様を持っていると仮定すると、接続と接続の間にパフォーマンスの違いがありますか？ vSphereディスクを介してVMに物理ディスクを追加し、VT-dを介してVMに渡されるHBAに接続しますか？ vSphere disk addメソッドは、ネイティブ速度と比較してディスクパフォーマンスに悪影響を与える可能性のあるリレー/要求転送動作を課しますか？
答えの逸話は良いですが、統計はより良いです：SSDは高速なので、最初はパフォーマンスの違いに気付かないでしょう。しかし、私はこの分野に長く携わっており、問題のあるパフォーマンスの違いがある場合、それは生産上重要な活動中に、最悪の場合に現れることを知っています:)
私の投稿のオールインワンZFSセットアップの構成に関する注意事項を参照してください： 仮想ゲストとしてZFSサーバーをホストする 。
SSDプールの作成、またはドライブをrawデバイスマッピング（RDM）として追加することについて話している場合は、この回答の残りの部分は無視してください。優先順位は、HBAとRDMを介して実行することです。必要に応じてSASエクスパンダーを使用します。主な理由は、移植性の容易さ、構成の単純さ（ this または this は不要）、および一貫性です。すでに構成したものを使用します。パフォーマンスへの影響はごくわずかです。管理オーバーヘッドは無視できます。
代わりに、ESXiに提示されたディスクでVMDKファイルを使用することを検討している場合、一般的な答えはどちらの方法でもかまいません。パフォーマンスの違いはおそらく問題ではありません。これは、アプリケーションが仮想化されたZFSシステムに [〜＃〜] zil [〜＃〜] ログまたは L2ARC キャッシュデバイスを追加していることを前提としています。 SSDを物理システムに追加し、その上にVMDKを追加してNexentaStorVMに提示する場合があります。その他の場合は、RAWドライブ全体をインスタンスに提示することがあります。
私はそれを利便性とパフォーマンスに基づいています。パフォーマンスが絶対的に最優先である場合、ストレージを仮想化することはありませんよね？便利な部分には、全体の100GB以上のSSDをZIL専用にすることなく既存のシステムに合理的なパフォーマンスの向上を提供する柔軟性があります（4GBのみが必要です）私の目的）。私が他の方法で制約されている場合、これはL2ARCの余地を残します。
だから私の質問は次のようになります：
- お使いのマザーボードのSATAコントローラーはESXiでサポート/認識されていますか？ 6Gですか？
- 何してるの？ ZIL？L2ARC？ 両方？ L2ARCは書き込みが重くなく、読み取りパフォーマンスはデータセットとキャッシュヒット率の関数になるため、これは重要です。 ZILの場合、待ち時間の短い書き込みが必要であり、デバイスの選択が 速度を落とす にならないようにする必要があります。
- 読み取り/書き込みプロファイルを調べましたか？ arcstat 、 arcsummary および zilstat は、何が可能かについての洞察を提供します。これをテストするための適切な方法でもあります。 ESXiによって提示されたVMDKを使用してみて、代表的なワークロードの下でのボトルネックを特定してください。
- どのタイプのSSDを追加しますか？あなたはSATAについて話しているので、すぐにハイエンドのSAS SSDが利用可能です。6GSATASSDを使用しますか？