本ブログエントリーはPernixData社のSystems EngineerであるPete Koehler氏のブログの翻訳版です。彼はもともとPernixData社の製品の1号ユーザーで、ブログでユーザーとして素晴らしい記事を幾つも投稿してくださっています。本年からPernixData社の社員になったそうで、記事を翻訳してもよいか確認したところ、すぐに快諾してくれました。
今回はそんなPete氏の記事翻訳第9弾です。
本記事の原文はWorking set sizes in the Data Centerで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
データセンタのミステリーは尽きることはありません。正体不明の彼らはパフォーマンスや環境の一貫性を阻害したりする一方で、切り分けや定量化、コントロールを難しくします。仮想化はこれらの情報のうちの幾つかを取り出す手助けとなりますが、それは理想的な可視化コントロールプレーンがあればの話です。実際にはそうではありませんし、正体不明の彼らを監督していくために必要で適切なすべての情報が提供されているわけではありません。ハイパーバイザーも誤解を生みやすい形でしか、データを表示していないのです。
今日の仮想化されたデータセンタに登場するミステリーの一つが｢ワーキングセット｣と呼ばれるものです。これは歴史的にはコンピューターサイエンスの領域で呼ばれていたものですが、実際にはデータセンタのコンポーネント～特にストレージ～を含んで利用される様な言葉になってきました。多くの場合、その定義すら難しいものです。それではこのワーキングセットがデータセンタに与える影響について見ていきながら、更にどのように計測するのかをお話していきましょう。
我々は我々が知っていることや、コントロール可能なものだけにフォーカスしがちです。しかし、データセンタの影響要素を十分に可視化しないままでは本当に必要なものにフォーカスがあたらないのです。残念なことに、ワーキングセットは通常そういう扱いを受けています。まったく予測できないものですから、データセンタ設計の講習にも含められていないということもしばしばです。同じ理由から殆どの文献にも含められていません。皮肉なことに、あらゆる最近のアーキテクチャの案件では、パフォーマンスの向上のためにデータの最適配置の問題に取り組まなくてはなりません。キャッシュされたコンテンツとそれを永続的に格納する場所の話題です。どれぐらいのサイズが必要なのでしょうか?どのぐらいの頻度でアクセスが起こるのでしょうか?こうしたあらゆる疑問に対する答えを知っておくことが非常に重要なのです。
ワーキングセットとは?
定義としては、ワーキングセットとは一定の時間内に処理されるデータのサイズの総計を意味します。これがホットだということは、永続ストレージのキャパシティの中において、頻繁にアクセスされているデータであるということになります。ですが、こうした簡単な説明は分かりやすい一方で、しっかりとした質と量での説明にはなりません。直近でとはどういう意味なのか?総計はRead, Writeもしくはその双方なのか?そして、何度も同じデータが書き込まれた場合はどう考えればいいのか?新しいデータの場合はどうなのか? さぁ、もっと掘り下げてみましょう。
以下のワーキングセットの特徴を抑えておけば、充分です。
- ワーキングセットはワークロードによって稼働し、ワークロードはアプリケーションによって稼働し、そのアプリケーションは仮想マシンで稼働します。永続ストレージがDAS、共有ストレージ、または分散ストレージであったとしても、それは仮想マシンからどう見えるかには影響しません。殆どの場合、そのサイズは同じです。
- ワーキングセットは常に一定の期間にで計測されます。しかし、連続的なものです。データのアクティビティについてはサイクルがあり、何度も繰り返されます。
- ワーキングセットはReadとWriteを含みます。それぞれの総計を知ることが重要で、それはReadとWriteは異なる特性を持ち、ストレージシステムへの要件も異なっているからです。
- ワーキングセットのサイズは総計やキャパシティと関連します、しかし、どれだけの数のI/Oによってそのキャパシティが出来上がっているかはブロックサイズによって様々です。
- データアクセスのタイプによっても異なってきます。1つのブロックに対して1000回のReadを発行するのか、1000のブロックを1回Readするのか?既存のデータを大抵の場合上書きしてしまうWriteなのか、新しいデータなのか? これによってワークロードはユニーク担っていくのです。
- ワーキングセットのサイズはワークロードやデータセンタの変更によって大きくなり、変わっていきます。他のあらゆるものと同じく留まっているものではないのです。
簡単にするために、ワーキングセットを視覚的に表してみました。以下の様なものになります。
もし、ワーキングセットが常に一定の期間によって決まるのであればどうやってそれを定義できるのでしょうか?実際には出来るのです。ワークロードというものは活動の後に、休眠の期間を持つものだからです。これは｢負荷サイクル(duty cycle)｣と言われることもあります。負荷サイクルは1日のメールボックスサーバや、1時間のSQLサーバのバッチ処理の負荷、30分のコードのコンパイルのようにパターンを示すようになります。長い時間の間隔で見ると仮想マシンの負荷サイクルは以下の様なものになります。
ワーキングセットを定義するためには時間を長くとってみることが重要です。しかし、本来の目的はワーキングセットを最短時間で見つけ出すことです。つまり、1つかもういくつかの負荷サイクルでそれを見つけ出すことなのです。
なぜそれが重要なのか?
ワーキングセットのサイズを理解することで、ワークロードの振る舞いを理解することができ、環境の設計、運用そして最適化を行うことが出来るようになります。全く同じ理由でコンピューティングやメモリの要求にすでに目を配っていると思いますが、ワーキングセットを含むストレージ特性についてもそれを知っておくべきなのです。ワーキングセットを理解し、正しく計算することでデータセンタの深淵でどんなことが起こっているかを理解できるのです。実際にワークロードのパフォーマンスが貧相であったり、階層化ストレージやハイブリッドストレージやハイパーコンバージド環境でパフォーマンスの不均一が起きたりということを聞いたことがありませんか?これらはキャッシュレイヤのサイズが不十分にしかサイジングされていなかったことによって引き起こされているのです。実環境のワークロードの正しくないワーキングセットのサイズの計算ミスはこうした問題を引き起こすのです。
従来のやり方での計算方法
何年もの間、このワーキングセットのサイズにまつわるミステリーは計算をしようとした悲しい試みの結果生み出されてきました。以下のような試みです:
- わかっている(けれどもさほど役には立たない)要素を用いての計算。大抵の場合、一定時間のIOPSを確認するというものです。もう幾つか要素を加えて綺麗に着飾ってみたものもあるかもしれません。これはひどいものです。ワークロードは全て同じブロックサイズを生成していると仮定してしまっていますし、ワークロードが常に一定であるとも仮定してしまっています。その上、すべてのReadとWriteが同じブロックサイズであると仮定してしまっているので、これも誤りです。
- ストレージのキャッシュレイヤとしてワーキングセットをストレージ側で図るという試み。この試みも場所を間違っているという点で失敗してしまうことがあります。どのブロックのデータがよくアクセスされているかということはわかるかもしれませんが、仮想マシンやワークロードからくる要求を理解しないままになっています。データに対するインテリジェンスの殆どはvSphereホストのHBAを抜けた瞬間に失われてしまいます。仮想マシンに対する情報の不足しているとノイジーネイバーな仮想マシンからによるキャッシュの汚染などの際には適切なストレージ上のキャッシュサイズの測定は行えなくなってしまいます。
- 変更差分バックアップを取って、変更差分の総計を見るというやり方。これはロジカルに見えますが、誤解をはらんでいます。というのも、何度も何度も上書きでWriteされたデータを合計したものではなく、Readも勘定に入っていません。変更差分バックアップもワークロードのサイクルを表したものではないのです。
- 推測。ストレージのキャパシティのうち、一定の割合がホットなデータであるという｢推奨｣を目にすることがあると思います。これは最もよく目にするものですが、これはほとんど不可能です。十分に大きければよいですが、足りなかった場合技術的にも金銭的にも大きな爪痕を残します。
お分かりのとおり、こうした古い戦略は上手くいっていませんし、管理者に対して本当の回答をせずに逃げ回っているに過ぎません。データセンタのアーキテクトはこうした要素までもを環境の設計や最適化に組み入れて上を目指していかなくてはならないのです。
PernixData Architectとワーキングセット
ハイパーバイザーは多くのものを計測するにはうってつけのコントロールプレーンです。ストレージのI/Oレイテンシを例に取ってみましょう。ストレージ装置からのレイテンシは気にする必要はありません、仮想マシンが実際に見ているものが重要です。でしたら、ハイバーバイザーカーネルの機能を拡張して、仮想マシンごとのワーキングセットのデータについての知見を得てはどうでしょうか?これがまさにPernixData Architectが提供するものです。ブロックサイズなどの以前ではまるで不可能だったストレージ特性を理解し、表示しながら、Architectは仮想マシン毎のワーキングセットの計算に不可欠なキー要素をも理解していくのです。
PernixData ArchitectはvSphereクラスタ内の個々の仮想マシンごとにワーキングセットを見積ります。仮想マシンごとの見積もり以外に、ホスト単位での見積もりも可能です。以下の例はそれぞれのブレイクダウンを表示しています。
そして、以下はホスト毎の見積もりです。
この見積りがユニークなのはReadとWriteの両方をその要素としていることです。なぜそれが重要なのでしょうか?ReadとWriteはインフラストラクチャに異なる要求をかけるということがわかっています。ですから、片方の数字だけではまさに片手落ちになってしまうのです。
PernixData ArchitectはFVPとは異なる単独のプロダクトです。しかし、FVPの利用者がArchitectも利用している場合にはFVPがハンドルしているキャッシュのコンテンツとその解析によって特別な、どれだけのフラッシュかRAMがそれぞれのホストに搭載されているのが最適なのかという計算結果も利用することができます。この結果はホストごとの推奨値として表示され、最大限の場合と最低限の場合とが表示されます。
このデータで何が出来るのか?
ワークロードのワーキングセットのサイズを知ることができれば、より良い環境設計と最適化についての多くの扉が開くことになります。以下はその一例です。
- 永続ストレージの最高パフォーマンスレイヤを適切なサイズで購入することが出来る
- PernixData FVPのようなサーバサイド高速化製品を利用している場合、ホストごとに適切なフラッシュやRAMのサイズを設定でき、できうる限りのI/Oをストレージ装置からオフロード出来る
- もし、別のデータセンタへデータをレプリケーションしようとしているのであればワーキングセットの見積もりのWriteのゲージを見ることでどれだけの帯域が2つのサイト間で必要なのかを知ることが出来る
- 既存のハイパーコンバージド環境にどれだけのキャッシュレイヤが必要かを知ることが出来る
- チャージバック/ショーバック 環境において誰がヘビーユーザーを知るというもう一つの方法になります。そしてチャージバック/ショーバックの配賦において非常に上手く動作します。
まとめ
環境のワーキングセットのサイズを知ることは環境の運用において何よりも重要な要素となりますが、これまで非常に難しいものでした。ArchitectはvCenterやvCenterから情報を得る他の従来からの監視システムでは不可能だった知見や解析を提供します。ワーキングセットのサイジングはスマートでデータに裏打ちされた決断をサポートするArchitectの機能のほんの一部です。優れた設計は想定通りの一定のパフォーマンスを生み出しますし、大切なITの予算適切な利用を実現します。実際のデータに基づき、推測をすて、理想の環境を生み出しましょう。
記事担当者: マーケティング本部 三好哲生 (@pernixdata_netw)
