本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
今回はそんなPete氏の記事翻訳第10弾です。
本記事の原文はUnderstanding block sizes in a virtualized environmentで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
データセンタのミステリーを紐解くことは宇宙を探検することにちょっと似ています。あらゆることを理解できており、すべてがどのようにかみあっているかも理解できていますが、事実に推測が入り混じり理解に苦しむケースも有ります。今回はブロックサイズについてのトピックスです。全てに関連するもので、まさにデータセンタのミステリーのうちの一つと言えるでしょう。ある意味で非常に身近なものですが、とっつきにくいもので、それが何なのかわかりにくく、またその影響も不確かなものです。
この目立つことのない、それでいて、とても重要なストレージのI/O特性ですが、ストレージを設計、最適化、トラブルシュートしようとしている注意深い管理者であっても、時々誤解(完全に見落とされてしまうことはないにしろ)をしています。似たようなトピックスにワーキングセットのサイズがありますが、ブロックサイズは管理者もしくは設計者から可視性と理解を欠いているという点から、心配すらされてこなかった分野です。悲しいことに、神話が一般的な知恵に変わって着ているようでも有ります。つまり、典型的な環境においてどうである、ということだけが取り沙汰され、アプリケーションやストレージシステムの挙動、そしてその環境においてどのように設計、最適化、トラブルシュートするべきかということだけが注目の対象となっているのです。
さぁ、こうした状況の中でブロックがどういうものであるかを理解し、その理解がどれだけ重要か、そしてデータセンタにどのように影響するかを見ていきましょう。
ブロックって何?
必要以上には難しくないレベルでお話をすると、ブロックとは単純なデータのチャンク(塊)です。ストレージI/Oという文脈で言うと、単一のReadもしくはWriteI/O操作を行うためのデータストリームの単位です。ブロックサイズは単一のユニットのペイロードのサイズによって決まります。業界の学術的な定義とこれが一部オーバーラップするため、ブロックとはなんなのか?という点で少し混乱がうまれます。ブロックサイズやクラスタサイズ、ページ、レイテンシなどは一般的な会話の中で普通に利用されていますが、その意味はどのように測定するか、どれが影響するかなど、多岐にわたります。ファイルシステムやストレージメディアの特性やハイパーバイザー、もしくはOSなどの文脈ではこれらの意味は様々に変わり、いつも同じ意味ではなくなってしまうのです。
データセンタの設計や運用を行っている方々に取っての意味はストレージシステムのパフォーマンススペックシート上のそれであったり、人工的なI/O生成器の構成のそれでしょう。ストレージシステムのパフォーマンススペックはアレイに対して特定のブロックサイズ(大抵は4Kかそれ未満)での人工的な負荷をかけ、アレイが最大どれだけのIOPSを提供できたか、というものです。人工的なI/Oの生成では大抵1つのサイズしか指定できません。ですから、ユーザーはブロックサイズがワークロード内で分散していることに気が付かず、また、人工的なI/Oをつかって、自身の環境にとって十分な検証ができているかもわかっていません。実際には多くのアプリケーションはそれぞれ固有のブロックサイズをあらゆる時点で、そしてアクティビティに応じてミックスして生成しているのです。
2013年に私は自分自身の本稼働環境にFVPを導入した際にブロックサイズの影響について記載しました。("IOPSとスループットとレイテンシの相関"の段落を見てください) FVPは私の環境のブロックサイズについて、直接的ではないにしろ、副次的な情報を提供しています。パフォーマンスグラフのサンプリング間隔の谷間とvscsistatコマンドを利用することでこれらのワークロードとそれを動かしている環境について新しい知見が得られました。しかし、そうしたツールがリアルタイムな分析には必要になってしまい、単一の仮想マシン、またはデータセンタ全体の長期でのブロックサイズの傾向の分析には不向きです。もっと簡単な方法が必要でした。
どう影響する?
ブロックサイズについて考える際に有効なのは、ストレージのペイロードが単一ユニットでどのように構成されているかを見ることです。4KBのペイロード、256KBのペイロード、または512KBのペイロードがどのように処理されるのかを見ることで、原理が明らかになります。ブロックとして参照しているので、四角形を使ってキャパシティを表しています。
スループットはIOPSの結果です。そして、ブロックサイズはそれぞれのI/Oで送受信されるデータのサイズです。256KBは4KBのブロックが64回やり取りされた総量というだけではありません。ストレージのスタックがそれだけのスループットをやり取りできるだけの処理を行ったということです。つまりはファブリックの帯域、プロトコル、HBAやスイッチ、ストレージコントローラーの処理のオーバーヘッドを含みます。そして、永続層のメディアに焼き付けも行わないといけないということも忘れないで下さい。
このパフォーマンスは従来の回転するディスクよりもフラッシュにおいてより大きく変動します。Readは比較的フラッシュにとっては簡単ですが、NANDフラッシュに対する書き込みの方法はReadに比べ悪いものになり、特に大きなブロックを利用したWriteは更に悪い結果になります。(フラッシュについての基本的な挙動についての詳細はFrank Dennemanの記事のフラッシュのウェアレベリング、ガーベージコレクション、ライトアンプリフィケーションを参照してください。こちらにも素晴らしいフラッシュについての記事があります。)ラージブロックによるほんの僅かな数のWriteだけで、小さなブロックのI/Oであれば適切なパフォーマンスを生み出すためのフラッシュデバイス上のすべての機構を埋め尽くすだけのアクティビティが生成されてしまうのです。このパフォーマンスの劣化は初めて見ると、みんなビックリしてしまうほどです。
ブロックサイズはどのようなストレージアーキテクチャを利用しているかにかかわらず、ストレージのパフォーマンスに影響を与えます。従来からのSANアーキテクチャ、ハイパーコンバージド環境で利用されている分散ストレージソリューション、事実、問題が残されています。ストレージシステムはワークロードとは関係なく、特定のサイズのブロックサイズに最適化されている可能性があるのです。これはストレージシステムの設計上の想定の結果であり、そのアーキテクチャの限界でも有ります。ストレージソリューションの特定のワークロードのパターンに対処しようとする能力もまた、非常に多岐にわたります。優れたストレージシステムとそうでないシステムの違いはしばしば、ラージブロックのI/Oに対しての能力に帰結することもあります。こうしたことを理解しておくことはあらゆる環境において設計や運用の重要な要素となります。
それを生成するアプリケーション
ブロックサイズに関するトピックスを興味深いものにするのはOS(オペレーティング・システム)やアプリケーション、そしてそれを生成するワークロードです。ブロックサイズはOSやその中で動作しているアプリケーションによって変換されてしまうことが有ります。
多くの人が想像するのとは違い、単一の仮想マシンの任意の時間を切り取ってみたとしても、ブロックサイズは幅広いものがミックスされているのです。そして、刻々と劇的に変化します。こうした変化は仮想マシンとそれが動作しているインフラストラクチャにおけるI/Oに、すぐさま影響を与えます。大体30%ぐらいのブロックは64KBだと知っているぐらいでは十分とはいえません。時系列上でどのようにそれが分布するのかを理解する必要がありますし、様々なブロックサイズにおけるレイテンシや他の属性を相関づけて理解しておかなければなりません。これは将来、このトピックスをさらに掘り下げる際の話題として残しておきましょう。
可視性に関する従来からの手法での限界
従来型の方法でブロックサイズを見ることにはいくつかの制限事項が有りました。その影響の一部しか見ることができませんでした。ーつまり、データセンタ全体か、または単一のワークロードかーです。
1. vscsistatsによるカーネルの詳細な分析 - これはESXiの一部に組み込まれているユーティリティで、ESXiホスト上でコマンドラインで実行します。実行中のブロックサイズについての概要を得ることができますが、いくつかの大変な問題をはらんでいます。
- 一つは特定のVMDKの非常に短い時間の情報以外に利用しようがないことです。リアルタイムに可視化することもできません。基本的には後から可視化を行うツールです。長時間にわたってデータを表示するためのツールでもありません。
- vscsistatは特定の時刻の合計のI/Oを表示するだけで、サンプリング間隔次第です。時間を遡ってみることもできません。それを行うためには複数の結果を出力するスクリプトを書かなくてはなりません。
- 文脈もありません。ワークロード(実際はただのVMDK)だけの情報が得られます。どんなアプリケーションが動いているかなどの文脈は失われ、適切な翻訳を行うこともできません。
- データを視覚的に理解することもできません。これを行うためには可視化を手伝う別のツールの助けが必要です。
- 結果として、多くのデータを見ようとした時、非常に労働集約的な作業が必要となり、ソリューションにはなりえません。管理者がこれをあらゆる仮想マシンで実行し、I/Oの特性を理解するするというようなことはありえません。
2. ストレージ装置 - これはベンダーに固有の｢付加価値｣機能で、ブロックサイズについてのシンプルな概要を表示することが出来るようになっています。しかし、これもまた不完全なソリューションです:
- VM-awareではない。 I/OがサーバホストのHBAを通り抜けた瞬間から殆どのインテリジェンスは失われてしまいます。ストレージ装置はどのブロックがどの仮想マシンに関連付けられているかわからなくなりますし、どうした順番でそれが提供されているかもわからないのです。
- 間違った場所での測定。単にストレージ装置はブロックサイズの影響を最初に測る地点としては誤った場所であるということです。ストレージトラフィックのすべてのキューを通り抜けた後にWriteはストレージにコミットされます。そして、それからReadが取得されます。(ストレージシステムの外側にはキャッシュ層がないと考えています。) 測定についてはこうしたことを全て考慮に入れて行わなくてはなりません。つまりハイパーバイザーで行うべきなのです。不幸なことに、ストレージ装置が素晴らしいパフォーマンスを誇っていたとしても仮想マシンのレイテンシで苦しむということが起こります。適切な場所での測定が重要であるということを教えてくれます。
- 不確かな、または一元的ではない手法での測定。ブロックサイズの情報を表示するのはストレージ装置の本筋の機能ではありません。そして、I/Oが生まれる場所(仮想マシンとそれが動作しているホスト)と同じ方法で取得する必要もありません。とすると、どのように測定するのか、どれぐらいの頻度なのかは普通に考えて重要ではありません。そして公開されることもありません。
- ストレージ装置に依存している。環境内でもしも別のタイプのストレージが利用されているのであれば、これは全てのワークロードが適切にカバーされているとは言いがたい事態です。
ハイパーバイザーはデータの分析には理想的なコントロールプレーンです。ゲストOS内の測定値やストレージソリューションの機能とは完全に独立した結果を見ることができます。これを受け継ぐことで、環境における理想的なデータセンタの包括的な理解を行うことが出来るのです。
完全に目をつぶってしまった状態 ー 最初からストレージの設計を誤っている
多くの設計に関する事項にひびが入っているとおもっています。我々の考えを示しましょう。まずストレージ設計の際に必要なことを考えてみましょう。大抵は以下の様な要素です。
殆どの環境の設計や管理を行っている人はこうした訓練を様々で受けていると思います。ちょっとした数学を使って、ディスクの配合やRAIDレベル、そしてファブリックで必要なパフォーマンスに対応できるかどうかなどを示すことができます。そうなった際には必要な公式を利用できますが、そうでない場合にはそれは想定に満ちています。さて、ブロックサイズ、これは全てに影響しますが、どこにも書かれていません。どうして?見えないし、理解し難いものだからです。ストレージシステムにとってブロックサイズが劇的なパフォーマンスの影響をもたらすものだと知ったとしたら(今後も記事を投稿していきます)、設計や最適化や、トラブルシューティングの訓練に組み入れなくてもいいものでしょうか?もちろん、組み入れるべきです。ワーキングセットのサイズと同じです。見えないからといって、考慮しないわけにはいかないのです。インフラストラクチャはサービスやアプリケーションを動作させるために存在しているのです。そうしたアプリケーションとワークロードが教えてくれる、どうしたタイプのストレージがあなたの環境に最もあうかという声を聞いて、助けましょう。それ以外の道はありません。
もっといい方法は?
あります。もっといい方法。PernixData Architectはデータセンタ全体に渡るこれまでにはない可視性とブロックサイズの分析を提供します。乞うご期待、我々はArchitectがブロックサイズによる環境への影響をもっとはっきりと見せていくようにします。
