Tintri VMstoreでは、お客様の承認のもと、マシンのヘルスチェックや動作に関するサマリーを毎晩アップロードしています。これにより、Tintriはお客様に積極的なサポートを提供するだけではなく、Tintriの技術者も製品の実際の使用方法や注意すべき分野に関する理解を深めることができます。これらのことを念頭に置きながら、data diveについてお読みいただければと思います。

私は以前、NFS operation mixへの仮想化の影響やVMのサイズに関するTintri VMstoreautosupportのデータについて取り上げました。今回は読み取り・書き込み操作の規模に触れながらフォローアップを行いたいと思います。

仮想化環境におけるサイズの分布はどうなっているのか？

• VMのワークロードにおける4KBの読み取り/書き込みサイズはI/Oオペレーションのサイズを上回っています。とはいえ、8KBの読み取りは、4KBの読み取りよりも一般的です。
• ほとんどのバイト数は256KBや64KBといった大きな読み取り/書き込みサイズに変換されます。
• 異なるワークロードは、オペレーションサイズの明らかな違いを示します。一つのオペレーションサイズのみ測定した場合、全体的なパフォーマンスを誤解してしまう可能性があります。

ここで示すデータは、各システムのカバレッジ内で数日間にわたって2,000もの実世界のシステムから集められたものです。VMwareとVMwareでないハイパーバイザーの両方を含んでいます。

Tintriは現在、VM単位でのオペレーションサイズのトラッキングは行っておらず、NFSレイヤでのみ行っています。このトラッキングでは、バケットサイズの2のべき乗値を利用したヒストグラムを使用し、オペレーション カウントについては毎晩、autosupportsで最も近い2のべき乗値が報告されています。

これにより、私たちは低コストで幅広い数値をカバーできる一方、通常とは異なるサイズの読み取り/書き込み数などの興味深いものを理解する能力が制限され、さらには結果の正確性が低下する可能性があります。読み取りサイズが限界値の2のべき乗値を超えた場合には、数値を切り捨てて、報告します。

データ全体を見ると、仮想化データセンターでは4KBのオペレーションが依然として優勢なのは明らかです。約47%の書き込みと約25%の読み取りが4KBのサイズで行われていました。しかし、最も多かった読み取りサイズは8KBで30%を占めていました。

また、64バイトの驚くべきスパイクがあります。これは小さな書き込みサイズで頻繁にアップデートされているVMwareロックファイルによって起こります。当調査におけるTintriのお客様について見てみると、8%以上の書き込み操作がこのサイズで行われており、ほぼすべてがロックファイルへのアクセスによるものでした。多くの操作を伴うその他の小さな書き込みサイズは8バイトで、サンプルのわずか0.12%でした。

他の小さな読み取りサイズと比べて、64バイトでは読み取り数に対応しているスパイクがありますが、これは読み取り操作のわずか0.004%です。これらのすべての操作でロックファイルが使われているという前提に立つと、VMwareロックファイルでは読み取りと同様に31回の書き込みが行われていると推測できます。

一つのVMに期待されるSCSI操作の最小値は512バイトです。これらの小さな操作では読み取りが2.6%、書き込みが5.1%を占めています。

大きな読み取り/書き込み（64KB以上）のほうがより一般的です。大きな読み取りと書き込み数はそれぞれ21%と8%を占めており、実際にほとんどのバイト数は大規模な操作によって変換されています。I/O数の代わりに変換されたバイト数で加重した各操作に関する同じデータが以下に記載されています。

読み書きされたすべてのバイト数のうち、約半数が256KBブロックとなっています。64KBの読み取り/書き込みサイズは128KBと比べて大きな比率を占めています。これはVMware Storage vMotionが64KBのサイズを使用しているからではないかと考えられます。

ここに記載されているデータは様々なアレイや時間の平均を示しています。データを表す一つの手法としてK平均法の使用があります。このアルゴリズムは多次元空間として考えられるアクセス分布がどれほど正確に一致しているかに基づいてデータセットの中の800万もの測定値をクラスターに分けます。その中でK=5は最も特徴的だと思われるクラスターを生み出していることがわかりました。各クラスターは行われた測定の約20%で「中心」となっているため、5つのほぼ等しい一般的なアクセスパターンを示していると考えることができます（ただし、各クラスターには同等のアクセス数がなく、10分間で得られたサンプルと同等の数しかない場合もあります）。

読み取りにおける5つのクラスターは以下の通りです。

1. 512バイトで、4KB、8KB、32KB、64KBの読み取りサイズをそれぞれ10~15%含む混合ワークロード
2. 期間中の読み取りの約60%を占める4KBのヘビー ワークロード
3. 読み取りの約65％を占める8KBのヘビー ワークロード
4. 読み取りの約55％を占める16KBのヘビー ワークロード
5. 最大256KBのサイズで操作の55％を占める大きな読み取りワークロード

つまり、約80％の場合においてVMワークロードには一つの主要な読み取りサイズがあると予想されます！以下のドーナッツ型グラフは各クラスターの中心におけるサイズの分布を示しています。

書き込みについても同様ですが、もう少し複雑です。5つのクラスターは以下の通りです。

1. わずか18%しかない不均衡で大きなブロックサイズの書き込み
2. （ロックファイルへの）64KBでの書き込みが約45％に相当するアイドル期間
3. 書き込みの約80％を占める8KBのヘビーな書き込みパターン
4. 約65％を占める4KBのヘビーな書き込み
5. 45%の4KBでの書き込みと他のサイズのスムーズな分布を持つ混合ワークロード

データセットの中では、バックアップ用のワークロードによって大きなブロックサイズの読み取り期間が与えられているのではないかと考えられています。なおそれに対応する大きなブロックサイズの重い書き込みワークロードはありません。混合的なオペレーション サイズを、時間さらにはIOPSの数と関連付けたことはまだありませんが、これは興味深いフォローアップ調査になるかもしれません。

データからわかること

これらのデータから2つの実践的教訓が得られます。それはベンチマーキングと、混合ワークロードにおけるサービスの質です。

仮想化システムの動作は複雑であり、たった1つか2つのブロックサイズでパフォーマンス測定を行うと、観測されたワークロードのうち、20%から40%のワークロードしか示されません。ストレージ システムが8KBの読み取りサイズでのみベンチマークされたとしたら、実世界における70%のワークロードは無視されることになります。

さらに、ほとんどの測定結果は一定のブロックサイズ用のものであり、実世界での結果から最も一般的な読み取りサイズと書き込みサイズはそれぞれ異なるということが分かります！より良いモデルでは、4KBの書き込みサイズと8KBの読み取りサイズが組み合わさっています。ベンチマークは指針を示す上で、このような実世界のデータにより近いものでなければなりません。一番良いのは独自のワークロードを使用することですが、IOMarkやVDBenchなどのフルスタック ベンチマークのほうがより現実的な組み合わせを提供します。

2つ目の教訓は小規模と大規模のブロックI/Oは共存し、ストレージ システムはそれらの組み合わせや時とともに変化する組み合わせを丁寧に扱わなければならないということです。10Gbpsでは、64KBのNFSの読み取りにおよそ50マイクロ秒かかります。一度に複数のリクエストが出されると、関係のないVMのトラフィックによって200マイクロ秒以上のレイテンシーが発生する可能性があります。データセットの中のほとんどの読み取りリクエストは小規模ですが、ほとんどのバイトは大きな読み取りサイズに対応しながら送信されることを覚えておいてください。つまり、レイテンシーの影響を受けやすいタスクではこのような状況に比較的頻繁に遭遇する可能性があります。

Tintri Vmstoreには混合的な読み取りサイズに適合するための自動化メカニズムが含まれています。外部ネットワークリンクではVM単位での公正な分配が行われます。そのため、一つのVMで複数の大きな読み取りが行われると、他のVMのレスポンスは最初にネットワークに送信されます。これにより、大きなブロックサイズでの読み取りを連続的に行うことで、小さなブロックサイズのワークロードでは過度のレイテンシーは見られなくなります。これはレイテンシーの影響を受けやすいVMをバックアップ トラフィックや他のノイジー ネイバー（うるさい隣人）から分離する上で重要な最適化です。

さらなる観測

さらに広く見てみると、これらのデータは一般的な特徴だけでなく様々な驚くべき事実も示していると考えられます。4KBはワークロードにおいて最も多く使われているサイズです。これは一般的なLinuxとWindowsのファイルシステムがいまだに4KBブロックを使用していることから考えられます。しかし8KBの読み取りサイズの方がより頻繁に見られ、それより大きなサイズのものはあまり見られません。つまり、ファイルシステム自体のブロックサイズは何十年も変化していないにもかかわらず、ゲストファイルシステムでは連続的なデータ配置が見事に行われていることがわかります。

ほとんどのバイト数が大きなブロックサイズに変換されるというこの測定結果は驚くべきことではありませんが、これにより仮想化ワークロードにおいては大きなブロックの性能がやはり重要であることが確認できます。このトラフィックの大半がバックアップ、リカバリーまたはライブ イグレーションであれば、VMstoreのビルトイン データの保護や複製機能にオフロードされる可能性があります。

64バイトで書き込まれた多数のデータは、VMwareワークロードにおける明確なシグネチャーです。ロッキングはアプリケーション自体が使用されていなくても続いていることからロックファイルの書き込み頻度は増えていると考えられます。また、これらのロックファイルの特別な扱いによって全体的なパフォーマンスの利益が与えられるかどうか調べてみる価値はあると思います。

様々なワークロードを主要な読み取り/書き込みサイズによって分類することこそがこの分析の中で最も興味深い部分だと思います。すべてのクラスターでは様々なサイズが混ざっていますが、80％の場合において、読み取りトラフィックの主要なブロックサイズは一つだけであることが分かります（各クラスターは時間間隔とVMstoreの両方から集められたサンプルの20%を示していることを覚えておいてください）。

VMstoreは内部では、測定により様々なリクエストサイズに適合することが判明した8KBのブロックサイズを使用しています。しかし、他の主要なサイズへの相変化はユーザーに興味深いシグナルを示したり、変化しているワークロードへの内部適応を推進したりするかもしれません。