本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
今回はそんなPete氏の記事翻訳第11弾です。
本記事の原文はViewing the impact of block sizes with PernixData Architectで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
仮想化環境のブロックサイズについて理解する という記事で、ブロックサイズがどういったものであるか、そして、それがストレージI/Oにどのように影響するのかということ、そして、どうしてそれが仮想環境において、最も見落とされがちな計測値の一つになりがちなのかということを述べました。その重要性を理解するための最初のステップはデータセンタ全体にわたってそれを可視化出来るようにした上で、それぞれのワークロードに対して十分なきめ細やかさも兼ね備えておくことです。しかし、ブロックサイズのような計測値を可視化する際にはそれだけでは十分とはいえません。データ自身を正しく理解できなければ、データ全く意味が無いものになってしまいます。データは以下の要件を満たす必要があります:
- 簡単にアクセスできる
- 簡単に意味が理解できる
- 正確である
- 他の関連する計測値とどのように相関するかを理解しやすい
今後の記事で特定のシナリオにおいて、こうした情報をどのように利用し、環境をアプリケーションのパフォーマンスのためにチューニングしていくのが良いのかという点においては追求していきます。さぁ、まずはPernixData Architectが基本的な、つまり、一般的なRead/Writeアクティビティに於いて、どのようにブロックサイズについて可視化するのかを見ていきましょう。
サマリビューにおけるブロックサイズの頻度
特定の仮想マシンの"Overview(概要)"ビューをArchitectで表示すると、I/Oサイズの頻度(IO Frequency)を小さなブロックから大きなブロックに渡るまで、任意の時間の間隔での分布を表示することが可能です。このI/Oの頻度はメインのサマリページでクラスタ全体を表示した時にも表示されます。以下のイメージは単独の仮想マシンにフォーカスした際のものです。
上の図で最も興味深い点はReadとWriteでブロックサイズの頻度が異なっているということです。これは一般的なことではあるものの、このようにデータを簡単に見ることができないため、殆どの場合、気づかれることなく放置されている特性です。
"Workload"を利用したブロックサイズ表示
Architectの"Workload"ビューはワークロード単独、ワークロードのグループ、もしくはvSphereクラスタ全体で発生するブロックサイズの分布をパーセンテージによって表示します。表示するタイムフレームはお望みのとおりに変えられます。この表示では特定の仮想マシンの複雑で、ユニーク、かつ動的なブロックサイズの分布を他のビューより明らかに、そして高速に表示してくれます。以下の例は単独のワークロードの15分間の例です。Read/Writeの割合や、CPU利用率などの他のメトリックと同様、こうした変動が起こる度にそれを理解しておくことは非常に重要です。単に積み重なっていくだけのものや、長い間で同じものでは無いからです。
実際の環境において"Workload"ビューを見てみると、人工的なI/O生成器の限界に瞬時に気付かされることになります。こうした人工的なワークロードは環境における複雑なブロックサイズの分布をエミュレーションすることはできず、その目的は非常に限られてしまうということです。"Workload"ビューはワークロードが非常に劇的で、常に変わり続けているということも表示してくれます。結果として1度きりのストレージアセスメントでは不十分だという事にもなります。CPUやメモリのリソースについてはこうした疑問を誰も持ちませんが、どうしてストレージについてはこうした制限を自分自身でかけてしまうのでしょうか?
"Workload"ビューはあくまで分布をパーセンテージで表示するということは気に留めておいてください。パーセンテージベースの表示であるということは全体からの相対的な割合を表示してくれるということです。こうしたパーセンテージの背後にある絶対的な値を表示しているわけではありません。その分布が50IOPSの時もあれば、5,000IOPSであることも有ります。しかしながら、こうした表示はワークロードや環境全体が短い時間で、または長い間隔のトレンドとして刻々と移り変わっているということを示すためには非常に有効です。
IOPSとThroughputビューにおけるブロックサイズ
この仮想マシンをまず、IOPSの標準の"Read/Write"ブレイクダウンで見てみましょう。以下のイメージは一定のReadが行われたあと、殆どWriteに移り変わっているということを示しています。上の"Workload"ビューを見返してみると、これらのI/Oがどのようなブロックサイズ分布になっているかを推定することが可能です。
このIOPSビューのまま、事前に定義されている"Block Size"のブレイクダウンを選ぶことで、ブロックサイズごとにどれだけのIOが発生しているかの絶対数を見ることが可能です。以下のイメージは"Workload"ビューとはことなり、実際のI/Oをブロックサイズごとに表示しています。
しかし、これは全体のうち一部しか言い表していません。単一のブロックサイズは単独のI/Oの属性に過ぎません。ですから、IOPSビューでは4Kブロックの10 IOPSは256Kの10 IOPSと全く同じに見えます。実際には64倍ものデータが流れているのです。｢転送されたデータ総量(Payload Amount Transmitted)｣という観点でこれを見ていくためには以下のように"Throughput"ビューを"Block Size"ブレイクダウンで見ていく必要があります。
上のようにブロックサイズをその転送量(Payload)のサイズ(Throughput)で見ていけば、その時点において大きなブロックサイズが支配的であるということをより良く表示することが可能ですし、比較的小さな転送量(Payload)は小さなブロックサイズによってなされていることがわかります。
もう一つ、Architectによってデータを可視化する方法をお伝えしましょう。"Performance Grid"ビューをクリックして、特定のブロックサイズのIOPSとThroughputを見ることが出来るように変更しましょう。以下のイメージが表示しているとおり、上の行は4K~8KのIOPSとThroughputを表示しており、同時に下の行では256K以上のIOPSとThroughputを表示しています。
上の図が示しているのは4K~8KのブロックサイズのIOPS数のピークも256K以上のブロックサイズのIOPSのピーク値もほとんど同じであるにもかかわらず、転送量は大きく異なっているということです。
なぜこれが問題なのか?
PernixData Architectがなぜこれらを取り上げているのかお伝えしていきましょう。同じ時間の間隔の中で、仮想マシンの実効レイテンシーを見ていきます。以下のイメージから、仮想マシンの実効レイテンシーがWriteが支配的に変わったタイミングから明らかに大きくなっています。(Read/Writeのチェックはあえて見やすさのために外しています)
以下のイメージをさらに見てください。こちらでは"Block Size"のブレイクダウンを利用して、ブロックサイズごとのレイテンシを表示しています。
見ていただいたとおり、大きなサイズのブロックほどレイテンシが大きくなっています。こうした柔軟なビューのおかげで、レイテンシを贔屓目なく見ることができ、そのレイテンシがどこに足を引っ張られているのかを見ることができます。さぁ、もっと歩みを進めましょう。Architectでは"Block Size"のブレイクダウンが事前定義されており、ReadとWriteのブロックサイズごとの特性ーレイテンシー、IOPS、スループットーを表示することが出来るようになっています。さらに、カスタムブレイクダウンを利用して、ブロックサイズだけではなく、以下のイメージのようにReadとWriteに特化して見ることも可能です。
上で表示されているレイテンシーの"Custom"ブレイクダウンではそれぞれのブロックサイズのすべてのReadとWriteの値を表示することができますが、単純化して見やすくするために幾つかのものはチェックを外しています。このビューから64Kか、それよりも大きなWriteによって殆どのレイテンシが生じているということを確認できます。こうすると仮想マシンで生じているレイテンシが、大きなサイズのブロックのWriteによって引き起こされているということを明確に見て取ることが可能です。ただし、その影響についてはただブロックサイズが大きいIOだけがレイテンシが高いというだけではありません。こうしたラージブロックのレイテンシは小さなブロックのI/Oにも影響を及ぼします。これについてはそれにフォーカスした情報をいつか投稿したいと思います。
以下のイメージにある通り、Architectは特定のポイントにマウスを当ててクリックすることでドリルダウンしてさらなる知見を表示することが可能です。これは仮想マシンごとにも、クラスタ全体においても行うことが可能です。マウスをそれぞれのブロックサイズを表している棒グラフの上に置くことでどれだけのIOが発行され、それぞれがどのようなレイテンシになっていたかを見ることが可能です。
フラッシュで解決?
ブロックサイズがアプリケーションのレイテンシに影響をおよぼすことは明らかです。フラッシュで解決?そうでしょうか? 実際にはそうとは限りません。上で上げてきた全ての例では仮想マシンはフラッシュ上で動作させています。フラッシュと、ストレージソリューションがどのように実装されているかによって、これは非常に興味深く、そして仮想マシンに対して非常に大きなパフォーマンスへの影響を及ぼすことになります。ストレージのメディアはストレージインフラストラクチャにおいては単なる一つのコンポーネントに過ぎません。これらのコンポーネントとそれらが引き起こすパフォーマンスへの影響は従来型の三層構造のアーキテクチャであれ、ハイパーコンバージド環境のような分散ストレージ環境であれ、変わることなく存在します。
パフォーマンスマトリックス内でのブロックサイズ
Architectに固有の表示としてパフォーマンスマトリックス(Performance Matrix)があります。それが表示するもののユニークさとどのように使うかをお伝えしていきます。利用しているストレージソリューションは製造社によってある一定の想定のもとに最適化されていますが、その想定はご自身のワークロードには合わないかもしれません。大抵の場合、それを知るすべはありません。しかし、いかに示すとおり、Architectを利用してどのようなワークロード特性をストレージ装置が苦手としているのかを知ることが可能です。
パフォーマンスマトリックスは(上で上げたとおり)仮想マシンごと、もしくはグループやクラスタの集計として表示することが可能です。どのサイズのブロックサイズ以上で、ストレージインフラストラクチャが悲鳴を上げ始めるかの閾値をみるためには非常に良い表示です。これはストレージ装置側が提供する統計情報とは大きく異なったものです。というのもArchitectは完全にエンドツーエンドでこうしたメトリックを理解する方法を提供し、さらにそれを非常にきめ細やかに行うからです。ストレージ装置はこうしたデータについて正確に理解し、計測するという点では正しい場所ではないのです。
まとめ
ブロックサイズは仮想マシンのパフォーマンスに対して非常に大きな影響をもたらしますし、コンピューティングや他のストレージの計測値と合わせて最重要な項目として取り扱われるべきものです。これを全く無視してしまうのは非常に大きな問題であり、ベンダーが｢我々のソリューションは高速です、信じてください｣という言葉もまたしかりです。Architectはブロックサイズについて、これまでには実現できなかった可視性を実現し、これに答えてくれます。これを活用して、あなたの環境にとってこれがどういう意味を持つのかということをしっかり見定めてください。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
