本ブログエントリーはPernixData社のチーフテクノロジストであるFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。
本記事の原文はPerformance isolation by aligning storage with compute resource management domainsで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。本ブログのPernixDataの記事のまとめはこちら。
仮想化データセンタ(もしくはクラウド)の設計において最も難しい課題はパフォーマンスの隔離です。仮想マシン内で動作しているアプリケーションは適切に動作出来るだけのリソース量を期待しますし、要求もします。とある仮想マシンのリソースの消費は他の仮想マシンのパフォーマンスに影響しないというのが理想的な状況です。
動的なリソース管理をあらゆる意味で失うことなく、特定の仮想マシンにリソースを割り当てるということが課題なのです。コンピューティングの予約などのマイクロマネージメントのツールを利用することはクラスタレベルの動的さへ影響します。これは様々なリソース管理のドメインを超えて設定されてしまうからです。ある仮想マシンのコンピューティング(CPUとメモリ)の利用は単一ホスト上の利用可能なコンピューティングリソースのプールに影響を及ぼします。ストレージリソースのドメインはクラスタや(仮想)データセンタにまたがります。つまり、ある仮想マシンのストレージに対する活動は他のホストで動作している仮想マシンにまで波及効果を及ぼしてしまうということです。必要な共有ストレージのリソースを提供しようとすると、別の形での管理、設計のアプローチが必要です。その後、コンピューティングリソースを提供すべきなのです。
ストレージの設計をする場合、ストレージ装置のリソースを可能な限り隔離しようとします。しかし、ストレージ装置は最低1つのリソースのドメインとして残ってしまい、更に大きなvSphereクラスタや仮想化データセンタ全体という構造体に影響を与えてしまいます。従来我々はリソース管理のツールを利用することなく、その上位レイヤの動的な、変わりゆくアプリケーションからの要求に対応してきました。これはストレージシステムが単一、もしくは複数のvSphereクラスタ内で動作している仮想マシンのワークロードの総和に対応できなければならないということを意味しています。
昔から｢生まれてから、死ぬまで全てを受け入れてくれるバケツ｣を設定するというやり方が使われてきました。設計者としてこれに何度も立ち会ってきています。しかし、想定される限り最高のパフォーマンスのピークに対応可能なストレージ装置が全てのライフサイクルの間必要になってくるのです。うまく動くことを願っています。そうでなければCFOやCIOのオフィスに何度も赴き、言い訳のための時間をスケジュールしたり、ストレージシステムのリプレースの前に以前購入したストレージ装置のアップグレードや増設をお願いしなくてはならなくなります。
アプリケーションが変わり、アーキテクチャが変わり、要求が変わり、ほとんどすべての顧客の期待も変わっています。近年のデータセンタはリソース管理のドメインが配置できるアーキテクチャが求められています。成長についても同じような計画が求められます。我々がプライベートデータセンタ、プライベートクラウドという時には、ある意味で、(一貫した)サービスレベル管理を期待しているのです。新しい仮想マシンが展開された時には以下の2つが満たされていなければなりません。
- 既存のインフラストラクチャは求められる(支払っているだけの)リソースを提供できる
- 既存のインフラストラクチャは新しいワークロードについて、今までに使っていた仮想マシンのサービスレベルに影響を与えずに吸収ができる
簡単に拡張できる ー拡張性(スケーラビリティ)ーは動的なリソースとともになくてはなりません。ストレージ管理をコンピューティングの管理に依存してしまうことはストレージのキャパシティとストレージのパフォーマンスの食い違いを再認識することになります。ストレージのキャパシティは成長しますが、大抵は一定の割合で成長します。減ることはほとんどありません。更に重要な事は仮想マシンはストレージのキャパシティをアプリケーションの活動がどうであれライフサイクル全般にわたって消費します。ストレージパフォーマンスは仮想マシンが活動している時にしか必要とされません。つまり、ストレージのキャパシティ管理はストレージパフォーマンスとは異なる動きをしているのです。仮想マシンの活動がコンピューティングとストレージのパフォーマンスを消費すると、これらのリソース管理ドメインが別々に割り当てられます。ですから、この2つは同じ拡張性のモデルが必要なのです。
拡張性は必ずしも、アドホックな設計になるということではありません。期待されているワークロードに合わせていけるアーキテクチャであればよいのです。必要とされる適応性のレベルで拡張できるようなアーキテクチャです。ストレージパフォーマンスの管理ドメインをコンピューティングの管理ドメインに寄り添わせることで、よりよいパフォーマンスの隔離のモデルを作ることができるのです。
これのとても良い例がサーバサイドメディアを利用してストレージのパフォーマンスを提供することです。これは一石三鳥です。拡張性、パフォーマンスの隔離、そして最近のデータセンタテクノロジーの最先端を活用することができます。数多くのサーバサイドソリューションがありますが、私はPernixDataのチーフテクノロジストですから、PernixData FVPをこの検証に使っています。
ご理解しやすいように、単純な検証にしました。この検証では3つの仮想マシンがストレージ装置のパフォーマンスとキャパシティの双方を消費します。それぞれの仮想マシンは別々のホストで動作しています。ストレージ装置はだいたい30,000～40,000 IOPSで動作しています。ご注目いただきたいタイミングは10:10 am、10:17 am、10.28 am そして 10:34 amです。表示のとおり、負荷は一定的で変わっていません。
上で列挙したタイミングで仮想マシンの電源をOn/Offしています。10:03～10:10の間、仮想マシンは30,000IOPSを消費しています。しかし、次の仮想マシンの電源がOnになるとパフォーマンスは半分になっています。10:17に3番目の仮想マシンがパワーオンされ、10:28にパワー・オフされるまで負荷をかけています。即座にストレージ装置は動作している仮想マシンに対して、利用可能なパフォーマンスを再配置しています。10:34に2つ目の仮想マシンが停止し、再び最初の仮想マシンがすべてのパフォーマンスを独り占めする状態に戻っています。
2番めの仮想マシンのスクリーンショットも同じ傾向を示しています。30K IOPSまでは出ていませんが、3番目の仮想マシンが起動してくるまでは19K IOPSほど利用できていました。
今回の検証は定常的な負荷ですが、共有リソースを利用している際の他の仮想マシンの波及効果をうまく説明しています。同じようなことはバーストするOLTPのワークロードを仮想マシン内で動作させている際にも起こります。グラフの左側は1台の仮想マシンでワークロードを動作させていますが、グラフの右側は3つの仮想マシンで同じワークロードを時間差で動作させて負荷が何度もピークに達するようにしています。
パフォーマンスは適切なワークロードの分散が行われていたとしても、ストレージシステムの内部動作によってパフォーマンスが低下します(キャッシュオフロード、データパス管理、データの受取、I/O完了通知、など)。
サーバサイドリソースを利用してストレージパフォーマンスを提供する場合、それはホストレベルのリソース管理ドメインにもたらされます。スケールアウトはホストレベルでなされ、あるホストで動作している仮想マシンは他のホストで動作している仮想マシンへは影響しません。サーバサイドメディアを利用することで、共有のキュー(待ち行列)、ストレージエリアネットワークコンポーネント、そして、絶対的な物理の法則(距離がある=遅い)ということも避けられます。
同じ検証内容で、最初の仮想マシンはサーバサイドメディアのパフォーマンスを利用できるようにしました。今回はIntel DC P3700のNVMeカードを利用しています。仮想マシンはアプリケーションが生成するIOPS全体をストレージから消費します。注目いただきたいのはボトルネックがストレージから取り除かれているということです。これまではストレージ装置が生成可能なだけのIOPSに制限されていたのです。これは大きな違いです!今日のフラッシュテクノロジーによって、ほとんどのIntel DC P3700のようなサーバサイドリソースはほとんどのミドルレンジのストレージ装置と互角に渡り合い、圧倒することができます。それに加えて、ワークロードに非常に近いことから、非常に一貫したパフォーマンス(レイテンシ)を提供することが可能です。今回の場合、アプリケーションは70,000IOPSよりちょっと大きいIOPSを要求しています。2:29PMに面白いことが起こっています。2番目の仮想マシンが別のホストで動作を開始しても、同じパフォーマンスを維持しています。つまり、他のホストで動作しているワークロードから、完全に隔離されたのです。
2番目の仮想マシンも必要なリソースを利用することができています。クラスタ内の他のワークロードに影響をあたえることなく、この仮想マシンは最大で90,000 IOPSを生成できています。
サーバサイドメディアのリソースがそれ自身でリソース管理のドメインをもち動作するので、クラスタは継続的にパフォーマンスを拡張できます。FVPは耐障害性やモビリティを提供するためにクラスタ機能をもちいますから、このパフォーマンスの隔離は他の重要なストレージ機能にくらべ言及されることがすくなくなっています。他の重要なストレージ機能については今回の記事の範囲を超えてしまいます。
素晴らしい点は、パフォーマンスがスケールできているということです。あたらしい仮想マシンが展開されても、それらは他のワークロードからは隔離されています。既存のアプリケーションのSLAには影響を与えないのです。既存のシステムが導入されてくるワークロードに十分なリソースを割り当てられなかった場合、スケールアップする、つまりリソースをホストに追加するか、更にクラスタにホストを追加してスケールアウトすることができます。サーバサイドメディアを追加することで、ストレージパフォーマンスの能力がコンピューティングのリソースと同じ様に向上します。活動中の要求に対して美しく寄り添うのです。フラッシュ技術の今日の先進性によって、もしくはRAMを高速化リソースとして使うことによって、パフォーマンスは今日ハイパーバイザーにサポートされている、利用可能な最も新しいモノを活用してパフォーマンスを向上させることが可能です。サーバサイドハードウェアの新しいものへの対応はストレージハードウェアの何倍も早いのです。
このアーキテクチャは仮想化データセンタ(クラウド)でのパフォーマンスの隔離を実現します。そして、ストレージシステムへのワークロードのオフロードを抑えることができます。つまり、これはキャパシティに捕まってしまっていた(GBあたりのIOPSの制限)状態から自由になれるということです。そして、よりよい拡張していくキャパシティ管理のモデルを提供します。多くのFVPの顧客はRAIDレベルを変更するようになってきています。それはパフォーマンスによって制限を受けることがなくなり、もっとキャパシティを経済的に利用するモデルへと移行できるからです。ストレージ装置の設計はキャパシティ主導になっているからなのです。
