vSphere 5.5以降、vFRCなどの機能がVMWare vSphere Enterprise Plusライセンスに登場しました。
それは何のためですか？
vFRC-vFlash Read Cashe-仮想化ホストのローカルSSDドライブ上の仮想マシンのディスク読み取り操作をキャッシュする機能。
つまり、SSDをESXiホストに挿入します。 このディスクをホスト設定のvFRCプールに追加し、仮想マシンのプロパティに移動して、必要に応じて各ディスクに必要なサイズのvFRCを追加します。 たとえば、VMのドライブには100 GBの容量があり、20 GBのvFRCが追加されています。 ハイブリッドドライブを入手しました。 すべての書き込み操作はメインに送られ、すべての読み取り操作はvFRC SSDミラーにキャッシュされます。 統計的アルゴリズムによれば、読み取り要求の最も頻繁なブロックはこのキャッシュに残ります。 VMを隣接するvFRCホストに移行すると、このVMのディスクデータも新しいホストのFRCプールに転送されます。 そこにvFRCプールがない場合、または十分なスペースがない場合、そのようなマシンのvFRCはオフになります。 このルールの動作は構成可能です。
私は長い間、この技術をテストしたいと思っていましたが、ついに手が届きました。
120 GB PNY SSD（eMLC）がESXiホストに挿入され、vFRCとして構成されました。
額でテストしようとしても、良い結果は得られませんでした。 IOMETERは、IOPSの増加を望みませんでした。
この問題を調査し始めたところ、vFRCを接続するときに、キャッシュに使用されるブロックのサイズを指定できることがわかりました。 デフォルトのブロックサイズは8キロバイトです。 問題は、判明したとおり、ここに埋められました。
ESXiには、ディスクサブシステムとのVM通信に関する統計を収集および分析するためのツールがあります。 さまざまなサイズのブロックの処理の統計を見ることができます。 これらの統計の分析により、システムで最も頻繁に使用されるブロックサイズがわかります。 すべては、ディスク負荷を作成するサービスに依存します。
そのため、 vscsiStatsを使用して統計を表示するには、ESXiホストでSSHを有効にし、コマンドラインに接続します。 記事のデータの一部がグーグルとドキュメントからのものであることを予約します。
1.ホストで使用するマシンとドライブのリストを確認します： vscsiStats -l
2.対象のディスクに関する統計情報の収集を開始します。vscsiStats-s -w YYYYY -i XXXX （YYYYYは仮想マシンのGroupID、XXXXは仮想SCSIディスクのhandleIDです）
3.次に、通常のロードを実行して待機します。
4.統計を確認します： vscsiStats -p ioLength -c -w YYYYY -i XXXX
フォームのプリントアウトを取得します。
最小、512
•最大、1052672
•平均、18434
•カウント、21150
•頻度、ヒストグラムバケット制限
•1576,512
•1073,1024
•539,2048
•375.4095
• 5219、4096
•428.8191
•4246,8192
•787.16383
•1858.16384
•3877,32768
•62,49152
•405,65535
•155,65536
•32,81920
•324.131072
•138,262144
•9,524288
•47,524288
最初の列はブロック数（ヒット）を示し、2番目の列はこれらのブロックのサイズを示します。 最大数を探しており、どのブロックが最も人気があるかを理解しています。 特定のケースでは、これは4キロバイトです。
統計の収集を終了します： vscsiStats -x
そして、VMディスクのvFRC設定で使用済みブロックのサイズを変更します。
では、vFRCの動作に関する統計をどのように見るのでしょうか？ グラフィカル形式では、何もありません。 コマンドラインのみ。 vSphereには統計を操作するための便利で強力なグラフィカルインターフェイスがあるため、これは便利ではないようです。
すべて同じように、コマンドラインで、VMにサービスを提供するキャッシュディスクを探します。
〜＃esxcli storage vflash cache list
vfc-413278667-vfrc-test
詳細を確認します。
〜＃esxcli storage vflash cache get -c vfc-413278667-vfrc-test
ワールドID：2299121
キャッシュ名：vfc-413278667-vfrc-test
vmdkname：vfrc-test-flat.vmdk
統計を見てみましょう：
〜＃esxcli storage vflash cache stats get -c vfc-413278667-vfrc-test
または、統計をリセットします。
〜＃esxcli storage vflash cache stats reset -c vfc-413278667-vfrc-test
素晴らしい。 実際にどのように機能するかを見てみましょう。
5ギガバイトの新しいシック（Thick Eager Zeroed）ディスクをVMにしがみついて、vFRCディスクも5ギガバイトに接続します。 最も効果的な労働条件でキャッシュを作成します。 VMディスク全体が読み取りキャッシュで覆われています。
IOMETERを起動し、観察します。
64ストリーム、1ワーカー、4kb BS、100％ランダム、100％読み取り
開始するには、ランダム読み取り用に10,000 IOPSを提供するストレージシステムに仮想マシンのディスクを配置します。
IOMETERはそれらを正直に示しています。 数分間、何も起こりませんが、IOPSインジケーターがスムーズに成長し始めます。 2時間後、それらは15,000 IOPSのレベルに達し、これに制限されます。 制限に達し、すべてのデータがキャッシュされているようです。
ストレージシステムにアクセスし、それに到達するIOPSを確認します。
はい、約1700 IOPSがVMディスクに到達することがわかります。 おそらく、データの100％がキャッシュに保存されたわけではありません。 おそらくこれは技術の特徴です。 私は承認するつもりはありません。
次に、VMディスクを既知の高速ストレージシステムに転送しようとします。これにより、ランダム読み取りで保証された60,000 IOPSが得られます。
すべてが論理的です。 データはVMディスクからではなくvFRCから取得されます。そうしないと、IOPSが大幅に増加します。
最終チェックでは、VMディスクを意図的に低速のストレージに転送します。これにより、ランダム読み取りに200 IOPSを超えることはありません（1 SATA 7.2kディスク）
7.000 IOPSが得られます!!! このような遅いストレージで素晴らしい結果が得られます！
統計から何を得ることができますか？
コマンドを入力して、以下を見てください：
だから、私の意見は統計は良くないということです。 それだけでなく、その中のデータは単なる人間には明らかではありませんが、天井からも取得されます。 最も興味深い指標であるキャッシュのヒット率は、テストの最初から36であり、その後2時間以内に32％に低下したとしましょう。 偽物。 残りのパラメーターはより良くなく、現実とは関係ありません。 個人的には、統計を拒否しました。 良くない。
vSphere自体の統計も奇妙です。 vFRC接続後、すべてのVMディスクを読み書きするためのデータ量の転送に関する統計は保存されなくなります。 つまり、単にゼロがあります。 録音レイテンシは約50ミリ秒になります（実際にはそうではありませんが）。 そのようなものは統計にのみ表示されます。 vSphere 5.5-u2にアップグレードしても状況は修正されませんでした。
vSphereグラフィカル環境から読み取られたVMディスクのレイテンシに関する統計は何を示していますか？ そしてそこにはすべてがうまくいきます：
待ち時間が長い。 VMディスクのウォッチドッグを変更した場合の影響は検出されませんでした。
小さな結論：この技術は非常に適切で機能しています。 はい、いくつかの欠陥がありますが、おそらく修正されますが、今すぐ使用できます:)
効率を高めるには、vFRCでPCI-E SSDを使用することをお勧めします。 PCI-Eカードは、ドライバーレベルでESXiと互換性がある必要があります。