PernixData FVPのパフォーマンス計測値を読み解く

本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。

今回はそんなPete氏の記事翻訳第4弾です。

本記事の原文はInterpreting Performance Metrics in PernixData FVPで閲覧可能です。

ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。

御存知の通り、パフォーマンスチャートとグラフは単なる可愛らしい色のライン以上のものです。これらによって様々な知見を得ることができ、よりよい意思決定ができるようになるのです。しかし、正しくこれを理解できなかった場合、意味がなくなってしまいますし、悪い場合には完全にその徴候を見逃してしまいます。どのようにデータが表示されているかによっては、パフォーマンスグラフは素晴らしい物になりますし、逆に混乱をもたらす事にもなります。この2つの違いは非常に大きいです。

vSphereの環境ではあらゆるタイプのパフォーマンスグラフを取り回すための膨大な機会が与えられます。しかし、実際のデータをどう読み解くかというテクニックは殆どの場合語られません。ほとんど一目瞭然でしょう?という反論もあるかもしれません。しかし、実際にはうまく読み解くことができず、利用率が低下しているということがほとんどです。このパフォーマンスグラフの難しさに対しては、多くのソリューションがシンプルなダッシュボードのような治験を提供する心を見を行っています。これはスタートとしては悪くありません。しかし、これによってデータが少なくなってしまい、実際のパフォーマンスの状態を理解するのに必要な詳細情報が得られないこともあります。パフォーマンスに影響のある要素は複雑になることもあり、緑･黄･赤の識別子で得られる知見よりも、もっと長いサンプリング期間が必要なこともあります。

殆どの場合、vSphereの管理者は環境内の｢長打者｣をVMをCPUでソートすることで簡単に見つけ出すことができます。強力な攻撃を繰り出す仮想マシンを見つけ出し、そこからドリルダウンできるのです。vCenterは標準ではストレージI/Oに関するよいビジュアルプレゼンテーションを提供しません。ストレージのパフォーマンスは仮想環境における非常に多くのパフォーマンスの真犯人であるにも関わらず、面白いことです。PernixData FVPはストレージI/Oの高速化を行いますが、それだけではなく、ストレージI/Oの理解を助けるというこの空白も埋めてくれます。

FVPの計測はVMkernel統計を活用します、私はそれをより見やすくしてくれると思っています。ハイパーバイザーからレポートされるこの統計は仮想マシンそして、アプリケーションからみた情報を測定していますので非常に重要です。インフラストラクチャ内の他のコンポーネント(ストレージやネットワークファブリック、等々)は非常によいパフォーマンスの値を表示しますが、アプリケーションからどう見えているかということは教えてくれないということを覚えておいてください。

パフォーマンスの計測値を読み解くことは大きな問題です。この記事の目的はPernixData FVPのパフォーマンス計測値をより正確に読み解くためのいくつかのポイントをご紹介することです。

一番上から初める

もっともバーストしている仮想マシンを見つけるためにはFVP クラスタの一番上から初めましょう。｢Performance Map｣をクリックしてください。ヒートマップとよく似ています。仮想マシンのI/Oの活動を色で表すのではなく、この表示ではそれぞれの仮想マシンが指定された時間の間にそれぞれのホストの上でどれだけのI/Oを生成したかということが大きさでわかるようになっています。より活動的な仮想マシンは活動が少ない仮想マシンに比べて大きく表示されるようになります。

ここから、ターゲットとなる仮想マシンをクリックして、どのような活動をしているのかを知ることができますーすなわち、Latency(レイテンシ)、IOPS、Throughput(スループット)など各々の仮想マシン毎に取得している情報に便利にドリルダウンしていけます。

以下のように、vSphereクライアントの左側で仮想マシンを選択した場合にも同じ計測値を表示することができ、もっと大きくそれぞれのグラフを表示することができます。こちらのほうが目に優しいのでこちらのやり方のほうが好きです。

仮想マシン単位の計測値 - IOPSとThroughput(スループット)

仮想マシンのFVPのパフォーマンス統計にドリルダウンすると、標準ではLatency(レイテンシ)のタブが表示されます。レイテンシがどんなに重要かを考えるとこれは理にかなっています。しかし、私はまずIOPSのタブをクリックして、この仮想マシンがどれぐらいのI/Oを生成しているか、リクエストしているかをみることが重要であると思っています。私がまず最初にLatency(レイテンシ)タブを見ないのは、Latency(レイテンシ)の計測値は状況しだいであるからです。大抵の仮想マシンのワークロードはバーストが起こるようなものです、そしてその時にIOPSがほとんどないか、全くないという場合もあります。VMkernelがレイテンシがほんの僅かか、全くI/O活動がないとレポートする場合に、これは正しくないことがあります。ですから、IOPSやThroughput(スループット)タブを最初に見ることで、Latency(レイテンシ)タブに現在の状況を加えるのです。

標準の｢Storage Type｣ブレイクダウン表示はIOPSとThroughput(スループット)を最初に見るのには良い表示方法です。よりシンプルな表示にする場合ために、ボックスをクリックして｢VM Observed｣と｢Datastore｣だけにしてあります。以下に表示します。

事前に定義された｢read/write｣ブレイクダウンもIOPSとThroughput(スループット)タブに置いてReadとWriteの割合を見るために大いに役立ちます。もう少し見てみましょう。

何を見たいか

FVPで高速化された環境のIOPSとThroughput(スループット)を見ている際に、｢VM Observed｣のライン(ブルー)と｢Datastore｣のライン(マゼンダ)の間に大きな隔たりがあるのを目にすることがあるでしょう。以下に表示されているように、隔たりを経て｢VM Observed｣のラインが｢Datastore｣のラインよりも非常に高いところに位置しているというのはFVPがこれらのI/Oを高速化し、レイテンシを下げているという明確な証となります。これを視覚的に認識するのにさほど時間はかかりません。

しかし、この2つのラインにほとんど隔たりがないか、まったく重なってしまっていることもあります。例えば以下の様な場合です。

さぁ、何が起こっているのでしょうか?これはFVPがもはや高速化を行っていないということを意味するのでしょうか?いいえ、まだ動いています。これにはグラフを正しく解釈する必要があります。FVPは高速化層のみです。キャッシュされたReadはホスト上の高速化層から読み出され、｢Datastore｣と｢VM Observed｣の値に大きな隔たりを作ります。FVPがWriteを高速化する場合、書き込みは高速化層に同期してバッファされ、可能な限り早く後ろのデータストアへデステージされます。大抵これは数ミリ秒です。｢VM Observed｣と｢Datastore｣の統計グラフのために計測され、表示されたデータはとても近い時間値となります。｢Breakdown｣を｢read/write｣に切り替えると、IOPSのグラフに置いてこのケースでは、ほとんどReadだったワークロードが、ほとんどWriteのワークロードに切り替わったということを確認できます。シアンの｢Write｣がマゼンダの｢Datastore｣とほぼ一致しているのが確認できます。

上のグラフはワークロードがReadからWriteへ切り替わったことで、パフォーマンスが落ちたというようにも見えます。本当にそうなのでしょうか?｢Throughput(スループット)｣タブを見てみましょう。IOPSのグラフがWriteの場合にはかなりI/O数が少なくなったということを表していますが、それでも以下で確認できるように、このグラフはいずれのワークロードのフェーズでも同じだけのデータを転送しているという事実を表しています。

このような事が起こる場合の原因の大抵はゲスト仮想マシンのOSのファイルシステムのバッファキャッシュによるもので、それによってWriteのI/Oサイズが大きくなってしまうからです。この例では読み込んだデータと書き込んだデータは同じでしたが、IOPS(1秒間に実行されるI/Oコマンド数のこと)のみしか計測していないと誤解が起きてしまいます。I/Oサイズだけがストレージパフォーマンスに良くない影響を及ぼすものではありませんが、この例はI/Oサイズがしばしば変わるものである(リンク先は英文記事)ということを表す良い例で、IOPSの計測だけでは誤解が起きやすいということをよく表しています。

上の例を考えると、業界標準のRead/Writeの割合を使った便利な性能指標や一般的なストレージシステムの評価方法に疑問をいだきませんか?そうなりますよね。

Write Back Destagingタブで、FVPがストレージが許す限りどんどん書き込みをでステージしていくのを見ることができます。以下では、バックエンドのストレージに1秒未満ですべての書き込みが送り込まれています。これは以前の｢VM Observed｣と｢Datastore｣のラインが書き込みをおこなっているタイミングでお互いに非常に近くなっていたグラフと関連しています。

パフォーマンスの改善について確認する際のキーとなるのはLatency(レイテンシ)タブです。以下のイメージでは仮想マシンのレイテンシが非常に低く落ちているのが確認できます。ワークロード全体が予測可能なスループットになっているということです。繰り返しになりますが、計測値が重要です。

これを別の観点から考えると、大抵の場合IOPSとThroughput(スループット)のパフォーマンスチャートはWriteのバッファリングよりも、Readキャッシングについてうまく視覚的な結果を表示できるということができます。理由は :

キャッシュされたReadはバックエンドのデータストアへは到達しませんが、バッファされたWriteはかならずバックエンドのデータストアに到達する
WriteよりもReadは小さなI/Oサイズになりがちで、これによってIOPSタブしか見ていない場合に視覚的に誤解を生みやすい

ですから、究極的な計測はLatency(レイテンシ)をReadとWrite両方図るということになります。

仮想マシンベースの計測 - Latency(レイテンシ)

Latency(レイテンシ)は議論の中で、見ておくべきもっとも重要な計測値の一つです。この値は動作している仮想マシンとその上で動作しているアプリケーションにとって最も影響があるものです。IOPSとThroughput(スループット)で見てきたように、今度はLatency(レイテンシ)タブを見てみましょう。｢Storage type｣のブレイクダウンが最初に表示され、仮想マシンから見た場合のレイテンシとバックエンドのデータストアのレイテンシを表示しています。他の計測値と同様、｢VM Observed｣と｢Datastore｣の間に隔たりがあって綺麗に分離しており、｢VM Observed｣のラインは｢Datastore｣のラインよりも低くなっています。先ほどのイメージではレイテンシが劇的に改善されており、繰り返しになりますが、実際の計測によるものです。同じデータを更に詳細に表示するために｢custom｣のブレイクダウンを選択することができます。以下の様なチェックボックスが表示されます。

さて、仮想マシンのレイテンシを再度見て行きましょう。チャート内のどこかにマウスを当てると面白いことが起こります。ポップアップが表示され、非常に有用な詳細の情報を表示します:

レイテンシがどこで追加されてしまっているか、もしそれがデータストアからであればデータストアのReadなのか、Writeなのか
実効の｢VM Observed｣のレイテンシに貢献しているのは何なのか?

何を見るべき

Latency(レイテンシ)タブで期待される結果は｢VM Observed｣のラインが低く、そして出来る限り一貫していることです。仮想マシンから見たレイテンシが期待するほど低くならないということがしばしば起こります。この理由は数多く考えられるため、別の記事に回すことにしますが、FVPはいくつかのレイテンシの源がどうなっているのかという知見を提供してくれます。先にも述べた｢Custom Breakdown｣へと切り替えることで、これをより明確に見ることができます。この表示は時々起こるレイテンシのスパイクに関連する原因をより良く理解するための効率のよいツールとして利用できます。

Hit & Eviction rate (ヒット率と廃棄率)

ヒット率はデータストアからではなく、高速化層から供給されたReadの割合です。この測定結果が高いというのは嬉しい事ですが、環境がいかにうまく動作しているかということをこれだけで見ることはできません。これは他の計測値と合わせて見る計測値であり、単独で見るべき値ではないのです。この値はReadキャッシュのヒット率のみにフォーカスされており、パーセントの値として提供されます。つまり仮想マシンから2,000 IOPSであっても、2 IOPSであっても同じなのです。

思ったようにこの値が高くならないということがあります。思うようにヒットレートが上がらないという理由には :

大容量のシーケンシャルなWrite。グラフはReadを｢ヒット｣と計測しますが、Writeを｢ヒットミス｣として扱います。
ほとんど、もしくは全くI/O活動をしていない仮想マシンを監視している
ゲスト内のよくわからない活動。例えば、ゲスト内のSQLのバックアップジョブは特定の仮想マシンの必要なキャッシュをすべて追い出してしまいます。これはよく行われる活動です。FVP 2.5の新しい機能であるインテリジェントI/Oプロファイリングでこのようなシナリオにおいてもキャッシュを最適化できるようになりました。この機能について、詳しくはFrank Denneman氏の記事(リンク先は英文、後日翻訳公開予定)をご参照ください。

さぁ、以下の期間に注目してヒット率を見て行きましょう。

うえの注目する期間だけに注目してください。以前のグラフと一緒ですが、注目する期間以外ではほとんどないかもしくは全く活動がありません。

ヒットレートが低いというのは必ずしもワークロードが高速化されていないということではありません。単に、理解に別のデータが必要だということを意味します。ヒット率を見るのに加えて、IOPSやThroughput(スループット)のタブでReadの総量をカスタム表示設定を作成して見るのが良いやり方です:

今度はどれだけのReadが実際に発生しているのかをよく見ることができます、また、そのうちいくつがキャッシュからで、いくつかがバックエンドのデータストアからなのかもわかります。これによってヒット率にすべてを委ねている状態よりも状況がより良く理解できるようになっています。

Eviction Rate(廃棄率)はその時間に廃棄されたブロックの割合を表します。廃棄率が非常に低い場合、FVPは新しく入ってくるほっとデータのために必要に応じて非常にゆるやかにデータを廃棄している状態です。これは高速化層のサイズが通常の動作でのデータを取り回すには十分なサイズであるということの証です。もしこの値が上昇すると、それはホットデータが高速化層内にはないということを意味します。廃棄率は高速化層が十分なサイズであるかということを示すのに良い値です。

状況の重要さとCPUサイクルとの連動

パフォーマンス計測値を見る際には、状況が全てです。パフォーマンス計測値はその状況の上に成り立っていますが、しばしば少し離れてしまうことがあります。言い換えると、人間というものはそれぞれを個別のものとして見たがる傾向にあるのです。先のグラフでIOPSとThroughput(スループット)、Latency(レイテンシ)はそれぞれに関連しあっていることがわかりました。それぞれストレージの負荷に対して部分的に役割を演じているのです。

仮想マシンが高いIOPSとThroughput(スループット)を生成しているということをみるのには良いのですが、誤解を招く可能性もあります。よくある、そして間違った思い込みのひとつは高速なストレージ上に仮想マシンを配置したら、素晴らしいIOPS値で動作し始めるだろうというものです。これは完全に間違いです。決まった時間内にどれだけのI/Oが必要かというのを決めるのはアプリケーション(とそれが乗るOS)です。大きなI/Oを生成するシングルスレッドのアプリケーションは多く知っていますが、マルチスレッドのアプリケーションはそうではありません。ですから、IOPSを追跡するのは得策ではありません。それよりも一貫して低いレイテンシを提供する能力が必要なのです。低いレイテンシはCPUに自由に呼吸をさせることができ、次のI/Oが実行できるようになるまで待つ必要をなくしてくれるのです。

｢自由に呼吸できる｣とはどういう意味でしょう? 実際のワークロードでは、速いストレージと遅いストレージの違いはCPUサイクルがI/Oリクエストを待つことなく処理を実行できるということです。ワークロードは何らかの定義された活動を実施します。そのためには一定のCPUサイクルと一定のストレージのI/Oが必要です。こうしたI/Oがより早く完了できるインフラストラクチャでは、更にリクエスを完了するために多くのCPUサイクルが必要ですが、全体の処理にかかる時間は短くなります。