本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
今回はそんなPete氏の記事翻訳第12弾です。
本記事の原文はKnow Your Virtual Workloads: Reads/Writes and Access Patternsで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
いいことに、この10年ぐらい、情報システム部は主にアップタイムを最大化するということに重きをおいてきました。ハードウェアの障害やソフトウェアのエラーに対して充分な耐性を持つようなインフラストラクチャをつくり上げるということです。計画的なメンテナンスは時々ある記念事業のようなものでした。しかし、仮想化やアプリケーションの耐障害性の改善によって、堅牢なインフラストラクチャをつくり上げるということは今日では比較的に簡単になってきています。結果として情報システム部の仕事はその代わりに最適化へとシフトしてきています。作り上げたインフラストラクチャを高速で、運用効率よく、またコスト効率もよくするためにはどうしたらよいでしょうか?
データセンタインフラストラクチャは変化のないものの集合に過ぎません。アプリケーションとワークロードが命を吹き込み、こうしたワークロードがどのように上手く動くか、ということを決めるのです。残念なことにこうしたワークロードは想像通りに動くということはありえません。設計通りにはいかないのです。全てのデータセンタで、様々なワークロードが混在し、どのようなアーキテクチャを採用しているかにかかわらず、インフラストラクチャへと影響を与えます。新しいワークロードを動作させ始めることは近年のデータセンタにおいては全く問題になりません。しかし、ここに問題が有ります。新しいワークロードはデータセンタ、そして既存のワークロードにどのような影響をあたえるのか、ということを予測することは難しいのです。
データセンタを適切に設計するためには、様々なワークロードの特性、そして、それがどのように変化していくのか、それがどのようにアプリケーションのパフォーマンスに影響をおよぼすのかを理解しておく必要があります。このブログはこの問題の解決を手助けするシリーズの最初の記事になり、仮想化されたワークロードについて知っておくべき最初の6つのことをお伝えしていきます。これらを理解することで、アプリケーションのパフォーマンスをコスト効率よく最適化しながら、仮想化データセンタのサービスも効率化することが出来るのです。
#1 ReadとWriteは振る舞いが異なる
殆どの人は仮想化データセンタ、特にストレージインフラストラクチャにおいては、ReadとWriteの振る舞いが異なっていることに気がついているでしょう。ですが、この詳細な振る舞いについてはしばしば見落とされています。それどころか、多くの会社はこれらの違いを計測する適切なツールすら持ち合わせていないという状態です。適切に計測ができなければ影響を考慮することも出来ないのです。逆もまた、しかりです。ストレージはフラッシュに向かって動いていますが、Read/Writeの振る舞いはこれまで以上に重要になってきます。
共有ストレージシステムにおいて、WriteはReadよりも難しい処理です。これはストレージシステムがデータ保護のために追加のアクティビティを実施しないといけないためです。｢ペナルティ｣がデータ保護の追加アクティビティという形でチャージされるのです。RAID 1ストライプを例に取ると、Writeが仮想マシンから発行される度に2回のI/Oが発生します。RAID 5では4つのI/O、RAID 6では6つのI/Oが発生します。これはストレージのパフォーマンスに大きな影響を与えます。しかし、違いはこれだけではありません。
ゲストオペレーティングシステムではしばしば仮想マシン内でバッファキャッシュを利用するファイルシステムを利用しているケースが有ります。これによってWriteを発行する際に大きなブロックサイズが生成される場合があります。ブロックサイズが大きいということはWriteデータではReadのI/Oよりもより多くのデータが取り扱われるということになります。これはインフラストラクチャ全体にわたって影響を与えることがあるということになります。特にこれはフラッシュストレージにおいては重要です。Readはフラッシュにとって比較的扱いやすいものですが、大きなI/OサイズでのWriteは殆どの場合に見てわかるほどのパフォーマンスの劣化を伴うからです。--これはディスクベースのストレージよりも更に悪いということもありえます。ストレージの要件に基づいて新しい高速なメディアへ移行した人にとってはこれは大きな驚きでしょう。
Read/Writeの振る舞いについて必要なだけの情報を把握するにはどうしたら良いのでしょうか?残念なことに既存のツールはこうした点をカバーできていません。理由は以下のとおりです :
- 既存のツールはRead/Writeの割合を計算する際に、Readコマンドの発行数とWriteコマンドの発行数を数えています。しかし、上で述べたように、Write I/OはReadのI/Oよりもおおきくなることがしばしばです。ですから、Read/Writeの割合が50/50であるということは現実には正しくなく、実際に転送されているデータは30/70であったり、20/80であったりするのです。Read/Writeの振る舞いを見ていると、実際のデータ量の観点からは大きく異なってしまうのです。
- 割合はもちろん知っておいて損はないものですが、これはパーセンテージの形で一定の期間をまとめたものです。本来知っておかなくてはならないものは時系列でのReadとWriteの分布であり、そして、その(Read操作とWrite操作の)ワークロードに紐付いた絶対数です。これはパフォーマンスの問題を理解するためには必須の項目です。
よく出来る管理者足るためには、Read/Writeの割合を把握しておくだけでなく、個々の仮想マシンと、そしてデータセンタ全体でこうしたReadとWriteがどのように分布して発生しているのかを知っておかなければなりません。これはRead/Writeのデータを単にI/Oのコマンドとしてだけでなく、どれだけの転送量が実際に行われているか、そしてそれぞれのアクティビティのレイテンシはどの程度なのかということも含まれます。
#2: アクセスパターンはパフォーマンスにも影響する
ワークロードのストレージへのアクセスパターンは仮想マシンの振る舞いや、それによって構成されるサービスの振る舞いに影響を与えるだけでなく、そのインフラストラクチャで動作している他のすべてのワークロードにも影響を与えます。これは｢ノイジーネイバー(やかましいご近所さん)｣効果で、上手く動作している環境内の他の仮想マシンに悪影響をおよぼすのです。
すでにReadとWriteがストレージインフラストラクチャに対して異なる影響をおよぼすことは述べてきましたが、それらが織りなすアクセスのパターンも同様に重要です。シーケンシャルアクセスとランダムアクセスパターンはストレージインフラストラクチャに大きく影響を与えるI/Oです。これらの特性はこれまでは回転するディスクの機械的なレイテンシにのみひも付けがなされてきました。しかし、これはフラッシュにも同様に言えることなのです。環境内に単一のシーケンシャルなワークロードだけがある場合、劇的に混雑が発生し、あっという間にうめつくされ、他のワークロードのためのキャッシュの廃棄が発生します。シーケンシャルワークロードは大抵は大きなブロックサイズで利用されるため、ストレージインフラストラクチャのパフォーマンスに異常をきたすのです。
環境におけるアクセスパターンを理解せず、そして、それに順応することがなければ、パフォーマンスは貧弱なものとなり、環境内で一様なパフォーマンスを得ることが出来ません。これはどのようなストレージアーキテクチャを利用していたとしても言えることです。従来型のSANインフラストラクチャ、もしくはハイパーコンバージド環境で利用される分散ストレージソリューションであっても、問題は残されているのです。
本シリーズの次の投稿をお待ち下さい、そこでは皆さんが見落としがちな仮想マシンの特性についてお話しようと思います。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
