本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はData acceleration, more than just a pretty flash deviceで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
時々もらう問い合わせとして、ネットワーク上にフラッシュアプライアンスを配置して、それによってデータを高速化しようとすることに意味があるか？というものがあります。このフラッシュプールはインフラに追加する際にワークロードの変更を一切伴いません。フィールドのストレージ担当のJustin Warren氏は最近同じ結論に至りました。私の意見はこの構造を用いた結果は、最善のものではなく、場当たり的で、全てのリソースを活用することができない上に、必要なときに必要なところへパフォーマンスを提供するための進化したアーキテクチャへ成長しようとする多くの可能性を失ってしまうということです。ソフトウェアがデータの高速化のために果たす役割とどうしてソフトウェアが必要なのかをこの記事で詳しく見て行きましょう。
データの高速化は問題の解決のために単に早いものを追加するだけに留まりません。高速化要素そのものを単に追加するだけでは、すぐにパフォーマンスの天井にぶち当たってしまいます。仮想データセンターは非常にダイナミックです。仮想化は、もはや少数のサーバのワークロードを統合するだけではありません。ビジネス戦略にITが寄り添わせるためのものに急速に変貌しつつあります。仮想化は企業が新しいデマンドにすぐさま対応することを可能にします。迅速に顧客の要求に対応した環境を展開することを可能にします。それでいて、限りある利用可能なリソースを統制しながら分配することができるのです。
さらに、これを適切に行うために、リソースを完全にコントロール出来る必要があります。リソースを可能な限り効率的に管理・利用するためには一元的にリソースのスタックをコントロールしながら、柔軟に選択可能にしておく必要があります。追加リソースの追加には、また別のコントロールが必要です。別のリソースの管理方法、別のリソース分配方法を行うことで、効率性が失われ、通常は複雑化してしまいます。管理のための時間を最小化しながら、人間が操作する部分を減らしていくことが根本となります。これには2つの別々のシステム ー ハイパーバイザーカーネル内とハイパーバイザーの外 ー のシステムを利用している場合、これらを1つのポリシーベースの管理プロセスに統合することはできません。マニュアルの作業が必要で、つまりは展開や迅速なサービス提供のためのリードタイムが必要です。ヒューマンリソースの都合や、専門性の度合い、複数のシステムへのアクセスの権限などを考えてみてください。自動化とポリシーベースの管理を行うことで、これらの不確実性や依存性を回避することが出来、オーケストレーションによる管理の自動化はいっそう流行にのることでしょう。業界の中ではAPIやフレームワークをオープンにするべきだという議論が活発化していますが、残念ながら、まだ要望に答えるまでにはなっていないのが実情です。
コントロール、統合、そして自動化は非常に重要な要素の上に成り立っています、それは認識、我々の場合、仮想マシンのリソースの認識です。誰がリソースを必要としているのかを知らなければ、適切なリソースの配分は行えません。必要としているのは誰か、何を必要としているか、他のワークロードと比べての優先順位を知る必要があります。ワークロードがESXiホストから移動した際、通常は仮想マシンはそのすべてのリソースが制限を受けなくなり、デマンドと利用率だけのランダムなストリームという状態になります。多くの場合、リソースをしっかりと分割し、直接上位リソースに専属で割り当てることで解決しようとします。例えばディスクグループが特定のクラスタに割り当てられた場合、もしくはホストとデータストア間で利用可能なリソースを開放するために、仮想マシンを別のデータストアへ移動させるなどです。しかしながら、実際にはこうした作業は少しの時間稼ぎにしかなりません。リソースを必要以上に利用し、アーキテクチャ内に、動的にリソースを分散するアルゴリズムから独立した静的なものを作成してしまうのです。簡潔に言うと、拡張性に乏しく、ITサービスの提供の成熟を妨げてしまうのです。
ということで、目指すべきはアプリケーションに限りなく近いところに有効な機能(インテリジェンス)を保持しつづけるということです。ソフトウェアのインテリジェンスの本来の力を活用します。ワークロードのリソースを認識し続けることで、いつでも必要とされた際に、適切な優先順位とリソースの稼働状況に応じてリソースを配布することが出来ます。仮想マシンのリソースを認識することでITサービスにRPOやリソースの可用性などのポリシーを割り当てることが可能になります。利用可能な適切なプロファイルを選択するだけで良いのです。これがソフトウェアの本来の力です。ソフトウェアは利用可能なリソースをもっとも効率的な方法で利用できるようにします。この例を私はFVPの最初の一年で見てきました。より優れた、よりインテリジェントな方法で仮想マシンのワークロードをフラッシュリソースに見せることによってフラッシュデバイスのパフォーマンスがより向上するのです。仮想マシンのリソースを認識することで、リソースをコントロールし、全てを同じコントロール元に解析することで、よりハードウェアのパフォーマンスを引き出しているのです。
他の業界でもソフトウェアの力を見つけることが可能です。もしMotoGPのレーシングチームのいずれかのソフトウェアエンジニアと話す機会があったとしたら、彼の管理下の環境とソフトウェアで何ができるか聞いてみてください。特定のアプリケーション(レーストラック)のワークロードを理解することで、彼らはサスペンションシステム、スロットルコントロール、レーストラック上のバイクの姿勢とエンジンの振る舞い、次のコーナーで最も最適なバイクのセッティングなどをコントロールできるようになるでしょう。それはひとつのコーナーについてだけではありません。どんなコーナーが次に出てきて、それがバイクにどのように影響を与え、それに同対応すべきかも知ることが出来ます。それをレース内で利用できるかは別の議論です、ですが、本当のソフトウェアの力、ワークロード解析、コントロールしているシステムの状況認識を完全に見せつけてくれます。
こうした解析とリソース分配の力はあなたがまさにアプリケーションに対して望んでいるものです。そして、最上の方法は仮想マシンのリソースをしっかりと認識し続けることです。解析を利用し、リソース分配管理を行い、先進的なQoSによってワークロードの要求に合わせて高いパフォーマンスを利用可能とします。このように行うことで、クリック数や設定数、管理しなくてはならないシステム数を最小限にすることが出来、これは私の信念ですが、ハイパーバイザーのカーネルの中でしかこれは行えません。カーネル内では複数のスケジューラーが協調して動作しています。そして仮想マシンのリソースをリソースの上位から、そしてワークロードに最も近いところから継続的に知ることができるのです。
カーネル外に高速化リソースを追加したとしても、この能力を持たせることは出来ず、特定のケース毎に、どの問題を解決すべきなのか思慮することになります。vSphere DRSのメンテナンスモードはシームレスにワークロードを移行させます、他のクラスタ内のホストに対しては透過的です。あらゆる面で影響を与えません。高速化リソースをITサービスのレベルに影響を与えずにインストールすることが可能なのです。もしも最適なIT健康法を学ぶのであれば、ESXiホストにデバイスを追加する前に絶対(これは絶対だと賭けても良いです)ホストをメンテナンスモードにすることが推奨です。これによって、先に述べたのと同様のホストとワークロード移行が行われます。
