本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
今回はそんなPete氏の記事翻訳第13弾です。
本記事の原文はKnow Your Virtual Workloads: Block Size and Workload Shiftで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
データセンタを適切に設計し、最適化するためには様々なワークロードの特性そのもの、そしてそれが時とともにどのように変わっていくのか、それによってアプリケーションの性能はどんな影響を受けるのかということを理解しておくことが重要です。私は6つの仮想化ワークロードについて知っておくべきことを突き止めることが出来ました。
最近の私の記事で、私はデータセンタにおいて見落とされがちな2つの仮想マシンの特性についてのべてきました。ReadとWriteがそれぞれ仮想マシンに異なった影響を及ぼすということと、アクセスパターンが異なればパフォーマンスへの影響を大きく異なるという2つの特徴です。これらを誤って認識したり、適切に計測ができないことになれば、アプリケーションのパフォーマンスへ多大なる影響を及ぼし、結果としてITコストが高く付くことになります。
今回の記事では前回同様に重要な2つの特性についてご紹介していきます : ブロックサイズとワークロードです。
#3 ブロックサイズが重要
仮想マシンのパフォーマンスの問題を特定し、解決するという冒険の中で、管理者は大抵CPU、メモリ、そしてストレージにまつわる計測値を利用します。しかし、仮想化インフラストラクチャ内のデータを得ることは難しいことも多々有ります。ブロックサイズはストレージのパフォーマンスに劇的な影響を与えることのある計測値の代表格ですが、アプリケーション、OS、そしてワークロードによって劇的に異なったものになります。しかも、一般的な管理システムでは殆どの場合、見えない値なのです。これが見えないことに起因して、ブロックサイズは仮想化、ネットワーク、ストレージの管理者のような方々に誤解されたり、見落とされたりしてしまうのです。
ストレージI/Oという文脈では、ブロックはデータの流れの中で転送される単なるデータの集まりの単位ということに過ぎません。ブロックの｢サイズ｣はReadであれWriteであれ、単一の転送サイズを表しているだけなのです。スループットは毎秒行われるI/O(IOPS)とそれぞれの送受信されたI/Oの結果を表します。アプリケーション、そして、それが動作しているオペレーティングシステムはアプリケーションとそれにまつわるワークロードの特性によって幅広く、そして常に変わり続ける混在したブロックサイズを生成します。ReadとWriteでブロックサイズが異なることさえ日常的です。
ブロックサイズはストレージシステムに異なる影響を及ぼすので、この計測値を見ておくことは非常に重要です。例えば、256Kのブロックは4Kのブロックよりも64倍も転送量が大きいですし、それによってストレージスタックの全てのコンポーネントがI/Oリクエストを完了するためにより多くのリソースを利用します。ストレージファブリック、プロトコル、HBAでの処理のオーバーヘッド、スイッチ、ストレージコントローラー、そしてストレージで利用されているメディアなど全てが影響を受けることになります。データセンタにおいてフラッシュを利用する際には、これまで以上にブロックサイズを確認しておくことが重要になります。これはフラッシュが大きなブロックサイズを通常上手く処理が出来ないからに他なりません。
vCenterのような従来型のハイパーバイザーの管理ツールでは、こうしたデータを確認することはできません。もちろん、vCenterの統計情報を利用する監視ツールも同様です。ストレージ装置は限定的なブロックサイズのデータを表示することも出来ますが、情報は非常に荒いもので、利用用途が限られます。ストレージの設計、最適化、そしてトラブルシュートの真に規範的なアプローチとしてはデータセンタ全体に渡るブロックサイズを適切に見なければなりません。しかも、個々のワークロードの状態を適切に理解出来るだけのきめ細やかさが必要です。
#4: ワークロードは常に変化する
パフォーマンスに関連する計測値はどのようにワークロードが振る舞うのかがわかるレベルで見なければなりません。管理者に提供されるデータの品質はそれをどのように計測したかだけでなく、どのぐらいの頻度でそれを計測したかも重要です。そもそも非常に動的で、バーストを起こすようなシステムにおいて、どの計測値が重要なのかということを考える場合、どのぐらいの頻度でデータをサンプリングしたのかが最も重要になります。
ストレージのI/Oレイテンシを例に取ってみましょう。小さいながらも何度もレイテンシがスパイクするような状態はインフラストラクチャ上の全ての仮想マシンに影響を及ぼします。既存のソリューションを利用している場合、ポーリングのインターバルが長いせいで、こうしたスパイクを適切に拾いきれていないということもありえます。さらに悪いことに、こうしたソリューションが時間軸上のデータを結合して平均してしまうことで、折角の情報を全く意味のないものにしてしまうこともあるのです。
こうした問題はレイテンシを分析するときに限った話ではありません。単一のワークロードや、環境全体のピークのIOPSを調べてみようと思ったことがある方も多いと思います。もし、ソリューションがデータを5分か、10分に一度しかサンプリングしていないとすると、このピークが本当にストレージシステムにとってのピークになっていると確定することが出来るのでしょうか?データセンタインフラストラクチャでは、ミリ秒の単位で物が動いているのです。
ワークロードはアプリケーションが何をさせられているかによって常に変わり続けます。Readリクエスト数とWriteリクエスト数、アクセスパターン、ブロックサイズの分布、データアクセス頻度は多くの変化し続ける値の中のほんの一部です。こうした値の全てが仮想マシンの要求を環境がどの程度満たせているのかという指標となります。理想的なソリューションは、管理者がこうした計測値を仮想マシンのパフォーマンスと、それ以外の環境上の仮想マシンにどのような影響を及ぼしているのかを適切に見ることが出来るようなものです。
次回、本シリーズの最終回では、環境において適切なパフォーマンスを提供するために重要なのに、見落とされがちなさらに2つの特性について取り上げていきます。乞うご期待!
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
