本ブログエントリーはPernixData社のテクノロジーエバンジェリストであるFrank Denneman氏のブログの翻訳版です。
本記事の原文はVM-granular Flash Resource Management and Sizing in FVPで閲覧可能です。
ネットワールドのPernixDataに関する情報はこちら。
FVPクラスタをセットアップした後には、高速化のために仮想マシンもしくはデータストアが選択できるようになります。待ってください・・・。データストアのパフォーマンスを高速化できる？違います。実際にはデータストア自身ではなく、そこに格納されている仮想マシンの高速化です。FVPの高速化のレベルを復習し、どのように新しいパフォーマンス層がそれに影響しているか理解していきましょう。
仮想マシンが高速化の最小の単位
高速化のために選択できる最小の単位は仮想マシンです。FVPは仮想マシン単位での高速化を実行します。これは仮想マシンが生成するI/OをFVPレイヤが処理するということです。仮想マシンが単一の仮想ディスクを持つか、複数の仮想ディスクを持つかは関係ありません。また、どこにディスクが格納されているかも関係ありません。ディスクが同じデータストアにあっても良いですし、複数のデータストアにまたがっていてもいいのです。とてもシンプルです。仮想マシンをフラッシュクラスタに追加した瞬間に、FVPは魔法をかけるのです。
FVPでの動的なフラッシュリソース管理
最近私が聞かれた質問は、もしも仮想マシンのサブセットである仮想ディスク毎に高速化ができるとしたら、もっときめ細やかな設定ができるんじゃないか？というものでした。私は、実際にそうしてみたことがないのではないか？つまりアプリケーションのユーザーはそういうことを言わないだろうと考えています。そもそも仮想マシンが生成するアプリケーションに関与するI/Oのうち、どのI/Oがオペレーティング・システムのルーチン的なロギング、ハートビート、その他一般的な手順なものであるかを本当に見分けるのは非常に難しいことです。適切に全ての仮想マシンについてこれをやっていくということは非常に巨大な運用でのオーバーヘッドになります。
FVPのリソースマネージャーはフラッシュ領域のサイジングを実施します。FVPはフラッシュデバイスのスペースの利用状況をそれぞれの高速化された仮想マシンに照らし合わせながら管理します。先に述べたようにオペレーティング・システムの振る舞いと仮想マシンの振る舞いを理解するのは難しいため、FVPがかわりにこれを実行するのです。それだけではありません。アプリケーションはその利用のライフサイクルの最中に、リソースの利用状況がかわります。大抵の場合、最初の設計時と検証の段階ではリソースの利用が増大しますが、リリースのタイミングで急速に減衰します。アプリケーションの導入初期はリソースの消費が増大する傾向にありますが、新しいヴァージョンや新しいアプリケーションが登場すると、ゆっくりと減衰していきます。あなたは仮想マシンが今どのフェーズにあるのかということを完全に理解できていますか？仮想インフラストラクチャ内のすべての仮想マシンについて知っていますか？新しいアプリケーションが登場した際に、パイプライン上に残されているリソースの消費を仮想マシンに割り当てることができるでしょうか？
アプリケーションのフラッシュ上のキャッシュのサイズを効率的に、適切に決定し、フラッシュリソースを余分に保持することなく、他のアプリケーションへ渡さずに保つことはできるのでしょうか？私が思うにPeter R. Drucker(ドラッカー)が最高のことを言っています。
There is nothing so useless as doing efficiently that which should not be done at all.(まったく効率的にやるべきでないことを効率的にやろうとすることは意味のないことだ。)
つまり、仮想マシン1つのための静的なフラッシュ領域をマニュアル作業で構成していくということは、管理者にとって不可能な要求になってしまうのです。FVPを利用している場合、フラッシュのキャッシュのサイズをマニュアルで指定する必要はありません。リソースマネージャーがその任に当たり、フラッシュのスペースの量を仮想マシンが効率的にフラッシュデバイスが使えるようにという観点と、複数の仮想マシンの相対的な優先順位という観点から自動的に決めてくれるのです。
データストアの追加
「Add datastore」オプションを選択することで、そのデータストア上で動作している仮想マシンの全てを選択することが可能で、フラッシュクラスタへ動的に追加をすることが可能です。これの良い所はデータストアに展開される全ての新しい仮想マシンが自動的にFVPクラスタへ追加されていくということです。SLAを保証するような環境や、階層化されたサービス構造を持っているような場合、これは大きく時間を短縮することにつながります。例えば、階層0番の環境では仮想マシンはWrite-Backポリシーとして構成されるのです。
Storage DRS
データストアクラスタはこのような階層化されたサービスレイヤを構築するのにとても便利です。FVPレイヤで同じWrite-Policyに設定された複数のデータストアをデータストアクラスタとしてグルーピングすることを推奨しています。これはデータストアクラスタが「同じレベルのサービスを提供する」データストアをクラスタ化することを推奨するということと合致します。
vCloud
Michael Webster氏はFVPをvCloud Directorと一緒に動かそうとしています、私はアイディアが大好きです。provider vDC群は基本的に階層化されたサービスをベースにしているのでこれは自然な話です。FVPはStorage DRSでのストレージのパフォーマンスを保証するの補助できます。残念ながらAPIがクローズな構造になっているため、我々はFVPをvCloud DirectorのUIへ追加することは出来ませんが、これはFVPがインフラストラクチャのレベルで動作するため問題にはなりません。
例えば、Tier-0のProvider vDCを作る場合、可能な限りのサービスレベルを提供したいわけです。最も早いサーバで構成されたDRSクラスタをコンピューティングパフォーマンスのために選択します。ストレージのためにはvSphere UIを用いてFVPで高速化したデータストアをクラスタ化したデータストアクラスタを選択すればよいわけです。
利用者が新しいvAppを作成した際には、vCloud Directorはデータストアクラスタを選択し、仮想マシンの初期配置をStorage DRSの初期配置アルゴリズムに「アウトソース」します。この時、全てのデータストアがFVPによって「高速化」されていれば新しく作成される全ての仮想マシンは自動的にFVPクラスタに配置され、加速されるのです。
前に述べたように、データストアを高速化した場合、データストア毎の標準の高速化ポリシーを設定でき、すべての仮想マシンはその設定を継承するのです。もしデータストアの標準でWrite-ThroughのWrite-Policyで高速化されていた場合、すべての新しい仮想マシンはWrite-Throughポリシーとして構成されます。もし一つづつ指示を出して自動化したいのならば、我々はFVPのポリシーエンジンをFVP PowerShellインターフェイスでふっくできるようにして提供しているため、仮想マシン毎のWrite-Policyをそこで設定することも可能です。
標準の高速化ポリシーをサービスの差別化のキーとして利用することも可能です(階層1ではWrite-Through、階層0ではWrite-Back)。運用の面から、仮想マシンが動きまわってしまったとしてもデータストアクラスタ内のデータストアがすべて高速化されていればパフォーマンスへの影響はありません。確実にしておいていただきたいのは新しくデータストアを追加した際に、必ずデータストアクラスタ内のデータストアをすべて同じように高速化しておくことです。こちらも同様にFVPのPowerShellコマンドで簡単に自動化することが出来ます。
FVPとStorage DRSについてお話して、やや脱線気味ですが、高速化のモードに戻りたいと思います。
仮想マシンベースのWrite-PolicyとデータストアのWrite-Policy
「仮想マシンの追加」と「データストアの追加」というレベルでポリシーが定義できます。仮想マシンレベルでもデータストアレベルでも両方で設定が可能ですが、仮想マシンレベルのWrite-PolicyはデータストアレベルのWrite-Policyを上書きします。これは仮想マシンがWrite-Throughポリシーで構成されており、データストアがWrite-Backポリシーで構成されている場合、仮想マシンはWrite-Throughポリシーになってしまうということです。
